Lazy Load Images ในปี 2026: หน้าเว็บที่เร็วขึ้นโดยไม่กระทบ LCP

ปรับปรุงล่าสุด: June 28, 2026

การโหลดแบบ Lazy loading ช่วยให้หน้าเว็บที่มีรูปภาพจำนวนมากรู้สึกเร็วขึ้น เพราะเบราว์เซอร์สามารถข้ามคำขอรูปภาพที่อยู่ต่ำกว่าส่วนที่มองเห็นได้ (below-fold) ในระหว่างการเรนเดอร์ครั้งแรก อย่างไรก็ตาม หากใช้โดยประมาท อาจทำให้เกิดความล่าช้าสำหรับรูปภาพเดียวที่ผู้ใช้ต้องการทันที: รูปแบบ hero, ภาพหลักของผลิตภัณฑ์, หรือหน้าปกบทความ ซึ่งจะกลายเป็นองค์ประกอบ Largest Contentful Paint (LCP).

คู่มือนี้จะแสดงว่าควรใช้ loading="lazy" แบบ native ที่ใด ควรเก็บรูปภาพแบบ eager ที่ใด และวิธีการเผยแพร่รูปภาพที่โหลดแบบ lazy-loaded โดยไม่ทำให้ Core Web Vitals, SEO หรือการส่งมอบผ่าน CDN เสียหาย

คำตอบสั้นๆ: ควรทำอย่างไรในการโหลดรูปภาพแบบ Lazy Load?

ควรใช้ lazy loading เฉพาะกับรูปภาพที่เริ่มต้นอยู่นอก first viewport เท่านั้น ให้คงสถานะของรูปภาพที่เป็นไปได้ว่าจะเป็น LCP ไว้แบบ eager จอง width และ height สำหรับทุกรูปภาพ และให้บริการไฟล์ responsive WebP หรือ AVIF จาก URL CDN ที่สามารถแคชได้

สำหรับ plain HTML การใช้งานที่ง่ายที่สุดคือการเพิ่ม loading="lazy" ให้กับองค์ประกอบ <img> ที่อยู่ below-fold ห้ามเพิ่มมันให้กับ hero image, product lead image, รูปภาพบทความแรกที่มองเห็นได้ หรือรูปภาพใดๆ ที่ต้องปรากฏก่อนที่ผู้ใช้จะเลื่อนหน้าจอ

เมื่อไม่แน่ใจ ให้ทดสอบหน้าใน Lighthouse หรือ Chrome DevTools หากรูปภาพที่โหลดแบบ lazy ถูกรายงานว่าเป็นองค์ประกอบ LCP ให้ลบ lazy loading ออกจากรูปภาพนั้น และพิจารณาใช้ fetchpriority="high"

การโหลดแบบขี้เกียจ (lazy loading) เปลี่ยนแปลงอะไรได้บ้างกันแน่?

การโหลดแบบขี้เกียจ (Lazy loading) เปลี่ยนแปลงช่วงเวลาการร้องขอ (request timing) ของข้อมูลได้ เบราว์เซอร์สามารถรอดาวน์โหลดรูปภาพจนกว่าผู้ใช้จะเข้าใกล้พอที่จะมองเห็นได้ ซึ่งช่วยประหยัดแบนด์วิดท์ในหน้าเว็บที่ยาว ลดแรงกดดันในการร้องขอครั้งแรก และเพิ่มโอกาสให้ CSS, fonts, scripts, และรูปภาพที่มองเห็นเสร็จสมบูรณ์ก่อน

มันไม่ได้ทำให้รูปภาพขนาดใหญ่กลายเป็นขนาดเล็ก รูป JPEG ขนาด 2400 px ก็ยังคงสิ้นเปลืองหลังจากที่โหลดเสร็จแล้ว ควรใช้ lazy loading ควบคู่ไปกับการปรับขนาด (resizing), การบีบอัด (compression), และการทำ responsive markup ตั้งแต่เริ่มต้น บทความ Image Compression Deep Dive ครอบคลุมเรื่องการลดไบต์ ในขณะที่บทความ Mobile Image Optimization Guide ครอบคลุม srcset และขนาดแสดงผลบนมือถือ

ฟีเจอร์พื้นฐานของเบราว์เซอร์ได้รับการบันทึกโดย MDN ในรูปแบบคุณสมบัติ loading บน images และ iframes ใน HTMLImageElement.loading สำหรับเว็บไซต์ที่ทันสมัย ควรใช้ฟีเจอร์ของเบราว์เซอร์นี้ก่อนที่จะเพิ่มไลบรารี lazy-loading ของ JavaScript

รูปภาพใดที่ไม่ควรใช้การโหลดแบบขี้เกียจ?

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

ควรให้รูปภาพเหล่านี้โหลดทันที (eager):

1. รูปภาพฮีโร่หลัก
2. รูปภาพสินค้าที่อยู่เหนือปุ่มซื้อ
3. รูปภาพแรกในบทความเมื่อปรากฏใกล้ส่วนบนบนอุปกรณ์มือถือ
4. โลโก้หรือภาพหน้าจออินเทอร์เฟซที่ต้องมองเห็นก่อนการโต้ตอบ
5. รูปภาพใด ๆ ที่ Chrome รายงานว่าเป็นองค์ประกอบ LCP

แนวทาง Core Web Vitals ของ Google ถือว่า LCP คือเวลาในการแสดงผลขององค์ประกอบเนื้อหาที่ใหญ่ที่สุดที่มองเห็นได้ใน viewport; ดู Largest Contentful Paint เมื่อองค์ประกอบนั้นเป็นรูปภาพ การหน่วงคำขอจะทำให้เมตริกแย่ลงอย่างรวดเร็ววิธีหนึ่ง

ใช้กฎนี้สำหรับเทมเพลต: ช่องรูปภาพแรกควรตั้งค่าเริ่มต้นเป็นแบบทันที (eager) และบล็อกรูปภาพที่ทำซ้ำในภายหลังควรตั้งค่าเริ่มต้นเป็นแบบขี้เกียจ (lazy) จากนั้นจึงเขียนทับตามประเภทหน้าเมื่อภาพหน้าจอของอุปกรณ์มือถือแสดง viewport แรกที่แตกต่างกัน

การใช้งาน Lazy Loading ใน HTML ทำได้อย่างไร?

ควรใช้ Markup แบบ Native ก่อน:

<img
  src="/images/gallery-chair.webp"
  alt="Walnut chair photographed from the front for a product gallery"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
>

แอททริบิวต์ width และ height มีความสำคัญพอ ๆ กับ loading เพราะมันช่วยให้เบราว์เซอร์จองพื้นที่สำหรับเลย์เอาต์ไว้ก่อนที่ไฟล์จะมาถึง หากไม่มีการจองพื้นที่ดังกล่าว รูปภาพที่โหลดล่าช้าอาจทำให้ข้อความถูกดันลงหน้าเพจและสร้าง Cumulative Layout Shift ได้

สำหรับรูปภาพแบบ Responsive ควรคงการใช้ lazy loading ไว้ที่แท็ก <img> ตัวสำรอง (fallback):

<picture>
  <source type="image/avif" srcset="/images/gallery-chair-800.avif 800w, /images/gallery-chair-1200.avif 1200w">
  <source type="image/webp" srcset="/images/gallery-chair-800.webp 800w, /images/gallery-chair-1200.webp 1200w">
  <img
    src="/images/gallery-chair-1200.webp"
    alt="Walnut chair photographed from the front for a product gallery"
    width="1200"
    height="800"
    sizes="(max-width: 700px) 92vw, 680px"
    loading="lazy"
  >
</picture>

สำหรับรูปภาพที่น่าจะเป็น LCP ควรใช้รูปแบบตรงกันข้าม:

<img
  src="/images/product-hero.webp"
  alt="Walnut lounge chair with green cushion on a white studio background"
  width="1600"
  height="1000"
  fetchpriority="high"
>

บทความของ Google เกี่ยวกับ browser-level image lazy loading แนะนำให้ใช้ native lazy loading และเตือนว่ารูปภาพที่อยู่ใน viewport ที่มองเห็นครั้งแรกควรโหลดตามปกติ คำแนะนำดังกล่าวนี้ยังคงเป็นแนวทางพื้นฐานที่สะอาดที่สุดสำหรับการเผยแพร่ในปี 2026

การโหลดแบบ Lazy Loading ส่งผลต่อ SEO อย่างไร?

การโหลดแบบ Lazy loading จะปลอดภัยสำหรับ SEO เมื่อเนื้อหาที่สำคัญยังคงสามารถค้นพบได้ในหน้าเว็บที่เรนเดอร์แล้ว Google สามารถประมวลผล JavaScript สมัยใหม่ได้ แต่ SEO สำหรับรูปภาพจะอ่อนลงเมื่อ URL รูปภาพสุดท้ายถูกซ่อนอยู่เบื้องหลังปฏิสัมพันธ์ (interaction), สคริปต์ที่ทำงานเมื่อเลื่อนเท่านั้น (scroll-only script), cookies, หรือ placeholder ที่เสียหาย

ควรใช้ markup <img> หรือ <picture> ปกติสำหรับรูปภาพเนื้อหา รักษาข้อความ alt ที่ให้คำอธิบาย, URL CDN ที่สามารถ crawl ได้, และข้อความรอบข้างที่อธิบายรูปภาพ คู่มือ Image SEO Guide 2026 มีขั้นตอนการ crawl และ alt-text ที่ครอบคลุมกว่า

คำแนะนำ JavaScript SEO ของ Google Search Central สำหรับ lazy loading ระบุว่าเนื้อหาควรโหลดเมื่อมองเห็นได้ใน viewport และไม่ควรขึ้นอยู่กับการกระทำของผู้ใช้ เช่น การคลิกหรือการพิมพ์ ดูรายละเอียดได้ที่ Fix lazy-loaded content นี่เป็นแนวทางป้องกันที่มีประโยชน์สำหรับแกลเลอรีรูปภาพ, แท็บ, และหน้าแบบ infinite scroll

Lazy loading ช่วยประหยัดประสิทธิภาพได้มากแค่ไหน?

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

ฉันได้เข้ารหัสกราฟิกทั้งสี่ในบทความนี้เป็นไฟล์ WebP ท้องถิ่นที่ขนาดสำหรับการเผยแพร่ สินทรัพย์สุดท้ายแต่ละชิ้นมีขนาด 25 KB ถึง 36 KB ดังนั้น lazy loading จึงไม่ได้ซ่อนปัญหาไบต์ขนาดใหญ่ไว้ที่นี่ การเพิ่มประสิทธิภาพที่ใหญ่กว่ามาจากการกำหนดเวลาในการร้องขอ: หน้าปกพร้อมใช้งานทันที และไดอะแกรมในภายหลังสามารถรอได้จนกว่าผู้อ่านจะเลื่อนหน้าจอ

ควรใช้ลำดับนี้ก่อนที่จะกล่าวโทษ lazy loading:

1. ปรับขนาดรูปภาพต้นฉบับให้เข้ากับพื้นที่แสดงผลจริงที่ใหญ่ที่สุด
2. แปลงรูปถ่ายและกราฟิกผสมเป็น WebP หรือ AVIF
3. เพิ่ม srcset และ sizes สำหรับเลย์เอาต์มือถือ
4. กำหนดขนาดรูปภาพหรืออัตราส่วนภาพ
5. ให้รูปภาพ LCP อยู่ในสถานะพร้อมใช้งานทันที
6. ใช้ lazy load เฉพาะกับรูปภาพที่อยู่ต่ำกว่าส่วนที่มองเห็นได้ (below-fold) เท่านั้น
7. เผยแพร่ผ่าน CDN ที่มีการแคชแบบมีอายุยาวนาน
8. ทดสอบหน้าเว็บบน viewport มือถือที่แคบ

หากคุณต้องการลำดับที่ครอบคลุมกว่านี้ Complete Image Optimization Checklist เป็นการตรวจสอบรอบสุดท้ายที่ดีก่อนเผยแพร่ สำหรับกฎของ CDN และ cache headers ให้ใช้ Image CDN Guide

สิ่งที่คุณควรทดสอบก่อนเผยแพร่คืออะไร?

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

ให้รันการตรวจสอบก่อนเผยแพร่ดังนี้:

• รูปภาพส่วนปกหรือฮีโร่ต้องโหลดอย่างเร่งด่วน (eagerly).
• รูปภาพที่น่าจะเป็น LCP ต้องไม่ถูกกำหนด loading="lazy".
• ทุกรูปภาพต้องมี width และ height หรือคอนเทนเนอร์ที่มีอัตราส่วนคงที่.
• รูปภาพใต้ขอบ (below-fold) ต้องใช้ loading="lazy".
• รูปภาพแบบ responsive ต้องมีค่า sizes ที่สมจริง.
• URL ของรูปภาพจาก CDN ต้องคืนค่า HTTP 200.
• ชื่อไฟล์ต้องอธิบายถึงรูปภาพที่มองเห็นได้.
• ข้อความ alt ต้องเฉพาะเจาะจงและไม่ได้ยัดไส้ด้วยคีย์เวิร์ด.
• Lighthouse หรือ PageSpeed Insights ต้องไม่ระบุรูปภาพแบบ lazy ว่าเป็น LCP.
• ภาพหน้าจอจากมือถือต้องไม่มีช่องว่างขนาดใหญ่หรือการกระโดดของเลย์เอาต์.

สำหรับทีมพัฒนา ควรเพิ่มกฎในเทมเพลต: เฉพาะส่วนประกอบรูปภาพเนื้อหาที่ทำซ้ำเท่านั้นที่ควรโหลดแบบ lazy เป็นค่าเริ่มต้น ส่วนประกอบฮีโร่, สื่อหลักของผลิตภัณฑ์, และรูปภาพบทความเหนือขอบ (above-the-fold) ต้องมีการตัดสินใจอย่างชัดเจน.

Lazy-loading checklist สำหรับปี 2026

Lazy loading ทำงานได้ดีที่สุดเมื่อเป็นส่วนเล็ก ๆ ของ image pipeline มันควรมาหลังจากการตรวจสอบ format, dimensions, priority, accessibility, และ CDN

ก่อนเผยแพร่ ให้ตรวจสอบ viewport แรกและถามคำถามเชิงปฏิบัติหนึ่งข้อ: หน้าเว็บยังคงสมเหตุสมผลหรือไม่หากรูปภาพทุกรูปที่อยู่ below-fold ต้องรอจนกว่าจะเลื่อนหน้าจอ? ถ้าใช่ แสดงว่า lazy loading น่าจะช่วยได้ หากหน้าเริ่มต้นด้วย hero slot ว่างเปล่า ให้แก้ไข priority ก่อนแตะต้องส่วนอื่นใด