Hosting
Core Web Vitals คืออะไร และทำไมถึงสำคัญ
Core Web Vitals (CWV) คือชุดตัวชี้วัดประสบการณ์ผู้ใช้ที่ Google กำหนดขึ้นเพื่อวัด "ความเร็วที่ผู้ใช้รู้สึก" จริงๆ ไม่ใช่แค่เวลาโหลดแบบเทคนิค ประกอบด้วย 3 ค่าหลักได้แก่ LCP, INP และ CLS โดย Google นำค่าเหล่านี้ไปใช้เป็นปัจจัยในการจัดอันดับ Search ตั้งแต่ปี 2021 เป็นต้นมา
สำหรับเว็บ WordPress บน Shared Hosting การปรับ CWV อาจดูซับซ้อน แต่จริงๆ แล้วมีขั้นตอนที่ชัดเจนและทำได้โดยไม่ต้องแตะ Server หรือใช้ CLI เลย เพียงแค่ตั้งค่า Plugin ให้ถูกต้องและปรับ Theme เล็กน้อยก็สามารถผ่านเกณฑ์ "Good" ของ Google ได้
LCP, INP และ CLS แตกต่างกันอย่างไร
LCP (Largest Contentful Paint) วัดเวลาที่ใช้ในการแสดงส่วนที่ใหญ่ที่สุดในหน้าจอ ซึ่งส่วนใหญ่คือรูป Hero Image หรือ Heading หลัก เกณฑ์ที่ดีคือ ≤ 2.5 วินาที ถ้า LCP สูงมักเกิดจากรูปภาพขนาดใหญ่ที่ยังไม่ Preload หรือ Server Response Time ที่ช้า
INP (Interaction to Next Paint) เข้ามาแทน FID ตั้งแต่มีนาคม 2024 วัดความเร็วในการตอบสนองเมื่อผู้ใช้คลิก แตะ หรือพิมพ์ เกณฑ์ที่ดีคือ ≤ 200ms ปัญหาหลักมักมาจาก JavaScript ขนาดใหญ่ที่ Block Main Thread ทำให้ Browser ไม่มีเวลาตอบสนองผู้ใช้
CLS (Cumulative Layout Shift) วัดความเสถียรของ Layout ขณะโหลด ถ้ารูปภาพไม่มีการกำหนดขนาด หรือ Font โหลดทีหลังแล้วดัน Content เลื่อน ค่า CLS จะสูง เกณฑ์ที่ดีคือ ≤ 0.1
| Metric | ย่อมาจาก | เกณฑ์ "Good" | ปัญหาหลักบน Shared Hosting |
|---|---|---|---|
| LCP | Largest Contentful Paint | ≤ 2.5 วินาที | Hero Image ใหญ่, TTFB สูง |
| INP | Interaction to Next Paint | ≤ 200ms | JavaScript หนัก, Third-party Scripts |
| CLS | Cumulative Layout Shift | ≤ 0.1 | รูปไม่มี Size, Web Font ไม่มี Fallback |
- LCP ส่งผลต่อ Ranking โดยตรงมากที่สุดในกลุ่ม CWV
- INP ส่งผลต่อ UX มือถือเป็นพิเศษ เพราะ CPU มือถือช้ากว่า Desktop มาก
- CLS ส่งผลต่อความน่าเชื่อถือ ผู้ใช้รู้สึกหงุดหน่ายเมื่อ Content เด้ง
- ผ่านทั้ง 3 ตัวพร้อมกันถึงจะนับว่าเว็บ "Good" ใน Core Web Vitals
ตรวจสอบคะแนน CWV ด้วย PageSpeed Insights
ก่อนแก้ปัญหา ต้องรู้ก่อนว่าเว็บเราคะแนนเป็นอย่างไร เครื่องมือหลักที่ Google แนะนำคือ PageSpeed Insights (pagespeed.web.dev) ซึ่งแสดงทั้ง Lab Data (จำลองจาก Lighthouse) และ Field Data (ข้อมูลจริงจากผู้ใช้ Chrome) โดย Google ใช้ Field Data เป็นปัจจัยในการจัด Ranking
เครื่องมืออื่นที่ควรใช้ร่วมด้วยคือ Google Search Console หมวด "Core Web Vitals" จะบอกว่าหน้าไหนมีปัญหาบ้าง และ Chrome DevTools แท็บ Performance สามารถ Record การโหลดเพื่อดู LCP/CLS ได้ละเอียดมากขึ้น
- เปิด pagespeed.web.dev แล้วใส่ URL เว็บของคุณ
- ดู Field Data ก่อนเสมอ — นี่คือข้อมูลที่ Google ใช้จริง
- ดู Opportunities และ Diagnostics เพื่อรู้ว่าต้องแก้อะไร
- ทดสอบทั้งหน้าแรก (Homepage) และหน้าบทความยาวๆ เพราะ CWV อาจต่างกัน
- ทดสอบทั้ง Mobile และ Desktop แยกกัน — เกณฑ์ Mobile เข้มงวดกว่ามาก
แก้ LCP: Preload Hero Image และ fetchpriority
LCP ที่ช้าส่วนใหญ่เกิดจากรูป Hero Image ที่ Browser ค้นพบช้าเกินไป เพราะต้องรอ CSS หรือ JavaScript โหลดก่อน วิธีแก้ที่เร็วที่สุดคือการบอก Browser ล่วงหน้าว่ารูปนี้สำคัญมาก ต้องโหลดก่อนสิ่งอื่น
วิธีที่ 1 คือใส่ fetchpriority="high" ลงในแท็ก <img> ของรูป Hero พร้อมกับลบ loading="lazy" ออก เพราะ lazy load จะทำให้รูปโหลดช้าลงโดยตั้งใจ ซึ่งขัดแย้งกับการ Optimize LCP
วิธีที่ 2 คือเพิ่ม <link rel="preload"> ใน <head> เพื่อให้ Browser เริ่ม Download รูปทันทีที่ HTML ถูก Parse โดยไม่ต้องรอ CSS/JS บน WordPress สามารถทำได้ผ่าน Plugin หรือเพิ่มโค้ดใน functions.php ของ Theme
- ใช้
fetchpriority="high"บน Hero Image เพียงรูปเดียวเท่านั้น ห้ามใส่หลายรูป - ลบ
loading="lazy"ออกจาก Hero Image (ใส่ lazy ได้กับรูปที่อยู่ด้านล่าง) - Compress Hero Image ให้ขนาดไม่เกิน 100–150 KB ก่อนเสมอ
- ใช้ format WebP แทน JPEG/PNG เพื่อลดขนาดอีก 25–35%
- กำหนด
widthและheightบน<img>เพื่อป้องกัน CLS ด้วย
แก้ INP: ลด JavaScript Execution Time
INP สูงมักเกิดจาก JavaScript ที่ใช้เวลานานเกินไปบน Main Thread ทำให้เมื่อผู้ใช้คลิกหรือแตะหน้าจอ Browser ต้องรอให้ JavaScript ทำงานเสร็จก่อนถึงจะ Paint ผลลัพธ์ได้ บน Shared Hosting ปัญหานี้รุนแรงขึ้นเพราะ CPU ที่ได้รับจัดสรรมีจำกัด
วิธีแก้หลักคือลด JavaScript ที่ไม่จำเป็นออกให้มากที่สุด ตรวจสอบ Plugin ทุกตัวว่า Load Script บนหน้าที่ไม่ได้ใช้งานหรือเปล่า เช่น Plugin Contact Form ที่โหลด Script ทุกหน้าทั้งที่มี Form แค่หน้าเดียว ใช้ Plugin อย่าง "Asset CleanUp" เพื่อปิด Script ที่ไม่จำเป็นในแต่ละหน้า
นอกจากนี้ Script ที่โหลดจากภายนอก (Third-party) อย่าง Chat Widget, Popup Builder หรือ Analytics ที่ไม่จำเป็น ควรเปลี่ยนเป็นแบบ Defer หรือ Lazy Load เพื่อไม่ให้ Block Main Thread ขณะที่ผู้ใช้กำลังโต้ตอบกับหน้าเว็บ
- ไปที่ PageSpeed Insights แล้วดู "Reduce JavaScript execution time" ใน Diagnostics
- ปิด Plugin ที่ไม่ได้ใช้งาน — แม้ปิดแล้วยังโหลด Script อยู่บางตัว ต้องลบออก
- ใช้ Plugin "Asset CleanUp Pro" หรือ "Perfmatters" เพื่อควบคุม Script ต่อหน้า
- เปลี่ยน Analytics Script เป็น
asyncหรือdeferเสมอ - หลีกเลี่ยง Page Builder ที่โหลด JavaScript หนักๆ เช่น Elementor บนหน้าที่เน้น CWV
แก้ CLS: กำหนด Width/Height รูปภาพและ Ad Slots
CLS เกิดขึ้นเมื่อ Element บนหน้าเว็บเลื่อนตำแหน่งหลังจาก Content อื่นโหลดแล้ว สาเหตุที่พบบ่อยที่สุดบน WordPress คือรูปภาพที่ไม่มีการกำหนด Width/Height เพราะ Browser ไม่รู้ว่าต้องจองพื้นที่เท่าไหร่ให้รูป เมื่อรูปโหลดเสร็จจึงดัน Content อื่นเลื่อนลงไป
วิธีแก้คือกำหนด width และ height attribute บนแท็ก <img> ทุกรูป WordPress 5.5 ขึ้นไปใส่ค่านี้โดยอัตโนมัติเมื่ออัปโหลดรูปผ่าน Media Library แต่รูปเก่าที่อัปโหลดมาก่อนอาจไม่มี ให้ใช้ Plugin "Regenerate Thumbnails" เพื่อสร้าง Meta ใหม่
สำหรับ Ad Slots หรือ Embed เช่น YouTube ให้กำหนด Container ที่มีขนาดตายตัว (Aspect Ratio) ไว้ก่อนที่ Embed จะโหลด ใช้ CSS Padding Trick padding-bottom: 56.25% สำหรับ 16:9 หรือใช้ aspect-ratio: 16/9 ใน CSS สมัยใหม่
- ตรวจหารูปที่ไม่มี Width/Height ด้วย DevTools → Elements แล้วค้นหา
imgที่ไม่มี attribute - Web Font ที่โหลดช้าทำ CLS ได้ — ใช้
font-display: swapใน CSS - Sticky Header หรือ Banner ที่โผล่ขึ้นมาหลัง Load ทำ CLS สูงมาก — ใช้ Position Fixed ตั้งแต่แรก
- ปิด Lazy Load บน Hero Image เพื่อลด LCP และป้องกัน CLS พร้อมกัน
- ทดสอบ CLS ด้วย Chrome DevTools → Performance → Layout Shift ดูได้ว่า Element ไหนเป็นตัวปัญหา
Plugin ที่ช่วย CWV บน WordPress
การปรับ Core Web Vitals บน WordPress ไม่จำเป็นต้องแก้โค้ดด้วยมือทั้งหมด มี Plugin หลายตัวที่ช่วยให้ทำงานได้โดยไม่ต้องมีความรู้ด้านเทคนิค แต่ต้องเลือกให้เหมาะสมกับ Theme และ Plugin ที่ใช้อยู่ เพราะการใส่ Plugin Cache หลายตัวพร้อมกันอาจทำให้เกิด Conflict
Plugin ที่แนะนำสำหรับมือใหม่คือ LiteSpeed Cache หากใช้ Hosting ที่รัน LiteSpeed Web Server (ปรึกษา Hosting เพื่อตรวจสอบ) ถ้าใช้ Apache หรือ Nginx ทั่วไปให้ใช้ WP Rocket หรือ W3 Total Cache แทน ทั้งสองตัวมีฟีเจอร์ Defer JS, Critical CSS และ Image Lazy Load ในตัว
| Plugin | ราคา | แก้ LCP | แก้ INP | แก้ CLS | เหมาะกับ |
|---|---|---|---|---|---|
| LiteSpeed Cache | ฟรี | ✓ | ✓ | บางส่วน | Hosting LiteSpeed เท่านั้น |
| WP Rocket | ~$59/ปี | ✓ | ✓ | ✓ | ทุก Hosting, ใช้ง่ายที่สุด |
| W3 Total Cache | ฟรี/Pro | ✓ | บางส่วน | ไม่ครบ | ผู้ที่รู้ด้านเทคนิค |
| Imagify / ShortPixel | ฟรี/จ่าย | ✓ | — | บางส่วน | Optimize รูปภาพโดยเฉพาะ |
| Perfmatters | ~$24/ปี | บางส่วน | ✓ | — | ปิด Script ต่อหน้า |
- ห้ามใช้ Cache Plugin 2 ตัวพร้อมกัน เช่น WP Rocket + W3 Total Cache จะ Conflict แน่นอน
- หลังติดตั้ง Plugin ให้ Purge Cache ก่อนทดสอบด้วย PageSpeed เสมอ
- ตั้งค่า Critical CSS (บางครั้งเรียก "Above the fold CSS") เพื่อให้ First Paint เร็วขึ้น
- เปิดฟีเจอร์ Defer JavaScript ระวัง jQuery Defer อาจทำให้บาง Plugin เสีย
ตรวจสอบ Core Web Vitals ด้วย PageSpeed Insights
ก่อนและหลังแก้ไข ให้ทดสอบด้วย PageSpeed Insights และเก็บผลเปรียบเทียบ ตัวอย่างด้านล่างแสดงโค้ดที่ใส่เพื่อปรับ LCP และป้องกัน CLS พร้อมวิธีตรวจสอบผ่าน Search Console API
<!-- 1. Preload Hero Image ใน <head> -->
<link rel="preload" as="image" href="/images/hero-banner.webp" fetchpriority="high">
<!-- 2. Hero Image Tag ที่ถูกต้อง (ไม่มี lazy, มี fetchpriority, มี size) -->
<img src="/images/hero-banner.webp"
alt="Hero Banner"
width="1200" height="630"
fetchpriority="high">
<!-- 3. รูปที่อยู่ด้านล่าง (Below the fold) ใส่ lazy ได้ปกติ -->
<img src="/images/article-thumbnail.webp"
alt="Article Thumbnail"
width="600" height="400"
loading="lazy">
<!-- 4. CSS สำหรับ YouTube Embed ป้องกัน CLS -->
<style>
.video-wrapper {
position: relative;
padding-bottom: 56.25%; /* 16:9 ratio */
height: 0;
overflow: hidden;
}
.video-wrapper iframe {
position: absolute;
top: 0; left: 0;
width: 100%; height: 100%;
}
</style>
<!-- 5. font-display: swap ป้องกัน CLS จาก Web Font -->
<style>
@font-face {
font-family: 'Sarabun';
src: url('/fonts/sarabun.woff2') format('woff2');
font-display: swap; /* <-- สำคัญมาก ป้องกัน FOIT/CLS */
}
</style>แก้ปัญหาที่พบบ่อย
LCP สูง แม้ Optimize รูปแล้ว — Server Response Time (TTFB) สูงเกินไป
ถ้า Optimize รูปแล้วแต่ LCP ยังไม่ลด ให้ดูที่ค่า TTFB (Time to First Byte) ใน PageSpeed Insights ซึ่งวัดเวลาที่ Server ใช้ในการส่ง Byte แรก ถ้า TTFB สูงกว่า 600ms แสดงว่า Server ตอบสนองช้า Browser จะยังไม่เริ่มโหลดอะไรเลย ทำให้ LCP สูงโดยปริยาย
แก้ TTFB บน Shared Hosting ได้ด้วยการเปิด Page Cache (ให้ Server ส่ง HTML สำเร็จรูปแทนการ Generate ใหม่ทุกครั้ง) ใช้ Object Cache ด้วย Redis หรือ Memcached (ถามกับ Hosting ว่ารองรับไหม) และเปิด Gzip/Brotli Compression ใน .htaccess หรือผ่าน Plugin
CLS เกิดแม้กำหนด Size รูปแล้ว — Font, Ads หรือ Embed เปลี่ยน Layout หลัง Load
CLS ที่ยังสูงแม้ใส่ Width/Height รูปครบแล้ว มักเกิดจาก 3 สาเหตุหลัก ได้แก่ Web Font ที่โหลดช้าแล้ว Swap ขนาด, Google AdSense หรือ Affiliate Banner ที่โหลดทีหลังแล้วดัน Content ลง, และ Embed เช่น Instagram/Twitter Widget ที่ Resize ตัวเองหลังโหลด
วิธีแก้คือกำหนด min-height ให้ Container ของ Ad/Widget ล่วงหน้าตามขนาดที่คาดว่า Ad จะแสดง สำหรับ Font ให้เปลี่ยน font-display: block เป็น font-display: swap หรือใช้ System Font Fallback ที่ใกล้เคียง
INP สูงบนมือถือ — Third-party Script ที่ไม่จำเป็น Blocking Main Thread
INP บนมือถือสูงกว่า Desktop เสมอเพราะ CPU มือถือมีประสิทธิภาพต่ำกว่ามาก Script ที่ Block Main Thread แค่ 100ms บน Desktop อาจกลายเป็น 500ms+ บนมือถือรุ่นกลาง สาเหตุที่พบบ่อยคือ Chat Widget (Tawk.to, Crisp), Popup Plugin (OptinMonster, Elementor Popup) และ Cookie Consent Banner
ให้ Delay Script เหล่านี้จนกว่าผู้ใช้จะ Interact ครั้งแรก (User Interaction Trigger) หรือหลัง Page Load 3–5 วินาที WP Rocket มีฟีเจอร์ "Delay JavaScript Execution" ที่ทำแบบนี้ได้โดยไม่ต้องแก้โค้ด
PageSpeed Score ต่ำแต่เว็บรู้สึกเร็ว — Lab Data กับ Real User Data ต่างกัน
PageSpeed Insights ใช้ Server จาก US (หรือ Region ใกล้เคียง) ในการทดสอบ Lab Data ดังนั้นถ้าเว็บของคุณอยู่ในไทยและมี CDN ที่ดี Real User ในไทยอาจได้ประสบการณ์ที่เร็วกว่ามาก ในขณะที่ Lab Score ดูต่ำ
ให้ดูที่ Field Data (Chrome User Experience Report) ซึ่งเก็บข้อมูลจาก Chrome ผู้ใช้จริง ถ้า Field Data "Good" แสดงว่า Google มองเว็บคุณในแง่ดีแล้ว การ Optimize ต่อเพื่อเพิ่ม Lab Score จาก 75 เป็น 85 อาจไม่มีผลต่อ Ranking มากนัก ควรโฟกัสที่ Field Data เป็นหลัก