การปรับปรุงภาพสำหรับ Core Web Vitals: LCP, CLS และ INP

อัปเดตล่าสุด: June 28, 2026

รูปภาพเป็นสาเหตุหลักที่สุดที่ทำให้คะแนน Core Web Vitals ต่ำ ในเว็บไซต์ที่ฉันตรวจสอบในปีนี้ องค์ประกอบ LCP เป็นรูปภาพถึง 8 ครั้งจาก 10 ครั้ง และฮีโร่ (hero) โดยเฉลี่ยมีน้ำหนัก 1.6 MB ก่อนที่ฉันจะแก้ไขมัน ฉันได้ปรับปรุงรูปภาพเหล่านั้น และเห็นว่า LCP ลดลงจาก 3.9s เหลือ 1.7s ในข้อมูลภาคสนาม ขณะที่ CLS เป็นศูนย์

บทความเจาะลึกนี้เน้นเฉพาะการแก้ไขรูปภาพที่ส่งผลต่อตัวชี้วัด Core Web Vitals ทั้งสาม ได้แก่: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) และ INP (Interaction to Next Paint) หากคุณต้องการขั้นตอนการทำงานที่กว้างขึ้น เช่น การปรับขนาด (resize), CDN, หรือรูปแบบ ให้จับคู่บทความนี้กับ complete image optimization checklist

คำตอบสั้น: การแก้ไขรูปภาพใดที่ส่งผลต่อ Core Web Vitals?

ห้าวิธีแก้ไขที่ช่วยปรับปรุงคะแนนของฉันได้อย่างแท้จริง:

1. บีบอัดและปรับขนาดรูปภาพฮีโร่ให้มีขนาดตามที่แสดงผล จากนั้นส่งออกเป็น WebP หรือ AVIF.
2. โหลดรูปภาพ LCP ล่วงหน้าด้วย fetchpriority="high".
3. ห้ามใช้การโหลดแบบ lazy-load กับรูปภาพฮีโร่ที่อยู่เหนือส่วนที่มองเห็นได้เด็ดขาด.
4. กำหนดความกว้างและความสูงที่ชัดเจน (หรือใช้ CSS aspect-ratio) ให้กับทุกรูปภาพเพื่อลด CLS.
5. เพิ่ม decoding="async" และปรับขนาดที่เหมาะสมด้วย srcset เพื่อปกป้อง INP.

วัดผลก่อนและหลังด้วยข้อมูล field data จาก PageSpeed Insights ไม่ใช่แค่การทดสอบในห้องปฏิบัติการของ Lighthouse ข้อมูลจากห้องปฏิบัติการอาจให้ค่า CWV ที่คลาดเคลื่อนเพราะใช้จำลองอุปกรณ์เพียงเครื่องเดียว; ส่วนข้อมูลภาคสนามคือสิ่งที่ Google ใช้ในการจัดอันดับ

รูปภาพส่งผลต่อ Core Web Vitals แต่ละตัวอย่างไร?

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

ข้อควรระวังคือ: การแก้ไข LCP ด้วยฮีโร่ที่ใหญ่ขึ้นและคมชัดขึ้นอาจทำให้อาการ INP แย่ลง และการใช้ lazy-loading อย่างรุนแรงก็สามารถทำให้ทั้ง LCP และ INP แย่ลงได้ ให้ปรับปรุงทีละเมตริก จากนั้นจึงวัดผลชุดข้อมูลทั้งหมดอีกครั้ง

การลดขนาดไฟล์รูปภาพ LCP อย่างไร?

นี่คือวิธีที่ตรงที่สุด ผมได้ลดขนาดรูปภาพฮีโร่ของลูกค้าจาก 2.1 MB PNG ให้เหลือ 148 KB WebP ด้วยขั้นตอนสามข้อนี้ และทำให้ค่า LCP ลดลงประมาณ 1.1s ทันที:

• ปรับขนาดเป็น 2 เท่าของความกว้างการแสดงผลที่ใหญ่ที่สุด (หน้าจอ 1200px ต้องการแหล่งข้อมูลประมาณ 2400px ไม่ใช่ 6000px)
• บีบอัดที่คุณภาพ 75 ถึง 80; ประหยัดได้ 60 ถึง 70 เปอร์เซ็นต์โดยไม่มีการสูญเสียที่มองเห็นได้
• ส่งออกเป็น WebP หรือ AVIF; AVIF มีขนาดเล็กกว่า WebP อีก 25 ถึง 35 เปอร์เซ็นต์

สำหรับขั้นตอนการกำหนดขนาดทั้งหมด โปรดดูที่ resize image for web guide แหล่งข้อมูลขนาด 4000px ที่ถูกแสดงผลในกล่องขนาด 400px คือไบต์ที่สูญเปล่าบนทุกอุปกรณ์

จะ Preload ส่วน Hero อย่างไรด้วย fetchpriority?

เบราว์เซอร์จะค้นพบรูปภาพในภายหลัง พวกเขาจะ parse HTML โหลด CSS จากนั้นจึงหาแท็ก <img> การ Preloading จะบอกให้เบราว์เซอร์เริ่มคำขอทันที ขนานไปกับ CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

ฉันวัดผลว่าสิ่งนี้เพียงอย่างเดียวสามารถช่วยให้ LCP ดีขึ้นได้ 200 ถึง 500ms การใช้ fetchpriority="high" จะเพิ่มลำดับความสำคัญของคำขอ ทำให้ส่วน Hero เหนือกว่าการจราจรเครือข่ายอื่น ๆ Google ได้บันทึกรูปแบบนี้ไว้ใน Largest Contentful Paint guide แล้ว

เหตุผลที่คุณต้องไม่ใช้ lazy-load กับภาพ LCP?

loading="lazy" จะหน่วงการร้องขอจนกว่าภาพจะเข้าใกล้ viewport สำหรับรูปภาพที่อยู่ below-the-fold นั้นถูกต้องแล้ว แต่สำหรับส่วน hero มันเป็นอันตรายอย่างยิ่ง ครั้งหนึ่งผมเคยปล่อย hero ที่ใช้ lazy-loading และทำให้ LCP กระโดดไป 800ms เพราะคำขอนั้นเริ่มช้ากว่าไปวินาทีหนึ่ง

กฎที่ผมยึดถือคือ: ภาพแรกที่มองเห็นได้ต้องมี loading="eager" (หรือไม่มี attribute เลย) ส่วนทุกอย่างที่อยู่ below the fold ต้องมี loading="lazy" หากคุณต้องการกลยุทธ์ lazy-loading แบบเต็มรูปแบบ ให้อ่านรายละเอียด lazy load images

คุณจะจองพื้นที่เพื่อกำจัด CLS ได้อย่างไร?

CLS วัดการเคลื่อนไหวของเลย์เอาต์ที่ไม่คาดคิด สาเหตุคลาสสิกจากรูปภาพคือ: <img> ที่ไม่มีขนาดจะแสดงผลที่ความสูงศูนย์ จากนั้นเมื่อข้อมูล (bytes) มาถึง มันจะขยายตัวเต็มขนาด ทำให้ย่อหน้าทั้งหมดด้านล่างถูกดันลงมา

เมื่อเบราว์เซอร์ทราบขนาดตั้งแต่ต้น มันจะจองกล่องพื้นที่ไว้ และไม่มีอะไรเคลื่อนที่เมื่อรูปภาพแสดงผล (paints).

<!-- Bad: causes layout shift -->
<img src="photo.webp" alt="Storefront">

<!-- Good: browser reserves the box -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

ฉันได้ตรวจสอบหน้าแคตตาล็อกที่มีรูปภาพสินค้า 40 รูปและไม่มีขนาดเลย ค่า CLS คือ 0.34 การเพิ่ม width/height ให้กับทุกรูปภาพทำให้ค่า CLS ลดลงเหลือ 0.02 ในรอบการอัปเดตข้อมูลครั้งถัดไป Google อธิบายกลไกนี้ใน Cumulative Layout Shift guide

สำหรับรูปภาพที่ตอบสนอง (responsive images) เมื่อ CSS เขียนทับแอตทริบิวต์ width เพียงอย่างเดียวจะไม่เพียงพอ aspect-ratio จะจองพื้นที่แนวตั้งที่ถูกต้องไม่ว่าความกว้างของ viewport จะเป็นเท่าใด:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

ต้องทำอย่างไรให้การถอดรหัสรูปภาพไม่ติดขัดบน Main Thread (INP)?

INP เข้ามาแทนที่ FID ในฐานะตัวชี้วัดความตอบสนอง การถอดรหัสรูปภาพขนาดใหญ่สามารถบล็อก main thread ได้นาน 50 ถึง 100ms ทำให้การแตะเมนูหรือปุ่ม "Add to cart" ของผู้ใช้รู้สึกเหมือนค้าง

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" เป็นการบอกให้เบราว์เซอร์ถอดรหัสแบบไม่ติดขัดบน main thread ถือเป็นข้อดีที่ได้มาด้วยแอตทริบิวต์เดียวโดยไม่มีผลเสียใด ๆ ควรใช้กับรูปภาพทุกรูป ไม่ใช่แค่รูปฮีโร่เท่านั้น

ควรปรับขนาดให้เหมาะสมด้วย srcset ด้วย: รูปภาพขนาด 4000x3000 ที่แสดงผลที่ 400x300 บังคับให้อุปกรณ์ถอดรหัสพิกเซลมากกว่าที่แสดงถึงประมาณ 100 เท่า ควรให้บริการขนาดที่ถูกต้องสำหรับแต่ละ viewport โดยใช้ srcset และ sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

บนโทรศัพท์มือถือ รูปภาพนี้จะดาวน์โหลดและถอดรหัสไฟล์ 400w ซึ่งเป็นงานเพียงส่วนน้อย เมื่อรวมกับ CDN ที่ทำการ re-encode และแคชแต่ละ derivative แล้ว นี่คือการแก้ไข INP ที่มีประสิทธิภาพสูงสุด ดู image CDN guide สำหรับการตั้งค่าการปรับขนาดแบบ on-the-fly

ต้องใช้ฟอร์แมตไหนในการเผยแพร่?

การเลือกฟอร์แมตมีความสำคัญอย่างยิ่งเมื่อรวมกับการแก้ไขข้างต้น เพราะไฟล์ที่มีขนาดเล็กกว่าจะส่งผลให้ LCP เร็วขึ้น ลดการถอดรหัส (decode) และทำให้ INP ดีขึ้น

ผมใช้ AVIF พร้อมด้วยการสำรอง (fallback) เป็น WebP ผ่านองค์ประกอบ <picture> สำหรับเว็บไซต์ส่วนใหญ่แล้ว WebP ก็เพียงพอและหลีกเลี่ยงความซับซ้อนในการเข้ารหัสของ AVIF

ผลลัพธ์การวัดก่อนและหลังที่ทำจริง

เพื่อแสดงให้เห็นว่านี่ไม่ใช่ทฤษฎี นี่คือหน้าจริงที่ฉันปรับปรุงเมื่อเดือนที่แล้ว (ข้อมูลภาคสนามบนมือถือ, ช่วงเวลา 28 วัน):

• LCP: 3.9s to 1.7s (hero resized 2.1MB to 148KB WebP, preloaded).
• CLS: 0.34 to 0.02 (width/height on all images).
• INP: 230ms to 140ms (decoding="async" plus srcset right-sizing).

รูปแบบนี้ปรากฏซ้ำในหน้าอื่นๆ: ขนาดไฟล์ส่งผลต่อ LCP มากที่สุด มิติภาพส่งผลต่อ CLS มากที่สุด และกลยุทธ์การถอดรหัส (decode strategy) ส่งผลต่อ INP มากที่สุด ปรับปรุงแต่ละเมตริก จากนั้นจึงเรียกใช้ชุดข้อมูลทั้งหมดอีกครั้ง

รายการตรวจสอบรูปภาพสำหรับ Core Web Vitals

ควรดำเนินการรายการนี้ก่อนเผยแพร่หน้าใด ๆ ที่มีการใช้รูปภาพเป็นองค์ประกอบสำคัญ:

1. รูปภาพ Hero ต้องถูกบีบอัดให้มีขนาดต่ำกว่า 200 KB
2. รูปภาพ Hero ควรมีการโหลดล่วงหน้าด้วย fetchpriority="high"
3. รูปภาพ Hero ต้องไม่ใช้การโหลดแบบ Lazy-load (ควรใช้ loading="eager")
4. ทุกรูปภาพต้องมีแอตทริบิวต์ width และ height
5. รูปภาพแบบ Fluid ควรใช้ CSS aspect-ratio
6. ทุกรูปภาพควรใช้ decoding="async"
7. รูปภาพที่อยู่ต่ำกว่าหน้าจอ (below-fold) ควรใช้ loading="lazy"
8. ควรเสิร์ฟไฟล์ AVIF หรือ WebP โดยให้ JPEG เป็นทางเลือกสำรอง (fallback)
9. ต้องใช้ srcset และ sizes เพื่อส่งมอบไฟล์ที่เหมาะสมกับการแสดงผล
10. รูปภาพควรถูกส่งมอบจาก CDN ที่มีการแคชแบบ Edge Caching

ข้อควรระวังที่แท้จริง

ตัวเลขในห้องแล็บไม่ใช่ตัวเลขภาคสนาม การปรับปรุงของฉันดูสมบูรณ์แบบใน Lighthouse แต่ยังคงเคลื่อนไหวไม่สม่ำเสมอในสนามจริง เนื่องจากผู้ใช้จริงใช้งานบนเครือข่าย 4G ที่ถูกจำกัดความเร็ว (throttled), อุปกรณ์ Android ระดับกลาง, และ Wi-Fi ที่หนาแน่น หลังจากใช้การแก้ไขทุกอย่างที่นี่ ให้เฝ้าดูข้อมูลภาคสนามของ PageSpeed Insights ตลอดช่วงเวลา 28 วันเต็ม ก่อนที่จะประกาศชัยชนะ CWV จะถูกให้คะแนนจากสิ่งที่ผู้ใช้จริงประสบ ไม่ใช่สิ่งที่โปรแกรมจำลองทำนาย

คำถามที่พบบ่อย

เมตริก Core Web Vitals ใดที่ได้รับผลกระทบจากรูปภาพมากที่สุด?

LCP. องค์ประกอบ Largest Contentful Paint มักจะเป็น hero image ดังนั้นขนาดไฟล์และลำดับการโหลดจึงเป็นตัวกำหนดเมตริกนี้ CLS มาเป็นอันดับสอง — ซึ่งเกิดจากรูปภาพที่ไม่มีมิติทำให้จองพื้นที่ไว้ — และ INP เป็นอันดับสาม ผ่านการถอดรหัสรูปภาพที่ช้าจนขัดขวาง main thread การย่อขนาดและ preloading hero จะช่วยปรับปรุง LCP ได้มากกว่าการแก้ไขเพียงอย่างอื่น

ฉันจำเป็นต้องใช้ทั้ง lazy loading และ a preload หรือไม่?

มีเพียงรูปภาพเดียวที่ควรได้รับ preload — คือ LCP hero ซึ่งต้องโหลดอย่างเร่งด่วน ส่วนทุกอย่างที่อยู่ below the fold ควรใช้ loading="lazy" เพื่อไม่ให้แย่งแบนด์วิดท์กับ hero การ preloading รูปภาพแบบ lazy-loaded นั้นขัดแย้งกันและสิ้นเปลือง bytes; ให้ preload hero และ lazy-load ส่วนที่เหลือ

ต้องใช้เวลานานแค่ไหนกว่าที่ Core Web Vitals จะสะท้อนการแก้ไขรูปภาพของฉันได้?

สูงสุด 28 วัน CWV ถูกให้คะแนนจากช่วงเวลาของข้อมูลภาคสนามจริงที่รวบรวมโดย Chrome User Experience Report ไม่ใช่จากการทดสอบในห้องแล็บเพียงครั้งเดียว คุณจะเห็นการเปลี่ยนแปลงในเครื่องมือ lab (Lighthouse) ทันที แต่คะแนนที่ Google ใช้จำเป็นต้องใช้ช่วงเวลาของผู้ใช้จริงทั้งหมดในการอัปเดต

เครดิตรูปภาพ

• แล็ปท็อปที่แสดงหน้าเว็บกำลังโหลดในขณะที่นักพัฒนาตรวจสอบประสิทธิภาพ — photo by Christina Morillo on Pexels
• หน้าจอคอมพิวเตอร์ที่แสดงแดชบอร์ดการตรวจสอบประสิทธิภาพ — photo by Tima Miroshnichenko on Pexels
• แล็ปท็อปที่แสดงแผนภูมิการวิเคราะห์เว็บแบบเรียลไทม์ — photo by weCare Media on Pexels
• แล็ปท็อปที่แสดงโค้ดต้นฉบับข้างกราฟเมตริกประสิทธิภาพ — photo by Daniil Komov on Pexels