ตรวจและปรับปรุง Core Web Vitals ด้วย PageSpeed Insights
Core Web Vitals คือชุดตัวชี้วัดของ Google ที่วัดประสบการณ์จริงของผู้ใช้ในสามด้าน ได้แก่ หน้าเว็บแสดงเนื้อหาหลักเร็วแค่ไหน ตอบสนองต่อการคลิกหรือแตะเร็วแค่ไหน และเลย์เอาต์กระโดดระหว่างโหลดหรือไม่ ค่าเหล่านี้เป็นส่วนหนึ่งของสัญญาณ Page Experience ที่ Google ใช้ประกอบการจัดอันดับ และที่สำคัญกว่านั้นคือเกี่ยวข้องโดยตรงกับยอดขายและอัตราการออกจากเว็บ
บทความนี้อธิบายวิธีอ่านผลจาก PageSpeed Insights ให้ถูก แยกแยะว่าปัญหาอยู่ที่เซิร์ฟเวอร์หรือหน้าเว็บ และแนวทางแก้ที่ได้ผลจริงสำหรับแต่ละตัวชี้วัด
สิ่งที่ต้องเตรียม
- URL ของหน้าที่สำคัญ เช่น หน้าแรก หน้าสินค้า หน้าบทความ (ควรทดสอบหลายแบบ ไม่ใช่แค่หน้าแรก)
- เบราว์เซอร์ Chrome สำหรับใช้ DevTools
- สิทธิ์แก้ธีม ปลั๊กอิน หรือโค้ดของเว็บ และถ้าเป็น Cloud Server ควรมีสิทธิ์ SSH ด้วย
- ถ้ามี ให้เข้าถึง Google Search Console ของเว็บ (ดู ยืนยันความเป็นเจ้าของเว็บไซต์บน Google Search Console)
ตัวชี้วัดทั้งสามและเกณฑ์
| ตัวชี้วัด | วัดอะไร | ดี | ต้องปรับปรุง | แย่ |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | เวลาที่องค์ประกอบใหญ่สุดในหน้าจอแรก (มักเป็นรูป Hero หรือหัวข้อ) แสดงผล | ไม่เกิน 2.5 วินาที | 2.5-4 วินาที | เกิน 4 วินาที |
| INP (Interaction to Next Paint) | ความเร็วที่หน้าจอตอบสนองหลังคลิก แตะ หรือพิมพ์ ตลอดการใช้งานหน้า | ไม่เกิน 200 มิลลิวินาที | 200-500 มิลลิวินาที | เกิน 500 มิลลิวินาที |
| CLS (Cumulative Layout Shift) | ปริมาณที่เนื้อหาเลื่อนตำแหน่งโดยไม่ได้ตั้งใจ | ไม่เกิน 0.1 | 0.1-0.25 | เกิน 0.25 |
INP เข้ามาแทน FID (First Input Delay) ตั้งแต่เดือนมีนาคม 2024 ถ้าเจอบทความเก่าที่พูดถึง FID ให้เข้าใจว่าเป็นตัวชี้วัดที่เลิกใช้แล้ว Google ประเมินจากค่าที่เปอร์เซ็นไทล์ที่ 75 ของผู้ใช้จริง แปลว่าผู้ใช้อย่างน้อย 75% ต้องได้ค่าอยู่ในเกณฑ์ดี
ขั้นตอนที่ 1: ทดสอบด้วย PageSpeed Insights
- เปิด https://pagespeed.web.dev/
- ใส่ URL เต็ม แล้วกด Analyze
- ผลแยกเป็นแท็บ Mobile และ Desktop ให้ดู Mobile ก่อน เพราะ Google จัดทำดัชนีด้วยมุมมองมือถือเป็นหลัก
หน้าผลลัพธ์มีสองส่วนที่ต้องแยกให้ออก
| ส่วน | ที่มา | ใช้ทำอะไร |
|---|---|---|
| Discover what your real users are experiencing | ข้อมูลจริงจาก Chrome User Experience Report (CrUX) ย้อนหลัง 28 วัน | คือค่าที่ Google ใช้ประเมินจริง ผ่านหรือไม่ผ่านดูที่นี่ |
| Diagnose performance issues | Lighthouse จำลองการโหลดหนึ่งครั้ง (Lab data) | ใช้หาสาเหตุและทดสอบผลการแก้ไขได้ทันที |
เว็บที่มีผู้เข้าชมน้อยอาจไม่มีข้อมูลจริง จะแสดงเฉพาะส่วน Lab ส่วนคะแนน Performance 0-100 เป็นคะแนนของ Lighthouse ไม่ใช่ Core Web Vitals โดยตรง คะแนนนี้แกว่งได้ทุกครั้งที่ทดสอบ ควรทดสอบ 3 ครั้งแล้วดูแนวโน้ม อย่ายึดตัวเลขครั้งเดียว
ใน Search Console รายงาน Core Web Vitals (ใต้เมนู Experience) จะจัดกลุ่ม URL ที่มีปัญหาเดียวกันให้ ช่วยให้รู้ว่าควรแก้ Template ไหนก่อน
ขั้นตอนที่ 2: แก้ LCP
ในส่วน Diagnose ให้ขยายหัวข้อ Largest Contentful Paint element เพื่อดูว่าองค์ประกอบใดคือ LCP และเวลาถูกใช้ไปกับช่วงใด (TTFB, Load delay, Load time, Render delay)
ถ้า TTFB สูง (เกินประมาณ 0.8 วินาที)
ปัญหาอยู่ที่เซิร์ฟเวอร์สร้างหน้าช้า วัดด้วยคำสั่ง
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s Total: %{time_total}s\n' https://example.com/แนวทางแก้ ได้แก่ เปิด Page Cache (ปลั๊กอินแคชของ WordPress หรือ FastCGI Cache ของ Nginx), ใช้ PHP เวอร์ชันใหม่ที่ยังได้รับการสนับสนุน, ใช้ Object Cache อย่าง Redis (ดู ติดตั้งและตั้งค่า Redis บน Linux Server) และหา Query ที่ช้า (ดู เปิด Slow Query Log เพื่อหา Query ที่ทำให้ฐานข้อมูลช้า) ถ้าเซิร์ฟเวอร์ทำงานเต็มกำลังตลอด ให้ตรวจทรัพยากรตาม ตรวจสอบ CPU, RAM และ Load Average ของ Linux Server
ถ้ารูป LCP โหลดช้า
- แปลงรูปเป็น WebP หรือ AVIF และลดขนาดให้พอดีกับที่แสดงจริง รูปกว้าง 4000px ที่แสดงแค่ 800px เป็นสาเหตุที่พบบ่อยที่สุด
- ห้าม ใส่
loading="lazy"ให้รูป LCP เพราะเบราว์เซอร์จะรอโหลดทีหลัง - บอกเบราว์เซอร์ว่ารูปนี้สำคัญ
<img src="/images/hero.webp" width="1200" height="600"
fetchpriority="high" alt="บริการของเรา">ถ้ารูป Hero เป็นภาพพื้นหลังใน CSS เบราว์เซอร์จะค้นพบช้า ให้เพิ่ม preload ใน <head>
<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">ถ้า Render delay สูง
หน้าเว็บถูกบล็อกด้วย CSS หรือ JavaScript จำนวนมากใน <head> ให้ลดไฟล์ที่ไม่จำเป็น ใส่ defer ให้สคริปต์ที่ไม่ต้องทำงานทันที และตรวจหัวข้อ Render-blocking requests ในรายงาน
ขั้นตอนที่ 3: แก้ INP
INP แย่มักมาจาก JavaScript ที่ทำงานนานบน Main Thread ในรายงานให้ดูหัวข้อเกี่ยวกับ Long main-thread tasks และ Reduce JavaScript execution time ซึ่งจะบอกว่าสคริปต์ใดใช้เวลามากที่สุด
- ถอดสคริปต์ของบุคคลที่สามที่ไม่จำเป็น เช่น Pixel หรือ Widget ที่เลิกใช้แล้ว แต่ละตัวเพิ่มภาระให้ทุกหน้า
- ปิดปลั๊กอินที่โหลดสคริปต์ทุกหน้าแต่ใช้แค่หน้าเดียว (เช่นฟอร์มหรือสไลเดอร์)
- ชะลอการโหลดแชตหรือ Widget จนกว่าผู้ใช้จะเลื่อนหน้าหรือมีการโต้ตอบ
ใน Chrome DevTools แท็บ Performance จะแสดงค่า INP ขณะที่คุณคลิกหน้าเว็บเอง ใช้ยืนยันว่าปุ่มใดตอบสนองช้า
ขั้นตอนที่ 4: แก้ CLS
- ใส่
widthและheightให้ทุกรูปและวิดีโอ เบราว์เซอร์จะจองพื้นที่ไว้ก่อนโหลดเสร็จ - จองพื้นที่ให้โฆษณา แบนเนอร์ และ Embed ด้วย
min-heightใน CSS - อย่าแทรกแถบประกาศหรือแบนเนอร์คุกกี้ดันเนื้อหาด้านบนลงมาหลังหน้าโหลดแล้ว ให้ใช้แบบลอยทับด้านล่างแทน
- ฟอนต์เว็บที่สลับทีหลังทำให้ข้อความขยับได้ ใช้
font-display: swapคู่กับการ preload ฟอนต์หลัก และเลือกฟอนต์สำรองที่ขนาดใกล้เคียง
หัวข้อ Layout shift culprits ในรายงานจะชี้องค์ประกอบที่ทำให้เลื่อน
ขั้นตอนที่ 5: การตั้งค่าฝั่งเซิร์ฟเวอร์ที่ช่วยทุกตัวชี้วัด
- เปิดการบีบอัด gzip หรือ Brotli สำหรับ HTML, CSS, JS ตรวจด้วย
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding - ตั้ง Cache-Control ให้ไฟล์ Static อายุยาว เช่น 30 วันขึ้นไป
- ใช้ HTTP/2 หรือ HTTP/3
- ถ้าผู้ใช้อยู่หลายประเทศ พิจารณา CDN
ตรวจสอบผลลัพธ์
หลังแก้ ให้รัน PageSpeed Insights ใหม่เพื่อดูส่วน Lab ซึ่งเปลี่ยนทันที ส่วนข้อมูลจริง (CrUX) เป็นค่าเฉลี่ยย้อนหลัง 28 วัน จึงต้องรอหลายสัปดาห์กว่าจะเห็นผลเต็มที่ ใน Search Console รายงาน Core Web Vitals เลือกกลุ่มปัญหาแล้วกด Validate Fix เพื่อให้ Google ติดตามผลในช่วง 28 วันถัดไป
ปัญหาที่พบบ่อย
คะแนนบนมือถือต่ำกว่าเดสก์ท็อปมาก
เป็นเรื่องปกติ เพราะ Lighthouse จำลองมือถือระดับกลางกับเครือข่ายช้า ให้ใช้ค่ามือถือเป็นเป้าหมาย ไม่ใช่เดสก์ท็อป
ติดตั้งปลั๊กอินเร่งความเร็วแล้วแย่ลง
การรวมไฟล์และเลื่อนสคริปต์แบบอัตโนมัติบางครั้งไปเลื่อนรูป LCP หรือทำให้ CSS โหลดทีหลังจนเกิด CLS ให้เปิดตัวเลือกทีละข้อแล้วทดสอบ อย่าเปิดทุกตัวเลือกพร้อมกัน และอย่าติดตั้งปลั๊กอินแคชมากกว่าหนึ่งตัว
Lab ดีแล้วแต่ข้อมูลจริงยังแย่
ผู้ใช้จริงอาจใช้เครื่องที่ช้ากว่า หรือปัญหาเกิดจากการโต้ตอบที่ Lighthouse ไม่ได้ทดสอบ (INP) หรือเกิดกับหน้าอื่นที่ไม่ได้ทดสอบ ให้ดูกลุ่ม URL ใน Search Console แล้วทดสอบหน้าในกลุ่มนั้น
ถ้าต้องการตรวจว่าเซิร์ฟเวอร์เป็นคอขวดหรือไม่ ติดต่อทีมงาน THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/
- Categories:
- Cloud
