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