การดึงภาพสำคัญสำหรับ LCP และ SEO

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

Critical image extraction หมายถึงการค้นหาภาพเดียวที่เป็นตัวกำหนดความประทับใจทางสายตาแรกของหน้าเว็บ ในหน้า product pages, landing pages, และบทความบล็อกจำนวนมาก ภาพนั้นคือภาพฮีโร่ (hero), รูปถ่ายผลิตภัณฑ์หลัก, หรือภาพประกอบขนาดใหญ่ที่อยู่เหนือส่วนพับ (above-the-fold) หากคุณระบุภาพนั้นได้ตั้งแต่เนิ่นๆ คุณสามารถ preload หรือจัดลำดับความสำคัญของไฟล์ที่ถูกต้อง แทนที่จะเร่งความเร็วให้ทุกรูปอย่างเท่าเทียมกัน

คำตอบสั้น ๆ: วิธีดึงภาพสำคัญคืออะไร?

ใช้การดึงภาพสำคัญเพื่อระบุว่ารูปภาพใดมีแนวโน้มที่จะเป็นองค์ประกอบ Largest Contentful Paint มากที่สุด จากนั้นให้การโหลดไฟล์นั้นด้วยวิธีการพิเศษ โดยปกติแล้วหมายความว่ารูปภาพที่มองเห็นได้ขนาดใหญ่ที่สุดใน initial viewport จะได้รับ fetchpriority="high", ไม่มีการ lazy loading, มี dimensions ที่เสถียร และบางครั้งก็ใช้ <link rel="preload">.

อย่า preload ไฟล์ขนาดใหญ่ทุกไฟล์ ให้ preload รูปภาพ hero หรือ product เฉพาะเมื่อเบราว์เซอร์จะค้นพบมันช้า เช่น ภายใน CSS, carousel, client-rendered component, หรือ responsive <picture> stack ที่มีการเลือก source ที่ซับซ้อน

หลังจากเปลี่ยนแปลงแล้ว ให้ตรวจสอบผลลัพธ์ Google's Largest Contentful Paint documentation กำหนด LCP รอบองค์ประกอบเนื้อหาที่มองเห็นได้ขนาดใหญ่ที่สุด และ PageSpeed Insights จะแสดงว่าวัดค่าองค์ประกอบใด Chrome DevTools ควรแสดงคำขอ critical image ตั้งแต่เนิ่น ๆ ใน waterfall

ใช้ลำดับนี้:

1. โหลดหน้าเว็บที่ mobile viewport ที่สมจริง
2. ค้นหารูปภาพหรือโปสเตอร์ขนาดใหญ่ที่สุดเหนือส่วนพับ (above-the-fold)
3. ตรวจสอบว่า PageSpeed หรือ Lighthouse รายงานว่าเป็น LCP หรือไม่
4. ลบ loading="lazy" ออกจากรูปภาพนั้น
5. เพิ่ม dimensions หรืออัตราส่วนภาพ (aspect ratio)
6. เพิ่ม fetchpriority="high" เมื่อเป็น <img>
7. Preload เฉพาะเมื่อการค้นพบเกิดขึ้นช้า
8. ให้รูปภาพที่อยู่ใต้ส่วนพับ (below-fold) เป็นแบบ lazy
9. ทดสอบซ้ำหลังจากมีการเปลี่ยนแปลง layout, CMS หรือข้อความ hero

อะไรที่นับว่าเป็นภาพสำคัญ?

ภาพสำคัญ (critical image) คือภาพที่ผู้เยี่ยมชมรอคอยจนกว่าหน้าเว็บจะรู้สึกว่ามีประโยชน์ โดยส่วนใหญ่มักจะเป็นองค์ประกอบ LCP แต่ก็ไม่เสมอไป โลโก้ขนาดเล็กที่ด้านบนของหน้าอาจโหลดก่อนได้ แต่มันแทบจะไม่ควบคุมความพร้อมที่รับรู้ได้เลย ภาพฮีโร่ (hero image) ที่กินพื้นที่ครึ่งหน้าจอโทรศัพท์มักจะทำหน้าที่นี้

ควรใช้ขนาดที่แสดงผล ตำแหน่งใน viewport และวัตถุประสงค์ร่วมกัน ภาพขนาดย่อ (thumbnail) ในเมนูนำทางนั้นมองเห็นได้ แต่ไม่ใช่เนื้อหาหลัก ภาพพื้นหลังด้านหลังหัวข้ออาจเป็นภาพสำคัญหากมันเป็นองค์ประกอบที่ใหญ่ที่สุดที่มองเห็นได้ ภาพการ์ดโซเชียลใน metadata มีความสำคัญสำหรับการแชร์ แต่จะไม่ถูกเรียกใช้สำหรับหน้าเว็บที่แสดงผล เว้นแต่ว่า template นั้นจะแสดงมันด้วย

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

สำหรับงานอื่น ๆ ให้เก็บรายการตรวจสอบ image optimization for SEO ไว้ใกล้ ๆ การสกัดภาพสำคัญจะตัดสินลำดับความสำคัญ แต่การบีบอัด ชื่อไฟล์ alt text และ structured content ยังคงเป็นตัวกำหนดว่าภาพนั้นมีประโยชน์หรือไม่หลังจากที่มันโหลดแล้ว

รูปภาพใดควรได้รับการ preload หรือ high priority?

ให้ความสำคัญสูงกับรูปภาพเพียงรูปเดียว: ซึ่งน่าจะเป็นรูปภาพ LCP ของหน้าปัจจุบัน หากมีตัวเลือกที่ใกล้เคียงกันสองตัว เลือกตัวที่ใหญ่ที่สุดสำหรับอุปกรณ์มือถือก่อน เนื่องจาก Core Web Vitals บนมือถือมักจะผ่านได้ยากกว่า

ใช้ fetchpriority="high" เมื่อรูปภาพที่สำคัญเป็นแท็ก <img> ปกติ หรือเป็น <img> สำรองในองค์ประกอบ <picture> คำแนะนำ fetch priority guidance ของ Google อธิบายว่าคำแนะนำนี้จะเปลี่ยนลำดับความสำคัญของทรัพยากรของเบราว์เซอร์โดยที่ไม่ได้เปลี่ยนแปลงเส้นทางในการค้นพบ markup

ใช้ preload เมื่อปัญหาคือการค้นพบ (discovery) MDN rel="preload" reference อธิบายว่า preload เป็นวิธีในการร้องขอทรัพยากรให้เร็วขึ้นในระหว่างที่หน้ากำลังโหลด ซึ่งมีประโยชน์เมื่อ URL ของรูปภาพปรากฏอยู่ใน CSS, มาถึงหลังจาก hydration, หรืออยู่หลัง markup ที่เบราว์เซอร์ไม่สามารถค้นพบได้ทันเวลา

สำหรับรูปภาพแบบ responsive ทั่วไป โครงสร้าง markup อาจมีลักษณะดังนี้:

หากรูปภาพเป็นพื้นหลังของ CSS และคุณยังไม่สามารถย้ายมันไปที่ HTML ได้ ให้ทำการ preload ทรัพยากรเดียวกับที่ initial viewport จะใช้:

คู่มือ image preloading guide ครอบคลุมไวยากรณ์ในรายละเอียดมากขึ้น กฎที่สำคัญที่นี่แคบกว่านั้นคือ: ให้ preload หลังจากทำการดึงข้อมูล (extraction) ไม่ใช่ก่อนหน้านั้น

คุณจะหลีกเลี่ยงการ lazy-loading รูปภาพผิดได้อย่างไร?

Lazy loading ควรอยู่ต่ำกว่า viewport แรก การทำเช่นนี้เป็นข้อผิดพลาดในการดึงรูปภาพที่สำคัญ (critical image) เพราะมันบอกให้เบราว์เซอร์รอจนกว่าการตรวจสอบ layout และระยะห่างจะเกิดขึ้น Google's browser-level lazy loading guide เตือนไม่ให้ใช้ lazy-loading กับรูปภาพที่มองเห็นได้ทันที

ควรตรวจสอบองค์ประกอบรูปภาพทั่วทั้งเว็บไซต์อย่างรอบคอบ เฟรมเวิร์กหลายตัวทำให้การ lazy loading เป็นค่าเริ่มต้น (default) เพราะรูปภาพส่วนใหญ่อยู่ต่ำกว่า fold ค่า default นี้จะทำลายหน้าเว็บที่มี hero image ถูกห่อด้วย component เดียวกับ gallery thumbnails

โปรดตรวจสอบในจุดเหล่านี้:

1. ตัวเรนเดอร์รูปภาพ rich-text ของ CMS
2. Component แกลเลอรีสินค้า (Product gallery components)
3. Component รูปภาพปกบล็อก (Blog cover image components)
4. ส่วนประกอบพื้นหลัง hero ของหน้าแรก (Homepage hero background utilities)
5. สไลด์โชว์ที่ซ่อนสไลด์ทั้งหมดจนกว่า JavaScript จะทำงาน
6. Placeholder components ที่เปลี่ยน data-src เป็น src
7. บล็อกการปรับแต่งเฉพาะบุคคลของ Third-party
8. Wrapper สำหรับ A/B testing ที่หน่วง markup ของ hero

วิธีแก้ไขมักจะเล็กน้อย เพิ่มตัวเลือก priority, aboveFold, หรือ isLcp ให้กับ component นั้น และให้เจ้าของ template เลือกอย่างชัดเจน รูปภาพในส่วน body ที่อยู่ต่ำกว่า fold ควรยังคงใช้ native lazy loading โดยเฉพาะคู่มือยาวที่มี screenshot และ diagram

สำหรับหน้าเว็บที่เน้นการใช้งานบนมือถือ (mobile-heavy pages) ให้จับคู่สิ่งนี้กับการ mobile image optimization guide Hero ที่มีการจัดลำดับความสำคัญอย่างถูกต้องก็ยังคงมีประสิทธิภาพต่ำ หากโทรศัพท์ดาวน์โหลดภาพครอปแบบ desktop ขนาด 2400 px สำหรับช่องขนาด 390 px

ต้องดึงรูปภาพจากหน้าเว็บจริงอย่างไร?

เริ่มต้นที่เบราว์เซอร์ ไม่ใช่ในไลบรารีสินทรัพย์ (asset library) ไลบรารีสินทรัพย์บอกคุณว่ามีอะไรอยู่ แต่เบราว์เซอร์จะบอกคุณว่าผู้ใช้ได้รับอะไร

ใช้ขั้นตอนการทำงานด้วยตนเองนี้:

1. เปิดหน้าเว็บที่มีความกว้าง 390 px และโหลดซ้ำโดยปิดใช้งานแคช
2. สังเกตรูปภาพที่ใหญ่ที่สุดที่มองเห็นได้ก่อนที่จะเลื่อนลง
3. ตรวจสอบองค์ประกอบนั้นและบันทึก URL สุดท้ายของมัน
4. ตรวจสอบว่ามันเป็น <img>, <picture>, ภาพโปสเตอร์วิดีโอ, หรือพื้นหลัง CSS
5. ยืนยันความกว้างและความสูงที่แสดงผลแล้ว
6. เปรียบเทียบความกว้างของไฟล์ที่ดาวน์โหลดกับช่องว่างที่แสดงผล
7. มองหา loading="lazy" หรือการกำหนดค่า src ที่ล่าช้าด้วย JavaScript
8. ตรวจสอบ DevTools Network เพื่อดูเวลาเริ่มต้นและลำดับความสำคัญของการร้องขอ
9. รัน PageSpeed Insights และบันทึกองค์ประกอบ LCP
10. ทำซ้ำบนเดสก์ท็อปหากส่วนฮีโร่ (hero) เปลี่ยนแปลงตามจุดหักเห (breakpoint)

สำหรับการตรวจสอบเทมเพลต ให้สร้างตารางการดึงข้อมูลขนาดเล็กก่อนแก้ไขโค้ด:

ฉันสร้างไดอะแกรมในบทความนี้เป็นไฟล์ WebP และเก็บแต่ละไฟล์ให้ต่ำกว่า 40 KB นั่นไม่ใช่เป้าหมายสากลสำหรับรูปถ่าย แต่เป็นเครื่องเตือนใจที่มีประโยชน์: รูปภาพที่ดึงมาควรมีขนาดเหมาะสมก่อนที่จะได้รับลำดับความสำคัญ หากไฟล์ยังใหญ่มาก ให้ใช้ image compression deep dive และ batch resize guide ก่อนเผยแพร่

คุณจะตรวจสอบภาพที่สำคัญในเครื่องมือได้อย่างไร?

การตรวจสอบมีหน้าที่สองอย่าง ประการแรก คือ การพิสูจน์ว่าภาพที่เลือกเป็นองค์ประกอบ LCP จริง หรือเป็นตัวเต็ง LCP ที่มีความสำคัญ ประการที่สอง คือ การพิสูจน์ว่าเบราว์เซอร์ค้นพบมันได้เร็วพอ

ใช้ PageSpeed Insights สำหรับบริบททั้งแบบ field และ lab แผงการวินิจฉัยมักจะระบุองค์ประกอบ LCP และภาพหน้าจอช่วยยืนยันว่าองค์ประกอบที่รายงานนั้นตรงกับ hero ภาพของหน้านั้นหรือไม่ หากคุณต้องการ trace ในเครื่อง ให้ใช้ Lighthouse หรือ DevTools Performance

ใช้ DevTools Network สำหรับพฤติกรรมการร้องขอ:

1. กรองเฉพาะคำขอรูปภาพ
2. โหลดซ้ำโดยปิดการใช้งาน cache
3. ยืนยันว่าภาพที่สำคัญเริ่มต้นใกล้ส่วนบนของ waterfall
4. ตรวจสอบให้แน่ใจว่า priority เป็น High หรือได้รับการอัปเกรดตั้งแต่เนิ่นๆ
5. ยืนยันว่าภาพ below-fold ไม่ได้แข่งขันกันพร้อมกันทั้งหมด
6. ตรวจสอบ status code, content type, transfer size และ cache headers

ใช้การตรวจสอบ HTML ที่เรนเดอร์แล้วสำหรับข้อผิดพลาดของ markup:

1. ภาพที่สำคัญต้องมี src หรือ srcset ที่ค้นพบได้ใน initial markup
2. มันต้องไม่มี loading="lazy"
3. มันต้องมี width และ height หรืออัตราส่วนภาพ CSS ที่เสถียร
4. alt text ของมันต้องอธิบายหัวข้อที่มองเห็นได้เมื่อรูปภาพนั้นเป็นเนื้อหา
5. URL ของ CDN ต้องส่งการตอบกลับแบบ crawlable 200

สำหรับการค้นหา image SEO best practices ของ Google ยังเน้นย้ำถึงชื่อไฟล์ที่สื่อความหมาย, alt text และข้อความรอบข้างที่มีประโยชน์ การดึงภาพที่สำคัญช่วยปรับปรุงลำดับความสำคัญในการโหลด แต่รูปภาพเดียวกันยังคงต้องการบริบทการค้นหา

สิ่งใดที่ทำให้การดึงภาพที่สำคัญล้มเหลว?

ความล้มเหลวที่พบบ่อยที่สุดคือการปฏิบัติต่อทุกหน้าเหมือนว่ามีภาพฮีโร่ (hero) เดียวกัน หน้าดัชนีบล็อก, หน้าผลิตภัณฑ์, และหน้าการกำหนดราคา อาจมี LCP candidates ที่แตกต่างกัน ขั้นตอนการดึงข้อมูลจะต้องเกิดขึ้นในระดับเทมเพลตและระดับ breakpoint

ระวังกับดักเหล่านี้:

1. การ Preloading ภาพ Open Graph ภาพการ์ดโซเชียลอาจไม่เคยแสดงผลบนหน้าเลย
2. การ Lazy-loading ภาพผลิตภัณฑ์แรก แกลเลอรีผลิตภัณฑ์มักจะสืบทอดค่าเริ่มต้นของภาพขนาดย่อ (thumbnail)
3. การให้ความสำคัญกับทุกสไลด์ในแกลเลอรีแบบหมุน มีเพียงสไลด์แรกที่มองเห็นได้เท่านั้นที่เป็นสิ่งสำคัญเมื่อโหลด
4. การละเลยภาพตัดสำหรับมือถือ (mobile crops) เดสก์ท็อปและมือถือสามารถเลือกภาพ LCP ที่แตกต่างกันได้
5. การใช้พื้นหลัง CSS สำหรับเนื้อหาที่มีความหมาย สิ่งเหล่านี้ยากต่อการให้ความสำคัญและเข้าถึงได้น้อยกว่า
6. การลืมกำหนดขนาด (dimensions) การให้ความสำคัญไม่ได้ป้องกัน layout shift
7. การส่งแหล่งที่มาที่มีขนาดใหญ่เกินไป ภาพขนาด 3 MB ที่มีความสำคัญสูงก็ยังช้าอยู่ดี
8. การทดสอบเฉพาะบน Wi-Fi ในพื้นที่ท้องถิ่น 4G ที่ช้าจะเผยให้เห็นความล่าช้าในการค้นพบ

หากปัญหาหลักคือขนาดไฟล์ ให้เริ่มต้นด้วย complete image optimization checklist หากปัญหาคือการเลือกรูปแบบ (format choice) ให้เปรียบเทียบ AVIF vs WebP ก่อนเปลี่ยนกฎการส่งมอบ

สรุป: รายการตรวจสอบการดึงภาพที่สำคัญ (critical image extraction)

Critical image extraction เป็นการตัดสินใจด้านความเร็วของหน้าเว็บ ไม่ใช่เพียงแค่การกำหนดชื่อสินทรัพย์ ค้นหาภาพที่ควบคุมมุมมองแรก (first viewport) ให้การโหลดล่วงหน้าเฉพาะภาพนั้น และป้องกันไม่ให้ส่วนอื่น ๆ ของหน้าเว็บมาแย่งทรัพยากรกับมัน

ก่อนการเผยแพร่ โปรดยืนยันว่า:

1. ภาพที่น่าจะเป็น LCP ถูกระบุชื่อไว้ในเทมเพลตหรือบันทึกการตรวจสอบแล้ว
2. ได้มีการตรวจสอบภาพสำหรับมือถือและเดสก์ท็อปแยกกัน
3. ภาพที่สำคัญ (critical image) ไม่ได้ถูกตั้งค่าให้โหลดแบบ lazy-loaded
4. มีการใช้ fetchpriority="high" สำหรับภาพ <img> ที่เป็นตัวเลือก LCP และมองเห็นได้
5. ใช้ Preload เมื่อทราบข้อมูลล่าช้าเท่านั้น
6. ไฟล์ที่เลือกถูกปรับขนาดและบีบอัดแล้ว
7. มีการสงวนพื้นที่เลย์เอาต์ด้วยความกว้างและความสูง หรืออัตราส่วนภาพ (aspect ratio)
8. ภาพที่อยู่ต่ำกว่าหน้าจอพับ (below-fold) ยังคงเป็นแบบ lazy load
9. PageSpeed Insights รายงานองค์ประกอบ LCP ที่คาดหวังได้
10. DevTools แสดงคำขอภาพที่สำคัญตั้งแต่ช่วงต้นของ waterfall
11. URL ของ CDN ส่งคืนค่า 200 พร้อมประเภทภาพที่คาดหวัง
12. ภาพมีข้อความ alt ที่เป็นประโยชน์และเนื้อหาอธิบายใกล้เคียง

ตัวอย่างโค้ดที่เก็บรักษาไว้

<img
  src="/images/product-hero-960.webp"
  srcset="/images/product-hero-480.webp 480w, /images/product-hero-960.webp 960w, /images/product-hero-1440.webp 1440w"
  sizes="(max-width: 640px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="Black leather backpack shown open with laptop sleeve visible"
>

<link
  rel="preload"
  as="image"
  href="/images/home-hero-960.webp"
  imagesrcset="/images/home-hero-480.webp 480w, /images/home-hero-960.webp 960w"
  imagesizes="100vw"
>