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

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

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

เรื่องของการเจรจาต่อรองด้านเนื้อหา

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

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

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

แม้ว่าเบราว์เซอร์ทุกชนิดจะรองรับรูปแบบรูปภาพ เช่น JPEG, PNG และ GIF แต่ "ยอมรับ" จะบอกในกรณีนี้ว่าเบราว์เซอร์ยังรองรับ 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 คำแนะนำเกี่ยวกับไคลเอ็นต์เป็นอีกหนึ่งทางเลือกสำหรับการเจรจาเกี่ยวกับเนื้อหา แต่ในบริบทของความสามารถของอุปกรณ์และเงื่อนไขเครือข่าย คำแนะนำเกี่ยวกับไคลเอ็นต์ช่วยให้เราตัดสินใจเรื่องประสิทธิภาพฝั่งเซิร์ฟเวอร์ได้จากประสบการณ์ของผู้ใช้แต่ละราย เช่น การตัดสินใจว่าจะแสดงทรัพยากรที่ไม่สำคัญแก่ผู้ใช้ที่มีสภาพเครือข่ายไม่ดีหรือไม่ ในคู่มือนี้ เราจะอธิบายคำแนะนำทั้งหมดที่มี และบางวิธีที่คุณสามารถใช้คำแนะนำเพื่อทำให้การส่งเนื้อหา สะดวกยิ่งขึ้นสำหรับผู้ใช้

การเลือกใช้

คําแนะนําสำหรับลูกค้าไม่เพียงแค่ปรากฏขึ้นมาอย่างน่าอัศจรรย์ (ยกเว้น Save-Data ซึ่งเราจะพูดถึงในภายหลัง) ซึ่งแตกต่างจากส่วนหัว Accept หากต้องการให้มีส่วนหัวของคำขออย่างน้อยที่สุด คุณจะต้องเลือกคำแนะนำที่ต้องการรับโดยส่งส่วนหัว 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" />

ทุกคำใบ้จากลูกค้านะ

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

คำแนะนำเกี่ยวกับอุปกรณ์

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

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

ขนาดภายใน: ขนาดจริงของทรัพยากรสื่อ ตัวอย่างเช่น หากคุณเปิดรูปภาพใน 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 คือความกว้างของวิวพอร์ตของผู้ใช้ในหน่วยพิกเซล CSS ดังนี้

Viewport-Width: 320

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

สาธารณรัฐประชาธิปไตยประชาชน

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

DPR: 2

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

ความกว้าง

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

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

Width: 544

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

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

DPR เนื้อหา

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

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

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

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

หน่วยความจำของอุปกรณ์

ในทางเทคนิคเป็นส่วนหนึ่งของ API หน่วยความจำอุปกรณ์ Device-Memory จะแสดงจำนวนหน่วยความจำโดยประมาณที่อุปกรณ์ปัจจุบันมีใน 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 ย่อมาจาก Effective Connection Type (ประเภทการเชื่อมต่อที่มีประสิทธิภาพ) ค่านี้เป็นหนึ่งในรายการประเภทการเชื่อมต่อที่มีการแจกแจง แต่ละประเภทจะอธิบายการเชื่อมต่อภายในช่วงที่ระบุของทั้งค่า RTT และ Downlink

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

ECT: 2g

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

บันทึกข้อมูล

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."
/>

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

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

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

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

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

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

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

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

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

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

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

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

ระวังแคชเหล่านี้ด้วย!

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

Vary: DPR, Width

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

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

คำแนะนำสำหรับไคลเอ็นต์ในโปรแกรมทำงานของบริการ

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

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

ปลั๊กอิน Imagemin สำหรับประเภทไฟล์

คำแนะนำสำหรับลูกค้า	เทียบเท่ากับ JS
"ECT"	`navigator.connection.effectiveType`
"RTT"	"navigator.connection.rtt"
"บันทึกข้อมูล"	`navigator.connection.saveData`
"ดาวน์ลิงก์"	`navigator.connection.downlink`
"หน่วยความจำของอุปกรณ์"	"navigator.deviceMemory"

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

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

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

ใกล้จะเสร็จแล้ว

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

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

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

แหล่งข้อมูล

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

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