การสร้างแอปสำหรับเว็บช่วยเพิ่มการเข้าถึงที่ไม่มีใครเทียบได้ คุณสามารถใช้งานเว็บแอปพลิเคชันได้ง่ายๆ ด้วยการคลิกเพียงครั้งเดียว และพร้อมใช้งานบนแทบทุกอุปกรณ์ ไม่ว่าจะเป็นสมาร์ทโฟน แท็บเล็ต แล็ปท็อปและเดสก์ท็อป ทีวี และอุปกรณ์อื่นๆ ที่มีการเชื่อมต่อ ไม่ว่าจะแบรนด์หรือแพลตฟอร์มใดก็ตาม เพื่อมอบประสบการณ์ที่ดีที่สุด คุณได้สร้างเว็บไซต์ที่ปรับเปลี่ยนตามอุปกรณ์ซึ่งปรับการนำเสนอและฟังก์ชันสำหรับอุปกรณ์แต่ละรูปแบบแล้ว และตอนนี้คุณกำลังใช้รายการตรวจสอบประสิทธิภาพเพื่อให้มั่นใจว่าแอปพลิเคชันโหลดได้เร็วที่สุดเท่าที่จะเป็นไปได้ คุณได้เพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญแล้ว คุณได้บีบอัดและแคชทรัพยากรข้อความแล้ว และตอนนี้ก็กำลังดูทรัพยากรรูปภาพส่วนใหญ่ที่โอนในบัญชี ซึ่งมักจะเป็นการปรับเส้นทางการแสดงผลที่สำคัญ ปัญหาก็คือการเพิ่มประสิทธิภาพ รูปภาพเป็นเรื่องยาก
- กำหนดรูปแบบที่เหมาะสม (เวกเตอร์เทียบกับแรสเตอร์)
- ระบุรูปแบบการเข้ารหัสที่เหมาะสม (jpeg, webp ฯลฯ)
- กำหนดการตั้งค่าการบีบอัดที่เหมาะสม (แบบสูญเสียเทียบกับแบบไม่สูญเสียรายละเอียด)
- ระบุข้อมูลเมตาที่ควรเก็บไว้หรือนำออก
- สร้างรายละเอียดปลีกย่อยแบบต่างๆ สำหรับจอแสดงผลและความละเอียด DPR แต่ละรายการ
- ...
- คำนึงถึงประเภทเครือข่าย ความเร็ว และค่ากำหนดของผู้ใช้
โดยแยกเป็นข้อๆ เหล่านี้ถือเป็นปัญหาที่เข้าใจได้เป็นอย่างดี พวกเขาสร้างพื้นที่ในการเพิ่มประสิทธิภาพขนาดใหญ่ซึ่งเรา (นักพัฒนาซอฟต์แวร์) มักจะมองข้ามหรือละเลย มนุษย์ทำงานแย่ๆ ในการสำรวจพื้นที่การค้นหาเดิมซ้ำๆ โดยเฉพาะเมื่อมีขั้นตอนมากมาย ในทางกลับกัน คอมพิวเตอร์ก็ทำงานประเภทนี้ได้อย่างดีเยี่ยม
คำตอบของกลยุทธ์การเพิ่มประสิทธิภาพที่ดีและยั่งยืนสำหรับรูปภาพ และทรัพยากรอื่นๆ ที่มีพร็อพเพอร์ตี้คล้ายกันนั้นไม่ซับซ้อน นั่นคือการทำงานอัตโนมัติ ถ้าคุณกำลังปรับแต่งทรัพยากรเอง ก็ถือว่าทำผิดแล้ว คุณอาจจะลืม ขี้เกียจ หรือมีคนทำผิดแทนคุณแน่นอน
ตำนานของนักพัฒนาซอฟต์แวร์ที่คำนึงถึงประสิทธิภาพ
การค้นหาผ่านพื้นที่การเพิ่มประสิทธิภาพรูปภาพมี 2 ระยะที่แตกต่างกัน ได้แก่ เวลาบิลด์และรันไทม์
- การเพิ่มประสิทธิภาพบางอย่างมีไว้สำหรับตัวทรัพยากรเอง เช่น การเลือกรูปแบบและประเภทการเข้ารหัสที่เหมาะสม การปรับแต่งการตั้งค่าการบีบอัดสำหรับโปรแกรมเปลี่ยนไฟล์แต่ละรายการ การตัดข้อมูลเมตาที่ไม่จำเป็น และอื่นๆ คุณสามารถทำตามขั้นตอนเหล่านี้ได้ใน "เวลาบิลด์"
- การเพิ่มประสิทธิภาพอื่นๆ จะพิจารณาจากประเภทและพร็อพเพอร์ตี้ของลูกค้าที่ขอการแสดงผลดังกล่าว และต้องดำเนินการ "รันไทม์" โดยเลือกทรัพยากรที่เหมาะสมสำหรับ DPR และความกว้างของการแสดงผลที่ต้องการของลูกค้า โดยคำนึงถึงความเร็วเครือข่ายของลูกค้า ค่ากำหนดของผู้ใช้และแอปพลิเคชัน เป็นต้น
มีเครื่องมือสำหรับเวลาบิลด์ แต่ควรปรับปรุงให้ดีขึ้น ตัวอย่างเช่น คุณจะประหยัดได้อีกมากมายด้วยการปรับแต่งการตั้งค่า "คุณภาพ" แบบไดนามิกสำหรับแต่ละรูปภาพและรูปแบบรูปภาพแต่ละแบบ แต่ฉันยังไม่เคยเห็นคนอื่นใช้จริงภายนอกการวิจัย นี่เป็นพื้นที่ที่เหมาะเจาะสำหรับนวัตกรรมมาก แต่สำหรับวัตถุประสงค์ของโพสต์นี้ ผมจะปล่อยไว้เช่นนั้น มาโฟกัสที่ช่วงระยะเวลาของเรื่องราวกัน
<img src="/image/thing" sizes="50vw"
alt="image thing displayed at 50% of viewport width">
จุดประสงค์ของแอปพลิเคชันนั้นเรียบง่ายมาก โดยดึงข้อมูลและแสดงรูปภาพที่ 50% ของวิวพอร์ตของผู้ใช้ ซึ่งเป็นที่ที่นักออกแบบทุกคนส่วนใหญ่ล้างมือและเอาหัวถล่มบาร์ ในขณะเดียวกัน นักพัฒนาซอฟต์แวร์ที่คำนึงถึงประสิทธิภาพในทีมก็อยู่ในช่วงเวลาดังต่อไปนี้มายาวนาน
- เพื่อให้การบีบอัดดีที่สุด เธอต้องการใช้รูปแบบรูปภาพที่เหมาะสมที่สุดสำหรับแต่ละไคลเอ็นต์ ได้แก่ WebP สำหรับ Chrome, JPEG XR สำหรับ Edge และ JPEG สำหรับส่วนที่เหลือ
- เพื่อให้ภาพมีคุณภาพดีที่สุด เธอต้องสร้างภาพหลายภาพที่มีความละเอียดแตกต่างกัน เช่น 1x, 1.5x, 2x, 2.5x, 3x หรือเพิ่มอีกเล็กน้อยระหว่างนี้
- เพื่อหลีกเลี่ยงการแสดงพิกเซลที่ไม่จำเป็น เธอต้องเข้าใจว่า "จริงๆ แล้ว 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 หากมีความคิดเห็นหรือคำถามอื่นๆ