การโหลดแบบ Lazy Loading ระดับเบราว์เซอร์สำหรับ CMS

การเรียนรู้สำหรับการใช้แอตทริบิวต์การโหลดแบบมาตรฐาน

เฟลิกซ์ อาร์นต์ซ์

เป้าหมายของโพสต์นี้คือการโน้มน้าวนักพัฒนาซอฟต์แวร์และผู้ร่วมให้ข้อมูลแพลตฟอร์ม CMS (เช่น ผู้ที่พัฒนาแกน CMS) ว่าตอนนี้ถึงเวลาที่จะรองรับฟีเจอร์การโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์แล้ว นอกจากนี้ ฉันจะแชร์คำแนะนำเกี่ยวกับวิธีตรวจสอบว่าผู้ใช้จะได้รับประสบการณ์ที่มีคุณภาพสูง และเปิดใช้การปรับแต่งโดยนักพัฒนาแอปรายอื่นในขณะที่ใช้การโหลดแบบ Lazy Loading ด้วย หลักเกณฑ์เหล่านี้มาจากประสบการณ์ของเราในการเพิ่มการรองรับ WordPress รวมถึงการช่วยให้ Joomla, Drupal และ TYPO3 ใช้ฟีเจอร์

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

ที่มา

ในปีที่ผ่านมา การโหลดรูปภาพและ iframe แบบ Lazy Loading โดยใช้แอตทริบิวต์ loading ได้กลายเป็นส่วนหนึ่งของ WHATWG HTML Standard และพบว่าเบราว์เซอร์ต่างๆ นิยมใช้กันมากขึ้น อย่างไรก็ตาม เป้าหมายเหล่านี้เป็นเพียงการวางรากฐานสำหรับเว็บที่เร็วขึ้นและประหยัดทรัพยากรได้มากขึ้นเท่านั้น โดยตอนนี้อยู่ในระบบนิเวศของเว็บแบบกระจายเพื่อใช้ประโยชน์จากแอตทริบิวต์ loading

ระบบจัดการเนื้อหา ประมาณ 60% ของเว็บไซต์ แพลตฟอร์มเหล่านี้จึงมีบทบาทสำคัญในการนำฟีเจอร์เบราว์เซอร์ที่ทันสมัย ไปใช้กับเว็บ สำหรับ CMS แบบโอเพนซอร์สยอดนิยมจำนวนหนึ่ง เช่น WordPress, Joomla และ TYPO3 ที่ได้ใช้การรองรับแอตทริบิวต์ loading กับรูปภาพแล้ว เรามาดูวิธีการและประเด็นสำคัญที่เกี่ยวข้องกับการนำฟีเจอร์นี้ไปใช้ในแพลตฟอร์ม CMS อื่นๆ กัน สื่อที่โหลดแบบ Lazy Loading เป็นฟีเจอร์สำคัญด้านประสิทธิภาพบนเว็บที่เว็บไซต์ควรได้รับประโยชน์ในวงกว้าง เราจึงแนะนำให้ใช้โฆษณาในระดับหลักของ CMS

กรณีการใช้งานการโหลดแบบ Lazy Loading ในตอนนี้

การกำหนดมาตรฐาน

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

การสนับสนุนเบราว์เซอร์

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

เกณฑ์ระยะห่างจากวิวพอร์ต

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

คำแนะนำเกี่ยวกับประสบการณ์ของผู้ใช้

จำเป็นต้องมีแอตทริบิวต์มิติข้อมูลในองค์ประกอบ

เพื่อหลีกเลี่ยงไม่ให้เกิดการเปลี่ยนแปลงของเลย์เอาต์ เราได้แนะนำมาอย่างยาวนานว่าเนื้อหาที่ฝัง เช่น รูปภาพหรือ iframe ควรมีแอตทริบิวต์ของขนาด width และ height เสมอ เพื่อให้เบราว์เซอร์อนุมานสัดส่วนภาพขององค์ประกอบเหล่านั้นได้ก่อนที่จะโหลดขึ้นจริง คำแนะนำนี้ใช้งานได้ดีไม่ว่าองค์ประกอบจะโหลดแบบ Lazy Loading หรือไม่ก็ตาม อย่างไรก็ตาม เนื่องจากแนวโน้มที่รูปภาพจะไม่โหลดอย่างสมบูรณ์มากขึ้น 0.1% เพียงครั้งเดียวในวิวพอร์ต ภาพจึงเริ่มรองรับการโหลดแบบ Lazy Loading มากขึ้นเล็กน้อย

ดังนั้น CMS ควรระบุแอตทริบิวต์ขนาดไว้ในรูปภาพและ iframe ทั้งหมด หากเป็นไปไม่ได้สำหรับองค์ประกอบดังกล่าวทั้งหมด เราขอแนะนำให้ข้ามรูปภาพการโหลดแบบ Lazy Loading ซึ่งไม่ได้ระบุแอตทริบิวต์ทั้ง 2 รายการนี้

หลีกเลี่ยงการโหลดแบบ Lazy Loading องค์ประกอบครึ่งหน้าบน

ในตอนนี้เราแนะนําให้ CMS ให้เพิ่มแอตทริบิวต์ loading="lazy" ลงในรูปภาพและ iframe ที่ตําแหน่งครึ่งหน้าล่างเท่านั้นเพื่อหลีกเลี่ยงความล่าช้าในเมตริกการแสดงผลเนื้อหาขนาดใหญ่ที่สุด ซึ่งในบางกรณีอาจมีนัยสำคัญตามที่ค้นพบในเดือนกรกฎาคม 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 ที่เจาะจงในเนื้อหา

ปรับปรุงเนื้อหาที่มีอยู่

การเพิ่มแอตทริบิวต์ loading ไปยังองค์ประกอบ HTML ใน CMS ทำได้ 2 วิธีดังนี้

  • เพิ่มแอตทริบิวต์จากภายในตัวแก้ไขเนื้อหาภายในแบ็กเอนด์ โดยบันทึกไว้ในฐานข้อมูลอย่างต่อเนื่อง
  • เพิ่มแอตทริบิวต์ได้ทันทีเมื่อแสดงผลเนื้อหาจากฐานข้อมูลในฟรอนท์เอนด์

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

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

เพิ่มประสิทธิภาพฝั่งเซิร์ฟเวอร์

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

คุณควรจำกัดการใช้นิพจน์ทั่วไปให้น้อยที่สุด เช่น นิพจน์ทั่วไปเดียวที่รวบรวมแท็ก img และ iframe ทั้งหมดในเนื้อหา รวมถึงแอตทริบิวต์ จากนั้นเพิ่มแอตทริบิวต์ loading ลงในสตริงแท็กแต่ละรายการตามที่เกี่ยวข้อง ตัวอย่างเช่น WordPress มีมากถึงการมีนิพจน์ทั่วไปทั่วไปเพียงรายการเดียวเพื่อทำงานต่างๆ ในทันทีกับองค์ประกอบบางอย่าง ซึ่งการเพิ่ม loading="lazy" เป็นเพียงตัวเดียวที่ใช้นิพจน์ทั่วไปรายการเดียวเพื่ออำนวยความสะดวกให้กับหลายฟีเจอร์ นอกจากนี้ รูปแบบการเพิ่มประสิทธิภาพนี้ยังเป็นอีกเหตุผลหนึ่งที่แนะนำให้ใช้การโหลดแบบ Lazy Loading ในหลักของ CMS มากกว่าส่วนขยาย เพราะจะช่วยให้เพิ่มประสิทธิภาพฝั่งเซิร์ฟเวอร์ได้ดียิ่งขึ้น

ขั้นตอนถัดไป

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

ทวีตฉัน (felixarntz@) หากมีข้อสงสัยหรือความคิดเห็น หรือต้องการให้ CMS แสดงในหน้านี้ หากมีการเพิ่มการรองรับการโหลดแบบ Lazy Loading ในระดับเบราว์เซอร์ หากคุณพบความท้าทายอื่นๆ ฉันก็อยากรู้ข้อมูลเพิ่มเติมเกี่ยวกับปัญหานี้เพื่อหาทางแก้ไขได้

หากคุณเป็นนักพัฒนาแพลตฟอร์ม CMS ให้ศึกษาวิธีที่ CMS อื่นๆ ใช้การโหลดแบบ Lazy Loading

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

รูปภาพหลักของ Colin Watts ใน Unsplash