โหลดรูปภาพได้เร็วขึ้นด้วยการแสดงตัวอย่างรูปภาพที่ฝังตัว

การแสดงตัวอย่างรูปภาพคุณภาพต่ำ (LQIP) และ SQIP ที่แปรผันตาม SVG เป็นสองเทคนิคหลักสำหรับการโหลดรูปภาพแบบ Lazy Loading สิ่งที่ทั้งสองมีเหมือนกันคือคุณต้องสร้างภาพตัวอย่างคุณภาพต่ำก่อน ซึ่งจะแสดงเป็นภาพเบลอและแทนที่ด้วยภาพต้นฉบับในภายหลัง จะเกิดอะไรขึ้นถ้าคุณสามารถนำเสนอภาพตัวอย่างแก่ผู้เยี่ยมชมเว็บไซต์โดยไม่ต้องโหลดข้อมูลเพิ่มเติม

ไฟล์ JPEG ซึ่งใช้การโหลดแบบ Lazy Loading เป็นส่วนใหญ่ มีความเป็นไปได้ตามข้อกำหนดในการจัดเก็บข้อมูลที่มีอยู่ในไฟล์ในลักษณะที่หยาบก่อนแล้วจึงแสดงเนื้อหาภาพที่มีรายละเอียด แทนที่จะให้รูปภาพสร้างขึ้นจากบนลงล่างระหว่างการโหลด (โหมดฐาน) สามารถแสดงภาพที่เบลอได้อย่างรวดเร็ว ซึ่งจะค่อยๆ คมชัดขึ้นและคมชัดขึ้น (โหมดโปรเกรสซีฟ)

นอกเหนือจากประสบการณ์การใช้งานที่ดีขึ้นจากลักษณะที่ปรากฏที่แสดงผลได้เร็วกว่า JPEG แบบโปรเกรสซีฟมักจะมีขนาดเล็กกว่าคู่ที่เข้ารหัสแบบพื้นฐาน สำหรับไฟล์ที่มีขนาดใหญ่กว่า 10 kB มีความเป็นไปได้ 94 เปอร์เซ็นต์ของภาพที่เล็กกว่าเมื่อใช้โหมดโปรเกรสซีฟตาม Stoyan Stefanov ของทีมพัฒนา Yahoo

หากเว็บไซต์ของคุณประกอบด้วย JPEG จำนวนมาก คุณจะสังเกตเห็นว่าแม้แต่ JPEG แบบโปรเกรสซีฟก็ยังโหลดทีละรายการ เนื่องจากเบราว์เซอร์สมัยใหม่อนุญาตให้เชื่อมต่อโดเมนได้พร้อมกันเพียงหกเครื่องเท่านั้น JPEG แบบโปรเกรสซีฟเพียงอย่างเดียวจึงไม่ใช่วิธีแก้ปัญหาเพื่อให้ผู้ใช้ได้รับความประทับใจในหน้าที่เร็วที่สุด ในกรณีที่เลวร้ายที่สุด เบราว์เซอร์จะโหลดรูปภาพทั้งหมดก่อนที่จะเริ่มโหลดรูปภาพถัดไป

แนวคิดที่นำเสนอในที่นี้คือการโหลด JPEG แบบโปรเกรสซีฟจากเซิร์ฟเวอร์ที่มีจำนวนไบต์จำนวนมากเท่านั้น คุณจึงสามารถสร้างความประทับใจให้กับเนื้อหาภาพได้อย่างรวดเร็ว ต่อมา ในเวลาที่กำหนดโดยเรา (เช่น เมื่อโหลดภาพตัวอย่างทั้งหมดในวิวพอร์ตปัจจุบันแล้ว) ส่วนที่เหลือของภาพควรโหลดโดยไม่ต้องร้องขอส่วนที่ร้องขอให้แสดงตัวอย่างอีกครั้ง

ขออภัย คุณไม่สามารถบอกแท็ก img ในแอตทริบิวต์ว่าควรโหลดรูปภาพเท่าใดในเวลาใด อย่างไรก็ตาม ด้วย Ajax สิ่งนี้เป็นไปได้ โดยมีเงื่อนไขว่าเซิร์ฟเวอร์ที่ส่งอิมเมจรองรับคำขอช่วง HTTP

เมื่อใช้คำขอช่วง HTTP ไคลเอ็นต์สามารถแจ้งเซิร์ฟเวอร์ในส่วนหัวคำขอ HTTP ว่าไบต์ของไฟล์ที่ร้องขอจะมีอยู่ในการตอบสนอง HTTP คุณลักษณะนี้ ซึ่งได้รับการสนับสนุนโดยเซิร์ฟเวอร์ขนาดใหญ่แต่ละแห่ง (Apache, IIS, nginx) ส่วนใหญ่จะใช้สำหรับการเล่นวิดีโอ หากผู้ใช้ข้ามไปที่ส่วนท้ายของวิดีโอ การโหลดวิดีโอทั้งหมดจะไม่มีประสิทธิภาพมากนัก ก่อนที่ผู้ใช้จะสามารถดูส่วนที่ต้องการได้ในที่สุด ดังนั้นเซิร์ฟเวอร์จะขอข้อมูลวิดีโอในช่วงเวลาที่ผู้ใช้ร้องขอเท่านั้น เพื่อให้ผู้ใช้สามารถดูวิดีโอได้โดยเร็วที่สุด

ตอนนี้เราเผชิญกับความท้าทายสามประการต่อไปนี้:

1. การสร้าง Progressive JPEG
2. กำหนด Byte Offset ที่คำขอช่วง HTTP แรกต้องโหลดภาพตัวอย่าง
3. การสร้างโค้ด JavaScript ส่วนหน้า

1. การสร้าง Progressive JPEG

JPEG แบบโปรเกรสซีฟประกอบด้วยส่วนการสแกนที่เรียกว่าหลายส่วน ซึ่งแต่ละส่วนประกอบด้วยส่วนของภาพสุดท้าย การสแกนครั้งแรกจะแสดงภาพคร่าวๆ เท่านั้น ในขณะที่ภาพที่ตามมาภายหลังในไฟล์จะเพิ่มข้อมูลรายละเอียดมากขึ้นเรื่อยๆ ให้กับข้อมูลที่โหลดไปแล้ว และในที่สุดก็สร้างรูปลักษณ์สุดท้าย

โปรแกรมที่สร้าง JPEG จะพิจารณาว่าการสแกนแต่ละรายการมีลักษณะอย่างไร ในโปรแกรมบรรทัดคำสั่ง เช่น cjpeg จากโปรเจ็กต์ mozjpeg คุณสามารถกำหนดได้ว่าการสแกนเหล่านี้มีข้อมูลที่ใดบ้าง อย่างไรก็ตาม สิ่งนี้ต้องการความรู้เชิงลึกมากขึ้น ซึ่งจะเกินขอบเขตของบทความนี้ สำหรับสิ่งนี้ ฉันต้องการอ้างถึงบทความของฉัน "Finally Understanding JPG" ซึ่งสอนพื้นฐานของการบีบอัด JPEG พารามิเตอร์ที่แน่นอนที่ต้องส่งผ่านไปยังโปรแกรมในสคริปต์สแกนมีอธิบายไว้ในวิซาร์ด.txt ของโปรเจ็กต์ mozjpeg ในความเห็นของฉัน พารามิเตอร์ของสคริปต์การสแกน (การสแกนเจ็ดครั้ง) ที่ใช้โดย mozjpeg โดยค่าเริ่มต้นนั้นเป็นการประนีประนอมที่ดีระหว่างโครงสร้างโปรเกรสซีฟที่รวดเร็วและขนาดไฟล์ ดังนั้นจึงสามารถนำมาใช้ได้

ในการแปลง JPEG เริ่มต้นเป็น JPEG แบบโปรเกรสซีฟ เราใช้ jpegtran จากโปรเจ็กต์ mozjpeg นี่คือเครื่องมือในการเปลี่ยนแปลงไฟล์ JPEG ที่มีอยู่โดยไม่สูญเสียข้อมูล บิลด์ที่คอมไพล์ล่วงหน้าสำหรับ Windows และ Linux มีอยู่ที่นี่: https://mozjpeg.codelove.de/binaries.html หากคุณต้องการเล่นอย่างปลอดภัยด้วยเหตุผลด้านความปลอดภัย คุณควรสร้างมันขึ้นมาเอง

จากบรรทัดคำสั่ง ตอนนี้เราสร้าง Progressive JPEG:

 $ jpegtran input.jpg > progressive.jpg

ความจริงที่ว่าเราต้องการสร้าง JPEG แบบโปรเกรสซีฟนั้นถูกสันนิษฐานโดย jpegtran และไม่จำเป็นต้องระบุอย่างชัดเจน ข้อมูลภาพจะไม่มีการเปลี่ยนแปลงแต่อย่างใด เฉพาะการจัดเรียงข้อมูลภาพภายในไฟล์เท่านั้นที่เปลี่ยนแปลง

ควรลบข้อมูลเมตาที่ไม่เกี่ยวข้องกับรูปลักษณ์ของรูปภาพ (เช่น ข้อมูล Exif, IPTC หรือ XMP) ออกจาก JPEG เนื่องจากเซ็กเมนต์ที่เกี่ยวข้องสามารถอ่านได้โดยตัวถอดรหัสข้อมูลเมตาเท่านั้นหากอยู่ก่อนหน้าเนื้อหารูปภาพ เนื่องจากเราไม่สามารถย้ายข้อมูลเหล่านี้ไปไว้ด้านหลังข้อมูลภาพในไฟล์ได้ ด้วยเหตุนี้ จึงส่งภาพดังกล่าวพร้อมกับภาพตัวอย่างและขยายคำขอแรกตามนั้น ด้วยโปรแกรมบรรทัดคำสั่ง exiftool คุณสามารถลบข้อมูลเมตาเหล่านี้ได้อย่างง่ายดาย:

 $ exiftool -all= progressive.jpg

หากคุณไม่ต้องการใช้เครื่องมือบรรทัดคำสั่ง คุณยังสามารถใช้บริการบีบอัดออนไลน์ compress-or-die.com เพื่อสร้าง JPEG แบบโปรเกรสซีฟโดยไม่มีเมตาดาต้า

2. กำหนด Byte Offset ที่คำขอช่วง HTTP แรกต้องโหลดภาพตัวอย่าง

ไฟล์ JPEG ถูกแบ่งออกเป็นส่วนต่างๆ โดยแต่ละส่วนจะมีส่วนประกอบต่างกัน (ข้อมูลรูปภาพ, ข้อมูลเมตา เช่น IPTC, Exif และ XMP, โปรไฟล์สีที่ฝังไว้, ตารางควอนไทซ์ เป็นต้น) แต่ละเซ็กเมนต์เหล่านี้เริ่มต้นด้วยเครื่องหมายที่นำมาใช้โดยไบต์ FF เลขฐานสิบหก ตามด้วยไบต์ที่ระบุประเภทของเซ็กเมนต์ ตัวอย่างเช่น D8 เติมเครื่องหมายให้กับเครื่องหมาย SOI FF D8 (จุดเริ่มต้นของรูปภาพ) โดยที่ไฟล์ JPEG แต่ละไฟล์เริ่มต้น

การเริ่มต้นการสแกนแต่ละครั้งจะมีเครื่องหมาย SOS (เริ่มการสแกน FF DA เลขฐานสิบหก) เนื่องจากข้อมูลที่อยู่เบื้องหลังตัวทำเครื่องหมาย SOS มีการเข้ารหัสเอนโทรปี (JPEG ใช้การเข้ารหัส Huffman) มีอีกส่วนที่มีตาราง Huffman (DHT, เลขฐานสิบหก FF C4 ) ที่จำเป็นสำหรับการถอดรหัสก่อนส่วน SOS พื้นที่ที่เราสนใจภายในไฟล์ JPEG แบบโปรเกรสซีฟประกอบด้วยการสลับตาราง/เซ็กเมนต์ข้อมูลการสแกนของ Huffman ดังนั้น หากเราต้องการแสดงการสแกนภาพคร่าวๆ ครั้งแรก เราต้องร้องขอไบต์ทั้งหมดจนถึงการเกิดขึ้นครั้งที่สองของเซ็กเมนต์ DHT (เลขฐานสิบหก FF C4 ) จากเซิร์ฟเวอร์

ใน PHP เราสามารถใช้โค้ดต่อไปนี้เพื่ออ่านจำนวนไบต์ที่จำเป็นสำหรับการสแกนทั้งหมดในอาร์เรย์:

 <?php $img = "progressive.jpg"; $jpgdata = file_get_contents($img); $positions = []; $offset = 0; while ($pos = strpos($jpgdata, "\xFF\xC4", $offset)) { $positions[] = $pos+2; $offset = $pos+2; }

เราต้องเพิ่มค่าของสองในตำแหน่งที่พบ เนื่องจากเบราว์เซอร์จะแสดงเฉพาะแถวสุดท้ายของภาพตัวอย่างเมื่อพบเครื่องหมายใหม่ (ซึ่งประกอบด้วยสองไบต์ตามที่กล่าวไว้)

เนื่องจากเราสนใจภาพตัวอย่างภาพแรกในตัวอย่างนี้ เราจึงพบตำแหน่งที่ถูกต้องใน $positions[1] ซึ่งเราต้องขอไฟล์ผ่านคำขอช่วง HTTP เพื่อขอภาพที่มีความละเอียดดีกว่า เราสามารถใช้ตำแหน่งภายหลังในอาร์เรย์ได้ เช่น $positions[3]

3. การสร้างโค้ด JavaScript ส่วนหน้า

ก่อนอื่น เรากำหนดแท็ก img ซึ่งเราให้ตำแหน่งไบต์ที่ประเมินเพียง:

 <img data-src="progressive.jpg" data-bytes="<?= $positions[1] ?>">

ตามปกติของไลบรารีโหลดแบบสันหลังยาว เราไม่ได้กำหนดแอตทริบิวต์ src โดยตรง เพื่อให้เบราว์เซอร์ไม่เริ่มขอรูปภาพจากเซิร์ฟเวอร์ทันทีเมื่อแยกวิเคราะห์โค้ด HTML

ด้วยโค้ด JavaScript ต่อไปนี้ เราโหลดภาพตัวอย่าง:

 var $img = document.querySelector("img[data-src]"); var URL = window.URL || window.webkitURL; var xhr = new XMLHttpRequest(); xhr.onload = function(){ if (this.status === 206){ $img.src_part = this.response; $img.src = URL.createObjectURL(this.response); } } xhr.open('GET', $img.getAttribute('data-src')); xhr.setRequestHeader("Range", "bytes=0-" + $img.getAttribute('data-bytes')); xhr.responseType = 'blob'; xhr.send();

รหัสนี้สร้างคำขอ Ajax ที่บอกให้เซิร์ฟเวอร์ในส่วนหัวของช่วง HTTP ส่งคืนไฟล์จากจุดเริ่มต้นไปยังตำแหน่งที่ระบุใน data-bytes ... และไม่มาก หากเซิร์ฟเวอร์เข้าใจคำขอช่วง HTTP เซิร์ฟเวอร์จะส่งคืนข้อมูลภาพไบนารีในการตอบสนอง HTTP-206 (HTTP 206 = เนื้อหาบางส่วน) ในรูปแบบของ blob ซึ่งเราสามารถสร้าง URL ภายในเบราว์เซอร์โดยใช้ createObjectURL เราใช้ URL นี้เป็น src สำหรับแท็ก img ของเรา ดังนั้นเราจึงได้โหลดภาพตัวอย่างของเรา

เราเก็บหยดเพิ่มเติมที่วัตถุ DOM ในคุณสมบัติ src_part เนื่องจากเราต้องการข้อมูลนี้ทันที

ในแท็บเครือข่ายของคอนโซลนักพัฒนาซอฟต์แวร์ คุณสามารถตรวจสอบว่าเราไม่ได้โหลดภาพที่สมบูรณ์ แต่เป็นเพียงส่วนเล็ก ๆ นอกจากนี้ การโหลด Blob URL ควรแสดงด้วยขนาด 0 ไบต์

เนื่องจากเราโหลดส่วนหัว JPEG ของไฟล์ต้นฉบับแล้ว รูปภาพตัวอย่างจึงมีขนาดที่ถูกต้อง ดังนั้น เราสามารถละเว้นความสูงและความกว้างของแท็ก img ได้ ทั้งนี้ขึ้นอยู่กับแอปพลิเคชัน

ทางเลือก: กำลังโหลดภาพตัวอย่างในบรรทัด

ด้วยเหตุผลด้านประสิทธิภาพ จึงสามารถถ่ายโอนข้อมูลของภาพตัวอย่างเป็น URI ข้อมูลได้โดยตรงในซอร์สโค้ด HTML วิธีนี้ช่วยประหยัดค่าใช้จ่ายในการถ่ายโอนส่วนหัว HTTP แต่การเข้ารหัส base64 ทำให้ข้อมูลรูปภาพใหญ่ขึ้นหนึ่งในสาม สิ่งนี้จะสัมพันธ์กันหากคุณส่งโค้ด HTML ที่มีการเข้ารหัสเนื้อหา เช่น gzip หรือ brotli แต่คุณควรใช้ URI ข้อมูลสำหรับภาพตัวอย่างขนาดเล็ก

ที่สำคัญกว่านั้นคือความจริงที่ว่าภาพตัวอย่างพร้อมใช้งานทันทีและผู้ใช้จะไม่เห็นความล่าช้าเมื่อสร้างเพจ

ก่อนอื่น เราต้องสร้าง data URI ซึ่งเราจะใช้ในแท็ก img เป็น src สำหรับสิ่งนี้ เราสร้าง data URI ผ่าน PHP โดยที่โค้ดนี้จะขึ้นอยู่กับโค้ดที่เพิ่งสร้างขึ้น ซึ่งกำหนดไบต์ออฟเซ็ตของตัวทำเครื่องหมาย SOS:

 <?php … $fp = fopen($img, 'r'); $data_uri = 'data:image/jpeg;base64,'. base64_encode(fread($fp, $positions[1])); fclose($fp);

ขณะนี้ URI ข้อมูลที่สร้างขึ้นถูกแทรกลงในแท็ก `img` โดยตรงเป็น src :

 <img src="<?= $data_uri ?>" data-src="progressive.jpg" alt="">

แน่นอน โค้ด JavaScript จะต้องถูกดัดแปลงด้วย:

 <script> var $img = document.querySelector("img[data-src]"); var binary = atob($img.src.slice(23)); var n = binary.length; var view = new Uint8Array(n); while(n--) { view[n] = binary.charCodeAt(n); } $img.src_part = new Blob([view], { type: 'image/jpeg' }); $img.setAttribute('data-bytes', $img.src_part.size - 1); </script>

แทนที่จะขอข้อมูลผ่านคำขอ Ajax ซึ่งเราจะได้รับ Blob ทันที ในกรณีนี้เราต้องสร้าง Blob ด้วยตนเองจาก URI ข้อมูล ในการทำเช่นนี้ เราทำให้ data-URI เป็นอิสระจากส่วนที่ไม่มี data data: data:image/jpeg;base64 เราถอดรหัสข้อมูลที่เข้ารหัส base64 ที่เหลือด้วยคำสั่ง atob ในการสร้าง Blob จากข้อมูลสตริงไบนารีในขณะนี้ เราต้องถ่ายโอนข้อมูลไปยังอาร์เรย์ Uint8 ซึ่งทำให้มั่นใจได้ว่าข้อมูลจะไม่ถือว่าเป็นข้อความที่เข้ารหัส UTF-8 จากอาร์เรย์นี้ เราสามารถสร้าง Binary Blob ด้วยข้อมูลภาพของภาพตัวอย่างได้

เพื่อที่เราจะได้ไม่ต้องปรับโค้ดต่อไปนี้สำหรับเวอร์ชันอินไลน์นี้ เราจึงเพิ่มแอตทริบิวต์ data-bytes ในแท็ก img ซึ่งในตัวอย่างก่อนหน้านี้มี byte offset ซึ่งต้องโหลดส่วนที่สองของรูปภาพ .

ในแท็บเครือข่ายของคอนโซลนักพัฒนาซอฟต์แวร์ คุณยังสามารถตรวจสอบได้ที่นี่ว่าการโหลดภาพตัวอย่างไม่ได้สร้างคำขอเพิ่มเติม ในขณะที่ขนาดไฟล์ของหน้า HTML เพิ่มขึ้น

กำลังโหลดภาพสุดท้าย

ในขั้นตอนที่สอง เราจะโหลดไฟล์รูปภาพที่เหลือหลังจากผ่านไปสองวินาทีดังตัวอย่าง:

 setTimeout(function(){ var xhr = new XMLHttpRequest(); xhr.onload = function(){ if (this.status === 206){ var blob = new Blob([$img.src_part, this.response], { type: 'image/jpeg'} ); $img.src = URL.createObjectURL(blob); } } xhr.open('GET', $img.getAttribute('data-src')); xhr.setRequestHeader("Range", "bytes="+ (parseInt($img.getAttribute('data-bytes'), 10)+1) +'-'); xhr.responseType = 'blob'; xhr.send(); }, 2000);

ในส่วนหัวของช่วง ครั้งนี้ เราระบุว่าเราต้องการขอรูปภาพจากตำแหน่งสิ้นสุดของภาพตัวอย่างไปยังจุดสิ้นสุดของไฟล์ คำตอบสำหรับคำขอแรกถูกเก็บไว้ในคุณสมบัติ src_part ของวัตถุ DOM เราใช้การตอบสนองจากคำขอทั้งสองเพื่อสร้าง blob ใหม่ต่อ new Blob() ซึ่งประกอบด้วยข้อมูลของทั้งภาพ Blob URL ที่สร้างจากสิ่งนี้ถูกใช้อีกครั้งเป็น src ของอ็อบเจ็กต์ DOM ตอนนี้โหลดรูปภาพเรียบร้อยแล้ว

ตอนนี้เราสามารถตรวจสอบขนาดที่โหลดได้ในแท็บเครือข่ายของคอนโซลนักพัฒนาซอฟต์แวร์อีกครั้ง..

ต้นแบบ

ที่ URL ต่อไปนี้ ฉันได้จัดเตรียมต้นแบบที่คุณสามารถทดลองกับพารามิเตอร์ต่างๆ ได้: https://embedded-image-preview.cerdmann.com/prototype/

ที่เก็บ GitHub สำหรับต้นแบบสามารถพบได้ที่นี่: https://github.com/McSodbrenner/embedded-image-preview

ข้อควรพิจารณาในตอนท้าย

การใช้เทคโนโลยี Embedded Image Preview (EIP) ที่นำเสนอในที่นี้ ทำให้เราโหลดภาพตัวอย่างที่แตกต่างกันในเชิงคุณภาพจาก JPEG แบบโปรเกรสซีฟได้ด้วยความช่วยเหลือของ Ajax และ HTTP Range Requests ข้อมูลจากภาพตัวอย่างเหล่านี้จะไม่ถูกละทิ้ง แต่จะใช้ซ้ำเพื่อแสดงภาพทั้งหมดแทน

นอกจากนี้ ไม่จำเป็นต้องสร้างภาพตัวอย่าง ทางฝั่งเซิร์ฟเวอร์ จะต้องกำหนดและบันทึกเฉพาะค่าชดเชยไบต์ที่ภาพตัวอย่างสิ้นสุดเท่านั้น ในระบบ CMS ควรบันทึกหมายเลขนี้เป็นแอตทริบิวต์บนรูปภาพและนำมาพิจารณาเมื่อส่งออกในแท็ก img แม้แต่เวิร์กโฟลว์ก็สามารถทำได้ ซึ่งเสริมชื่อไฟล์ของรูปภาพด้วยออฟเซ็ต เช่น Progressive-8343.jpg เพื่อที่จะไม่ต้องบันทึกออฟเซ็ตนอกเหนือจากไฟล์รูปภาพ ออฟเซ็ตนี้สามารถแยกได้ด้วยโค้ด JavaScript

เนื่องจากมีการใช้ข้อมูลภาพตัวอย่างซ้ำ เทคนิคนี้อาจเป็นทางเลือกที่ดีกว่าวิธีการปกติในการโหลดภาพตัวอย่างแล้วจึงใช้ WebP (และจัดเตรียม JPEG สำรองสำหรับเบราว์เซอร์ที่ไม่สนับสนุน WebP) ภาพตัวอย่างมักจะทำลายข้อดีของการจัดเก็บของ WebP ซึ่งไม่รองรับโหมดโปรเกรสซีฟ

ในปัจจุบัน ภาพตัวอย่างใน LQIP ปกติมีคุณภาพต่ำกว่า เนื่องจากถือว่าการโหลดข้อมูลตัวอย่างต้องใช้แบนด์วิดท์เพิ่มเติม ตามที่ Robin Osborne ระบุไว้ในบล็อกโพสต์ในปี 2018 อย่างชัดเจน การแสดงตัวยึดตำแหน่งที่ไม่ทำให้คุณเห็นภาพสุดท้ายจึงไม่สมเหตุสมผล โดยใช้เทคนิคที่แนะนำในที่นี้ เราสามารถแสดงภาพสุดท้ายเพิ่มเติมบางส่วนเป็นภาพตัวอย่างได้โดยไม่ลังเล โดยให้ผู้ใช้สแกน Progressive JPEG ในภายหลัง

ในกรณีที่การเชื่อมต่อเครือข่ายของผู้ใช้มีสัญญาณอ่อน อาจเป็นเรื่องที่สมเหตุสมผล ทั้งนี้ขึ้นอยู่กับแอปพลิเคชัน ไม่ต้องโหลด JPEG ทั้งหมด แต่เช่น ละเว้นการสแกนสองครั้งล่าสุด สิ่งนี้สร้าง JPEG ที่เล็กกว่ามากโดยมีคุณภาพลดลงเพียงเล็กน้อยเท่านั้น ผู้ใช้จะขอบคุณเราและเราไม่ต้องเก็บไฟล์เพิ่มเติมบนเซิร์ฟเวอร์

ตอนนี้ฉันขอให้คุณสนุกกับการลองใช้ต้นแบบและรอความคิดเห็นของคุณ