Core Web Vitals ปฏิบัติจริง: จัดลำดับการวินิจฉัยและแก้ไข LCP/INP/CLS
หนึ่ง: แต่ละตัวชี้วัดดูแลอะไร แยกให้ชัดก่อนลงมือ
หลายทีมเริ่มจากรัน Lighthouse เห็นกากบาทแดงเต็มไปหมดก็แก้กันมั่ว ลองทำความเข้าใจก่อนว่าแต่ละตัวชี้วัดวัดอะไร จะได้แก้ตรงจุด
| ตัวชี้วัด | วัดอะไร | เกณฑ์ผ่าน | ตัวการที่พบบ่อย |
|---|---|---|---|
| LCP Largest Contentful Paint | เวลาที่องค์ประกอบใหญ่สุดเหนือหน้าจอแรกโหลดเสร็จ | ≤ 2.5 วินาที | ภาพหน้าจอแรกใหญ่เกินไป ฟอนต์บล็อก เซิร์ฟเวอร์ตอบช้า |
| INP จากการโต้ตอบถึงการวาดครั้งถัดไป | ความหน่วงของอินเทอร์เฟซหลังผู้ใช้คลิก | ≤ 200 มิลลิวินาที | งานยาวบน main thread, ขนาด JS ใหญ่เกินไป, สคริปต์ของบุคคลที่สาม |
| CLS การเลื่อนตำแหน่งสะสม | ระดับการกระโดดขององค์ประกอบระหว่างโหลดหน้า | ≤ 0.1 | รูปไม่มี width/height, ตำแหน่งโฆษณาไม่มีที่กันพื้นที่, การสลับฟอนต์ |
เกณฑ์ตัดสินต้องใช้เปอร์เซ็นไทล์ 75: ในผู้เข้าชม 100 คน ต้องมี 75 คนแรกที่ผ่านจึงนับว่าผ่าน ค่าเฉลี่ยหรือมัธยฐานไม่มีความหมาย ข้อมูล CrUX ดูได้ในรายงานประสบการณ์ใน Search Console ซึ่งเป็นข้อมูลชุดเดียวกับที่ Google ใช้เป็นสัญญาณจัดอันดับ
ยังต้องระวังว่าสามตัวชี้วัดรัดกันอยู่: การบีบอัดภาพลด LCP ได้ แต่ถ้านโยบาย lazy load ของภาพผิด จะดันองค์ประกอบ LCP ไปเฟรมที่สองแทน; การ preload ฟอนต์ลด LCP ได้ แต่ preload ฟอนต์มากเกินไปจะแย่งคำขอเครือข่าย กระทบ INP หลังแก้อย่างหนึ่งต้องรอ 14 วันดูข้อมูลผู้ใช้จริง อย่าแก้ต่อกันเป็นลูกโซ่
สอง: แก้ LCP ก่อนเพราะได้ผลตอบแทนมากที่สุด
LCP มักคิดเป็นกว่า 50% ของผลตอบแทนจากการปรับสามตัวชี้วัด ประกอบด้วยสี่ช่วง ดูก่อนว่าตัวเองติดอยู่ช่วงไหน
| ช่วงของ LCP | เครื่องมือวินิจฉัย | คอขวดที่พบบ่อย | วิธีแก้ |
|---|---|---|---|
| TTFB การตอบสนองของเซิร์ฟเวอร์ | waterfall ใน WebPageTest | PHP เรนเดอร์ช้า, ไม่ผ่าน CDN | แคชขอบ CDN, อัปเกรด PHP |
| การโหลดทรัพยากร | ประสิทธิภาพใน Chrome DevTools | ภาพหน้าจอแรกไม่บีบอัด, ไม่ preload | WebP/AVIF, preload ภาพสำคัญ |
| การเรนเดอร์ทรัพยากร | โอกาสใน Lighthouse | ฟอนต์บล็อกการเรนเดอร์ | font-display: swap + preload |
| การเรนเดอร์ฝั่งไคลเอนต์ | แผงประสิทธิภาพ Trace | SPA เรนเดอร์หลัง JS ดาวน์โหลดเสร็จ | SSR หรือ skeleton screen |
ตัวอย่างสถานการณ์: หน้าแรกของเว็บ B2B อุตสาหกรรมมีรูปสินค้าขนาด 1.8MB ยังไม่บีบอัด TTFB ปกติ แต่ LCP ค้างอยู่ที่ 4.2 วินาที เปลี่ยนรูปเป็น WebP บีบอัดเหลือ 320KB แล้วเพิ่ม fetchpriority=”high” ภายในหนึ่งสัปดาห์ LCP ลดลงเหลือ 1.9 วินาที การแก้ไขครั้งนี้แตะแค่แท็ก img แท็กเดียว ไม่ได้แก้การตั้งค่าเซิร์ฟเวอร์ใดๆ
การเลือกโหนด CDN และกลยุทธ์แคชส่งผลโดยตรงต่อ TTFB ดูที่CDN เร่งความเร็วทั่วโลก สำหรับเว็บหลายภาษา การแปลรูปภาพให้เหมาะกับท้องถิ่นยังต้องพิจารณาร่วมกับ การจัดการแผนภูมิของเว็บหลายภาษา ด้วย
สาม、แก้ไข INP: ใช้เวลามากที่สุดแต่ข้ามไม่ได้
INP เป็นตัวชี้วัดใหม่ที่มาแทน FID ในเดือนมีนาคม 2024 วัดความหน่วงทั้งหมดตั้งแต่ผู้ใช้โต้ตอบจนอินเทอร์เฟซตอบสนองจริง แก้ยากกว่า LCP เพราะปัญหากระจายอยู่ทั่วทั้ง JS bundle
| คำถาม | วิธีตรวจสอบ | วิธีแก้ | ผลที่คาดว่าจะได้ |
|---|---|---|---|
| งานยาวบน main thread > 50ms | ดูเครื่องหมายงานยาวในแผง Performance | แยกโค้ด、Web Worker | INP ลดลง 100 ถึง 200 มิลลิวินาที |
| สคริปต์บุคคลที่สามบล็อก | ดูสัดส่วนในแผง Coverage | โหลดแบบเลื่อน、async/defer | INP ลดลง 50 ถึง 150 มิลลิวินาที |
| event callback หนักเกินไป | ดูฟังก์ชันที่ใช้เวลานานใน call stack | debounce throttle、แยก callback | INP ลดลง 30 ถึง 80 มิลลิวินาที |
| ทรัพยากรที่บล็อกการเรนเดอร์ | CSS/JS ที่ไม่ได้ใช้ใน Lighthouse | อินไลน์ critical CSS、เลื่อนตัวที่ไม่สำคัญ | INP ลดลง 50 ถึง 100 มิลลิวินาที |
จุดที่ขัดกับสัญชาตญาณ: INP แย่ไม่จำเป็นต้องเป็นปัญหาจากโค้ดของคุณเอง เว็บ B2B มักฝัง LinkedIn pixel、ปลั๊กอินฟอร์ม HubSpot、สคริปต์แชทบริการลูกค้า สามอย่างนี้รวมกันบล็อก main thread ได้เกิน 300 มิลลิวินาที จัดลำดับสคริปต์บุคคลที่สามตามความสำคัญในการโหลดก่อน ได้ผลเร็วกว่าแก้โค้ดธุรกิจ
สี่、แก้ไข CLS: ผลตอบแทนง่ายที่แก้แล้วนิ่งทันที
CLS เป็นตัวชี้วัดที่แก้ง่ายที่สุดในสามตัว: 90% ของปัญหา CLS มาจากสองสาเหตุ——รูปไม่ได้ระบุความกว้างความสูง、โฆษณาหรือเนื้อหาฝังไม่มีที่จอง
| ตัวการ CLS | วิธีตรวจสอบ | วิธีแก้ |
|---|---|---|
| รูปไม่ได้ระบุ width/height | ดู layout shift ใน DevTools | เพิ่ม width/height + aspect-ratio ในแท็ก img |
| ฟอนต์สลับกระตุก | ปรากฏการณ์ FOIT/FOUT | font-display: swap + size-adjust |
| โฆษณา/เนื้อหาฝังไม่มีที่จอง | โฆษณาโหลดแล้วดันเนื้อหา | จองคอนเทนเนอร์ความสูงคงที่ |
| แบนเนอร์ที่ฉีดแบบไดนามิก | แถบแจ้งเตือนด้านบนเด้งขึ้น | จองพื้นที่ ไม่บีบเนื้อหา |
ตัวอย่างสถานการณ์ที่สอง: บล็อกของเว็บ SaaS ที่ออกต่างประเทศมี CLS อยู่ที่ 0.35 มานาน สาเหตุคือด้านบนบทความมีแบนเนอร์ “สมัคร Newsletter” แทรกเข้ามาหลัง JS โหลด ดันบทความทั้งเรื่องลงไป 120 พิกเซล เปลี่ยนแบนเนอร์เป็นเรนเดอร์ฝั่งเซิร์ฟเวอร์และจองพื้นที่ 120px ภายในหนึ่งสัปดาห์ CLS ลดลงเหลือ 0.04
ห้า、เครื่องมือวินิจฉัยและขั้นตอนตรวจสอบ
| ระยะ | เครื่องมือ | แหล่งข้อมูล | กำหนดเวลาตรวจสอบ |
|---|---|---|---|
| ระบุปัญหา | รายงาน CrUX / รายงานประสบการณ์ใน GSC | ข้อมูลผู้ใช้จริง 28 วัน | ดูสัปดาห์ละครั้ง |
| จำลองในห้องแล็บ | Lighthouse / WebPageTest | จำลอง Moto G4 บน 4G ช้า | รันหนึ่งครั้งก่อนแก้ไข |
| มอนิเตอร์บนไลน์ | CrUX / เครื่องมือ RUM | แนวโน้มตัวชี้วัดที่เปอร์เซ็นไทล์ 75 | 14 วันหลังอัปโหลด |
| ตรวจรับ | รายงาน Core Web Vitals ใน GSC | ตัวชี้วัดทั้งสามประเภท “ผ่าน” ทั้งหมด | 28 วันหลังอัปโหลด |
ข้อผิดพลาดที่พบบ่อยคือดูแค่คะแนน Lighthouse ในเครื่อง เพราะ Lighthouse รันในสภาพแวดล้อมสะอาด ไม่มีเครือข่ายผู้ใช้จริงของคุณ ไม่มีสคริปต์ของบุคคลที่สาม ไม่มีสถานะล็อกอิน เว็บที่ได้ 95 คะแนนในเครื่องแต่ไม่ผ่าน CrUX มีอยู่เยอะมาก หลังแก้เสร็จต้องรอข้อมูลแบบ rolling 28 วันอัปเดตก่อน อย่าตัดสินว่าสำเร็จตั้งแต่วันที่สามที่อัปเดต
การปรับประสิทธิภาพและ ระบบตัวชี้วัด Core Web Vitals เป็นงานวิศวกรรมต่อเนื่อง ไม่ใช่โปรเจกต์ครั้งเดียวจบ ช่วงดูแลเว็บไซต์ ควรจัดรายงาน CWV รายเดือนเป็นรายการประจำ
หก、เขียน performance budget เข้าไปในกระบวนการพัฒนาได้อย่างไร
แก้ CWV ไปรอบหนึ่งไม่ได้แปลว่าจบตลอดไป ฟีเจอร์ใหม่ ปลั๊กอินใหม่ สคริปต์การตลาดใหม่ ล้วนทำให้ตัวชี้วัดแย่ลงอีก วิธีที่ถูกต้องคือเขียน performance budget เข้าไปในกระบวนการปล่อยเวอร์ชัน กั้นด่านก่อนขึ้นจริงทุกครั้ง
| ประเภทหน้า | งบประมาณ LCP | งบประมาณ INP | งบประมาณ CLS | งบประมาณ JS รวม |
|---|---|---|---|---|
| หน้าแรกและแลนดิ้งเพจ | ≤ 2.0 วินาที | ≤ 150 มิลลิวินาที | ≤ 0.05 | ≤ 250KB gzip |
| หน้ารายละเอียดสินค้า | ≤ 2.5 วินาที | ≤ 200 มิลลิวินาที | ≤ 0.1 | ≤ 350KB gzip |
| หน้าบทความบล็อก | ≤ 2.5 วินาที | ≤ 200 มิลลิวินาที | ≤ 0.1 | ≤ 300KB gzip |
| หน้าติดต่อและฟอร์ม | ≤ 2.0 วินาที | ≤ 150 มิลลิวินาที | ≤ 0.05 | ≤ 200KB gzip |
ก่อนปล่อยเวอร์ชันทุกครั้ง ให้รัน Lighthouse CI ในสภาพแวดล้อม pre-production กับหน้าหลักเหล่านี้ ถ้าเกินงบประมาณห้าม merge ป๊อปอัป สคริปต์แชท และพิกเซลติดตามที่ทีมการตลาดเพิ่มชั่วคราว ต้องผ่านเช็กลิสต์รีวิวว่า สคริปต์นี้เลื่อนการโหลดได้ไหม ย้ายไปหลัง first screen ได้ไหม โหลดเฉพาะบางหน้าได้ไหม ทุกสามเดือนทำรายงาน CrUX รายเดือน ดูแนวโน้มเปอร์เซ็นไทล์ที่ 75 ถ้าหน้าประเภทใดลดลงติดกันสองเดือนก็ตั้งโปรเจกต์แก้
อีกจุดที่มักถูกมองข้ามคือการจัดการไฟล์ภาพ บทความบล็อกที่เขียนใหม่ถ้าอัปโหลดภาพต้นฉบับที่ไม่บีบอัด LCP จะแย่ลงทันที ควรต่อ pipeline บีบอัดภาพไว้ในหลังบ้านเนื้อหาเป็นค่าเริ่มต้น ตอนอัปโหลดให้แปลงเป็น WebP อัตโนมัติ บีบอัดให้ได้ขนาดที่เหมาะสม สร้าง srcset ให้ ประหยัดแรงกว่ามาแก้วันละบทความทีหลังมาก pipeline นี้สอดคล้องกับกระบวนการจัดการสื่อและไฟล์ภาพ ดูที่การจัดการสินทรัพย์สื่อ。
สคริปต์ของบุคคลที่สามเป็นตัวการอันดับหนึ่งที่ทำให้ INP แย่ลง พิกเซล ปลั๊กอินแชท ฟอร์มฝังที่ทีมการตลาดเพิ่มชั่วคราวเพื่อแคมเปญใหม่ มักไม่ได้เลื่อนการโหลด ไปเบียดอยู่ในช่วงเรนเดอร์ first screen ทั้งหมด ทุกไตรมาสให้ดึงรายการสคริปต์บุคคลที่สามทั้งเว็บออกมาทบทวน ตัวไหนยังใช้อยู่ ตัวไหนเลื่อนไปหลัง first screen ได้ ตัวไหนไม่มีใครดูแล้วลบได้เลย จัดรีวิวนี้เป็นส่วนหนึ่งของกระบวนการปล่อยเวอร์ชันประจำ จะสบายใจกว่ามาคอยแก้ทีหลังมาก
สุดท้ายขอย้ำเกณฑ์การตรวจสอบ หลังแก้เสร็จอย่าดูแค่คะแนน Lighthouse ในเครื่อง ต้องรอข้อมูลผู้ใช้จริงแบบ rolling 28 วันของ CrUX อัปเดตก่อน คะแนนในเครื่องใช้ระบุปัญหาได้เท่านั้น ใช้ประกาศความสำเร็จไม่ได้ ส่งรายงาน CWV รายเดือนให้หัวหน้าฝ่ายวิศวกรรมและการตลาดเป็นประจำ ทำให้ประสิทธิภาพเป็นตัวชี้วัดที่ทุกทีมช่วยกันจับตา ไม่ใช่ KPI ของฝ่าย SEO คนเดียว
FAQ คำถามที่พบบ่อย
LCP, INP, CLS ควรแก้ตัวไหนก่อน
ทำไม Lighthouse ได้ 95 คะแนน แต่ Search Console ยังบอกว่าไม่ผ่าน?
ลด INP จาก 500 มิลลิวินาทีให้เหลือไม่เกิน 200 ใช้เวลานานแค่ไหน?
CLS เท่าไหร่ถึงถือว่าปกติ?
Core Web Vitals ส่งผลต่ออันดับโดยตรงไหม?
CWV ของมือถือและเดสก์ท็อปต้องดูแยกกันไหม?
ทิ้งท้าย
Core Web Vitals เป็นรายการที่ผลตอบแทนเทียบกับต้นทุนชัดเจนที่สุดในสายเทคนิคัล SEO เพราะแต่ละตัวชี้วัดมีเกณฑ์ชัดเจน เครื่องมือวินิจฉัยชัดเจน และวิธีแก้ชัดเจน อย่าให้คะแนน Lighthouse หลอกตา ให้ดูข้อมูลผู้ใช้จริงจาก CrUX
ลงมือสามขั้นตอน: สัปดาห์นี้ใช้รายงานประสบการณ์ใน GSC ระบุว่าตัวชี้วัดใดแย่ที่สุด สัปดาห์หน้าแก้ตัวแรกตามลำดับ LCP → CLS → INP หลังอัปเดตแล้วรอ 28 วันดูว่า CrUX ผ่านทั้งหมดหรือไม่ ถ้าทั้งสามตัวชี้วัดอยู่ในเกณฑ์ผ่าน คุณก็แซงเว็บ B2B ที่ออกตลาดต่างประเทศกว่า 70% แล้ว
ประโยคเดียวที่จำง่าย: CWV ไม่ใช่เกมวัดคะแนน แต่คือเวลารอของคนจริง LCP ดูภาพ INP ดูการตอบสนอง CLS ดูความนิ่ง ต้องสบายตาทั้งสามอย่างถึงจะผ่าน