
ตั้งแต่ปี 2021 เป็นต้นมา Google ได้นำ Core Web Vitals มาใช้เป็น Ranking Signal อย่างเป็นทางการ หมายความว่าเว็บ WordPress ที่โหลดช้าหรือ Layout กระตุกจะเสียเปรียบในการจัดอันดับ Search ทันที แม้เนื้อหาจะดีแค่ไหนก็ตาม
ปัญหาคือ Core Web Vitals ไม่ใช่แค่เรื่อง "ความเร็ว" แต่วัด ประสบการณ์ผู้ใช้งาน 3 มิติ พร้อมกัน ได้แก่ ความเร็วโหลดเนื้อหาหลัก (LCP), การตอบสนองต่อการกดหรือพิมพ์ (INP) และความเสถียรของหน้าเว็บระหว่างโหลด (CLS) เว็บ WordPress ที่ใช้ Theme หนักหรือติด Plugin เยอะมักพลาดเกณฑ์ทั้ง 3 ข้อพร้อมกัน
บทความนี้จะพาแก้ทีละ Metric พร้อมวิธีวัดผลที่ถูกต้อง และ Plugin ที่ช่วยได้จริงโดยไม่ทำให้เว็บพัง
Core Web Vitals 3 ตัวในปี 2026: Google อัพเดต INP (Interaction to Next Paint) มาแทน FID อย่างเป็นทางการตั้งแต่มีนาคม 2024 เป็นต้นมา ทุกเว็บที่ยังวัดแค่ LCP + FID + CLS อาจพลาดตัววัดสำคัญนี้ไป
Core Web Vitals คืออะไร — รู้จักทั้ง 3 ตัว
ก่อนจะแก้ไขได้ต้องเข้าใจว่าแต่ละ Metric วัดอะไรและเกณฑ์ผ่านอยู่ที่ไหน Google กำหนดเกณฑ์ไว้ 3 ระดับคือ Good, Needs Improvement และ Poor โดยวัดที่ Percentile ที่ 75 ของผู้ใช้จริงทั้งหมด (ไม่ใช่ค่าเฉลี่ย)
| Metric | วัดอะไร | Good | Poor |
|---|---|---|---|
| LCP | Largest Contentful Paint — ความเร็วโหลดเนื้อหาหลัก | ≤ 2.5s | > 4.0s |
| INP | Interaction to Next Paint — การตอบสนองต่อการกด/พิมพ์ | ≤ 200ms | > 500ms |
| CLS | Cumulative Layout Shift — ความเสถียรของ Layout | ≤ 0.1 | > 0.25 |
ค่า LCP วัดว่าใช้เวลานานแค่ไหนกว่าองค์ประกอบที่ใหญ่ที่สุดในหน้า (มักเป็นรูป Hero หรือ Heading หลัก) จะปรากฏขึ้น INP วัดระยะเวลาที่เว็บตอบสนองหลังจากผู้ใช้กดปุ่ม คลิก หรือพิมพ์ในช่องต่างๆ ส่วน CLS วัดว่าองค์ประกอบในหน้าขยับตำแหน่งไปมากแค่ไหนในระหว่างที่หน้ากำลังโหลด ทั้ง 3 ตัวนี้ต้องอยู่ในระดับ Good พร้อมกันจึงจะถือว่าผ่าน Core Web Vitals
วิธีวัด Core Web Vitals ที่ถูกต้อง
หลายคนวัดผ่าน PageSpeed Insights แล้วได้คะแนนสูง แต่ Google Search Console กลับแสดงว่า Poor — เพราะ PageSpeed Insights มีข้อมูล 2 ชุดที่แยกกัน:
1. Lab Data (Lighthouse)
เป็นการจำลองโดย Google Lighthouse ในสภาพแวดล้อมที่ควบคุมได้ (ใช้ Moto G Power จำลอง + 4G ช้า) เหมาะสำหรับ Debug และทดสอบก่อน deploy แต่ ไม่ใช่ค่าที่ Google ใช้เป็น Ranking Signal
2. Field Data (CrUX)
Chrome User Experience Report (CrUX) คือข้อมูลจากผู้ใช้จริงที่เปิด Chrome และยินยอมแชร์ข้อมูล นี่คือค่าที่ Google ใช้ตัดสิน Ranking จะมีก็ต่อเมื่อเว็บมี Traffic พอเพียง และแสดงใน Google Search Console หัวข้อ "Core Web Vitals" แบบแยก Desktop/Mobile
เครื่องมือที่ต้องใช้ควบคู่กัน: Google Search Console (Field Data จริง) + PageSpeed Insights (Lab Data สำหรับ debug) + Chrome DevTools tab Performance + Extension Web Vitals ของ Chrome สำหรับดูค่า real-time ระหว่าง browse
แก้ LCP — ให้เนื้อหาหลักโหลดเร็วขึ้น
LCP ที่ช้าบน WordPress มักมีสาเหตุมาจาก 4 ปัจจัยหลัก ได้แก่ Server ที่ตอบสนองช้า (TTFB สูง), รูปภาพขนาดใหญ่เกินจำเป็น, การโหลด Resource ที่บล็อก Render และ Theme หรือ Plugin ที่โหลด CSS/JS เยอะโดยไม่จำเป็น
ลด TTFB ด้วย Page Cache
Time to First Byte (TTFB) คือเวลาที่ Server ใช้ในการส่ง Byte แรกกลับมา WordPress ที่ไม่มี Cache จะรัน PHP + Query Database ทุกครั้ง เพิ่ม TTFB ได้หลายร้อย millisecond Cache Plugin ที่แนะนำ:
- WP Rocket — ครอบคลุมที่สุด ตั้งค่าง่าย มี Page Cache + Object Cache + Database Optimization ในตัวเดียว (มีค่าใช้จ่าย)
- LiteSpeed Cache — ฟรีและทรงพลังมากถ้า Hosting ใช้ LiteSpeed Web Server (AsiaGB Hosting รองรับ)
- W3 Total Cache — ฟรี ตั้งค่าเยอะหน่อย แต่ใช้ได้กับทุก Hosting
- WP Super Cache — Plugin อย่างเป็นทางการจาก WordPress.org ตั้งค่าง่าย เหมาะสำหรับมือใหม่
Optimize รูปภาพให้เป็น WebP + ระบุขนาด
รูปภาพคือสาเหตุอันดับ 1 ของ LCP ช้าบน WordPress สิ่งที่ต้องทำ:
- แปลงรูปเป็น WebP — ขนาดเล็กกว่า JPEG 25–35% คุณภาพเทียบเท่า ใช้ Plugin Imagify, ShortPixel หรือ Smush แปลงอัตโนมัติ
- ระบุ width และ height ทุก <img> tag — ป้องกัน Layout Shift และช่วย Browser จองพื้นที่ก่อนโหลด
- ใช้ fetchpriority="high" กับรูป Hero หรือรูปหลักที่อยู่ Above the Fold — บอก Browser ให้โหลดรูปนี้ก่อน
- ใช้ loading="lazy" กับรูปที่อยู่ Below the Fold เพื่อไม่ให้โหลดโดยไม่จำเป็น
- ปรับขนาดรูปให้ตรงกับที่แสดงจริง — ถ้าแสดง 820px ความกว้าง อย่าอัพรูปที่ 3000px เพราะ Browser จะต้องดาวน์โหลดข้อมูลที่ไม่จำเป็น
<!-- ตัวอย่าง Hero Image ที่ถูกต้อง -->
<img
src="hero.webp"
alt="ชื่อสินค้า"
width="1200"
height="630"
fetchpriority="high"
>
<!-- รูปทั่วไปใช้ lazy loading -->
<img
src="content.webp"
alt="คำอธิบาย"
width="820"
height="460"
loading="lazy"
>
Preload รูป LCP ใน Theme
ถ้ารู้ล่วงหน้าว่ารูปไหนคือ Largest Contentful Paint ให้เพิ่ม Preload ใน <head> เพื่อให้ Browser โหลดรูปนั้นทันทีโดยไม่ต้องรอ CSS หรือ JS:
<!-- เพิ่มใน header.php หรือ functions.php -->
<link rel="preload" as="image" href="/wp-content/themes/mytheme/img/hero.webp" type="image/webp">
แก้ INP — ลด JavaScript ที่บล็อกการตอบสนอง
INP (Interaction to Next Paint) คือ Metric ที่วัดว่าหลังจากผู้ใช้คลิกหรือพิมพ์ ต้องรอนานแค่ไหนก่อนที่หน้าจะ Paint อัพเดตให้เห็น ถ้า JavaScript ทำงานหนักบน Main Thread จะทำให้ Browser ไม่สามารถตอบสนองได้ทันที INP สูง (>200ms) มักพบในเว็บที่มี Plugin เยอะหรือ Theme ที่ใช้ JS หนัก
Defer และ Delay JavaScript ที่ไม่จำเป็น
JavaScript ที่รันทันทีตอนโหลดหน้าจะบล็อก Main Thread ทำให้ INP สูง วิธีแก้:
- ใช้ defer attribute สำหรับ JS ที่ไม่ต้องรันก่อน render เช่น analytics, chat widget, social share
- WP Rocket มีฟีเจอร์ Delay JavaScript Execution — JS บางตัวจะรันก็ต่อเมื่อผู้ใช้เลื่อนหน้าหรือ Interact ครั้งแรก
- ลบ Plugin ที่ไม่ใช้และ Script ที่โหลดทุกหน้าโดยไม่จำเป็น ใช้ Plugin Asset CleanUp หรือ WP Rocket's Load JS Deferred เพื่อควบคุม
- ตรวจ Long Tasks ใน Chrome DevTools → Performance → บาร์แดงที่ยาวเกิน 50ms คือ Long Task ที่ต้องแก้
ลด Third-Party Scripts
Third-Party Scripts เช่น Facebook Pixel, Google Tag Manager, Chat Plugin, A/B Testing Tool มักเป็นตัวการหลักของ INP สูง เพราะรันบน Main Thread เดียวกับ WordPress เอง
- รัน Script เหล่านี้ผ่าน Google Tag Manager แล้ว Delay trigger ให้ยิงหลัง interaction แรก
- ใช้ Partytown (ถ้า Theme รองรับ) เพื่อรัน Third-Party JS บน Web Worker แยก Main Thread
- ตรวจว่า Plugin แต่ละตัวโหลด Script อะไรบ้างด้วย Chrome DevTools → Network tab กรอง JS
ระวัง: การ Delay หรือ Defer Script อาจทำให้ฟีเจอร์บางอย่างทำงานผิดพลาดได้ เช่น Popup, Form Validation หรือ Cart อย่า Defer Script ที่เว็บต้องพึ่งพาตอนโหลด — ทดสอบในหน้า Staging ก่อนเสมอ
แก้ CLS — หยุดหน้าเว็บกระตุก
CLS (Cumulative Layout Shift) เป็น Metric ที่ผู้ใช้รู้สึกได้ทันที — รูปที่กระโดดขึ้น ข้อความที่เลื่อนลง หรือปุ่มที่ขยับออกพอดีตอนจะกด ทำให้ UX แย่มากและส่งผลต่อ Conversion โดยตรง สาเหตุหลักบน WordPress:
ระบุ width และ height ทุกรูปภาพ
การไม่ระบุขนาดรูปทำให้ Browser ไม่รู้จะจองพื้นที่เท่าไหร่ เมื่อรูปโหลดเสร็จจึงดันเนื้อหาอื่นออกไป ทำให้ CLS สูง แก้ได้ด้วยการใส่ width และ height ใน HTML โดยตรง หรือใช้ CSS aspect-ratio บน container
/* CSS แก้ CLS สำหรับรูป Responsive */
img {
max-width: 100%;
height: auto; /* ให้ความสูง scale ตาม width แต่ต้องมี width/height ใน HTML ด้วย */
}
/* หรือใช้ aspect-ratio */
.hero-image-wrap {
aspect-ratio: 820 / 340;
width: 100%;
overflow: hidden;
}
Font Loading — ป้องกัน FOUT/FOIT
Web Font ที่โหลดทีหลัง Fallback Font ทำให้ Text ขยับตำแหน่ง (เรียกว่า FOUT — Flash of Unstyled Text) ซึ่งเพิ่ม CLS ได้มาก แก้ด้วย:
- ใช้ font-display: swap ใน CSS เพื่อให้แสดง Fallback Font ทันทีแล้วค่อยสลับ
- เพิ่ม <link rel="preload"> สำหรับ Font ที่ใช้บ่อยที่สุด (เช่น Font ที่ใช้ใน Heading)
- ใช้ Google Fonts ผ่าน
&display=swapparameter เช่นhttps://fonts.googleapis.com/css2?family=Sarabun&display=swap - พิจารณาใช้ System Font Stack แทน Custom Font สำหรับ Body Text เพื่อ LCP + CLS ที่ดีขึ้น
กำหนดพื้นที่สำรองสำหรับโฆษณาและ Embed
โฆษณา Google AdSense, Facebook Embed, YouTube Embed และ Widget อื่นๆ ที่โหลดทีหลังมักทำให้ Layout Shift เพราะไม่มีพื้นที่สำรองไว้ล่วงหน้า
- กำหนด min-height บน Container ที่จะแสดงโฆษณา (เช่น
min-height: 250pxสำหรับ Banner 250px) - YouTube Embed ใช้ CSS aspect-ratio: 16/9 ป้องกันการ Shift
- ใช้ Plugin Embed Optimizer (มาพร้อมกับ Autoptimize หรือ WP Rocket) ที่จัดการ aspect-ratio อัตโนมัติ
/* CSS สำหรับ YouTube Embed ที่ไม่ Shift */
.video-wrap {
position: relative;
padding-bottom: 56.25%; /* 16:9 ratio */
height: 0;
overflow: hidden;
}
.video-wrap iframe {
position: absolute;
top: 0; left: 0;
width: 100%; height: 100%;
}
เครื่องมือวินิจฉัย Core Web Vitals ที่ใช้งานได้ทันที
ก่อนจะแก้ไขอะไรต้องรู้ก่อนว่าปัญหาอยู่ที่ไหน เครื่องมือที่ใช้ได้ฟรีและให้ข้อมูลตรงประเด็น:
| เครื่องมือ | ข้อมูลที่ได้ | เหมาะกับ |
|---|---|---|
| PageSpeed Insights | Lab + Field Data, คำแนะนำแก้ไขละเอียด | Debug ปัญหาเฉพาะหน้า |
| Google Search Console | Field Data จริง แยก Desktop/Mobile, แสดง URL ที่มีปัญหา | ติดตาม Core Web Vitals ทั้งเว็บ |
| Chrome DevTools | Performance Timeline, Long Tasks, Layout Shift ละเอียด | Debug แบบ Deep Dive |
| Web Vitals Extension | ดูค่า LCP/INP/CLS แบบ Real-time ขณะ Browse | ทดสอบการ Interact |
| Lighthouse (CLI/DevTools) | Audit ครบ รวม Accessibility, SEO, Best Practices | Audit ก่อน Deploy |
Plugin WordPress ที่ช่วย Core Web Vitals ได้จริง
มี Plugin จำนวนมากที่อ้างว่าช่วย Core Web Vitals แต่ในทางปฏิบัติมีเพียงไม่กี่ตัวที่ให้ผลจริงโดยไม่ทำให้เว็บพัง ต่อไปนี้คือ Plugin ที่ผ่านการทดสอบกับเว็บจริงและให้ผลดีที่สุด:
สำหรับ LCP + การโหลดโดยรวม
- WP Rocket — ครอบคลุม LCP, INP, CLS ในตัวเดียว Page Cache + Preload + Image Lazy Load + Defer JS + Remove Unused CSS ตั้งค่าง่ายที่สุดในกลุ่ม (Premium เริ่มต้น $59/ปี)
- LiteSpeed Cache — ฟรี ครอบคลุมเกือบเท่า WP Rocket ต้องใช้กับ LiteSpeed Web Server จึงจะได้ประสิทธิภาพเต็มที่
- Flying Pages — ทำ Intelligent Prefetch โหลดหน้าถัดไปล่วงหน้าเมื่อ Mouse Hover ช่วยให้ LCP หน้า Second Page เร็วมาก (ฟรี)
สำหรับ CSS/JS Optimization
- Autoptimize — Minify + Combine CSS และ JS ใช้ร่วมกับ Plugin Cache ได้ดี ตั้งค่าผ่าน UI ง่าย (ฟรี)
- Asset CleanUp: Page Speed Booster — ปิด CSS/JS ของ Plugin ในหน้าที่ไม่จำเป็น เช่น Contact Form ไม่ต้องโหลดทุกหน้า ลด INP ได้มาก (ฟรี)
- Perfmatters — ตั้งค่า Performance ละเอียดมาก Disable Emojis, Remove Query Strings, Disable WP Embeds, Heartbeat Control (Premium)
สำหรับ Image Optimization
- Imagify — แปลงเป็น WebP อัตโนมัติ + Optimize ตอน Upload ใหม่ + Re-optimize ไฟล์เดิมทั้งหมด (มี Free tier)
- ShortPixel — คุณภาพ Compression ดีมาก รองรับ WebP + AVIF รัน API-based (ฟรี 100 ภาพ/เดือน)
- Smush — ฟรี แต่ WebP ต้องใช้ Pro ใช้ร่วมกับ WP Engine ได้ดี
สำคัญมาก: ห้ามติดตั้ง Cache Plugin สองตัวพร้อมกัน (เช่น WP Rocket + LiteSpeed Cache) เพราะจะ Conflict กัน เลือกใช้แค่ตัวเดียวที่ครอบคลุมที่สุด แล้วเพิ่ม Plugin เฉพาะทาง (เช่น Image Optimization) เสริมได้
การตั้งค่า Hosting ที่ส่งผลต่อ Core Web Vitals
ไม่ว่าจะ Optimize WordPress ดีแค่ไหน ถ้า Hosting ช้าคะแนนก็ดีขึ้นได้จำกัด TTFB ที่สูงกว่า 600ms บน Mobile จะทำให้ LCP พลาดเกณฑ์แทบทุกกรณี สิ่งที่ต้องดูที่ฝั่ง Hosting:
- ตำแหน่ง Server — เลือก Data Center ที่ใกล้ผู้ใช้กลุ่มหลัก ถ้า Target เป็นคนไทย ควรใช้ Server ไทยหรือสิงคโปร์เพื่อ TTFB ต่ำกว่า 150ms
- PHP Version — ใช้ PHP 8.2 หรือ 8.3 ซึ่งเร็วกว่า PHP 7.x มากถึง 30% ตั้งค่าได้ใน DirectAdmin → PHP Selector
- PHP OPcache — ต้องเปิดใช้งาน OPcache เพื่อ Cache Compiled PHP Code ลด CPU และ Response Time ลงมาก
- MySQL/MariaDB Version — ใช้ MariaDB 10.6+ เพื่อ Query Performance ที่ดีกว่า
- Persistent Connection / Keep-Alive — ลด TCP Handshake Overhead สำหรับ Resource ที่โหลดจาก Server เดียวกัน
CDN และ HTTP/2 — เร่ง LCP อีกขั้น
Content Delivery Network (CDN) กระจาย Static Files (CSS, JS, รูปภาพ) ไปยัง Edge Server ที่ใกล้กับผู้ใช้ที่สุด ลด TTFB และ LCP ได้ชัดเจนโดยเฉพาะสำหรับผู้ใช้ที่อยู่ต่างประเทศหรือห่างจาก Server มาก
- Cloudflare (Free tier) — ง่ายที่สุด เพียงเปลี่ยน DNS ไปชี้ Cloudflare ก็เริ่มใช้ CDN ได้ทันที รองรับ HTTP/3 (QUIC) ด้วย
- BunnyCDN — ราคาถูกที่สุดในกลุ่ม Pay-per-use ($0.01/GB) Performance ดีมาก ใช้คู่กับ WP Rocket ได้ดี
- อ่านรายละเอียดการตั้งค่า CDN บน WordPress เพิ่มเติมที่ CDN บน WordPress เพิ่มความเร็วเว็บ
ตรวจ Core Web Vitals บน Mobile — สำคัญกว่า Desktop
Google ใช้ Mobile-First Indexing มาตั้งแต่ปี 2023 ซึ่งหมายความว่า Core Web Vitals ที่ Google สนใจเป็นหลักคือ ค่า Mobile ไม่ใช่ Desktop เว็บ WordPress จำนวนมากได้คะแนน Desktop ดีมากแต่ Mobile ช้ามาก เพราะ Theme หรือ CSS ไม่ได้ถูก Optimize สำหรับ Mobile โดยเฉพาะ
สิ่งที่ทำให้ Mobile ช้ากว่า Desktop:
- Mobile มี CPU ช้ากว่า Emulation ที่ Google ใช้ (Moto G Power) ทำให้ Long Task มีผลมากกว่า
- JavaScript ที่บน Desktop รันใน 50ms อาจใช้ถึง 200ms+ บน Mobile CPU
- การ Resize รูปด้วย CSS (max-width:100%) ไม่ได้ลดขนาดไฟล์ที่ดาวน์โหลด ใช้ srcset สำหรับรูปที่แสดงต่างกันบน Mobile
- Viewport ที่แคบกว่าทำให้ Above-the-fold Content เปลี่ยน ควรทดสอบ LCP ทั้งบน Desktop และ Mobile แยกกัน
<!-- ใช้ srcset เพื่อส่งรูปขนาดต่างกันตาม Viewport -->
<img
src="hero-820.webp"
srcset="hero-400.webp 400w, hero-820.webp 820w, hero-1200.webp 1200w"
sizes="(max-width:400px) 400px, (max-width:820px) 820px, 1200px"
alt="Hero Image"
width="820"
height="430"
fetchpriority="high"
>
Checklist Core Web Vitals — ทำตามลำดับ
| # | งานที่ต้องทำ | Metric ที่ช่วย | ความสำคัญ |
|---|---|---|---|
| 1 | ติดตั้ง Cache Plugin (WP Rocket / LiteSpeed) | LCP, INP | สูงมาก |
| 2 | แปลงรูปเป็น WebP + ระบุ width/height ทุก img | LCP, CLS | สูงมาก |
| 3 | เพิ่ม fetchpriority="high" บนรูป LCP | LCP | สูง |
| 4 | Defer / Delay JavaScript ที่ไม่จำเป็น | INP, LCP | สูง |
| 5 | ลบ Plugin ที่ไม่ใช้และโหลด JS/CSS ทุกหน้า | INP, LCP | สูง |
| 6 | กำหนดพื้นที่สำรองสำหรับโฆษณาและ Embed | CLS | สูง |
| 7 | Preload Web Font + ใช้ font-display:swap | CLS, LCP | กลาง |
| 8 | อัพเกรด PHP เป็น 8.2+ เปิด OPcache | LCP (TTFB) | สูง |
| 9 | ติดตั้ง CDN (Cloudflare Free หรือ BunnyCDN) | LCP | กลาง |
| 10 | ตรวจ Core Web Vitals ใน Google Search Console | ทุก Metric | สูงมาก |
เป้าหมาย: หลังทำ Checklist ครบ ควรได้ PageSpeed Insights Mobile ≥ 70 คะแนน และ Google Search Console แสดง URL ในกลุ่ม "Good" ≥ 75% ของหน้าทั้งหมด ภายใน 28 วัน (รอบเก็บข้อมูล CrUX อัพเดตทุก 28 วัน)
การแก้ Core Web Vitals ไม่ใช่งานทำครั้งเดียวแล้วเสร็จ เพราะทุกครั้งที่ติดตั้ง Plugin ใหม่ อัพเดต Theme หรือเพิ่ม Widget ใหม่ล้วนส่งผลต่อ Performance ทั้งสิ้น ควรตรวจ Google Search Console อย่างน้อย เดือนละ 1 ครั้ง และรัน PageSpeed Insights ก่อน–หลังการเปลี่ยนแปลงสำคัญทุกครั้ง อ่านเพิ่มเติมเกี่ยวกับ Cache Plugin ที่เหมาะสมที่ ใช้ Cache Plugin บน WordPress เพิ่มความเร็ว และการเพิ่มความเร็วแบบครบวงจรที่ เพิ่มความเร็ว WordPress ฉบับสมบูรณ์
Hosting WordPress ที่เร็วตั้งแต่ต้น — รวม SSL ฟรี
AsiaGB Hosting มี PHP 8.3, OPcache, LiteSpeed Web Server และ SSL Certificate ฟรีในตัว พร้อม DirectAdmin จัดการง่าย เริ่มต้น 500 บาท/ปี ลด TTFB และ LCP ได้ทันทีโดยไม่ต้องแก้โค้ด
ดูแพ็กเกจ Hosting ราคาถูก →