การพัฒนาเว็บไซต์ที่รวดเร็วในทุกที่อาจเป็นโอกาสในการเติบโต ความสามารถของอุปกรณ์ ที่มีมากมายและคุณภาพของเครือข่ายที่อุปกรณ์เชื่อมต่อด้วยนั้นทำให้งานยากยิ่ง แม้ว่าเราจะใช้ประโยชน์จากฟีเจอร์ของเบราว์เซอร์เพื่อปรับปรุงประสิทธิภาพในการโหลดได้ แต่เราจะรู้ได้อย่างไรว่าอุปกรณ์ของผู้ใช้สามารถทำอะไรได้บ้าง หรือคุณภาพการเชื่อมต่อเครือข่ายของผู้ใช้เป็นอย่างไร วิธีแก้ปัญหาก็คือคำใบ้จากลูกค้า!
คำแนะนำไคลเอ็นต์คือชุดส่วนหัวของคำขอ 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
นั้นซับซ้อนพอที่จะทำให้การทำงานอัตโนมัติต้องทำในลักษณะที่ยังคงความยืดหยุ่นเอาไว้
คำแนะนำสำหรับไคลเอ็นต์จะช่วยให้ขั้นตอนนี้ง่ายขึ้น การเจรจาต่อรองรูปภาพด้วยคำแนะนำลูกค้า อาจมีลักษณะประมาณนี้
- หากเกี่ยวข้องกับเวิร์กโฟลว์ของคุณ ก่อนอื่นให้เลือกการจัดการรูปภาพ (เช่น ภาพที่มีศิลปะกำกับ) โดยดูคำแนะนำ
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 นั้น จะต้องมีการเขียนมาร์กอัปใหม่ขึ้นมาเพื่อตอบโจทย์การใช้งานทุกกรณี ได้เลย คุณสามารถสร้างมาร์กอัปโดยอัตโนมัติได้ แต่หากการออกแบบหรือข้อกำหนดมีการเปลี่ยนแปลง ก็มีโอกาสสูงที่คุณจะกลับไปที่กลยุทธ์การทำงานอัตโนมัติในอนาคต
คำแนะนำสำหรับไคลเอ็นต์ช่วยให้คุณเริ่มต้นด้วยรูปภาพความละเอียดสูงที่ไม่สูญเสียรายละเอียด ซึ่งจากนั้นสามารถปรับขนาดแบบไดนามิกให้เหมาะสมกับการผสมผสานหน้าจอและเลย์เอาต์ทุกรูปแบบ วิธีนี้ต่างจาก 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
คำแนะนำสำหรับลูกค้า | เทียบเท่ากับ 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
โดยเฉพาะอย่างยิ่งในกรณีการใช้งานที่ซับซ้อน สิ่งนี้ไม่เพียงช่วยให้เราลดเวลาและความพยายามของฝั่งการพัฒนา แต่ยังเพิ่มประสิทธิภาพทรัพยากรได้ด้วย (โดยเฉพาะรูปภาพ) โดยกำหนดเป้าหมายหน้าจอของผู้ใช้ได้ละเอียดกว่า
และที่สำคัญกว่านั้นคือ เราสามารถดักจับการเชื่อมต่อเครือข่ายที่ไม่ดีและปิดช่องว่างสำหรับผู้ใช้ได้โดยการแก้ไขสิ่งที่เราส่ง รวมถึงวิธีที่เราส่งข้อมูลดังกล่าว ซึ่งอาจส่งผลให้ผู้ใช้ในเครือข่ายที่เปราะบางเข้าถึงเว็บไซต์ได้ง่ายขึ้น เมื่อใช้ร่วมกับ Service Worker แล้ว เราจึงสามารถสร้างเว็บไซต์ที่รวดเร็วมาก ซึ่งใช้งานแบบออฟไลน์ได้
แม้ว่าคำแนะนำไคลเอ็นต์จะใช้ได้เฉพาะในเบราว์เซอร์ Chrome และเบราว์เซอร์แบบ Chromium เท่านั้น แต่คุณก็สามารถใช้คำแนะนำดังกล่าวในลักษณะที่ไม่กระทบกับเบราว์เซอร์ที่ไม่รองรับได้ ลองใช้คำแนะนำสำหรับไคลเอ็นต์เพื่อสร้างประสบการณ์การใช้งานที่ครอบคลุมและปรับเปลี่ยนได้อย่างแท้จริง ซึ่งตระหนักถึงความสามารถของอุปกรณ์ของผู้ใช้ทุกคน รวมถึงเครือข่ายที่ผู้ใช้เชื่อมต่อ หวังว่าผู้ให้บริการเบราว์เซอร์รายอื่นๆ จะเห็นคุณค่าของตนและแสดงถึงความตั้งใจในการใช้งาน
แหล่งข้อมูล
- รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์อัตโนมัติพร้อมคำแนะนำจากไคลเอ็นต์
- คำแนะนำไคลเอ็นต์และรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ - สิ่งที่เปลี่ยนแปลงไปใน Chrome 67
- รับคำแนะนำ (ลูกค้า) เลย! (สไลด์)
- การให้บริการแอปพลิเคชันที่รวดเร็วและใช้ทรัพยากรน้อยด้วย
Save-Data
ขอขอบคุณ Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss และ Estelle Weyl ที่แสดงความคิดเห็นและแก้ไขบทความนี้