การสร้างแอปสำหรับเว็บมอบการเข้าถึงที่เหนือชั้น แค่คลิกเดียวก็สามารถใช้เว็บแอปพลิเคชันได้จากอุปกรณ์ทุกเครื่องที่เชื่อมต่อ ทั้งสมาร์ทโฟน แท็บเล็ต แล็ปท็อปและเดสก์ท็อป ทีวี และอื่นๆ อีกมากมาย ไม่ว่าแบรนด์จะเป็นแบรนด์ใดหรือแพลตฟอร์มใดก็ตาม เพื่อมอบประสบการณ์ที่ดีที่สุด คุณได้สร้างเว็บไซต์ที่ปรับเปลี่ยนตามอุปกรณ์ซึ่งปรับการนำเสนอและฟังก์ชันการทำงานสำหรับรูปแบบของอุปกรณ์แต่ละแบบ และตอนนี้คุณกำลังใช้รายการตรวจสอบประสิทธิภาพเพื่อให้มั่นใจว่าแอปพลิเคชันจะโหลดเร็วที่สุดเท่าที่จะเป็นไปได้ คุณได้เพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญแล้ว คุณบีบอัดและแคชทรัพยากรข้อความแล้ว และตอนนี้คุณจะดูทรัพยากรรูปภาพส่วนใหญ่ของจำนวนไบต์ในบัญชีซึ่งมักจะโอน ปัญหาคือการเพิ่มประสิทธิภาพรูปภาพ ทำได้ยาก
- กำหนดรูปแบบที่เหมาะสม (เวกเตอร์กับแรสเตอร์)
- กำหนดรูปแบบการเข้ารหัสที่เหมาะสมที่สุด (jpeg, webp ฯลฯ)
- กำหนดการตั้งค่าการบีบอัดที่เหมาะสม (แบบสูญเสียและไม่สูญเสียข้อมูล)
- กำหนดว่าควรเก็บหรือตัดข้อมูลเมตาใด
- สร้างตัวแปรหลายรายการสำหรับแต่ละจอแสดงผล + ความละเอียดของ DPR
- ...
- พิจารณาประเภทเครือข่าย ความเร็ว และค่ากำหนดของผู้ใช้
เมื่อพิจารณาแยกกันแล้ว สิ่งเหล่านี้เป็นปัญหาที่เข้าใจได้ เมื่อรวมกันแล้ว พวกเขาได้สร้างพื้นที่ขนาดใหญ่เพื่อการเพิ่มประสิทธิภาพที่เรา (นักพัฒนาซอฟต์แวร์) มักมองข้ามหรือละเลยไป มนุษย์ทำงานแย่ๆ คือการสำรวจพื้นที่ค้นหาเดิมซ้ำๆ โดยเฉพาะเมื่อต้องหลายขั้นตอน ในทางกลับกัน คอมพิวเตอร์ทำงานประเภทนี้ได้อย่างดีเยี่ยม
คำตอบของกลยุทธ์การเพิ่มประสิทธิภาพที่ดีและยั่งยืนสำหรับรูปภาพ และแหล่งข้อมูลอื่นๆ ที่มีคุณสมบัติคล้ายกันนั้นเป็นเรื่องง่าย นั่นก็คือการทำงานอัตโนมัติ การปรับแต่งทรัพยากรด้วยตนเองถือว่าทำผิด การจะลืม คุณจะถูกขี้เกียจ ไม่แน่ว่าจะถูกคนอื่นทำผิดพลาดเช่นนี้ แน่นอน
ตำนานของนักพัฒนาซอฟต์แวร์ที่คำนึงถึงประสิทธิภาพ
พื้นที่การเพิ่มประสิทธิภาพการค้นหาผ่านรูปภาพมี 2 ระยะ ได้แก่ เวลาบิลด์และรันไทม์
- การเพิ่มประสิทธิภาพบางอย่างเป็นหัวใจสำคัญของทรัพยากร เช่น การเลือกรูปแบบและประเภทการเข้ารหัสที่เหมาะสม การปรับแต่งการตั้งค่าการบีบอัดสำหรับโปรแกรมเปลี่ยนไฟล์แต่ละตัว การตัดข้อมูลเมตาที่ไม่จำเป็นออก และอื่นๆ คุณจะทำขั้นตอนเหล่านี้ได้ใน "เวลาสร้าง"
- การเพิ่มประสิทธิภาพอื่นๆ จะกำหนดตามประเภทและพร็อพเพอร์ตี้ของลูกค้าที่ส่งคำขอ และต้องดำเนินการใน "เวลาทำงาน" เช่น การเลือกทรัพยากรที่เหมาะสมสำหรับ DPR ของลูกค้าและความกว้างของการแสดงผลที่ต้องการ โดยพิจารณาจากความเร็วเครือข่ายของลูกค้า ค่ากำหนดผู้ใช้และแอปพลิเคชัน และอื่นๆ
เครื่องมือดังกล่าวยังมีอยู่ แต่ควรปรับปรุงให้ดีขึ้น เช่น การปรับแต่งการตั้งค่า "คุณภาพ" แบบไดนามิกสำหรับแต่ละรูปภาพและแต่ละรูปแบบรูปภาพจะช่วยประหยัดค่าใช้จ่ายได้มากเลย แต่ฉันยังไม่เห็นว่ามีใครนำการตั้งค่า "คุณภาพ" ไปใช้จริงข้างนอกการวิจัยเลย นี่เป็นด้านที่เต็มอิ่มสำหรับนวัตกรรม แต่สำหรับจุดประสงค์ของโพสต์นี้ เราจะคงไว้ตามเดิม ไปดูกันที่รันไทม์ของเรื่องกัน
<img src="/image/thing" sizes="50vw"
alt="image thing displayed at 50% of viewport width">
Intent ของแอปพลิเคชันนั้นเรียบง่ายมาก โดยดึงและแสดงรูปภาพที่ 50% ของวิวพอร์ตของผู้ใช้ ที่นี่เป็นที่ที่นักออกแบบส่วนใหญ่ล้างมือ และสวมหัวเพื่อซื้อบาร์ ในขณะเดียวกัน นักพัฒนาซอฟต์แวร์ที่ให้ความสำคัญกับประสิทธิภาพในทีมก็อยู่ต่ออีกหลายคืน
- เธอต้องการใช้รูปแบบรูปภาพที่เหมาะสมที่สุดกับแต่ละไคลเอ็นต์เพื่อให้ได้การบีบอัดที่ดีที่สุด โดย WebP สำหรับ Chrome, JPEG XR สำหรับ Edge และ JPEG กับส่วนอื่นๆ
- เพื่อให้ได้ภาพที่มีคุณภาพดีที่สุด เธอต้องสร้างรูปแบบต่างๆ สำหรับรูปภาพแต่ละรูปที่มีความละเอียดแตกต่างกัน ซึ่งได้แก่ 1x, 1.5x, 2x, 2.5x, 3 เท่า
- เพื่อหลีกเลี่ยงการแสดงพิกเซลที่ไม่จำเป็น เธอต้องเข้าใจว่า "50% ของวิวพอร์ตผู้ใช้หมายถึงอะไร" ความกว้างวิวพอร์ตมีมากมาย
- ซึ่งตามหลักแล้ว เธอยังต้องการมอบประสบการณ์ที่ยืดหยุ่น โดยผู้ใช้ในเครือข่ายที่ช้ากว่าจะดึงข้อมูลความละเอียดที่ต่ำกว่าโดยอัตโนมัติ ตอนนี้ก็ได้เวลาแก้วน้ำแล้ว
- แอปพลิเคชันยังแสดงการควบคุมของผู้ใช้บางอย่างที่มีผลต่อทรัพยากรรูปภาพที่ควรดึงข้อมูล ดังนั้นจึงต้องมีการควบคุมดังกล่าวด้วยเช่นกัน
แล้วนักออกแบบก็นึกขึ้นได้ว่าต้องแสดงรูปภาพอื่นที่มีความกว้าง 100% หากวิวพอร์ตมีขนาดเล็กเพื่อให้อ่านได้ง่ายขึ้น ซึ่งหมายความว่าตอนนี้เราต้องทำขั้นตอนเดิมซ้ำสำหรับเนื้อหาอีก 1 รายการ แล้วทำให้การดึงข้อมูลตามเงื่อนไขของขนาดวิวพอร์ต เคยบอกว่าเรื่องนี้ยากไหม งั้นเรามาเริ่มกันเลย องค์ประกอบ picture จะทำให้เราไปได้ไกล:
<picture>
<!-- serve WebP to Chrome and Opera -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
/image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
/image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
type="image/webp">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
/image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
/image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
type="image/webp">
<!-- serve JPEGXR to Edge -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w,
/image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w,
/image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w"
type="image/vnd.ms-photo">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w,
/image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w,
/image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w"
type="image/vnd.ms-photo">
<!-- serve JPEG to others -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
/image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
/image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
/image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
/image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
<!-- fallback for browsers that don't support picture -->
<img src="/image/thing.jpg" width="50%">
</picture>
เราได้จัดการเกี่ยวกับทิศทางศิลปะ การเลือกรูปแบบ และจัดเตรียมรูปแบบ 6 แบบของแต่ละรูปภาพให้รองรับความแปรปรวนของ DPR และความกว้างของวิวพอร์ตของอุปกรณ์ไคลเอ็นต์ น่าประทับใจ
ขออภัย องค์ประกอบ picture ไม่อนุญาตให้เรากำหนดกฎเกี่ยวกับลักษณะการทำงานตามประเภทการเชื่อมต่อหรือความเร็วของไคลเอ็นต์ อย่างไรก็ตาม อัลกอริทึมการประมวลผลจะช่วยให้ User Agent ปรับทรัพยากรที่ดึงมาได้ในบางกรณี โปรดดูขั้นตอนที่ 5 เราต้องหวังว่า User Agent ฉลาดเพียงพอ (หมายเหตุ: ไม่มีการติดตั้งใช้งานในปัจจุบัน) ในทำนองเดียวกัน ไม่มีฮุกในองค์ประกอบ picture ที่อนุญาตให้ใช้ตรรกะเฉพาะแอปที่คำนึงถึงแอปหรือค่ากำหนดของผู้ใช้ เพื่อให้ได้ 2 บิตสุดท้ายนี้ เราต้องย้ายตรรกะข้างต้นทั้งหมดไปยัง JavaScript แต่จะทำให้การเพิ่มประสิทธิภาพเครื่องสแกนการโหลดล่วงหน้าที่ picture เสนอหมดลง อืม…
วิธีนี้ใช้ได้ผล อย่างน้อยก็สำหรับเนื้อหานี้ ปัญหาที่แท้จริงซึ่งเป็นความท้าทายในระยะยาวคือเราไม่อาจคาดหวังให้นักออกแบบหรือนักพัฒนาซอฟต์แวร์ออกแบบโค้ดแบบนี้ให้กับทุกชิ้นงานได้ เป็นเกมไขปัญหาสมองที่สนุกในการพยายามครั้งแรก แต่เกมนี้จะอุทธรณ์ไม่ได้ในทันที เราต้องใช้ระบบอัตโนมัติ เครื่องมือเปลี่ยนรูปแบบเนื้อหาอื่นๆ ของ IDE หรือเนื้อหาอื่นๆ อาจช่วยให้เราช่วยเราได้และสร้างต้นแบบโดยอัตโนมัติไว้ด้านบน
การเลือกทรัพยากรโดยอัตโนมัติพร้อมคำแนะนำสำหรับไคลเอ็นต์
สูดลมหายใจเข้าลึกๆ ระงับความเชื่อใจ แล้วลองพิจารณาตัวอย่างต่อไปนี้
<meta http-equiv="Accept-CH" content="DPR, Viewport-Width, Width">
...
<picture>
<source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing">
<img sizes="100vw" src="/image/thing-crop">
</picture>
เชื่อหรือไม่ว่าตัวอย่างด้านบนก็เพียงพอแล้วสำหรับการแสดงความสามารถทั้งหมดเหมือนกับมาร์กอัปรูปภาพขนาดยาวด้านบนบวกอย่างที่เราเห็นอยู่แล้ว ซึ่งช่วยให้นักพัฒนาแอปควบคุมวิธีการ ดึงข้อมูลทรัพยากรรูปภาพ รวมถึงเวลาที่ดึงทรัพยากรรูปภาพได้อย่างเต็มที่ "เวทมนตร์" จะอยู่ในบรรทัดแรกที่
เปิดใช้การรายงานคำแนะนำของลูกค้า
และบอกเบราว์เซอร์ให้โฆษณาอัตราส่วนพิกเซลของอุปกรณ์ (DPR), ความกว้างของ
วิวพอร์ตของเลย์เอาต์ (Viewport-Width) และความกว้างของการแสดงผลที่ต้องการ (Width) ของ
เซิร์ฟเวอร์
เมื่อเปิดใช้คำแนะนำสำหรับไคลเอ็นต์ มาร์กอัปฝั่งไคลเอ็นต์ที่ได้จะเป็นไปตามข้อกำหนดในการนำเสนอ นักออกแบบไม่ต้องกังวลเกี่ยวกับประเภทอิมเมจ ความละเอียดของไคลเอ็นต์ เบรกพอยท์ที่ดีที่สุดเพื่อลดจำนวนไบต์ที่ส่ง หรือเกณฑ์การเลือกทรัพยากรอื่นๆ ยอมรับเถอะ พวกเขาไม่เคยทำและไม่ควร นอกจากนี้ นักพัฒนาซอฟต์แวร์ยังไม่จำเป็นต้องเขียนและขยายมาร์กอัปด้านบนใหม่ เพราะไคลเอ็นต์และเซิร์ฟเวอร์จะเจรจาต่อรองการเลือกทรัพยากรจริง
Chrome 46 จะรองรับในตัวสำหรับคำแนะนำ DPR, Width และ Viewport-Width ระบบจะปิดใช้คำแนะนำไว้โดยค่าเริ่มต้นและ <meta http-equiv="Accept-CH" content="..."> ด้านบนจะทำหน้าที่เป็นสัญญาณการเลือกใช้ที่บอกให้ Chrome เพิ่มส่วนหัวที่ระบุต่อท้ายคำขอขาออก เมื่อพร้อมแล้ว มาตรวจสอบส่วนหัวของคำขอและคำตอบสำหรับคำขอรูปภาพตัวอย่างกัน
Chrome โฆษณาการรองรับรูปแบบ WebP ผ่านส่วนหัวของคำขอ "ยอมรับ" ส่วนเบราว์เซอร์ Edge ใหม่จะโฆษณาการรองรับ JPEG XR ผ่านส่วนหัว "ยอมรับ" ในทำนองเดียวกัน
ส่วนหัวของคำขอ 3 รายการถัดไปคือส่วนหัวของคำแนะนำจากลูกค้าที่โฆษณาอัตราส่วนพิกเซลของอุปกรณ์ของลูกค้า (3 เท่า) ความกว้างของวิวพอร์ตของเลย์เอาต์ (460 พิกเซล) และความกว้างของการแสดงผลที่ต้องการของทรัพยากร (230 พิกเซล) ซึ่งจะเป็นการให้ข้อมูลที่จำเป็นทั้งหมดแก่เซิร์ฟเวอร์เพื่อเลือกรูปแบบรูปภาพที่ดีที่สุดโดยอิงตามชุดนโยบายของตัวเอง เช่น ความพร้อมใช้งานของทรัพยากรที่สร้างไว้ล่วงหน้า ค่าใช้จ่ายในการเข้ารหัสซ้ำหรือการปรับขนาดทรัพยากร ความนิยมของทรัพยากร โหลดของเซิร์ฟเวอร์ปัจจุบัน และอื่นๆ ในกรณีนี้ เซิร์ฟเวอร์จะใช้คำแนะนำ DPR และ
Width และแสดงผลทรัพยากร WebP ตามที่ระบุโดยส่วนหัว Content-Type,
Content-DPR และ Vary
ไม่มีเวทย์มนต์เลย เราได้ย้ายการเลือกทรัพยากรจากมาร์กอัป HTML และไปยังการเจรจาเกี่ยวกับคำขอการตอบกลับระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ด้วยเหตุนี้ HTML จึงมีความกังวลเกี่ยวกับการนำเสนอเท่านั้น และเราเชื่อใจนักออกแบบและนักพัฒนาซอฟต์แวร์ทุกคนให้เขียน ส่วนการค้นหาผ่านพื้นที่การเพิ่มประสิทธิภาพรูปภาพจะถูกเลื่อนเวลาออกไปทางคอมพิวเตอร์ และในปัจจุบันสามารถทำเป็นอัตโนมัติในวงกว้างได้อย่างง่ายดาย จำนักพัฒนาซอฟต์แวร์ที่คำนึงถึงประสิทธิภาพของเราได้ไหม ตอนนี้งานของเธอคือเขียนบริการรูปภาพที่สามารถใช้ประโยชน์จากคำแนะนำที่ให้ไว้และส่งคืนคำตอบที่เหมาะสม เธอจะใช้ภาษาหรือเซิร์ฟเวอร์ใดก็ได้ที่เธอชอบ หรือให้บริการของบุคคลที่สามหรือ CDN ดำเนินการแทนเธอก็ได้
<img src="/image/thing" sizes="50vw"
alt="image thing displayed at 50% of viewport width">
จำบุคคลนี้ที่ด้านบนได้ไหม เมื่อใช้คำแนะนำของลูกค้า แท็กรูปภาพที่เรียบง่ายตอนนี้จะอยู่ในรูปแบบ DPR, วิวพอร์ต และเป็นแบบรับรู้ความกว้างโดยไม่มีมาร์กอัปเพิ่มเติม หากคุณต้องการเพิ่มทิศทางศิลปะ คุณสามารถใช้แท็ก picture ตามที่เราแสดงไว้ด้านบน ไม่เช่นนั้นแท็กรูปภาพที่มีอยู่ทั้งหมดจะฉลาดขึ้นอย่างมาก คำแนะนำลูกค้าช่วยปรับปรุงองค์ประกอบ img และ picture ที่มีอยู่
ควบคุมการเลือกทรัพยากรด้วย Service Worker
ServiceWorker เป็นพร็อกซีฝั่งไคลเอ็นต์ที่ทำงานในเบราว์เซอร์ของคุณ ซึ่งจะสกัดกั้นคำขอที่ส่งออกทั้งหมด และให้คุณตรวจสอบ เขียนใหม่ แคช หรือแม้แต่รวมคำตอบเข้าด้วยกัน รูปภาพก็ไม่แตกต่างกัน เมื่อเปิดใช้คำแนะนำจากไคลเอ็นต์ ServiceWorker ที่ใช้งานอยู่จะระบุคำขอรูปภาพ ตรวจสอบคำแนะนำไคลเอ็นต์ที่ให้ไว้ และกำหนดตรรกะในการประมวลผลของตัวเองได้
self.onfetch = function(event) {
var req = event.request.clone();
console.log("SW received request for: " + req.url)
for (var entry of req.headers.entries()) {
console.log("\t" + entry[0] +": " + entry[1])
}
...
}
ServiceWorker ให้คุณควบคุมการเลือกทรัพยากรฝั่งไคลเอ็นต์ได้อย่างเต็มรูปแบบ เรื่องนี้สำคัญมาก ปล่อยให้มันจมลงเพราะความเป็นไปได้นั้น แทบไม่มีที่สิ้นสุดเลยทีเดียว
- คุณจะเขียนค่าส่วนหัวของคำแนะนำไคลเอ็นต์ใหม่ที่ตั้งค่าโดย User Agent ได้
- คุณเพิ่มค่าส่วนหัวคำแนะนำสำหรับไคลเอ็นต์ใหม่ต่อท้ายคำขอได้
- คุณสามารถเขียน URL ใหม่และชี้คำขอรูปภาพไปที่เซิร์ฟเวอร์สำรอง (เช่น CDN)
- คุณยังสามารถย้ายค่าคำแนะนำจากส่วนหัวไปยัง URL เองได้ด้วยหากการดำเนินการนี้ทำให้ทุกอย่างง่ายขึ้นในโครงสร้างพื้นฐานของคุณ
- คุณสามารถแคชการตอบกลับและกำหนดตรรกะของตนเองสำหรับทรัพยากรที่จะแสดงได้
- คุณปรับคําตอบได้ตามการเชื่อมต่อของผู้ใช้
- คุณใช้ NetInfo API เพื่อค้นหาและโฆษณาค่ากำหนดบนเซิร์ฟเวอร์ได้
- คุณส่งการตอบกลับสำรองได้หากการดึงข้อมูลช้า
- คุณนำการลบล้างค่ากำหนดแอปพลิเคชันและค่ากำหนดของผู้ใช้มาพิจารณาได้
- คุณสามารถสร้างได้ทุกอย่างที่หัวใจต้องการ
องค์ประกอบ picture ให้การควบคุมการกำกับทิศทางที่จำเป็นในมาร์กอัป HTML
คำแนะนำสำหรับไคลเอ็นต์จะแสดงคำอธิบายประกอบเกี่ยวกับคำขอรูปภาพที่ได้ ซึ่งช่วยให้การเลือกทรัพยากรทำงานโดยอัตโนมัติ ServiceWorker มีความสามารถในการจัดการคำขอและการตอบกลับบนไคลเอ็นต์ นี่คือการใช้งานเว็บที่ขยายได้จริง
คำถามที่พบบ่อยเกี่ยวกับคำแนะนำสำหรับไคลเอ็นต์
คำแนะนำสำหรับลูกค้ามีอยู่ที่ใดบ้าง จัดส่งแล้วใน Chrome 46 อยู่ระหว่างการพิจารณาใน Firefox และ Edge
เหตุใดการเลือกใช้คำแนะนำจากลูกค้า เราต้องการลดค่าใช้จ่ายในการดำเนินการสำหรับเว็บไซต์ที่ไม่ใช้คำแนะนำสำหรับไคลเอ็นต์ หากต้องการเปิดใช้คำแนะนำสำหรับไคลเอ็นต์ เว็บไซต์ควรระบุส่วนหัว
Accept-CHหรือคำสั่ง<meta http-equiv>ที่เทียบเท่าในมาร์กอัปหน้าเว็บ หากมีตัวเลือกข้างต้น User Agent จะเพิ่มคำแนะนำที่เหมาะสมต่อท้ายคำขอทรัพยากรย่อยทั้งหมด ในอนาคต เราอาจมีกลไกเพิ่มเติมให้คงค่ากำหนดนี้สำหรับต้นทางหนึ่งๆ ไว้ ซึ่งจะทำให้ระบบสามารถแสดงคำแนะนำเดียวกันนี้ในคำขอการนำทางเหตุใดเราจึงต้องมีคำแนะนำสำหรับลูกค้าหากมี ServiceWorker ServiceWorker ไม่มีสิทธิ์เข้าถึงข้อมูลเลย์เอาต์ ทรัพยากร และความกว้างของวิวพอร์ต อย่างน้อยที่สุดก็ไม่ใช่การแสดงไปกลับที่มีราคาแพงและทำให้คำขอรูปภาพล่าช้าลงอย่างมาก เช่น เมื่อคำขอรูปภาพเริ่มต้นโดยโปรแกรมแยกวิเคราะห์โหลดล่วงหน้า คำแนะนำสำหรับไคลเอ็นต์จะผสานรวมกับเบราว์เซอร์เพื่อทำให้ข้อมูลนี้พร้อมใช้งานโดยเป็นส่วนหนึ่งของคำขอ
คำใบ้จากลูกค้ามีไว้สำหรับแหล่งข้อมูลรูปภาพเท่านั้นใช่ไหม กรณีการใช้งานหลักของคำแนะนำ DPR, ความกว้างของวิวพอร์ต และความกว้างคือการเปิดใช้การเลือกทรัพยากรสำหรับชิ้นงานรูปภาพ อย่างไรก็ตาม ระบบจะส่งคำแนะนำเดียวกันสำหรับทรัพยากรย่อยทั้งหมดโดยไม่คำนึงถึงประเภท เช่น คำขอ CSS และ JavaScript จะได้รับข้อมูลเดียวกันและสามารถใช้เพื่อเพิ่มประสิทธิภาพทรัพยากรเหล่านั้นด้วย
คำขอรูปภาพบางรายการไม่รายงาน "ความกว้าง" เหตุใดจึงเป็นเช่นนั้น เบราว์เซอร์อาจไม่ทราบความกว้างของการแสดงผลที่ต้องการเนื่องจากเว็บไซต์ต้องใช้ขนาดภายในของรูปภาพ ดังนั้น ระบบจะละเว้นคำแนะนำด้านความกว้างสำหรับคำขอดังกล่าว และสำหรับคำขอที่ไม่มี "ความกว้างของการแสดงผล" เช่น ทรัพยากร JavaScript หากต้องการคำแนะนำด้านความกว้าง อย่าลืมระบุค่าขนาดในรูปภาพ
แล้ว <แทรกคำแนะนำโปรดของฉัน> ล่ะ ServiceWorker ช่วยให้นักพัฒนาซอฟต์แวร์สามารถสกัดกั้นและแก้ไข (เช่น เพิ่มส่วนหัวใหม่) คำขอขาออกทั้งหมด ตัวอย่างเช่น คุณสามารถเพิ่มข้อมูลที่อิงตาม NetInfo เพื่อระบุประเภทการเชื่อมต่อปัจจุบันได้อย่างง่ายดาย โปรดดู "การรายงานความสามารถด้วย ServiceWorker" คำแนะนำ "เนทีฟ" ที่ส่งใน Chrome (DPR, ความกว้าง, ความกว้างทรัพยากร) มีการนำมาใช้ในเบราว์เซอร์เนื่องจากการใช้งานแบบ SW เพียงอย่างเดียวจะทำให้คำขอรูปภาพทั้งหมดล่าช้า
ฉันจะดูข้อมูลเพิ่มเติม ดูตัวอย่างเพิ่มเติม และเนื้อหาที่เกี่ยวข้องได้ที่ใด โปรดดูเอกสารอธิบาย และเปิดปัญหาใน GitHub หากคุณมีความคิดเห็นหรือคำถามอื่นๆ