สิ่งที่ได้เรียนรู้จากการใช้แอตทริบิวต์การโหลดที่เป็นมาตรฐาน
เป้าหมายของฉันในโพสต์นี้คือการโน้มน้าวนักพัฒนาซอฟต์แวร์และผู้มีส่วนร่วมในแพลตฟอร์ม CMS (เช่น ผู้ที่พัฒนาแกนหลักของ CMS) ว่าถึงเวลาแล้วที่จะใช้การรองรับฟีเจอร์การโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์ นอกจากนี้ เราจะแชร์คำแนะนำเกี่ยวกับวิธีมอบประสบการณ์การใช้งานคุณภาพสูงแก่ผู้ใช้และเปิดใช้การปรับแต่งโดยนักพัฒนาแอปรายอื่นๆ ขณะใช้การโหลดแบบ Lazy Loading ด้วย หลักเกณฑ์เหล่านี้มาจากประสบการณ์ของเราในการเพิ่มการรองรับให้กับ WordPress รวมถึงการช่วย Joomla, Drupal และ TYPO3 ในการใช้ฟีเจอร์นี้
ไม่ว่าคุณจะเป็นนักพัฒนาแพลตฟอร์ม CMS หรือผู้ใช้ CMS (เช่น ผู้ที่สร้างเว็บไซต์ด้วย CMS) คุณสามารถใช้โพสต์นี้เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับประโยชน์ของการโหลดแบบ Lazy Loading ระดับเบราว์เซอร์ใน CMS ของคุณ ดูส่วนขั้นตอนถัดไปเพื่อดูคำแนะนำเกี่ยวกับวิธีส่งเสริมให้แพลตฟอร์ม CMS ใช้การโหลดแบบ Lazy Loading
ฉากหลัง
ในช่วงปีที่ผ่านมา การโหลดรูปภาพและ iframe แบบ Lazy Loading โดยใช้แอตทริบิวต์ loading ได้กลายเป็นส่วนหนึ่งของมาตรฐาน HTML ของ WHATWG และมีการนำไปใช้มากขึ้นในเบราว์เซอร์ต่างๆ
อย่างไรก็ตาม เหตุการณ์สำคัญเหล่านี้เป็นเพียงการวางรากฐานสำหรับเว็บที่เร็วขึ้นและประหยัดทรัพยากรมากขึ้น
ตอนนี้ระบบนิเวศของเว็บแบบกระจายจะใช้แอตทริบิวต์ loading
ระบบจัดการเนื้อหาขับเคลื่อนเว็บไซต์ประมาณ 60% ดังนั้นแพลตฟอร์มเหล่านี้จึงมีบทบาทสำคัญในการนำฟีเจอร์ของเบราว์เซอร์ที่ทันสมัยมาใช้กับเว็บ CMS แบบโอเพนซอร์สยอดนิยมบางรายการ เช่น WordPress, Joomla และ TYPO3 ได้ใช้การรองรับแอตทริบิวต์ loading ในรูปภาพแล้ว เรามาดูแนวทางและประเด็นสำคัญที่เกี่ยวข้องกับการใช้ฟีเจอร์นี้ในแพลตฟอร์ม CMS อื่นๆ กัน สื่อที่โหลดแบบ Lazy Loading เป็นฟีเจอร์สำคัญด้านประสิทธิภาพของเว็บที่เว็บไซต์ควรได้รับประโยชน์ในวงกว้าง จึงขอแนะนำให้ใช้ฟีเจอร์นี้ที่ระดับแกนหลักของ CMS
เหตุผลที่ควรใช้การโหลดแบบ Lazy Loading ตอนนี้
การกำหนดมาตรฐาน
การใช้ฟีเจอร์เบราว์เซอร์ที่ไม่ได้มาตรฐานใน CMS ช่วยให้ทำการทดสอบในวงกว้างและแสดงจุดที่อาจปรับปรุงได้ อย่างไรก็ตาม ความเห็นพ้องต้องกันโดยทั่วไปใน CMS คือ ตราบใดที่ฟีเจอร์ของเบราว์เซอร์ยังไม่ได้มาตรฐาน ก็ควรนำไปใช้ในรูปแบบของส่วนขยายหรือปลั๊กอินสำหรับแพลตฟอร์มที่เกี่ยวข้อง เมื่อฟีเจอร์ได้รับการกำหนดมาตรฐานแล้วเท่านั้น จึงจะพิจารณานำไปใช้ในแกนหลักของแพลตฟอร์มได้
การสนับสนุนเบราว์เซอร์
การรองรับฟีเจอร์ของเบราว์เซอร์ก็เป็นข้อกังวลที่คล้ายกัน โดยผู้ใช้ CMS ส่วนใหญ่ควรได้รับประโยชน์จากฟีเจอร์นี้ หากมีเบราว์เซอร์จำนวนมากที่ยังไม่รองรับฟีเจอร์นี้ ฟีเจอร์ดังกล่าวจะต้องตรวจสอบว่าอย่างน้อยก็ไม่มีผลเสียต่อเบราว์เซอร์เหล่านั้น
เกณฑ์ระยะห่างจากวิวพอร์ต
ข้อกังวลที่พบบ่อยเกี่ยวกับการใช้การโหลดแบบ Lazy Loading คือโดยหลักการแล้วจะเพิ่มโอกาสที่รูปภาพจะไม่โหลดเมื่อปรากฏในวิวพอร์ตของผู้ใช้ เนื่องจากวงจรการโหลดเริ่มต้นในระยะหลัง ซึ่งต่างจากโซลูชันที่ใช้ JavaScript ก่อนหน้านี้ เบราว์เซอร์จะใช้แนวทางนี้อย่างระมัดระวัง และยังสามารถปรับแต่งแนวทางตามข้อมูลประสบการณ์ของผู้ใช้ในชีวิตจริง เพื่อลดผลกระทบ ดังนั้นแพลตฟอร์ม CMS จึงควรนำการโหลดแบบ Lazy Loading ระดับเบราว์เซอร์มาใช้ได้อย่างปลอดภัย
คำแนะนำเกี่ยวกับประสบการณ์ของผู้ใช้
ต้องมีแอตทริบิวต์มิติข้อมูลในองค์ประกอบ
เพื่อหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ เราจึงมีคำแนะนำที่ใช้มานานว่าเนื้อหาที่ฝัง เช่น รูปภาพหรือ iframe ควรมีแอตทริบิวต์มิติข้อมูล width และ height เสมอ เพื่อให้เบราว์เซอร์อนุมานสัดส่วนภาพขององค์ประกอบเหล่านั้นได้ก่อนที่จะโหลดจริง คำแนะนำนี้มีความเกี่ยวข้องไม่ว่าองค์ประกอบจะโหลดแบบ Lazy Loading หรือไม่ก็ตาม อย่างไรก็ตาม เนื่องจากมีโอกาสมากขึ้น 0.1% ที่รูปภาพจะโหลดไม่เต็มเมื่ออยู่ในวิวพอร์ต การโหลดแบบ Lazy Loading จึงมีประโยชน์มากขึ้นเล็กน้อย
CMS ควรระบุแอตทริบิวต์มิติข้อมูลในรูปภาพและ iframe ทั้งหมด หากไม่สามารถทำเช่นนี้ได้สำหรับทุกองค์ประกอบดังกล่าว เราขอแนะนำให้ข้ามรูปภาพที่โหลดแบบ Lazy Loading ซึ่งไม่มีแอตทริบิวต์ทั้ง 2 รายการนี้
หลีกเลี่ยงการโหลดแบบ Lazy Loading สำหรับองค์ประกอบครึ่งหน้าบน
ในขณะนี้ เราขอแนะนำให้ CMS เพิ่มแอตทริบิวต์ loading="lazy" ลงในรูปภาพและ iframe ที่อยู่ด้านล่างครึ่งหน้าบนเท่านั้น เพื่อหลีกเลี่ยงความล่าช้าในเมตริก Largest Contentful Paint ซึ่งในบางกรณีอาจมีความสำคัญตามที่ค้นพบในเดือนกรกฎาคม 2021 อย่างไรก็ตาม ต้องยอมรับว่าการประเมินตำแหน่งขององค์ประกอบที่สัมพันธ์กับวิวพอร์ตก่อนกระบวนการแสดงผลนั้นมีความซับซ้อน ซึ่งสำคัญมากในกรณีที่ CMS ใช้วิธีการอัตโนมัติในการเพิ่มแอตทริบิวต์ loading แต่แม้จะใช้การแทรกแซงด้วยตนเอง ก็ยังต้องพิจารณาปัจจัยหลายอย่าง เช่น ขนาดวิวพอร์ตและสัดส่วนภาพที่แตกต่างกัน อย่างไรก็ตาม เราขอแนะนำอย่างยิ่งให้ละเว้นรูปภาพหลักและรูปภาพอื่นๆ หรือ iframe ที่มีแนวโน้มจะปรากฏครึ่งหน้าบนจากการโหลดแบบ Lazy Loading
หลีกเลี่ยงการใช้ JavaScript สำรอง
แม้ว่า JavaScript จะใช้เพื่อให้การโหลดแบบ Lazy Loading แก่เบราว์เซอร์ที่ (ยัง) ไม่รองรับแอตทริบิวต์ loading ได้ แต่กลไกดังกล่าวจะอาศัยการนำแอตทริบิวต์ src ของรูปภาพหรือ iframe ออกในตอนแรกเสมอ ซึ่งทำให้เกิดความล่าช้าสำหรับเบราว์เซอร์ที่รองรับแอตทริบิวต์ นอกจากนี้ การเปิดตัวโซลูชันที่ใช้ JavaScript ดังกล่าวในส่วนหน้าของ CMS ขนาดใหญ่ยังเพิ่มโอกาสที่จะเกิดปัญหา ซึ่งเป็นสาเหตุหนึ่งที่ทำให้ไม่มี CMS รายใหญ่รายใดนำการโหลดแบบ Lazy Loading มาใช้ในแกนหลักก่อนที่จะมีฟีเจอร์เบราว์เซอร์ที่ได้มาตรฐาน
คำแนะนำทางเทคนิค
เปิดใช้การโหลดแบบ Lazy Loading โดยค่าเริ่มต้น
คำแนะนำโดยรวมสำหรับ CMS ที่ใช้การโหลดแบบ Lazy Loading ระดับเบราว์เซอร์คือให้เปิดใช้โดยค่าเริ่มต้น กล่าวคือ ควรเพิ่ม loading="lazy" ลงในรูปภาพและ iframe โดยควรใช้กับองค์ประกอบที่มีแอตทริบิวต์มิติข้อมูลเท่านั้น
การเปิดใช้ฟีเจอร์นี้โดยค่าเริ่มต้นจะช่วยประหยัดทรัพยากรเครือข่ายได้มากกว่าการเปิดใช้ด้วยตนเอง เช่น การเปิดใช้ทีละรูปภาพ
loading="lazy"คุณควร
เพิ่ม ลงในองค์ประกอบที่มีแนวโน้มจะปรากฏในครึ่งหน้าล่างเท่านั้นให้มากที่สุดเท่าที่จะทำได้
แม้ว่าข้อกำหนดนี้อาจซับซ้อนในการนำไปใช้กับ CMS เนื่องจากขาดการรับรู้ฝั่งไคลเอ็นต์และขนาดวิวพอร์ตที่หลากหลาย แต่เราขอแนะนำให้ใช้การวิเคราะห์พฤติกรรมโดยประมาณเป็นอย่างน้อยเพื่อละเว้นองค์ประกอบต่างๆ เช่น รูปภาพหลักที่มีแนวโน้มจะปรากฏครึ่งหน้าบนจากการโหลดแบบ Lazy Loading
อนุญาตให้แก้ไขแต่ละองค์ประกอบ
แม้ว่าควรเพิ่ม loading="lazy" ลงในรูปภาพและ iframe โดยค่าเริ่มต้น แต่สิ่งสำคัญคือต้องอนุญาตให้ละเว้นแอตทริบิวต์ในรูปภาพบางรูป เช่น เพื่อเพิ่มประสิทธิภาพสำหรับ LCP หากผู้ชมของ CMS มีความเชี่ยวชาญด้านเทคโนโลยีมากกว่าค่าเฉลี่ย นี่อาจเป็นตัวควบคุม UI ที่แสดงสำหรับรูปภาพและ iframe ทุกรายการ ซึ่งช่วยให้เลือกไม่ใช้การโหลดแบบ Lazy Loading สำหรับองค์ประกอบนั้นได้
หรืออาจแสดง API ต่อนักพัฒนาแอปบุคคลที่สามเพื่อให้นักพัฒนาแอปทำการเปลี่ยนแปลงที่คล้ายกันผ่านโค้ดได้
ตัวอย่างเช่น WordPress อนุญาตให้ข้ามแอตทริบิวต์ loading สำหรับแท็ก HTML หรือบริบททั้งหมด หรือสำหรับองค์ประกอบ HTML ที่เฉพาะเจาะจงในเนื้อหา
ปรับแต่งเนื้อหาที่มีอยู่
โดยรวมแล้ว มี 2 วิธีในการเพิ่มแอตทริบิวต์ loading ลงในองค์ประกอบ HTML ใน CMS ดังนี้
- เพิ่มแอตทริบิวต์จากภายในเครื่องมือแก้ไขเนื้อหาในแบ็กเอนด์ โดยบันทึกไว้ในฐานข้อมูลอย่างถาวร
- เพิ่มแอตทริบิวต์ได้ทันทีเมื่อแสดงผลเนื้อหาจากฐานข้อมูลในฟรอนท์เอนด์
เราขอแนะนำให้ CMS เลือกเพิ่มแอตทริบิวต์ในทันทีเมื่อแสดงผล เพื่อให้เนื้อหาที่มีอยู่ได้รับประโยชน์จากการโหลดแบบ Lazy Loading ด้วย หากเพิ่มแอตทริบิวต์ผ่านเครื่องมือแก้ไขได้เพียงอย่างเดียว เฉพาะเนื้อหาใหม่หรือเนื้อหาที่แก้ไขล่าสุดเท่านั้นที่จะได้รับประโยชน์ ซึ่งจะลดผลกระทบของ CMS ในการประหยัดทรัพยากรเครือข่ายลงอย่างมาก นอกจากนี้ การเพิ่มแอตทริบิวต์ในทันทีจะช่วยให้ทำการแก้ไขในอนาคตได้ง่าย หากมีการขยายความสามารถของการโหลดแบบ Lazy Loading ระดับเบราว์เซอร์เพิ่มเติม
การเพิ่มแอตทริบิวต์ในทันทีควรตอบสนองต่อแอตทริบิวต์ loading ที่อาจมีอยู่แล้วในองค์ประกอบ และให้แอตทริบิวต์ดังกล่าวมีความสำคัญเหนือกว่า ด้วยวิธีนี้ CMS หรือส่วนขยายของ CMS จะใช้แนวทางที่ขับเคลื่อนโดยเครื่องมือแก้ไขได้โดยไม่ทำให้เกิดความขัดแย้งกับแอตทริบิวต์ที่ซ้ำกัน
เพิ่มประสิทธิภาพฝั่งเซิร์ฟเวอร์
เมื่อเพิ่มแอตทริบิวต์ loading ลงในเนื้อหาแบบไดนามิกโดยใช้ (เช่น) มิดเดิลแวร์ฝั่งเซิร์ฟเวอร์ คุณต้องพิจารณาเรื่องความเร็วด้วย คุณสามารถเพิ่มแอตทริบิวต์ผ่านการข้ามผ่าน DOM หรือนิพจน์ทั่วไปก็ได้ ทั้งนี้ขึ้นอยู่กับ CMS โดยเราขอแนะนำให้ใช้นิพจน์ทั่วไปเพื่อประสิทธิภาพ
ควรใช้นิพจน์ทั่วไปให้น้อยที่สุด เช่น นิพจน์ทั่วไปรายการเดียวที่รวบรวมแท็ก img และ iframe ทั้งหมดในเนื้อหา รวมถึงแอตทริบิวต์ของแท็กเหล่านั้น แล้วเพิ่มแอตทริบิวต์ loading ลงในสตริงแท็กแต่ละรายการตามความเหมาะสม ตัวอย่างเช่น WordPress มีนิพจน์ทั่วไปทั่วไปรายการเดียวเพื่อดำเนินการแบบทันทีกับองค์ประกอบบางอย่าง ซึ่งการเพิ่ม loading="lazy" เป็นเพียงหนึ่งในนั้น โดยใช้นิพจน์ทั่วไปรายการเดียวเพื่ออำนวยความสะดวกให้กับฟีเจอร์หลายรายการ การเพิ่มประสิทธิภาพรูปแบบนี้ยังเป็นอีกเหตุผลหนึ่งที่แนะนำให้ใช้การโหลดแบบ Lazy Loading ในแกนหลักของ CMS แทนส่วนขยาย เนื่องจากช่วยให้เพิ่มประสิทธิภาพฝั่งเซิร์ฟเวอร์ได้ดียิ่งขึ้น
ขั้นตอนถัดไป
ดูว่ามีคำขอฟีเจอร์ที่มีอยู่เพื่อเพิ่มการรองรับฟีเจอร์ใน CMS ของคุณหรือไม่ หรือเปิดคำขอใหม่หากยังไม่มี ใช้การอ้างอิงถึงโพสต์นี้ตามความจำเป็นเพื่อสนับสนุนข้อเสนอของคุณ
ทวีตหาฉัน (felixarntz@) หากมีคำถามหรือความคิดเห็น หรือต้องการให้ CMS ของคุณแสดงในหน้านี้หากมีการเพิ่มการรองรับการโหลดแบบ Lazy Loading ระดับเบราว์เซอร์ หากคุณพบปัญหาอื่นๆ เราก็อยากทราบข้อมูลเพิ่มเติมเกี่ยวกับปัญหาเหล่านั้นเพื่อหาทางแก้ไข
หากคุณเป็นนักพัฒนาแพลตฟอร์ม CMS ให้ศึกษาว่า CMS อื่นๆ ใช้การโหลดแบบ Lazy Loading อย่างไร
คุณสามารถใช้สิ่งที่ได้เรียนรู้จากการค้นคว้าและคำแนะนำทางเทคนิคจากโพสต์นี้เพื่อเริ่มส่งโค้ดไปยัง CMS เช่น ในรูปแบบของแพตช์หรือ Pull Request