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

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

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

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

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

รูปภาพการโหลดแบบ Lazy Loading ที่มีแอตทริบิวต์ loading

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

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

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

อย่าโหลดรูปภาพแบบ Lazy Loading ในวิวพอร์ตเริ่มต้น

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

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

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

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

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

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

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

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

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

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

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

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

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

การสาธิต iframe แบบ Lazy Loading

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

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

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

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

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

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

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

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

ไลบรารีการโหลดแบบ Lazy Loading ของ JavaScript

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

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

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

สมมติว่าคุณมีวิดีโอที่แทนที่ GIF แบบเคลื่อนไหว แต่คุณต้องการโหลดแบบ Lazy Loading ด้วยโซลูชัน 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> คืออะไร

"eager"
ถูกต้องแล้ว!
"lazy"
โปรดลองอีกครั้ง

เมื่อใดที่โซลูชันการโหลดแบบ Lazy Loading ที่ทำงานด้วย JavaScript จะเหมาะสมสำหรับใช้งานเมื่อใด

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

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

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

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

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