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

Jeremy Wagner

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

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

การเลือกใช้

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

Accept-CH: Viewport-Width, Downlink

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

หมายเหตุ: เว็บไซต์ของคุณต้องแสดงผ่าน HTTPS เพื่อให้คำแนะนำของลูกค้าใช้งานได้เลย

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

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

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

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

คำแนะนำสำหรับไคลเอ็นต์จะอธิบาย 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

วันที่

รูปที่ 1 ภาพแสดงภายในเทียบกับ ภายนอก รูปภาพจะมีขนาดภายนอกมากขึ้นหลังจากวางปัจจัยของเลย์เอาต์แล้ว มาใช้กับโทรศัพท์ ในกรณีนี้ การใช้กฎ CSS ของ width: 256px; และ height: 192px; จะแปลงรูปภาพที่มีขนาดเฉพาะ 320x240 เป็นขนาดภายนอก 256x192

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

ความกว้างของวิวพอร์ต

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

Viewport-Width: 320

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

DPR

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

DPR: 2

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

ความกว้าง

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

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

Width: 544

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

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

เกาหลี (DPR) เนื้อหา

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

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

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

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

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

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

Device-Memory: 2

หมายเหตุ: เนื่องจากข้อมูลนี้อาจนำไปใช้เพื่อระบุตัวตนผู้ใช้ได้ ค่าของ Device-Memory จึงมีเจตนาแบบคร่าวๆ ค่าที่ถูกต้องคือ 0.25, 0.5, 1, 2, 4 และ 8

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

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

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

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

RTT

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

RTT: 125

หมายเหตุ: ค่า RTT จะปัดเศษให้เป็นค่า 25 มิลลิวินาทีที่ใกล้ที่สุดเพื่อป้องกันฟิงเกอร์ปรินต์

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

ลิงก์ขาลง

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

Downlink: 2.5

หมายเหตุ: ค่า Downlink จะปัดเศษให้เป็นจำนวนทวีคูณที่ใกล้เคียงที่สุดของ 25 กิโลบิตต่อวินาที อีกอย่างหนึ่งคือ ฟิงเกอร์ปรินต์

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

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

Save-Data: on

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

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

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

รูปภาพที่ตอบสนองตามอุปกรณ์

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

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

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

วันที่

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

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

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

วันที่

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

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

วันที่

รูปที่ 4 เว็บไซต์เดียวกัน ผ่านการเชื่อมต่อเดียวกัน จะยกเว้นเฉพาะทรัพยากรที่ “มีไว้ก็ดี” เท่านั้นเพื่อให้ กำลังโหลด

คำแนะนำไคลเอ็นต์ลดเวลาในการโหลดหน้าเว็บจาก 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 ของคุณเอง

คำแนะนำของไคลเอ็นต์ใน Service Worker

การเจรจาต่อรองเนื้อหาไม่ได้มีไว้สำหรับเซิร์ฟเวอร์อีกต่อไปแล้ว เนื่องจาก Service Worker ดำเนินการ เป็นพร็อกซีระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ทำให้คุณสามารถควบคุมวิธีการทรัพยากร จะส่งผ่านทาง JavaScript ซึ่งรวมถึงคำแนะนำสำหรับไคลเอ็นต์ด้วย ในโปรแกรมทำงานของบริการ fetch คุณสามารถใช้ออบเจ็กต์ 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!
    })(),
  );
});

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

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

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

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

แหล่งข้อมูล

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

ขอขอบคุณ Ilya Grigorik, Eric พอร์ติส, เจฟฟ์ พอสนิก, โยอาฟ Weiss และ Estelle Weyl สำหรับทั้งคู่ ความคิดเห็นและการแก้ไขที่เป็นประโยชน์ในบทความนี้