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

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

ในกรณีของรูปภาพที่โหลดแบบ Lazy Loading การเลื่อนการโหลดรูปภาพที่ นอกวิวพอร์ตเริ่มต้นอาจมีประโยชน์ในการลดการช่วงชิงแบนด์วิดท์ เพื่อดูทรัพยากรที่สำคัญภายในวิวพอร์ตเริ่มต้น ซึ่งสามารถช่วย การแสดงผลเนื้อหาขนาดใหญ่ที่สุด (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>

อย่าโหลดรูปภาพที่อยู่ในวิวพอร์ตเริ่มต้น

คุณควรเพิ่มแอตทริบิวต์ 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

การโหลดแบบ Lazy Loading เอลิเมนต์ <iframe>

การโหลดองค์ประกอบ <iframe> แบบ Lazy Loading จนกว่าจะมองเห็นได้ในวิวพอร์ตจะบันทึกได้ ข้อมูลที่สำคัญและปรับปรุงการโหลดทรัพยากรที่สำคัญที่จำเป็น เพื่อให้หน้าระดับบนสุดโหลด นอกจากนี้ เนื่องจากองค์ประกอบ <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" คือค่าเริ่มต้น จะแจ้งให้เบราว์เซอร์โหลด <iframe> HTML และทรัพยากรย่อยขององค์ประกอบนั้นทันที
• "lazy" เลื่อนการโหลด HTML ขององค์ประกอบ <iframe> และทรัพยากรย่อยขององค์ประกอบนั้น จนกว่าจะอยู่ในระยะทางที่กำหนดไว้ล่วงหน้าจากวิวพอร์ต

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

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

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

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

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

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

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

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

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

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

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

โดยเฉพาะอย่างยิ่ง การเล่นอัตโนมัติและการวนซ้ำองค์ประกอบ <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 ซึ่งจะส่งคำขอดาวน์โหลดวิดีโอและ เริ่มเล่นโดยอัตโนมัติ

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

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

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