จะแก้คะแนน Core Web Vitals ที่ไม่ดีได้อย่างไร

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

ขั้นตอนที่ 1: ตรวจหาสิ่งที่ไม่ผ่าน

1. เปิดรายงาน Core Web Vitals ใน Search Console แล้วเลือก Mobile หรือ Desktop เพราะทั้งสองแบบมีการประเมินแยกกัน
2. เปิดปัญหาหนึ่งรายการที่แสดงอยู่ เช่น ปัญหา LCP บนมือถือ เพื่อดูกลุ่ม URL ที่ได้รับผลกระทบและ URL ตัวอย่าง ทั้งกลุ่มใช้สถานะเดียวกัน ซึ่งกำหนดจากเมตริกที่แย่ที่สุด
3. นำ URL ตัวอย่างไปรันใน PageSpeed Insights เพื่อดูข้อมูลภาคสนามของหน้านั้นควบคู่กับการทดสอบในห้องแล็บที่ช่วยในการดีบัก

เครื่องมือทดสอบในห้องแล็บอย่าง Lighthouse ไม่สามารถวัด INP ได้ เนื่องจากไม่มีผู้ใช้โต้ตอบกับหน้าเว็บ จึงรายงาน Total Blocking Time แทน สำหรับ INP การวัดจากผู้ใช้จริงคือแนวทางที่เชื่อถือได้

วิธีแก้ LCP ที่ช้า

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

• ทำให้รูปภาพ LCP ถูกค้นพบได้ ใน HTML เริ่มต้น แทนที่จะแทรกด้วย JavaScript หรือ CSS และกำหนด fetchpriority="high" ให้กับรูปภาพนั้น
• ห้ามใช้ lazy-load กับรูปภาพ LCP
• ลดขนาดที่ส่งออกไป: ใช้ขนาดที่เหมาะสม ฟอร์แมตสมัยใหม่ การบีบอัด และ CDN ที่อยู่ใกล้ผู้เข้าชม
• กำจัดทรัพยากรที่บล็อกการแสดงผล: ใช้สไตล์ชีตที่เล็กลง ไม่ใช้สคริปต์แบบซิงโครนัสใน <head> และใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์สำหรับเนื้อหาหลัก
• เร่งเวลาตอบสนองของเซิร์ฟเวอร์: ลดการรีไดเรกต์ และให้แคชหน้าเว็บไว้ที่ edge ได้

วิธีแก้ INP ที่ไม่ดี

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

• ความล่าช้าของอินพุต: ลด JavaScript ที่ทำงานระหว่างโหลดหน้า เพื่อให้เมนเธรดว่างเมื่อมีคนแตะหน้าจอ
• เวลาประมวลผล: แบ่งตัวจัดการเหตุการณ์ที่ใช้เวลานานออกเป็นงานย่อย และคืนการควบคุมให้เมนเธรด โดยอัปเดตส่วนที่ผู้ใช้มองเห็นก่อน แล้วเลื่อนส่วนที่เหลือไปทำภายหลัง
• ความล่าช้าในการแสดงผล: รักษา DOM ให้มีขนาดเล็ก หลีกเลี่ยงการบังคับให้คำนวณเลย์เอาต์ด้วยการอ่านค่าสไตล์ทันทีหลังจากเปลี่ยนแปลง และใช้ content-visibility กับหน้าที่ยาว

วิธีแก้ CLS ที่สูง

คู่มือการปรับ CLS ระบุสาเหตุที่พบบ่อยและวิธีแก้ไว้ดังนี้

• รูปภาพและวิดีโอที่ไม่มีการกำหนดขนาด: เพิ่มแอตทริบิวต์ width และ height หรือใช้ aspect-ratio ของ CSS
• โฆษณา เนื้อหาที่ฝัง และ iframe: กันพื้นที่ในเลย์เอาต์ไว้ล่วงหน้าก่อนที่จะโหลด
• เนื้อหาที่ถูกแทรกไว้เหนือเนื้อหาเดิม: ใช้ตัวแทนที่มีขนาดพอดี หรือแทรกเนื้อหาใหม่ไว้ใต้ส่วนที่ผู้เข้าชมกำลังอ่านอยู่
• เว็บฟอนต์: โหลดฟอนต์สำคัญล่วงหน้า เพื่อไม่ให้ข้อความจัดเรียงใหม่ในภายหลัง
• แอนิเมชัน: ทำแอนิเมชันกับ transform แทนพร็อพเพอร์ตีอย่าง top หรือ left

หน้าที่ใช้ back/forward cache ของเบราว์เซอร์ได้ก็จะไม่เกิดการเลื่อนของเลย์เอาต์เมื่อผู้เข้าชมย้อนกลับมาด้วย

ขั้นตอนที่ 3: ยืนยันผลการแก้ไข

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

AutoPSEO ช่วยคุณได้อย่างไร

รายงาน Core Web Vitals ของ AutoPSEO แสดงข้อมูล Chrome UX Report รายสัปดาห์ย้อนหลังประมาณหกเดือนในรูปแบบแผนภูมิ สำหรับทั้งเว็บไซต์หรือเฉพาะ URL เดียว บนโทรศัพท์ เดสก์ท็อป หรือแท็บเล็ต คุณจึงเห็นได้ว่าการแก้ไขมีผลในสัปดาห์ใด หรือรีลีสใดทำให้ผลแย่ลง โดยไม่ต้องรอให้หน้าต่าง 28 วันถัดไปสิ้นสุด