การพัฒนาเว็บไซต์ที่รวดเร็วในทุกที่อาจเป็นเรื่องยาก มากมาย ความสามารถของอุปกรณ์ และคุณภาพของเครือข่ายที่เชื่อมต่อ ซึ่งอาจดูเป็นงานที่ยากจะต้านทาน แม้ว่าเราสามารถ เราจะรู้ได้อย่างไรว่าฟีเจอร์เบราว์เซอร์ต่างๆ ช่วยปรับปรุงประสิทธิภาพในการโหลด ความสามารถของอุปกรณ์ของผู้ใช้ หรือคุณภาพเครือข่าย ไหม โซลูชันคือลูกค้า คำใบ้!
คำแนะนำสำหรับไคลเอ็นต์เป็นชุดส่วนหัวของคำขอ 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
รายการ" ไม่ต้องกังวลเกี่ยวกับคำใบ้นั้นๆ
เราจะตรวจสอบข้อมูลดังกล่าวในอีกสักครู่
คุณสามารถตั้งค่าส่วนหัวการเลือกใช้เหล่านี้เป็นภาษาแบ็กเอนด์ใดก็ได้ ตัวอย่างเช่น PHP
ใช้ฟังก์ชัน header
ได้
คุณยังสามารถตั้งค่าส่วนหัวการเลือกใช้เหล่านี้ด้วย 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
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
กรณีการใช้งานที่เป็นไปได้สำหรับคำแนะนำนี้คือการลดจำนวน 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 ไม้ ไม้ที่สมมติขึ้น บริษัทที่ตั้งอยู่ในย่าน Upper Midwest แถบชนบท เช่น การใช้งานจากระยะไกล พื้นที่ การเชื่อมต่อเครือข่ายอาจไม่ค่อยดีนัก จุดนี้เป็นที่ที่เทคโนโลยีอย่างคำแนะนำของลูกค้า สามารถสร้างความแตกต่าง ให้กับผู้ใช้ได้จริง
รูปภาพที่ตอบสนองตามอุปกรณ์
Use Case รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ได้ง่ายที่สุดอาจซับซ้อนได้ จะเกิดอะไรขึ้นหากคุณ
มีกลุ่มทดสอบและรูปแบบต่างๆ ของรูปภาพเดียวกันสำหรับหน้าจอที่ต่างกัน
ขนาดต่างๆ และหลายรูปแบบได้อย่างไร มาร์กอัปนี้มีความซับซ้อนมากมาก
อย่างรวดเร็ว
ผิดได้ง่ายและหลงลืมหรือเข้าใจผิดได้ง่าย
แนวคิด (เช่น sizes
)
แม้ว่า <picture>
และ srcset
จะเป็นเครื่องมือที่ยอดเยี่ยมอย่างหลีกเลี่ยงไม่ได้ แต่ก็เป็นเพราะ
ใช้เวลานานในการพัฒนาและดูแลรักษาสำหรับกรณีการใช้งานที่ซับซ้อน เราสามารถทำให้
การสร้างมาร์กอัป แต่การทำเช่นนั้นก็ทำได้ยากเช่นกันเนื่องจากฟังก์ชัน
การระบุ <picture>
และ srcset
ซับซ้อนพอที่การทำงานอัตโนมัติต้องการ
ด้วยวิธีการที่ช่วยรักษาความยืดหยุ่นที่ให้ไว้
คำแนะนำสำหรับไคลเอ็นต์จะช่วยให้การทำงานง่ายขึ้น กำลังต่อรองการตอบกลับรูปภาพกับลูกค้า คำแนะนำอาจมีลักษณะดังนี้
- เลือกการจัดการรูปภาพ (เช่น
ภาพที่เน้นงานศิลปะ) โดยตรวจสอบคำแนะนำ
Viewport-Width
- เลือกความละเอียดของรูปภาพโดยดูคำแนะนำ
Width
และคำแนะนำDPR
และ การเลือกแหล่งที่มาที่เหมาะกับขนาดการจัดวางและความหนาแน่นของหน้าจอ (คล้ายกัน กับวิธีการทำงานของข้อบ่งชี้x
และw
ในsrcset
) - เลือกรูปแบบไฟล์ที่เหมาะสมที่สุดที่เบราว์เซอร์รองรับ (ประมาณ
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 สรุปก็คือ ถ้าเราใช้คำแนะนำเกี่ยวกับเครือข่ายใน
บางอย่าง เราสามารถสร้างประสบการณ์ที่ดีขึ้นสำหรับผู้ที่เชื่องช้า
เครือข่าย
![การเปรียบเทียบไซต์ที่ไม่ได้ใช้ไคลเอ็นต์
ที่จะปรับให้เข้ากับการเชื่อมต่อเครือข่ายที่ช้า (ซ้าย) และเว็บไซต์เดียวกับที่
(ขวา)](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-comparison-a-site-doe-b20caac28fc7f.png?authuser=19&hl=th)
เมื่อเว็บไซต์ปรับให้เข้ากับข้อมูลที่ได้จากลูกค้า เราไม่จำเป็นต้องนำมาใช้ โดยใช้แนวทางแบบ "เต็มรูปแบบหรือไม่มีอะไรเลย" เราสามารถตัดสินใจได้อย่างชาญฉลาดว่า ส่ง เราสามารถแก้ไขตรรกะการเลือกรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ให้ส่งคุณภาพต่ำลงได้ รูปภาพบนหน้าจอหนึ่งๆ เพื่อเพิ่มประสิทธิภาพในการโหลดเมื่อคุณภาพเครือข่าย ค่อนข้างแย่
ในตัวอย่างนี้ เราจะเห็นผลจากคำแนะนำของลูกค้า การปรับปรุงประสิทธิภาพของเว็บไซต์บนเครือข่ายที่ช้ากว่า ด้านล่างนี้เป็น WebPagetest Waterfall ของเว็บไซต์ในเครือข่ายที่ช้าซึ่งไม่ปรับให้เข้ากับคำแนะนำของลูกค้า
![Waterfall WebPagetest ของ Sconnie
เว็บไซต์ไม้กำลังโหลดทรัพยากรทั้งหมดเมื่อใช้การเชื่อมต่อเครือข่ายที่ช้า](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-6bc17bbfd8c27.png?authuser=19&hl=th)
และตอนนี้ Waterfall สำหรับเว็บไซต์เดียวกันในการเชื่อมต่อที่ช้าเดียวกัน ยกเว้น เว็บไซต์จะใช้คำแนะนำของลูกค้าเพื่อกำจัดทรัพยากรของหน้าเว็บที่ไม่สำคัญ:
![Waterfall WebPagetest ของ Sconnie
ไซต์ไม้ใช้คำแนะนำของไคลเอ็นต์เพื่อตัดสินใจว่าจะไม่โหลดทรัพยากรที่ไม่สำคัญบน
การเชื่อมต่อเครือข่ายที่ช้า](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-3ba4268e712f2.png?authuser=19&hl=th)
คำแนะนำไคลเอ็นต์ลดเวลาในการโหลดหน้าเว็บจาก 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!
})(),
);
});
ในกรณีนี้ ส่วนหัวคำแนะนำของไคลเอ็นต์ที่คุณเลือกใช้จะสามารถอ่านได้ แม้ว่า
ไม่ใช่วิธีเดียวที่คุณจะได้รับข้อมูลบางส่วน คำแนะนำเฉพาะเครือข่าย
สามารถอ่านได้ในคุณสมบัติ JavaScript ที่เทียบเท่าเหล่านี้ในออบเจ็กต์ navigator
:
คำแนะนำลูกค้า | เทียบเท่า 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 ที่ซับซ้อน ซึ่งทำให้เรา
ไม่เพียงลดเวลาและความพยายามในฝั่งการพัฒนาเท่านั้น แต่ยังเพื่อเพิ่มประสิทธิภาพ
ทรัพยากร โดยเฉพาะรูปภาพ ในลักษณะที่กำหนดเป้าหมายไปที่หน้าจอของผู้ใช้
ได้ละเอียดกว่า
หรือบางทีที่สำคัญกว่านั้น เราอาจจะตรวจพบการเชื่อมต่อเครือข่ายที่ไม่ดีและบริดจ์ได้ ช่องว่างสำหรับผู้ใช้ด้วยการแก้ไขสิ่งที่เราส่งและวิธีส่ง วิธีนี้ เป็นวิธีที่ยาว ในการทำให้ผู้ใช้เข้าถึงเว็บไซต์ได้ง่ายขึ้นในเครือข่ายที่แตกง่าย เมื่อใช้ร่วมกับโปรแกรมทำงานของบริการ เราก็สามารถสร้างเว็บไซต์ที่เร็วเหลือเชื่อ ใช้งานแบบออฟไลน์ได้
แม้ว่าคำแนะนำไคลเอ็นต์จะมีเฉพาะใน Chrome และ Chromium คุณสามารถใช้งานเบราว์เซอร์ในลักษณะต่างๆ ที่ไม่เอื้อต่อการใช้งาน เบราว์เซอร์ที่ไม่สนับสนุน ลองใช้คำแนะนำของลูกค้าเพื่อสร้าง ประสบการณ์การใช้งานที่ครอบคลุมและปรับเปลี่ยนได้ซึ่งรองรับอุปกรณ์ของผู้ใช้ทุกคน ความสามารถ และเครือข่ายที่เชื่อมต่ออยู่ หวังว่าผู้ให้บริการเบราว์เซอร์รายอื่นๆ ก็จะเห็นคุณค่าของกลยุทธ์เหล่านั้นและแสดงถึงความตั้งใจที่จะนำไปใช้
แหล่งข้อมูล
- รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์อัตโนมัติด้วยไคลเอ็นต์ คำแนะนำ
- คำแนะนำไคลเอ็นต์และรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์—สิ่งที่เปลี่ยนแปลงใน Chrome 67
- รับคำแนะนำ (ลูกค้า) (สไลด์)
- มอบแอปพลิเคชันที่รวดเร็วและเบาด้วย
Save-Data
ขอขอบคุณ Ilya Grigorik, Eric พอร์ติส, เจฟฟ์ พอสนิก, โยอาฟ Weiss และ Estelle Weyl สำหรับทั้งคู่ ความคิดเห็นและการแก้ไขที่เป็นประโยชน์ในบทความนี้