LCP คืออะไร เกณฑ์ผ่านเท่าไหร่ แก้ยังไงให้เนื้อหาหลักโหลดเร็ว

LCP คืออะไร และวัดอะไรกันแน่

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

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

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

element แบบไหนที่ถูกนับเป็น LCP

ไม่ใช่ทุกอย่างบนหน้าจะมีสิทธิ์เป็น LCP ชนิดที่ถูกนับได้แก่ แท็กรูป img, รูปที่อยู่ใน svg ผ่านแท็ก image, แท็ก video ซึ่งนับจากรูป poster หรือเฟรมแรกที่แสดงผล, element ที่มีรูปพื้นหลังโหลดผ่าน url() ใน CSS และ element ระดับบล็อกที่มีข้อความอยู่ข้างใน เช่นหัวข้อหรือย่อหน้า

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

สิ่งที่เบราว์เซอร์ไม่นับเป็น LCP

Chrome มีกฎตัดบางอย่างออกเพื่อไม่ให้ค่าเพี้ยน เช่น element ที่โปร่งใสทั้งหมดจนมองไม่เห็น รูปที่กินพื้นที่เต็มหน้าจอจนถือว่าเป็นพื้นหลังมากกว่าเนื้อหา และรูปที่มีรายละเอียดต่ำมากแบบภาพเบลอหรือสีพื้นที่ใช้เป็นตัวยึดตำแหน่งระหว่างรอรูปจริง

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

LCP เท่าไหร่ถึงเรียกว่าผ่าน

เกณฑ์ของ LCP คือไม่เกิน 2.5 วินาทีถือว่าดี มากกว่า 2.5 แต่ไม่เกิน 4 วินาทีคือต้องปรับปรุง และมากกว่า 4 วินาทีคือแย่ โดยวัดจาก เปอร์เซ็นไทล์ 75 ของการเปิดหน้าจริง แยกมือถือกับเดสก์ท็อปคนละชุด

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

ควรจำไว้ด้วยว่า LCP ผ่านตัวเดียวไม่ได้แปลว่า Core Web Vitals ผ่าน หน้าหนึ่งจะถือว่าผ่านต้องได้เกณฑ์ดีครบทั้ง LCP, INP และ CLS และบางครั้งการแก้ตัวหนึ่งก็กระทบอีกตัว เช่นการ lazy load รูปเพื่อลดน้ำหนักหน้าอาจทำให้รูปหลักมาช้าจน LCP แย่ลง หรือการโหลดรูปโดยไม่ใส่ขนาดอาจทำให้หน้ากระตุก ซึ่งเป็นเรื่องของ CLS ที่ต้องดูควบคู่กันไป

• ดี: ไม่เกิน 2.5 วินาที
• ต้องปรับปรุง: มากกว่า 2.5 วินาที แต่ไม่เกิน 4 วินาที
• แย่: มากกว่า 4 วินาที
• วัดที่เปอร์เซ็นไทล์ 75 ของการเปิดหน้าจริง แยกมือถือกับเดสก์ท็อป
• ต้องผ่านครบทั้ง LCP, INP และ CLS หน้านั้นจึงจะถือว่าผ่าน Core Web Vitals

LCP แบ่งเป็นกี่ส่วน และแต่ละส่วนบอกอะไร

LCP แบ่งได้เป็น 4 ส่วนย่อยต่อกัน คือ TTFB, resource load delay, resource load duration และ element render delay เวลาทั้งสี่ส่วนบวกกันได้เท่ากับค่า LCP พอดี การแยกแบบนี้คือหัวใจของการแก้ LCP เพราะบอกได้ทันทีว่าเวลาหายไปตรงไหน

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

แนวทางที่ทีม Chrome แนะนำไว้ใน web.dev คือ เวลาส่วนใหญ่ควรอยู่ที่ TTFB กับ resource load duration ซึ่งเป็นการรอเครือข่ายที่เลี่ยงไม่ได้ ส่วน resource load delay กับ element render delay ควรเหลือน้อยที่สุด เพราะสองส่วนนี้คือเวลาที่เสียไปเปล่าๆ ระหว่างที่เบราว์เซอร์ยังไม่ได้ทำอะไรกับรูปหลักเลย ถ้าเห็นสองส่วนนี้ยาว แปลว่ามีของบางอย่างขวางทางอยู่

LCP ที่เป็นข้อความมีแค่ส่วนเดียวที่ต้องห่วง

ถ้า LCP ของหน้าเป็นก้อนข้อความ เช่นหัวข้อบทความ ส่วน resource load delay กับ resource load duration จะเป็นศูนย์ เพราะไม่มีไฟล์รูปให้โหลด เวลาทั้งหมดจึงเหลือแค่ TTFB กับ element render delay

กรณีนี้ตัวการที่เจอบ่อยคือฟอนต์ที่ต้องดาวน์โหลดก่อนข้อความจะขึ้น และ CSS ที่ขวางการวาดหน้า ถ้าเบราว์เซอร์ถูกตั้งให้ซ่อนข้อความไว้จนฟอนต์มา LCP ก็จะรอฟอนต์ไปด้วย

ดูค่า 4 ส่วนย่อยได้จากที่ไหน

PageSpeed Insights และ Lighthouse แสดงชื่อ element ที่เป็น LCP พร้อมการแตกเวลาเป็นส่วนย่อยให้ดูได้ ส่วน Chrome DevTools ที่ Performance panel จะแสดงทั้ง element และการแบ่งช่วงเวลาบนเส้นเวลาการโหลดจริง ทำให้เห็นว่าไฟล์ไหนขวางอยู่ในช่วงไหน

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

ทำไม LCP ของเว็บถึงช้า

LCP ช้ามักมาจากสาเหตุไม่กี่กลุ่ม คือเซิร์ฟเวอร์ตอบช้า เบราว์เซอร์เจอรูปหลักช้า ไฟล์รูปหนักเกินจำเป็น และมีไฟล์ CSS หรือ JavaScript ขวางการแสดงผล แต่ละกลุ่มตรงกับส่วนย่อยคนละส่วน จึงต้องแก้คนละจุด

ในเว็บจริงมักเจอหลายข้อพร้อมกัน โดยเฉพาะเว็บที่ใช้ธีมสำเร็จรูปหรือเว็บที่ประกอบหน้าด้วย JavaScript เป็นหลัก ข้อด้านล่างเรียงตามที่เจอบ่อยในงานตรวจเว็บทั่วไป

• เซิร์ฟเวอร์ตอบช้า: โฮสติ้งแรงไม่พอ ไม่มีแคช ฐานข้อมูลช้า หรือมี redirect หลายทอดก่อนถึงหน้าจริง
• รูปหลักถูก lazy load: ปลั๊กอินหรือโค้ดสั่ง loading=lazy กับทุกรูป รวมรูปแบนเนอร์บนสุดด้วย
• รูปหลักถูกเรียกจาก CSS หรือ JavaScript: เบราว์เซอร์มองไม่เห็นจาก HTML จึงเริ่มโหลดช้า
• ไฟล์รูปใหญ่เกินจอ: ส่งรูปกว้างหลายพันพิกเซลไปให้มือถือ หรือยังใช้ JPEG และ PNG ที่ไม่ได้บีบอัด
• CSS และ JavaScript ขวางการวาดหน้า: ไฟล์ใหญ่ที่ต้องโหลดและประมวลผลให้เสร็จก่อนหน้าจะขึ้น
• หน้าประกอบด้วย JavaScript ฝั่งไคลเอนต์: ต้องโหลดและรันสคริปต์ก่อน element หลักจึงจะถูกสร้าง
• สไลด์แบนเนอร์บนสุด: ต้องรอสคริปต์ของสไลด์ก่อนรูปแรกจะแสดง และบางตัวโหลดรูปทุกใบพร้อมกัน

แก้ LCP ยังไงให้เนื้อหาหลักขึ้นเร็ว

หลักการแก้ LCP คือทำให้เบราว์เซอร์ เจอรูปหลักเร็วที่สุด โหลดเร็วที่สุด และวาดได้ทันทีที่โหลดเสร็จ โดยเริ่มจากส่วนย่อยที่กินเวลามากผิดสัดส่วนก่อน

ลำดับที่คุ้มแรงสำหรับเว็บส่วนใหญ่คือ เช็กว่ารูป LCP ถูก lazy load อยู่หรือเปล่า แล้วตามด้วยการบอกเบราว์เซอร์ให้โหลดรูปนั้นก่อน เพราะสองข้อนี้มักแก้ได้ในไม่กี่บรรทัดแต่ลด resource load delay ได้มาก จากนั้นค่อยไล่เรื่องขนาดไฟล์ CSS และ JavaScript และฝั่งเซิร์ฟเวอร์ตามลำดับ

• เอา loading=lazy ออกจากรูปที่เป็น LCP
• ใส่ fetchpriority=high ที่รูป LCP และ preload ถ้ารูปไม่ได้อยู่ใน HTML ตรงๆ
• ใช้ WebP หรือ AVIF และส่งขนาดให้พอดีจอด้วย srcset และ sizes
• ตัด CSS ที่ไม่ได้ใช้ ใส่ defer ให้สคริปต์ที่ไม่จำเป็นต่อจอแรก
• เรนเดอร์เนื้อหาหลักจากฝั่งเซิร์ฟเวอร์ แทนการให้ JavaScript สร้างทีหลัง
• ใช้ CDN และแคช HTML เพื่อลด TTFB และตัด redirect ที่ไม่จำเป็น

1. ห้าม lazy load รูปที่เป็น LCP

loading=lazy บอกเบราว์เซอร์ให้รอจนรูปใกล้เข้ามาในจอก่อนค่อยโหลด ซึ่งดีกับรูปท้ายหน้า แต่กับรูปหลักบนสุดคือการสั่งให้รอโดยไม่จำเป็น เพราะเบราว์เซอร์ต้องคำนวณเลย์เอาต์ก่อนจึงจะรู้ว่ารูปอยู่ในจอ รูปที่เป็น LCP ต้องไม่ใส่ loading=lazy เด็ดขาด

จุดที่พลาดบ่อยคือปลั๊กอินเร่งความเร็วหรือธีมที่ใส่ lazy load ให้ทุกรูปอัตโนมัติ และคอมโพเนนต์รูปของเฟรมเวิร์กที่ตั้งค่าเริ่มต้นเป็น lazy ให้ตรวจที่ระดับเทมเพลตแล้วยกเว้นรูปบนสุดของแต่ละชนิดหน้า

2. ใช้ fetchpriority=high และ preload ให้ถูกที่

ใส่ fetchpriority=high ที่แท็กรูป LCP เพื่อบอกเบราว์เซอร์ว่ารูปนี้สำคัญกว่ารูปอื่น ปกติเบราว์เซอร์จะเริ่มรูปด้วยลำดับความสำคัญต่ำแล้วค่อยปรับขึ้นเมื่อรู้ว่าอยู่ในจอ การใส่ค่านี้ช่วยข้ามขั้นตอนรอนั้น

ถ้ารูป LCP ไม่ได้อยู่ใน HTML ตรงๆ เช่นเป็นรูปพื้นหลังใน CSS หรือถูกใส่ด้วย JavaScript ให้ใช้ link rel=preload ในส่วน head เพื่อให้เบราว์เซอร์เริ่มโหลดตั้งแต่อ่าน HTML ถ้ารูปใช้ srcset ก็ต้องใส่ imagesrcset และ imagesizes ใน preload ให้ตรงกัน ไม่งั้นอาจโหลดผิดขนาดหรือโหลดซ้ำสองไฟล์

ข้อควรระวังคือใช้กับรูป LCP รูปเดียวหรือไม่กี่รูปเท่านั้น ถ้าใส่ความสำคัญสูงให้ทุกอย่าง ก็เท่ากับไม่มีอะไรสำคัญกว่ากัน และไฟล์เหล่านั้นจะไปแย่งแบนด์วิดท์กันเอง

3. ทำไฟล์รูปให้เบาและขนาดพอดีจอ

แปลงรูปเป็น WebP หรือ AVIF ซึ่งโดยทั่วไปไฟล์เล็กกว่า JPEG ที่คุณภาพใกล้เคียงกัน แล้วส่งขนาดให้พอดีกับจอด้วย srcset และ sizes มือถือจะได้ไม่ต้องดาวน์โหลดรูปขนาดเดสก์ท็อป

อย่าลืมใส่ width และ height ให้รูปด้วย เพื่อกันหน้ากระตุกระหว่างรอ รายละเอียดการเตรียมรูปทั้งเรื่องฟอร์แมต ขนาด alt และชื่อไฟล์ อ่านต่อได้ที่ Image SEO คู่มือปรับรูปให้ติดอันดับ

4. ลด CSS และ JavaScript ที่ขวางการแสดงผล

CSS ในส่วน head ขวางการวาดหน้าทั้งหน้า ยิ่งไฟล์ใหญ่ยิ่งรอนาน ให้ตัด CSS ที่ไม่ได้ใช้ออก แยก CSS ที่จำเป็นต่อจอแรกให้เล็กพอจะใส่แบบ inline ได้ และโหลดส่วนที่เหลือทีหลัง ส่วนสคริปต์ที่ไม่จำเป็นต่อการแสดงผลจอแรกให้ใส่ defer หรือ async

เว็บที่ประกอบเนื้อหาด้วย JavaScript ฝั่งไคลเอนต์จะเจอ element render delay ยาวเป็นพิเศษ เพราะรูปหลักยังไม่มีอยู่จริงจนกว่าสคริปต์จะรันเสร็จ ทางแก้ที่ได้ผลคือเรนเดอร์ HTML จากฝั่งเซิร์ฟเวอร์หรือสร้างเป็นหน้าสถิตไว้ล่วงหน้า ซึ่งดีกับการเก็บข้อมูลของ Google ด้วย อ่านเพิ่มได้ที่ JavaScript SEO คืออะไร

5. เร่งฝั่งเซิร์ฟเวอร์ด้วย CDN และแคช

ถ้า TTFB ยาว ทุกอย่างหลังจากนั้นช้าตามหมด เพราะเบราว์เซอร์ยังไม่ได้ HTML ก็ยังไม่รู้ว่าต้องโหลดอะไร ทางแก้หลักคือเสิร์ฟผ่าน CDN ให้ข้อมูลอยู่ใกล้ผู้ใช้ แคช HTML ของหน้าที่ไม่ต้องเปลี่ยนบ่อย ตัด redirect ที่ไม่จำเป็น และดูว่าฐานข้อมูลหรือปลั๊กอินตัวไหนทำให้เซิร์ฟเวอร์ประมวลผลช้า

อีกจุดที่ช่วยได้คือถ้ารูป LCP อยู่บนโดเมนอื่น เช่นเซิร์ฟเวอร์รูปแยก ให้ใช้ preconnect ไปยังโดเมนนั้น หรือย้ายรูปมาไว้บนโดเมนเดียวกันเพื่อตัดเวลาเชื่อมต่อใหม่

วัดค่า LCP ของเว็บตัวเองได้ด้วยเครื่องมืออะไรบ้าง

เครื่องมือหลักมี 4 ตัว คือ PageSpeed Insights สำหรับดูทีละหน้า, Chrome UX Report หรือ CrUX ซึ่งเป็นฐานข้อมูลผู้ใช้จริง, รายงาน Core Web Vitals ใน Google Search Console สำหรับดูภาพรวมทั้งเว็บ และ Chrome DevTools สำหรับไล่หาสาเหตุ ทุกตัวใช้ได้ฟรี

สิ่งที่ต้องแยกให้ออกคือ field data กับ lab data ข้อมูล field มาจากผู้ใช้ Chrome จริงผ่าน CrUX สรุปค่าย้อนหลัง 28 วัน ส่วน lab data อย่าง Lighthouse เป็นการโหลดหน้ารอบเดียวในเงื่อนไขจำลอง ค่าที่ Google ใช้ประเมินคือข้อมูลผู้ใช้จริง ไม่ใช่คะแนนจากแล็บ ค่าจากแล็บมีไว้หาสาเหตุและทดสอบว่าแก้แล้วดีขึ้นหรือเปล่า

เว็บที่ทราฟฟิกน้อยอาจยังไม่มีข้อมูลผู้ใช้จริงพอให้ CrUX แสดงผล กรณีนั้นต้องอาศัย lab data ไปก่อน และควรทดสอบแบบจำลองมือถือกับเน็ตช้า ไม่ใช่ดูจากเครื่องที่เน็ตแรงและมีแคชอยู่แล้ว

PageSpeed Insights

ใส่ URL แล้วได้ทั้งค่าผู้ใช้จริงจาก CrUX ด้านบน และผล Lighthouse ด้านล่าง ส่วนผล Lighthouse จะบอกว่า element ไหนคือ LCP พร้อมการแตกเวลาเป็นส่วนย่อยและข้อเสนอแนะ เป็นจุดเริ่มต้นที่ง่ายที่สุดสำหรับหน้าที่อยากเช็ก

Search Console รายงาน Core Web Vitals

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

Chrome DevTools

ใน Performance panel จะเห็นค่า LCP ของหน้าที่เปิดอยู่ บันทึกการโหลดแล้วดูได้ว่า element ไหนเป็น LCP ไฟล์ไหนโหลดก่อนหลัง และเวลาแต่ละส่วนย่อยยาวแค่ไหน ใช้คู่กับการจำลองเน็ตช้าและ CPU ช้าเพื่อให้ใกล้กับมือถือจริง ส่วน CrUX ใช้ดูแนวโน้มย้อนหลังระดับ origin หรือ URL ผ่านเครื่องมืออย่าง CrUX Dashboard หรือ API

LCP มีผลกับ SEO มากแค่ไหน

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

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

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

สรุป: ควรเริ่มแก้ LCP จากตรงไหนก่อน

เริ่มจากรายงาน Core Web Vitals ใน Search Console เพื่อดูว่ากลุ่ม URL ไหนติด LCP แล้วเปิดหน้าตัวอย่างของกลุ่มนั้นใน PageSpeed Insights เพื่อดูว่า element ไหนคือ LCP และส่วนย่อยไหนกินเวลามากที่สุด

ถ้า resource load delay ยาว ให้เช็ก lazy load กับ fetchpriority ก่อน ถ้า resource load duration ยาว ให้ดูขนาดและฟอร์แมตรูป ถ้า element render delay ยาว ให้ไล่ CSS และ JavaScript ที่ขวางอยู่ และถ้า TTFB ยาว ให้แก้ที่เซิร์ฟเวอร์ แคช และ CDN แก้แล้วรอข้อมูลผู้ใช้จริงสะสมอย่างน้อยราว 28 วันก่อนสรุปผล เพราะค่าที่ Google ใช้เป็นค่าย้อนหลัง ไม่ได้เปลี่ยนในวันเดียว

ถ้าไม่แน่ใจว่าเว็บของตัวเองติดตรงไหนหรือควรแก้อะไรก่อน บริการ ตรวจสุขภาพเว็บ SEO Audit ของ SEONo1 ช่วยไล่ดู Core Web Vitals และงาน Technical SEO ส่วนอื่นพร้อมจัดลำดับสิ่งที่ควรแก้ให้ได้