โหลดรูปภาพแบบ Lazy Loading และองค์ประกอบ <iframe>

รูปภาพและองค์ประกอบ <iframe> มักใช้แบนด์วิดท์มากกว่าทรัพยากรประเภทอื่นๆ ในกรณีขององค์ประกอบ <iframe> อาจต้องใช้เวลาในการประมวลผลเพิ่มเติมพอสมควรในการโหลดและแสดงหน้าภายในองค์ประกอบดังกล่าว

ในกรณีของรูปภาพที่โหลดแบบ Lazy Loading การเลื่อนการโหลดรูปภาพที่อยู่นอกวิวพอร์ตเริ่มต้นอาจช่วยลดการแย่งแบนด์วิดท์สำหรับทรัพยากรที่สำคัญกว่าภายในวิวพอร์ตเริ่มต้นได้ ซึ่งอาจช่วยปรับปรุง Largest Contentful Paint (LCP) ของหน้าเว็บในบางกรณีที่การเชื่อมต่อเครือข่ายไม่ดี และแบนด์วิดท์ที่จัดสรรใหม่จะช่วยให้ LCP candidates โหลดและแสดงผลได้เร็วขึ้น

ในส่วนขององค์ประกอบ <iframe> คุณสามารถปรับปรุง Interaction to Next Paint (INP) ของหน้าเว็บได้ในระหว่างการเริ่มต้นโดยใช้การโหลดแบบ Lazy Loading เนื่องจาก <iframe> เป็นเอกสาร HTML ที่แยกต่างหากโดยสมบูรณ์ซึ่งมีทรัพยากรย่อยของตัวเอง แม้ว่าองค์ประกอบ <iframe> จะเรียกใช้ในกระบวนการแยกต่างหากได้ แต่ก็ไม่แปลกที่องค์ประกอบเหล่านี้จะแชร์กระบวนการกับเธรดอื่นๆ ซึ่งอาจทำให้หน้าเว็บตอบสนองต่ออินพุตของผู้ใช้น้อยลง

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

โหลดรูปภาพแบบ Lazy Loading ด้วยแอตทริบิวต์ loading

คุณเพิ่มloadingแอตทริบิวต์ลงในองค์ประกอบ <img> เพื่อบอกเบราว์เซอร์ว่าควรโหลด องค์ประกอบอย่างไรได้

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

นอกจากนี้ โปรดทราบว่าหากคุณใช้องค์ประกอบ <picture> คุณควรยังคงใช้แอตทริบิวต์ loading กับองค์ประกอบย่อย <img> ขององค์ประกอบดังกล่าว ไม่ใช่องค์ประกอบ <picture> เอง เนื่องจากองค์ประกอบ <picture> เป็นคอนเทนเนอร์ที่มีองค์ประกอบ <source> เพิ่มเติมซึ่งชี้ไปยังรูปภาพตัวเลือกต่างๆ และตัวเลือกที่เบราว์เซอร์เลือกจะนำไปใช้กับองค์ประกอบย่อย <img> โดยตรง

อย่าใช้ Lazy Loading กับรูปภาพที่อยู่ในวิวพอร์ตเริ่มต้น

คุณควรเพิ่มแอตทริบิวต์ loading="lazy" เฉพาะในองค์ประกอบ <img> ที่วางอยู่นอกวิวพอร์ตเริ่มต้น อย่างไรก็ตาม การทราบตำแหน่งที่แน่นอนขององค์ประกอบที่สัมพันธ์กันภายในวิวพอร์ตก่อนที่หน้าเว็บจะแสดงผลอาจเป็นเรื่องซับซ้อน ต้องพิจารณาขนาดวิวพอร์ต สัดส่วนภาพ และอุปกรณ์ที่แตกต่างกัน

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

อย่างไรก็ตาม มีบางกรณีที่ค่อนข้างชัดเจนว่าคุณควรหลีกเลี่ยงการสมัครใช้loading="lazy" เช่น คุณควรละเว้นแอตทริบิวต์ loading="lazy" จากองค์ประกอบ <img> ในกรณีของภาพฮีโร่ หรือกรณีการใช้งานรูปภาพอื่นๆ ที่องค์ประกอบ <img> มีแนวโน้มที่จะปรากฏเหนือ พับ หรือใกล้กับด้านบนสุดของเลย์เอาต์ในอุปกรณ์ใดก็ตาม ซึ่งสำคัญยิ่งกว่า สำหรับรูปภาพที่มีแนวโน้มที่จะเป็น LCP

รูปภาพที่โหลดแบบ Lazy Loading จะต้องรอให้เบราว์เซอร์จัดวางเลย์เอาต์เสร็จก่อน จึงจะทราบว่าตำแหน่งสุดท้ายของรูปภาพอยู่ภายใน Viewport หรือไม่ ซึ่งหมายความว่าหากองค์ประกอบ <img> ใน Viewport ที่มองเห็นได้มีแอตทริบิวต์ loading="lazy" ระบบจะขอเฉพาะหลังจากดาวน์โหลด แยกวิเคราะห์ และ ใช้ CSS ทั้งหมดกับหน้าเว็บแล้วเท่านั้น ซึ่งต่างจากการดึงข้อมูลทันทีที่เครื่องมือสแกนการโหลดล่วงหน้าในมาร์กอัปดิบตรวจพบ

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

การสาธิตการโหลดรูปภาพแบบ Lazy Loading

โหลดองค์ประกอบ <iframe> แบบ Lazy Loading

การโหลดองค์ประกอบแบบ Lazy Loading <iframe> จนกว่าจะมองเห็นใน Viewport จะช่วยประหยัด ข้อมูลได้อย่างมากและปรับปรุงการโหลดทรัพยากรที่สำคัญซึ่งจำเป็น ต่อการโหลดหน้าเว็บระดับบนสุด นอกจากนี้ เนื่องจากองค์ประกอบ <iframe> เป็นเอกสาร HTML ทั้งหมดที่โหลดภายในเอกสารระดับบนสุด จึงอาจมีทรัพยากรย่อยจำนวนมาก โดยเฉพาะ JavaScript ซึ่งอาจส่งผลต่อ INP ของหน้าเว็บอย่างมากหากงานภายในเฟรมเหล่านั้นต้องใช้เวลาในการประมวลผลนาน

การฝังของบุคคลที่สามเป็นกรณีการใช้งานทั่วไปสำหรับองค์ประกอบ <iframe> ตัวอย่างเช่น เพลเยอร์วิดีโอที่ฝังหรือโพสต์ในโซเชียลมีเดียโดยทั่วไปจะใช้องค์ประกอบ <iframe> และมักต้องใช้ทรัพยากรย่อยจำนวนมาก ซึ่งอาจส่งผลให้เกิดการแย่งแบนด์วิดท์สำหรับทรัพยากรของหน้าเว็บระดับบนสุดด้วย ตัวอย่างเช่น การโหลดวิดีโอ YouTube แบบ Lazy Loading จะช่วยประหยัดข้อมูลได้มากกว่า 500 KiB ในระหว่างการโหลดหน้าเว็บครั้งแรก ขณะที่การโหลดปลั๊กอินปุ่ม "ถูกใจ" ของ Facebook แบบ Lazy Loading จะช่วยประหยัดข้อมูลได้มากกว่า 200 KiB ซึ่งส่วนใหญ่เป็น JavaScript

ไม่ว่าจะด้วยวิธีใดก็ตาม เมื่อใดก็ตามที่คุณมี <iframe> ครึ่งหน้าล่างในหน้าเว็บ คุณควรพิจารณาใช้ Lazy Loading อย่างยิ่งหากไม่จำเป็นต้องโหลดครีเอทีฟโฆษณาตั้งแต่แรก เนื่องจาก การทำเช่นนี้จะช่วยปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างมาก

แอตทริบิวต์ loading สำหรับองค์ประกอบ <iframe>

นอกจากนี้ เบราว์เซอร์หลักๆ ทั้งหมดยังรองรับloadingแอตทริบิวต์ในองค์ประกอบ <iframe> ด้วย ค่าสำหรับแอตทริบิวต์ loading และลักษณะการทำงานของค่าเหล่านั้นจะเหมือนกับองค์ประกอบ <img> ที่ใช้แอตทริบิวต์ loading ดังนี้

  • "eager" คือค่าเริ่มต้น ซึ่งจะแจ้งให้เบราว์เซอร์โหลด HTML ขององค์ประกอบ <iframe> และทรัพยากรย่อยทันที
  • "lazy" จะเลื่อนการโหลด HTML ขององค์ประกอบ <iframe> และทรัพยากรย่อย จนกว่าจะอยู่ภายในระยะทางที่กำหนดไว้ล่วงหน้าจากวิวพอร์ต

การสาธิต iframe การโหลดแบบ Lazy Loading

ส่วนหน้าอาคาร

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

กรณีการใช้งานที่พบบ่อยสำหรับ Facade คือการฝังวิดีโอจากบริการของบุคคลที่สาม ซึ่งการฝังอาจเกี่ยวข้องกับการโหลดทรัพยากรย่อยเพิ่มเติมจำนวนมากและอาจมีค่าใช้จ่ายสูง เช่น JavaScript นอกเหนือจากเนื้อหาวิดีโอเอง ในกรณีเช่นนี้ วิดีโอที่ฝังจะต้องให้ผู้ใช้โต้ตอบก่อนเล่นโดยคลิกปุ่มเล่น เว้นแต่จะมีความจำเป็นที่ถูกต้องตามกฎหมายที่วิดีโอต้องเล่นอัตโนมัติ

นี่เป็นโอกาสที่ดีในการแสดงรูปภาพแบบคงที่ซึ่งมีลักษณะคล้ายกับ วิดีโอที่ฝัง และประหยัดแบนด์วิดท์ได้อย่างมากในกระบวนการนี้ เมื่อผู้ใช้คลิกรูปภาพ ระบบจะแทนที่รูปภาพด้วย<iframe>ฝังจริง ซึ่งจะทริกเกอร์ HTML ขององค์ประกอบ <iframe> ของบุคคลที่สามและทรัพยากรย่อยให้เริ่มดาวน์โหลด

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

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

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

แม้ว่าคุณจะสร้าง Facade ของตัวเองได้ แต่ก็มีตัวเลือกโอเพนซอร์ส สำหรับบุคคลที่สามยอดนิยม เช่น lite-youtube-embed สำหรับวิดีโอ YouTube, lite-vimeo-embed สำหรับวิดีโอ Vimeo และ React Live Chat Loader สำหรับวิดเจ็ตแชท

ไลบรารีการโหลด JavaScript แบบ Lazy

หากต้องการใช้ Lazy Load กับองค์ประกอบ <video>, รูปภาพในองค์ประกอบ <video> poster, รูปภาพที่โหลดโดยพร็อพเพอร์ตี้ background-image ของ CSS หรือองค์ประกอบอื่นๆ ที่ไม่รองรับ คุณสามารถทำได้ด้วยโซลูชัน Lazy Load ที่ใช้ JavaScript เช่น lazysizes หรือ yall.js เนื่องจาก Lazy Load สำหรับทรัพยากรประเภทเหล่านี้ไม่ใช่ฟีเจอร์ระดับเบราว์เซอร์

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

ไลบรารีส่วนใหญ่เหล่านี้ทำงานโดยใช้ Intersection Observer API และMutation Observer API เพิ่มเติมหาก HTML ของหน้าเว็บเปลี่ยนแปลงหลังจากโหลดครั้งแรก เพื่อให้ระบบจดจำได้เมื่อองค์ประกอบเข้าสู่ Viewport ของผู้ใช้ หากรูปภาพ ปรากฏขึ้นหรือใกล้จะเข้าสู่ Viewport ไลบรารี JavaScript จะแทนที่แอตทริบิวต์ที่ไม่เป็นไปตามมาตรฐาน (มักเป็น data-src หรือแอตทริบิวต์ที่คล้ายกัน) ด้วยแอตทริบิวต์ที่ถูกต้อง เช่น src

สมมติว่าคุณมีวิดีโอที่แทนที่ GIF แบบเคลื่อนไหว แต่ต้องการโหลดแบบ Lazy ด้วยโซลูชัน JavaScript คุณทำได้ด้วย yall.js โดยใช้รูปแบบมาร์กอัปต่อไปนี้

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

โดยค่าเริ่มต้น yall.js จะสังเกตองค์ประกอบ HTML ที่มีคุณสมบัติทั้งหมดที่มีคลาสเป็น "lazy" เมื่อโหลดและเรียกใช้ yall.js ในหน้าเว็บแล้ว วิดีโอจะไม่โหลดจนกว่าผู้ใช้จะเลื่อนวิดีโอไปยังวิวพอร์ต เมื่อถึงจุดนั้น ระบบจะสลับแอตทริบิวต์ data-src ในองค์ประกอบย่อย <source> ขององค์ประกอบ <video> เป็นแอตทริบิวต์ src ซึ่งจะส่งคำขอให้ดาวน์โหลดวิดีโอและ เริ่มเล่นโดยอัตโนมัติ

ทดสอบความรู้ของคุณ

ค่าเริ่มต้นสำหรับแอตทริบิวต์ loading สำหรับทั้งองค์ประกอบ <img> และ <iframe> คือค่าใด

"lazy"
"eager"

เมื่อใดที่ควรใช้โซลูชันการโหลดแบบ Lazy Loading ที่ใช้ JavaScript

สำหรับทรัพยากรที่โหลดแบบ Lazy Loading ได้
สำหรับแหล่งข้อมูลที่loadingแอตทริบิวต์ไม่ รองรับ เช่น ในกรณีของวิดีโอที่เล่นอัตโนมัติซึ่งมีไว้เพื่อแทนที่ รูปภาพเคลื่อนไหว หรือเพื่อโหลดรูปภาพโปสเตอร์ขององค์ประกอบ <video> แบบ Lazy Load

เมื่อใดที่เทคนิค Facade มีประโยชน์

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

ถัดไป: การดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้า

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