การปรับเปลี่ยนให้เหมาะกับผู้ใช้โดยให้คำใบ้กับไคลเอ็นต์

Jeremy Wagner

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

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

ทุกอย่างเกี่ยวกับการเจรจาเนื้อหา

คำแนะนำไคลเอ็นต์เป็นอีกวิธีหนึ่งของการเจรจาเนื้อหา ซึ่งหมายถึงการเปลี่ยน การตอบสนองเนื้อหาตามส่วนหัวคำขอของเบราว์เซอร์

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

Accept: image/webp,image/apng,image/*,*/*;q=0.8

แม้ว่าเบราว์เซอร์ทั้งหมดจะรองรับรูปแบบรูปภาพ เช่น JPEG, PNG และ GIF แต่ Accept จะระบุในกรณีนี้ว่าเบราว์เซอร์ยังรองรับ WebP และ APNG ด้วย เราใช้ข้อมูลนี้เพื่อ เจรจาต่อรองประเภทรูปภาพที่ดีที่สุดสำหรับแต่ละเบราว์เซอร์ได้ ดังนี้

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

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

การเลือกใช้

คำแนะนำไคลเอ็นต์ไม่ได้ปรากฏขึ้นมาโดยอัตโนมัติเหมือนกับส่วนหัว Accept (ยกเว้น Save-Data ซึ่งเราจะพูดถึงในภายหลัง) เพื่อรักษาขนาดของส่วนหัวคำขอให้มีขนาดเล็กที่สุด คุณจะต้องเลือกใช้ Client Hints ที่ต้องการรับโดยส่งส่วนหัว Accept-CH เมื่อผู้ใช้ขอทรัพยากร

Accept-CH: Viewport-Width, Downlink

ค่าสำหรับ Accept-CH คือรายการคำแนะนำที่ขอซึ่งคั่นด้วยคอมมาที่เว็บไซต์ จะใช้ในการพิจารณาผลลัพธ์สำหรับคำขอทรัพยากรที่ตามมา เมื่อไคลเอ็นต์อ่านส่วนหัวนี้ ระบบจะแจ้งว่า "เว็บไซต์นี้ต้องการคำแนะนำไคลเอ็นต์ Viewport-Width และ Downlink" ไม่ต้องกังวลเกี่ยวกับคำแนะนำที่เฉพาะเจาะจง เราจะพูดถึงเรื่องนี้ในอีกสักครู่

คุณตั้งค่าส่วนหัวที่เลือกใช้เหล่านี้ได้ในภาษาแบ็กเอนด์ใดก็ได้ เช่น คุณอาจใช้ฟังก์ชัน header ของ PHP คุณยังตั้งค่าส่วนหัวการเลือกใช้นี้ด้วยแอตทริบิวต์ http-equiv ในแท็ก <meta> ได้ด้วย

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

คำแนะนำสำหรับไคลเอ็นต์ทั้งหมด

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

คำแนะนำอุปกรณ์

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

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

ขนาดโดยธรรมชาติ: ขนาดจริงของทรัพยากรสื่อ ตัวอย่างเช่น หากคุณเปิดรูปภาพใน Photoshop ขนาดที่แสดงในกล่องโต้ตอบขนาดรูปภาพจะอธิบายขนาดที่แท้จริงของรูปภาพ

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

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

สมมติว่าขนาดดั้งเดิมของรูปภาพ 1x ในกรณีนี้คือ 320x240 และขนาดดั้งเดิมของรูปภาพ 2x คือ 640x480 หากไคลเอ็นต์ที่ติดตั้งในอุปกรณ์ที่มีอัตราส่วนพิกเซลของอุปกรณ์หน้าจอเป็น 2 (เช่น หน้าจอ Retina) แยกวิเคราะห์มาร์กอัปนี้ ระบบจะขอรูปภาพ 2x ขนาดจริงที่ปรับตามความหนาแน่นของ 2x รูปภาพคือ 320x240 เนื่องจาก 640x480 หารด้วย 2 เท่ากับ 320x240

ขนาดภายนอก: ขนาดของทรัพยากรสื่อหลังจากที่ใช้ CSS และปัจจัยอื่นๆ ของเลย์เอาต์ (เช่น แอตทริบิวต์ width และ height) กับทรัพยากรนั้น สมมติว่าคุณมีองค์ประกอบ <img> ที่โหลดรูปภาพที่มีขนาดโดยเนื้อแท้ที่แก้ไขความหนาแน่นแล้วเป็น 320x240 แต่ก็มีพร็อพเพอร์ตี้ CSS width และ height ที่มีค่า 256px และ 192px ตามลำดับ ในตัวอย่างนี้ ขนาดภายนอกขององค์ประกอบ <img> นั้นจะกลายเป็น 256x192

เมื่อทราบคำศัพท์บางคำแล้ว เรามาดูรายการคำแนะนำไคลเอ็นต์เฉพาะอุปกรณ์ ที่พร้อมให้คุณใช้งานกัน

Viewport-Width

Viewport-Width คือความกว้างของวิวพอร์ตของผู้ใช้ในพิกเซล CSS

Viewport-Width: 320

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

DPR

DPR ซึ่งย่อมาจากอัตราส่วนพิกเซลของอุปกรณ์ จะรายงานอัตราส่วนของพิกเซลจริงต่อพิกเซล CSS ของหน้าจอผู้ใช้

DPR: 2

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

ความกว้าง

คำใบ้ Width จะปรากฏในคำขอสำหรับทรัพยากรรูปภาพที่ทริกเกอร์โดยแท็ก <img> หรือ <source> โดยใช้แอตทริบิวต์ sizes sizes จะบอกเบราว์เซอร์ว่าขนาดภายนอกของทรัพยากรจะเป็นเท่าใด Width ใช้ขนาดภายนอกนั้นเพื่อขอรูปภาพที่มีขนาดภายในซึ่ง เหมาะกับเลย์เอาต์ปัจจุบัน

ตัวอย่างเช่น สมมติว่าผู้ใช้ขอหน้าเว็บที่มีหน้าจอความกว้าง 320 พิกเซล CSS และมี DPR เท่ากับ 2 อุปกรณ์จะโหลดเอกสารที่มีองค์ประกอบ <img> ซึ่งมี ค่าแอตทริบิวต์ sizes เป็น 85vw (เช่น 85% ของความกว้างวิวพอร์ตสำหรับหน้าจอทุกขนาด) หากเลือกใช้คำแนะนำ Width แล้ว ไคลเอ็นต์จะส่งคำแนะนำ Width นี้ไปยังเซิร์ฟเวอร์พร้อมกับคำขอสำหรับ <img> ของ src

Width: 544

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

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

Content-DPR

แม้ว่าคุณจะทราบอยู่แล้วว่าหน้าจอมีอัตราส่วนพิกเซลของอุปกรณ์ แต่ทรัพยากรก็มีอัตราส่วนพิกเซลของตัวเองเช่นกัน ในกรณีการใช้งานการเลือกทรัพยากรที่ง่ายที่สุด อัตราส่วนพิกเซล ระหว่างอุปกรณ์และทรัพยากรอาจเหมือนกัน แต่ ในกรณีที่ทั้งส่วนหัว DPR และ Width มีการใช้งาน ขนาดภายนอกของทรัพยากรอาจทำให้เกิดสถานการณ์ที่ทั้ง 2 ส่วนหัวแตกต่างกัน Content-DPR คำใบ้ จึงเข้ามามีบทบาทในจุดนี้

Content-DPR ไม่ใช่ส่วนหัวคำขอที่เซิร์ฟเวอร์ใช้ แต่เป็นส่วนหัวการตอบกลับที่เซิร์ฟเวอร์ต้องส่งทุกครั้งที่มีการใช้คำแนะนำ DPR และ Width เพื่อเลือกทรัพยากร ซึ่งแตกต่างจากคำแนะนำไคลเอ็นต์อื่นๆ ค่าของ Content-DPR ควรเป็นผลลัพธ์ของสมการนี้

Content-DPR = [ขนาดทรัพยากรของรูปภาพที่เลือก] / ([Width] / [DPR])

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

Device-Memory

Device-Memory ซึ่งเป็นส่วนหนึ่งของDevice Memory API ในทางเทคนิคจะแสดงปริมาณหน่วยความจำโดยประมาณ ที่อุปกรณ์ปัจจุบันมีในหน่วย GiB ดังนี้

Device-Memory: 2

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

คำแนะนำเกี่ยวกับเครือข่าย

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

RTT

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

RTT: 125

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

ดาวน์ลิงก์

แม้ว่าเวลาในการตอบสนองจะมีความสำคัญต่อประสิทธิภาพการโหลด แต่แบนด์วิดท์ก็มีผลเช่นกัน Downlink คำแนะนำที่แสดงในหน่วยเมกะบิตต่อวินาที (Mbps) จะแสดงความเร็วในการดาวน์โหลดโดยประมาณของการเชื่อมต่อของผู้ใช้

Downlink: 2.5

Downlink ร่วมกับ RTT จะมีประโยชน์ในการเปลี่ยนวิธีส่งเนื้อหา ให้แก่ผู้ใช้ตามคุณภาพของการเชื่อมต่อเครือข่าย

ECT

คำใบ้ ECT ย่อมาจากประเภทการเชื่อมต่อที่มีประสิทธิภาพ ค่าคือรายการประเภทการเชื่อมต่อที่แจงนับ ซึ่งแต่ละประเภทอธิบายการเชื่อมต่อ ภายในช่วงที่ระบุของทั้งค่า RTT และ Downlink

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

ECT: 2g

ค่าที่ใช้ได้สำหรับ ECT คือ 4g, 3g, 2g และ slow-2g คำใบ้นี้สามารถใช้เป็นจุดเริ่มต้นในการประเมินคุณภาพการเชื่อมต่อ และปรับแต่งในภายหลังโดยใช้คำใบ้ RTT และ Downlink

Save-Data

Save-Data ไม่ใช่คำแนะนำที่อธิบายถึงสภาพเครือข่ายมากนัก แต่เป็นค่ากำหนดของผู้ใช้ ที่ระบุว่าหน้าเว็บควรส่งข้อมูลน้อยลง

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

Save-Data: on

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

ลองนำทุกอย่างมารวมกัน

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

รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์

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

แม้ว่า <picture> และ srcset จะเป็นเครื่องมือที่ยอดเยี่ยมอย่างไม่ต้องสงสัย แต่การพัฒนาและบำรุงรักษาเครื่องมือเหล่านี้สำหรับกรณีการใช้งานที่ซับซ้อนอาจต้องใช้เวลานาน เราสามารถสร้างมาร์กอัปโดยอัตโนมัติได้ แต่การทำเช่นนั้นก็เป็นเรื่องยากเช่นกัน เนื่องจากฟังก์ชันการทำงานที่ <picture> และ srcset มีนั้นซับซ้อนมากพอที่การทำงานอัตโนมัติจะต้องทำในลักษณะที่ยังคงความยืดหยุ่นที่ฟังก์ชันการทำงานเหล่านี้มีอยู่

คำแนะนำไคลเอ็นต์ช่วยให้กระบวนการนี้ง่ายขึ้นได้ การเจรจาต่อรองการตอบกลับรูปภาพกับคำแนะนำของไคลเอ็นต์ อาจมีลักษณะดังนี้

1. หากเวิร์กโฟลว์ของคุณเกี่ยวข้อง ให้เลือกการปรับแต่งรูปภาพก่อน (เช่น รูปภาพที่ผ่านการกำกับศิลป์) โดยทำเครื่องหมายที่คำแนะนำ Viewport-Width
2. เลือกความละเอียดของรูปภาพโดยดูคำแนะนำ Width และคำแนะนำ DPR แล้ว เลือกแหล่งที่มาที่เหมาะกับขนาดเลย์เอาต์ของรูปภาพและความหนาแน่นของหน้าจอ (คล้ายกับวิธีที่ตัวอธิบาย x และ w ทำงานใน srcset)
3. เลือกรูปแบบไฟล์ที่เหมาะสมที่สุดซึ่งเบราว์เซอร์รองรับ (Accept ช่วยให้เราทำได้ในเบราว์เซอร์ส่วนใหญ่)

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

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

ฉันสามารถลดจำนวนลงได้ดังนี้โดยอิงตามการรองรับเบราว์เซอร์แต่ละรายการ

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

ในตัวอย่างนี้ /image URL คือสคริปต์ PHP ตามด้วยพารามิเตอร์ ที่เขียนใหม่โดย mod_rewrite โดยจะใช้ชื่อไฟล์รูปภาพและพารามิเตอร์เพิ่มเติมเพื่อช่วยสคริปต์แบ็กเอนด์ เลือกรูปภาพที่ดีที่สุดในเงื่อนไขที่กำหนด

เราทราบว่าคำถามแรกของคุณคือ "แต่การดำเนินการนี้ไม่ใช่การนำ <picture> และ srcset มาใช้ใหม่ใน แบ็กเอนด์ใช่ไหม"

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

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

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

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

การช่วยเหลือผู้ใช้ในเครือข่ายที่ช้า

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

ในส่วนของเว็บไซต์ Sconnie Timber เราจะดำเนินการเพื่อลดภาระเมื่อเครือข่ายช้า โดยจะตรวจสอบส่วนหัว Save-Data, ECT, RTT และ Downlink ในโค้ดแบ็กเอนด์ เมื่อดำเนินการนี้เสร็จแล้ว เราจะสร้างคะแนนคุณภาพเครือข่าย ซึ่งเราสามารถใช้เพื่อพิจารณาว่าควรแทรกแซงเพื่อมอบประสบการณ์การใช้งานที่ดีขึ้นแก่ผู้ใช้หรือไม่ คะแนนเครือข่ายนี้อยู่ระหว่าง 0 ถึง 1 โดย 0 คือคุณภาพเครือข่ายที่แย่ที่สุด และ 1 คือคุณภาพเครือข่ายที่ดีที่สุด

ในตอนแรก เราจะตรวจสอบว่ามี Save-Data หรือไม่ หากเป็นเช่นนั้น ระบบจะตั้งคะแนนเป็น 0 เนื่องจากเราถือว่าผู้ใช้ต้องการให้เราทำทุกอย่างที่จำเป็นเพื่อทำให้ ประสบการณ์การใช้งานเบาและเร็วขึ้น

อย่างไรก็ตาม หากไม่มี Save-Data เราจะพิจารณาค่าของคำแนะนำ ECT, RTT และ Downlink เพื่อคำนวณคะแนนที่อธิบายคุณภาพการเชื่อมต่อเครือข่าย ซอร์สโค้ดการสร้างคะแนนเครือข่าย พร้อมให้บริการบน Github ประเด็นสำคัญคือ หากเราใช้คำแนะนำที่เกี่ยวข้องกับเครือข่ายในลักษณะบางอย่าง เราจะมอบประสบการณ์การใช้งานที่ดีขึ้นสำหรับผู้ที่ใช้เครือข่ายที่ช้าได้

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

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

และตอนนี้มี Waterfall สำหรับเว็บไซต์เดียวกันในการเชื่อมต่อที่ช้าเหมือนกัน แต่ครั้งนี้เว็บไซต์ใช้คำแนะนำไคลเอ็นต์เพื่อกำจัดทรัพยากรหน้าเว็บที่ไม่สำคัญ

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

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

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

ในที่นี้ "4g" แสดงถึงการเชื่อมต่อเครือข่ายที่มีคุณภาพสูงสุดที่ส่วนหัว ECT อธิบาย หากเราเริ่มต้น $ect เป็น "4g" เบราว์เซอร์ที่ไม่รองรับ Client Hints จะไม่ได้รับผลกระทบ เลือกใช้ FTW!

อย่าลืมแคชเหล่านั้น

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

Vary: DPR, Width

อย่างไรก็ตาม ข้อควรระวังที่สำคัญในเรื่องนี้คือคุณไม่ควรVaryแคชCookieการตอบกลับVaryในส่วนหัวที่มีการเปลี่ยนแปลงบ่อย (เช่น Cookie) เนื่องจากทรัพยากรเหล่านั้นจะแคชไม่ได้ เมื่อทราบเช่นนี้ คุณอาจต้องหลีกเลี่ยงการVaryอิงตามส่วนหัวของคำแนะนำไคลเอ็นต์ เช่น RTT หรือ Downlink เนื่องจากสิ่งเหล่านี้เป็นปัจจัยในการเชื่อมต่อที่อาจเปลี่ยนแปลงได้บ่อย หากต้องการแก้ไข การตอบกลับในส่วนหัวเหล่านั้น ให้พิจารณาการระบุคีย์เฉพาะส่วนหัว ECT ซึ่งจะ ลดการพลาดแคช

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

คำแนะนำสำหรับไคลเอ็นต์ใน Service Worker

การเจรจาเนื้อหาไม่ได้มีไว้สำหรับเซิร์ฟเวอร์อีกต่อไป เนื่องจาก Service Worker ทำหน้าที่เป็นพร็อกซีระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ คุณจึงควบคุมวิธีส่งทรัพยากรผ่าน JavaScript ได้ ซึ่งรวมถึงคำแนะนำไคลเอ็นต์ ในเหตุการณ์ของ Service Worker fetch คุณสามารถใช้วิธีการ request.headers.get ของออบเจ็กต์ event เพื่ออ่านส่วนหัวของคำขอของทรัพยากรได้ดังนี้

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

อ่านส่วนหัวของคำแนะนำไคลเอ็นต์ที่คุณเลือกใช้ได้ในลักษณะนี้ แต่คุณก็ดูข้อมูลบางอย่างนี้ได้ด้วยวิธีอื่นๆ คำแนะนำเฉพาะเครือข่าย สามารถอ่านได้ในพร็อพเพอร์ตี้ JavaScript ที่เทียบเท่าในออบเจ็กต์ navigator

เนื่องจาก API เหล่านี้ไม่พร้อมใช้งานในทุกที่ คุณจึงต้องตรวจสอบฟีเจอร์ด้วยตัวดำเนินการ in

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

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

สรุป

Client Hints ช่วยให้เราสามารถมอบประสบการณ์การใช้งานที่รวดเร็วขึ้นแก่ผู้ใช้ในลักษณะ แบบค่อยเป็นค่อยไปอย่างเต็มรูปแบบ เราสามารถแสดงสื่อตามความสามารถของอุปกรณ์ของผู้ใช้ ในลักษณะที่ทำให้การแสดงรูปภาพที่ตอบสนองง่ายกว่าการใช้ <picture> และ srcset โดยเฉพาะสำหรับกรณีการใช้งานที่ซับซ้อน ซึ่งช่วยให้เราไม่เพียงลดเวลาและความพยายามในฝั่งการพัฒนาเท่านั้น แต่ยังเพิ่มประสิทธิภาพทรัพยากร โดยเฉพาะรูปภาพ ในลักษณะที่กำหนดเป้าหมายหน้าจอของผู้ใช้ได้ละเอียดยิ่งกว่า และ srcset

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

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

แหล่งข้อมูล

• รูปภาพที่ปรับเปลี่ยนตามพื้นที่โฆษณาอัตโนมัติด้วยคำแนะนำไคลเอ็นต์
• คำแนะนำไคลเอ็นต์และรูปภาพที่ปรับเปลี่ยนตามพื้นที่โฆษณา - สิ่งที่เปลี่ยนแปลงใน Chrome 67
• รับคำแนะนำ (สำหรับไคลเอ็นต์) (สไลด์)
• การส่งมอบแอปพลิเคชันที่รวดเร็วและมีขนาดเล็กด้วย Save-Data

ขอขอบคุณIlya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss และ Estelle Weyl สำหรับ ความคิดเห็นและการแก้ไขที่มีคุณค่าในบทความนี้