ทำให้การเลือกทรัพยากรทำงานโดยอัตโนมัติด้วยคำแนะนำสำหรับไคลเอ็นต์

Ilya Grigorik

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

• กำหนดรูปแบบที่เหมาะสม (เวกเตอร์เทียบกับแรสเตอร์)
• ระบุรูปแบบการเข้ารหัสที่เหมาะสม (jpeg, webp ฯลฯ)
• กำหนดการตั้งค่าการบีบอัดที่เหมาะสม (แบบสูญเสียเทียบกับแบบไม่สูญเสียรายละเอียด)
• ระบุข้อมูลเมตาที่ควรเก็บไว้หรือนำออก
• สร้างรายละเอียดปลีกย่อยแบบต่างๆ สำหรับจอแสดงผลและความละเอียด DPR แต่ละรายการ
• ...
• คำนึงถึงประเภทเครือข่าย ความเร็ว และค่ากำหนดของผู้ใช้

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

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

ตำนานของนักพัฒนาซอฟต์แวร์ที่คำนึงถึงประสิทธิภาพ

การค้นหาผ่านพื้นที่การเพิ่มประสิทธิภาพรูปภาพมี 2 ระยะที่แตกต่างกัน ได้แก่ เวลาบิลด์และรันไทม์

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

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

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

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

1. เพื่อให้การบีบอัดดีที่สุด เธอต้องการใช้รูปแบบรูปภาพที่เหมาะสมที่สุดสำหรับแต่ละไคลเอ็นต์ ได้แก่ WebP สำหรับ Chrome, JPEG XR สำหรับ Edge และ JPEG สำหรับส่วนที่เหลือ
2. เพื่อให้ภาพมีคุณภาพดีที่สุด เธอต้องสร้างภาพหลายภาพที่มีความละเอียดแตกต่างกัน เช่น 1x, 1.5x, 2x, 2.5x, 3x หรือเพิ่มอีกเล็กน้อยระหว่างนี้
3. เพื่อหลีกเลี่ยงการแสดงพิกเซลที่ไม่จำเป็น เธอต้องเข้าใจว่า "จริงๆ แล้ว 50% ของวิวพอร์ตของผู้ใช้หมายความว่าอย่างไร" กล่าวคือมีความกว้างของวิวพอร์ตที่แตกต่างกันมาก
4. โดยหลักการแล้ว เธอต้องการมอบประสบการณ์ที่ยืดหยุ่น ซึ่งผู้ใช้ที่มีเครือข่ายที่ช้าจะดึงข้อมูลความละเอียดที่ต่ำลงโดยอัตโนมัติ เพราะเสร็จแล้ว
5. แอปพลิเคชันยังเผยให้เห็นการควบคุมของผู้ใช้บางอย่างซึ่งส่งผลต่อทรัพยากรรูปภาพที่ควรดึงข้อมูลด้วย ดังนั้นจึงต้องคำนึงถึงเรื่องนี้ด้วย

และนักออกแบบก็นึกขึ้นได้ว่าเธอจะต้องแสดงรูปภาพอื่นที่ความกว้าง 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 และความกว้างของวิวพอร์ตสำหรับอุปกรณ์ของลูกค้า น่าประทับใจมาก

หมายเหตุ: สำหรับผู้กล้าหาญ Jason Grigsby มีชุด 10 ส่วนที่ยอดเยี่ยม " Response Images 101" ที่ให้รายละเอียดแบบเจาะลึกทั้งหมดเกี่ยวกับองค์ประกอบ picture

น่าเสียดายที่องค์ประกอบ 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

เมื่อเปิดใช้คําแนะนําของไคลเอ็นต์ มาร์กอัปฝั่งไคลเอ็นต์ที่ได้จะคงไว้เพียงข้อกําหนดในการนำเสนอเท่านั้น ผู้ออกแบบไม่ต้องกังวลเกี่ยวกับประเภทรูปภาพ ความละเอียดของไคลเอ็นต์ เบรกพอยท์ที่เหมาะสมในการลดจำนวนไบต์ที่ส่ง หรือเกณฑ์การเลือกทรัพยากรอื่นๆ ยอมรับเถอะว่า พวกเขาไม่เคยทำ และไม่ควรทำ ยิ่งไปกว่านั้น นักพัฒนาซอฟต์แวร์ยังไม่จำเป็นต้องเขียนและขยายมาร์กอัปข้างต้นใหม่ เนื่องจากไคลเอ็นต์และเซิร์ฟเวอร์จะเจรจาต่อรองการเลือกทรัพยากรจริง

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

หมายเหตุ: เซิร์ฟเวอร์ใช้ส่วนหัว Content-DPR เพื่อยืนยัน DPR ของเนื้อหาที่ส่งคืน เพื่อให้ User Agent คำนวณ "ขนาดภายใน" ที่ถูกต้องของทรัพยากรรูปภาพ

ไม่มีเวทมนตร์อะไรที่นี่เลย เราย้ายการเลือกทรัพยากรจากมาร์กอัป 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 มีความสามารถในการจัดการคำขอและการตอบกลับในไคลเอ็นต์ นี่คือเว็บที่ยืดหยุ่นในการใช้งานจริง

คำถามที่พบบ่อยเกี่ยวกับคำแนะนำของไคลเอ็นต์

1. คำแนะนำลูกค้ามีให้บริการที่ใดบ้าง จัดส่งใน Chrome 46 แล้ว อยู่ระหว่างการพิจารณาใน Firefox และ Edge

2. ทำไมถึงเลือกใช้คำแนะนำของลูกค้า เราต้องการลดค่าใช้จ่ายสำหรับเว็บไซต์ที่จะไม่ใช้คำแนะนำไคลเอ็นต์ หากต้องการเปิดใช้คำแนะนำของไคลเอ็นต์ เว็บไซต์ควรมีส่วนหัว Accept-CH หรือคำสั่ง <meta http-equiv> ที่เทียบเท่าในมาร์กอัปของหน้า เมื่อมีรายการใดรายการหนึ่งข้างต้น User Agent จะเพิ่มคำแนะนำที่เหมาะสมต่อท้ายคำขอทรัพยากรย่อยทั้งหมด ในอนาคต เราอาจมีกลไกเพิ่มเติมเพื่อคงค่ากำหนดนี้สำหรับต้นทางบางแห่งไว้ ซึ่งจะช่วยให้ส่งคำแนะนำเดียวกันนี้ในคำขอการนำทางได้

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

4. คำแนะนำสำหรับไคลเอ็นต์สำหรับทรัพยากรรูปภาพเท่านั้นใช่ไหม กรณีการใช้งานหลักเบื้องหลังคำแนะนำ DPR, ความกว้างวิวพอร์ต และความกว้างคือการเปิดใช้การเลือกทรัพยากรสำหรับชิ้นงานรูปภาพ อย่างไรก็ตาม ระบบจะนำส่งคำแนะนำเดียวกันสำหรับทรัพยากรย่อยทั้งหมดไม่ว่าจะเป็นประเภทใดก็ตาม เช่น คำขอ CSS และ JavaScript ก็จะได้รับข้อมูลเดียวกันและใช้เพื่อเพิ่มประสิทธิภาพทรัพยากรเหล่านั้นได้เช่นกัน

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

6. แล้ว <ใส่คำแนะนำโปรดของฉัน> ล่ะ ServiceWorker จะช่วยให้นักพัฒนาซอฟต์แวร์สกัดกั้นและแก้ไข (เช่น เพิ่มส่วนหัวใหม่) คำขอขาออกทั้งหมดได้ ตัวอย่างเช่น คุณสามารถเพิ่มข้อมูลที่ใช้ NetInfo เพื่อระบุประเภทการเชื่อมต่อปัจจุบันได้อย่างง่ายดาย โปรดดู "การรายงานความสามารถด้วย ServiceWorker" คำแนะนำ "เนทีฟ" ที่จัดส่งใน Chrome (DPR, ความกว้าง, ความกว้างทรัพยากร) จะใช้ในเบราว์เซอร์เนื่องจากการใช้งานแบบ SW เพียงอย่างเดียวจะทําให้คำขอรูปภาพทั้งหมดล่าช้า

7. ฉันจะดูข้อมูลเพิ่มเติม ดูตัวอย่างอื่นๆ ได้จากที่ไหน และมีอะไรบ้าง โปรดดูเอกสารอธิบายและเปิดปัญหาใน GitHub หากมีความคิดเห็นหรือคำถามอื่นๆ