ถ้าคุณเคยเปิด Google PageSpeed Insights ใส่ URL เว็บของคุณลงไป แล้วเห็นตัวเลขสีแดงเด้งขึ้นมาที่ 35 หรือ 42 — คุณไม่ได้อยู่คนเดียว ผมเจอลูกค้าที่ตกใจกับ score นี้ทุกอาทิตย์ บางคนถึงขนาดยกเลิกแคมเปญโฆษณา Google Ads เพราะกลัวว่าเว็บช้าจะทำให้ Quality Score ตก ทั้งที่จริง ๆ แล้วผู้ใช้งานจริงไม่ได้รู้สึกว่าเว็บช้าขนาดนั้น คำถามคือ — ทำไม score มันถึงต่ำ ทั้งที่เว็บเปิดเร็วในความรู้สึกของเรา
ความจริงคือ Google PageSpeed Insights ปี 2026 ไม่ใช่เครื่องมือ “วัดความเร็ว” แบบที่หลายคนเข้าใจ แต่มันคือเครื่องมือ “ประเมินคุณภาพการ render” ของเว็บ ที่ผสมข้อมูลสองชุดเข้าด้วยกัน — Lab Data (จำลองในห้อง lab ของ Google) และ Field Data (เก็บจาก Chrome ของผู้ใช้จริงทั่วโลก) ถ้าคุณอ่านสองอย่างนี้ไม่เป็น คุณจะไปแก้ผิดจุด เสียเวลาเสียเงินกับ optimization ที่ไม่ตอบโจทย์ และที่แย่ที่สุดคือ — เว็บอาจช้าลงกว่าเดิมเพราะแก้ผิดวิธี
บทความนี้ผมจะสอนคุณทุกอย่างที่ต้องรู้เกี่ยวกับ PageSpeed Insights ตั้งแต่พื้นฐานว่ามันคืออะไร ทำงานยังไง อ่าน Core Web Vitals 6 ตัวให้เข้าใจ แก้ Lighthouse audits 30 ตัวที่พบบ่อย พร้อมเปรียบเทียบกับเครื่องมืออื่นอย่าง GTmetrix และ WebPageTest จบด้วย case study จริงของเว็บ E-commerce ที่จังหวัดภูเก็ตที่เราปรับ score จาก 35 ขึ้นไปที่ 95 ภายใน 3 อาทิตย์ ทุกอย่างเป็นวิธีที่ developer มืออาชีพใช้กันจริง ไม่ใช่ทฤษฎีลอย ๆ
PageSpeed Insights คืออะไร และทำไมต้องใช้
Google PageSpeed Insights (เรียกย่อ ๆ ว่า PSI) คือเครื่องมือ web performance analysis ที่ Google ปล่อยให้ใช้ฟรีที่ pagespeed.web.dev คุณแค่ใส่ URL ลงไป กดปุ่ม Analyze รออีก 20-30 วินาที ระบบจะให้ score 0-100 พร้อมรายงานละเอียดว่าเว็บมีปัญหาอะไรบ้าง และจะแก้ยังไง โดยจะวิเคราะห์ทั้งบน Mobile และ Desktop แยกกัน เพราะพฤติกรรมการ render มันต่างกันมาก
เครื่องมือนี้ขับเคลื่อนด้วย Lighthouse — open-source automated tool ที่ Google สร้างมาเพื่อ audit คุณภาพเว็บไซต์ ครอบคลุม 4 ด้านหลัก คือ Performance, Accessibility, Best Practices และ SEO ส่วนข้อมูล field จริงดึงมาจาก Chrome User Experience Report (CrUX) ซึ่งเป็น dataset สาธารณะที่ Google เก็บจาก Chrome ของผู้ใช้ที่ opt-in ไว้แล้ว ครอบคลุมเว็บไซต์หลายล้านโดเมนทั่วโลก รวมข้อมูลย้อนหลัง 28 วันล่าสุด
ทำไมคุณต้องใส่ใจกับมันในปี 2026? เพราะ Google ใช้ Core Web Vitals เป็น ranking signal มาตั้งแต่ปี 2021 และในปี 2024 ก็เปลี่ยนจาก FID มาเป็น INP อย่างเป็นทางการ พอถึงปี 2026 ที่การแข่งขัน SEO ดุเดือดมาก เว็บที่ score ต่ำใน PSI จะถูก demote ในผลการค้นหาแบบเห็นได้ชัด ไม่ใช่แค่นั้น ผู้ใช้งานสมัยใหม่อดทนกับเว็บช้าน้อยลงเรื่อย ๆ ข้อมูลจาก Google บอกว่าถ้า LCP เกิน 3 วินาที bounce rate จะเพิ่มขึ้น 32% และถ้าเกิน 5 วินาที จะเพิ่มเป็น 90%
Lab Data vs Field Data — อันไหนสำคัญกว่า
นี่คือจุดที่ developer หน้าใหม่สับสนกันมากที่สุด เพราะ PageSpeed Insights แสดงข้อมูลสองชุดบนหน้าเดียวกัน แล้วบางที score ก็ไม่ตรงกันเลย เช่น Lab data บอกว่า LCP คือ 4.2 วินาที แต่ Field data บอกว่า LCP จริงของผู้ใช้คือ 2.1 วินาที — แล้วคุณจะเชื่ออันไหน?
Lab Data (Lighthouse Simulation)
Lab data คือข้อมูลที่ Lighthouse จำลองขึ้นมาจากการเปิดเว็บของคุณในสภาพแวดล้อมควบคุม โดยใช้ Moto G Power virtual device + Slow 4G throttling (1.6 Mbps download, 750 Kbps upload, 150ms RTT) เพื่อจำลองสภาพการใช้งานบนมือถือกลาง ๆ ในประเทศที่อินเทอร์เน็ตไม่เร็วมาก
ข้อดีของ Lab data คือมัน reproducible — เปิดกี่ครั้งก็ได้ผลใกล้เคียงกัน ทำให้เหมาะกับการ debug และทดสอบหลัง deploy แต่ละครั้ง รวมทั้ง CI/CD pipeline ที่ต้องการตัวเลขแน่นอน ข้อเสียคือมัน ไม่สะท้อนผู้ใช้จริง เพราะผู้ใช้คุณอาจอยู่บน 5G iPhone 15 Pro ในกรุงเทพ ไม่ใช่ Moto G Power บน Slow 4G
Field Data (Chrome User Experience Report)
Field data หรือ CrUX data คือข้อมูลจริงที่ Google เก็บมาจากผู้ใช้ Chrome ทั่วโลกที่ opt-in ให้ส่ง performance metrics กลับมา ครอบคลุมข้อมูลย้อนหลัง 28 วัน และจะแสดงเฉพาะเว็บที่มี traffic เพียงพอ (ประมาณ 4,500 visits ต่อเดือนขึ้นไป) ถ้าเว็บคุณยังเล็กเกินไป จะเห็นข้อความ “The Chrome User Experience Report does not have sufficient real-world speed data for this page”
Field data จะแสดง 3 ค่าที่สำคัญที่สุดคือ LCP, INP, CLS โดยใช้ 75th percentile เป็นเกณฑ์วัด ซึ่งแปลว่า 75% ของผู้ใช้ต้องได้ค่าดีกว่าหรือเท่ากับ threshold นั้น ถึงจะถือว่าผ่าน นี่คือเกณฑ์ที่ Google ใช้ตัดสินใจในการจัดอันดับ SEO จริง
สรุป — เชื่ออันไหน
ถ้าเว็บคุณมี Field data อยู่แล้ว — ให้เชื่อ Field data เป็นหลัก เพราะมันคือสิ่งที่ผู้ใช้จริงเจอ และเป็นสิ่งที่ Google ใช้ rank เว็บ ส่วน Lab data ให้ใช้เป็นเครื่องมือ debug ว่าตอนนี้ปัญหาอยู่ที่ไหน แก้แล้ววัดผลยังไง ถ้าเว็บใหม่ยังไม่มี Field data ก็ใช้ Lab data ไปก่อน แต่ต้องเข้าใจว่ามันคือ worst-case scenario
| ลักษณะ | Lab Data | Field Data (CrUX) |
|---|---|---|
| แหล่งข้อมูล | Simulation ใน Google data center | Chrome ผู้ใช้จริง |
| Device | Moto G Power virtual | ทุก device ที่ user ใช้ |
| Network | Slow 4G throttled | ตามที่ user ใช้จริง |
| Reproducibility | สูง (เปิดกี่ครั้งก็ใกล้เคียง) | ต่ำ (เปลี่ยนทุกวัน) |
| ใช้ตอนไหน | Debug, CI/CD, ทดสอบหลัง deploy | วัด UX จริง, SEO ranking |
| Update บ่อยแค่ไหน | ทุกครั้งที่ analyze | ทุก 24 ชั่วโมง (28-day rolling) |
| ต้องมี traffic ขั้นต่ำ | ไม่ต้อง | ต้องมี ~4,500 visits/เดือน |
6 Core Metrics ที่คุณต้องเข้าใจ
PageSpeed Insights วัด metrics หลายตัวมาก แต่มี 6 ตัวที่สำคัญที่สุดและมีน้ำหนักต่อ score มากที่สุด คุณต้องรู้จักทั้งหมดและเข้าใจว่าจะวัดและแก้ยังไง
1. LCP (Largest Contentful Paint) — เป้าหมาย < 2.5s
LCP คือระยะเวลาที่ใช้ในการ render องค์ประกอบที่ใหญ่ที่สุดที่มองเห็นได้ใน viewport — ปกติคือ hero image, video poster, หรือ heading ขนาดใหญ่ มันสะท้อน “ความรู้สึกว่าเว็บโหลดเสร็จแล้ว” ของผู้ใช้
// วัด LCP ด้วย JavaScript บน production
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log('LCP:', entry.startTime);
console.log('Element:', entry.element);
}
}).observe({ type: 'largest-contentful-paint', buffered: true });เกณฑ์: ดี < 2.5s | ปานกลาง 2.5-4.0s | แย่ > 4.0s
วิธีแก้ที่ effective ที่สุดคือ preload hero image, ใช้ CDN ที่อยู่ใกล้ผู้ใช้ (อ่านเพิ่มที่ คู่มือ Cloudflare ฉบับสมบูรณ์), แปลงรูปเป็น WebP/AVIF, และเพิ่ม fetchpriority="high" ให้ hero image
<!-- ก่อน -->
<img src="/hero.jpg" alt="hero" />
<!-- หลัง -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="hero" width="1920" height="1080"
fetchpriority="high" decoding="async" />2. INP (Interaction to Next Paint) — เป้าหมาย < 200ms
INP เข้ามาแทน FID (First Input Delay) อย่างเป็นทางการในเดือนมีนาคม 2024 ความต่างคือ FID วัดแค่ delay ของ interaction ครั้งแรก ส่วน INP วัด ทุก interaction ตลอด session และเอาค่าที่แย่ที่สุดมารายงาน (ไม่ใช่ average) ดังนั้นเว็บที่เคยผ่าน FID อาจตกที่ INP เพราะมีบาง interaction ที่ช้ามาก
// วัด INP ด้วย web-vitals library
import { onINP } from 'web-vitals';
onINP((metric) => {
console.log('INP:', metric.value);
console.log('Target:', metric.entries[0].target);
// ส่งไป analytics
navigator.sendBeacon('/analytics', JSON.stringify(metric));
});เกณฑ์: ดี < 200ms | ปานกลาง 200-500ms | แย่ > 500ms
สาเหตุหลักของ INP สูงคือ JavaScript ที่ block main thread นาน ๆ โดยเฉพาะ event handler ที่มี logic หนัก ทางแก้คือใช้ requestIdleCallback, แบ่ง task ใหญ่เป็น chunk เล็ก ๆ ด้วย scheduler.yield(), และลบ third-party scripts ที่ไม่จำเป็น
3. CLS (Cumulative Layout Shift) — เป้าหมาย < 0.1
CLS คือค่าผลรวมของการที่ element เลื่อนตำแหน่งโดยไม่คาดคิดในระหว่างที่ผู้ใช้กำลังดูหน้านั้น ๆ ปัญหาที่พบบ่อยคือ ad banner ที่โหลดทีหลังแล้วดันเนื้อหาลง, รูปที่ไม่ได้ใส่ width/height ทำให้ browser ต้องคำนวณใหม่ตอนรูปโหลดเสร็จ, และ font swap ที่ทำให้ขนาดข้อความเปลี่ยน
/* ป้องกัน CLS จากรูปภาพ — ใส่ aspect-ratio */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
/* ป้องกัน CLS จาก font swap */
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom.woff2') format('woff2');
font-display: optional; /* หรือ swap ถ้าจำเป็นต้องโชว์ทันที */
size-adjust: 95%; /* ลด layout shift ตอนสลับ font */
}
/* Reserve space สำหรับ ad slot */
.ad-slot {
min-height: 250px;
contain: layout;
}เกณฑ์: ดี < 0.1 | ปานกลาง 0.1-0.25 | แย่ > 0.25
4. FCP (First Contentful Paint) — เป้าหมาย < 1.8s
FCP วัดเวลาที่ browser render เนื้อหาตัวแรกใด ๆ บนหน้า — อาจเป็น text, image, หรือ SVG ก็ได้ มันเป็น metric ที่บอกว่าเว็บ “เริ่มแสดงผล” เมื่อไหร่ ค่านี้สำคัญเพราะ user จะรู้สึกว่าเว็บไม่ค้าง
ปัจจัยหลักที่กระทบ FCP คือ TTFB ที่ต่ำเกินไป, render-blocking CSS ขนาดใหญ่, และ font loading strategy ที่ไม่ดี วิธีแก้ที่ effective คือ inline critical CSS, defer non-critical CSS, และใช้ font-display: swap
<!-- Inline critical CSS -->
<style>
/* Critical above-the-fold styles */
body { margin: 0; font-family: system-ui; }
.hero { min-height: 100vh; background: #1e3a8a; }
</style>
<!-- Defer non-critical CSS -->
<link rel="preload" href="/styles/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>เกณฑ์: ดี < 1.8s | ปานกลาง 1.8-3.0s | แย่ > 3.0s
5. TTFB (Time to First Byte) — เป้าหมาย < 800ms
TTFB คือเวลาที่ browser ใช้รอ byte แรกของ response กลับมาจาก server หลังจากส่ง request ไป มันสะท้อนความเร็วของ server, database query, และ network latency รวมกันทั้งหมด
# วัด TTFB ด้วย curl
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" \
https://yoursite.comถ้า TTFB ของคุณสูงเกิน 800ms ปัญหามักอยู่ที่ server hosting คุณภาพต่ำ, database query ที่ไม่ได้ index, หรือไม่มี caching layer วิธีแก้คือย้ายไป hosting ที่อยู่ใน region ใกล้ผู้ใช้ ใช้ Cloudflare เป็น CDN+cache layer และเปิด full page caching สำหรับเนื้อหาที่ไม่เปลี่ยนบ่อย
6. Speed Index — เป้าหมาย < 3.4s
Speed Index วัดว่าเนื้อหาที่มองเห็นได้ของหน้านั้น render ได้เร็วแค่ไหน โดยใช้การวิเคราะห์ video frame-by-frame ของ Lighthouse แล้วคำนวณ pixel ที่ painted ในแต่ละช่วงเวลา ยิ่ง Speed Index ต่ำยิ่งดี เพราะแปลว่าเนื้อหา above-the-fold พร้อมให้ดูเร็ว
เกณฑ์: ดี < 3.4s | ปานกลาง 3.4-5.8s | แย่ > 5.8s
| Metric | Good | Needs Improvement | Poor | น้ำหนักใน score |
|---|---|---|---|---|
| FCP | < 1.8s | 1.8-3.0s | > 3.0s | 10% |
| Speed Index | < 3.4s | 3.4-5.8s | > 5.8s | 10% |
| LCP | < 2.5s | 2.5-4.0s | > 4.0s | 25% |
| TBT | < 200ms | 200-600ms | > 600ms | 30% |
| CLS | < 0.1 | 0.1-0.25 | > 0.25 | 25% |
หมายเหตุ: TBT (Total Blocking Time) คือ proxy ของ INP ใน lab environment เพราะ INP ต้องการ user interaction จริงจึงวัดใน lab ไม่ได้
Score Breakdown — สูตรการคำนวณคะแนน
PageSpeed Insights ใช้ weighted formula คำนวณ score 0-100 จาก 5 metrics ข้างต้น โดยใช้ log-normal distribution เพื่อให้คะแนนกระจายตัวสมจริง ผลคือเว็บที่ดีเยี่ยมจะได้ 90+ เว็บส่วนใหญ่จะได้ 50-89 และเว็บที่มีปัญหาจะได้ต่ำกว่า 50
Color Coding
- 90-100 (สีเขียว — Good): เว็บอยู่ใน top 10% ของ web ทั้งหมด ผ่านเกณฑ์ Core Web Vitals แทบทุกตัว
- 50-89 (สีส้ม — Needs Improvement): มีจุดที่ต้องปรับปรุง แต่ยังใช้งานได้พอใช้
- 0-49 (สีแดง — Poor): มีปัญหาจริงจัง ผู้ใช้น่าจะรู้สึกได้ ต้องแก้ด่วน
สิ่งที่ต้องเข้าใจคือ score 90 ไม่ได้แปลว่าเว็บคุณดีกว่า 89 แค่ 1% เพราะ formula มันโค้ง — การไต่จาก 50 ไป 70 ง่ายกว่าจาก 90 ไป 95 มาก ดังนั้นถ้าเว็บคุณอยู่ที่ 88 อย่าเครียดเกินไป มันใกล้ 90 มากแล้ว แต่การไปต่อจาก 88 อาจต้องใช้ effort มากกว่าการจาก 50 ไป 70
Mobile vs Desktop Score — ทำไมต่างกันมาก
Lighthouse จะทดสอบสองสภาพแวดล้อมแยกกัน Mobile ใช้ Moto G Power throttled 4G ส่วน Desktop ใช้ Custom Desktop emulation ไม่ throttle network ดังนั้นเว็บเดียวกันอาจได้ Desktop 95 แต่ Mobile 45 ซึ่งเป็นเรื่องปกติ
ในปี 2026 Mobile score สำคัญกว่า Desktop เพราะ Google ใช้ Mobile-First Indexing มาตั้งแต่ปี 2019 และในไทย traffic จาก mobile สูงกว่า 75% ของทั้งหมด ดังนั้นถ้าต้องเลือก optimize ตัวไหนก่อน — เลือก Mobile
30 Lighthouse Audits ที่พบบ่อย แบ่งตามหมวด
Performance Audits (12 ตัวที่พบบ่อย)
1. Eliminate render-blocking resources — CSS/JS ใน <head> ที่ block การ render วิธีแก้คือ inline critical CSS, defer non-critical CSS/JS
<!-- BAD -->
<link rel="stylesheet" href="/main.css">
<script src="/app.js"></script>
<!-- GOOD -->
<style>/* critical CSS inline */</style>
<link rel="preload" href="/main.css" as="style"
onload="this.rel='stylesheet'">
<script src="/app.js" defer></script>2. Properly size images — ส่งรูปขนาดใหญ่กว่าที่ display จริง วิธีแก้คือใช้ responsive images ด้วย srcset
<img src="/hero-800.webp"
srcset="/hero-400.webp 400w,
/hero-800.webp 800w,
/hero-1200.webp 1200w,
/hero-1920.webp 1920w"
sizes="(max-width: 600px) 100vw,
(max-width: 1200px) 80vw,
1200px"
alt="hero" width="1920" height="1080" />3. Defer offscreen images — รูปที่ยังไม่อยู่ใน viewport ก็ไม่ต้องโหลดทันที ใช้ native lazy loading
<img src="/below-fold.webp" loading="lazy"
decoding="async" width="800" height="600" alt="content" />4. Minify CSS — ลบช่องว่าง comment unnecessary characters ส่วนใหญ่ build tool จัดการให้อยู่แล้ว แต่ต้องตรวจสอบใน production
5. Minify JavaScript — เหมือนกับ CSS แต่สำคัญกว่าเพราะ JS file ใหญ่กว่ามาก ใช้ esbuild, terser หรือ swc
// next.config.js
module.exports = {
swcMinify: true,
compiler: {
removeConsole: process.env.NODE_ENV === 'production',
},
};6. Reduce unused CSS — CSS ที่โหลดมาแต่ไม่ได้ใช้ ใช้ PurgeCSS หรือ Tailwind JIT mode
// tailwind.config.js
module.exports = {
content: ['./src/**/*.{html,js,ts,jsx,tsx}'],
// Tailwind จะ purge class ที่ไม่ใช้อัตโนมัติ
};7. Reduce unused JavaScript — JS bundle ที่ใหญ่เกินจำเป็น ใช้ code splitting + dynamic import
// แทนที่ import ปกติ
import HeavyComponent from './HeavyComponent';
// ด้วย dynamic import
const HeavyComponent = lazy(() => import('./HeavyComponent'));8. Serve images in next-gen formats (WebP/AVIF) — รูปแบบใหม่ลดขนาดได้ 25-50% เทียบกับ JPEG/PNG อ่านเพิ่มที่ WebP vs AVIF 2026
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="hero" />
</picture>9. Use video formats for animated content — GIF file ใหญ่มาก เปลี่ยนเป็น MP4 หรือ WebM
<!-- แทน <img src="anim.gif"> -->
<video autoplay loop muted playsinline>
<source src="anim.webm" type="video/webm">
<source src="anim.mp4" type="video/mp4">
</video>10. Efficiently encode images — บีบอัดรูปให้เหมาะสม ใช้ quality 75-85 สำหรับ JPEG/WebP
# ใช้ cwebp บีบ WebP
cwebp -q 80 input.jpg -o output.webp
# ใช้ avifenc บีบ AVIF
avifenc --min 25 --max 35 input.png output.avif11. Enable text compression — เปิด Brotli หรือ Gzip บน server
# nginx.conf
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript
application/json application/javascript application/xml+rss;
# Brotli (ดีกว่า gzip ~20%)
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript;12. Preconnect to required origins — เปิด TCP connection ล่วงหน้าสำหรับ third-party domain ที่จะใช้แน่ ๆ
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://www.google-analytics.com">Accessibility Audits (8 ตัวที่พบบ่อย)
1. Color contrast — text ต้องมี contrast ratio อย่างน้อย 4.5:1 (text ปกติ) หรือ 3:1 (text ใหญ่ 18pt+) เทียบกับ background
/* BAD — contrast 2.8:1 ไม่ผ่าน */
.text-light { color: #999; background: #fff; }
/* GOOD — contrast 7:1 ผ่าน AAA */
.text-readable { color: #555; background: #fff; }2. Image alt attributes — รูปทุกรูปต้องมี alt attribute รูป decorative ใช้ alt="" รูปมีความหมายต้องบรรยายให้เข้าใจ
3. Form labels — input ทุกตัวต้องมี <label> ที่ associate ผ่าน for attribute หรือ wrap ไว้
<!-- BAD -->
<input type="email" placeholder="Email" />
<!-- GOOD -->
<label for="email">อีเมล</label>
<input type="email" id="email" name="email" required />4. ARIA roles — ใช้ ARIA role ให้ถูกต้องเฉพาะเมื่อจำเป็น ไม่ควรใส่ role ที่ขัดกับ semantic HTML
5. Heading order — heading ต้องเรียงจาก h1 → h2 → h3 ไม่ข้าม level (เช่น h1 → h3 โดยไม่มี h2)
6. Link names — <a> ทุกตัวต้องมี text หรือ aria-label ที่อธิบายปลายทาง อย่าใช้ “click here”
7. Document language — ตั้ง lang attribute ที่ <html> tag
<html lang="th">8. Tap targets sized appropriately — ปุ่มและ link บน mobile ต้องมีขนาดอย่างน้อย 48x48 pixel และห่างกันไม่น้อยกว่า 8 pixel
Best Practices Audits (5 ตัวที่พบบ่อย)
1. HTTPS — ทุกหน้าต้องเป็น HTTPS รวมทั้ง resource ภายในด้วย ถ้ามี mixed content จะเสีย score
2. No browser errors in console — error ใน console ทุกตัวลด score เก็บ log production ด้วย Sentry แล้วแก้ทุก error
3. No deprecated APIs — ห้ามใช้ document.write(), eval() ใน inline script, หรือ Web SQL API
4. Source maps — production code ควรมี source map (แต่ไม่ deploy ขึ้น public) เพื่อให้ debug ได้
// next.config.js
module.exports = {
productionBrowserSourceMaps: true,
};5. Avoid third-party cookies — Chrome กำลังจะ deprecate third-party cookies เต็มรูปแบบในปี 2026 ใช้ first-party cookies หรือ Privacy Sandbox API แทน
SEO Audits (5 ตัวที่พบบ่อย)
1. Document title — ทุกหน้าต้องมี <title> ที่ unique และ descriptive ยาว 50-60 ตัวอักษร
2. Meta description — meta description ที่อธิบายเนื้อหา ยาว 150-160 ตัวอักษร
<title>คู่มือ PageSpeed Insights 2026 | Southern Whale</title>
<meta name="description"
content="คู่มือใช้ PageSpeed Insights ฉบับสมบูรณ์ปี 2026 — เข้าใจ Lab vs Field Data..." />3. Crawlable links — link ต้องเป็น <a href="..."> ห้ามใช้ <div onclick=""> แทน
4. Mobile-friendly — viewport meta tag ต้องถูกต้อง
<meta name="viewport" content="width=device-width, initial-scale=1" />5. robots.txt valid — ต้องมี robots.txt ที่ syntax ถูกต้อง
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Sitemap: https://yoursite.com/sitemap.xmlเปรียบเทียบ PageSpeed Insights vs GTmetrix vs WebPageTest
PageSpeed Insights ไม่ใช่เครื่องมือ performance test เพียงตัวเดียว ในงานจริง developer มืออาชีพมักใช้หลายตัวประกอบกันเพื่อมุมมองที่ครอบคลุม ผมเปรียบเทียบ 3 ตัวที่ใช้กันมากที่สุด
| คุณสมบัติ | PageSpeed Insights | GTmetrix | WebPageTest |
|---|---|---|---|
| ราคา | ฟรี | ฟรี + Pro $14.95/เดือน | ฟรี + Premium $200+/เดือน |
| Engine | Lighthouse | Lighthouse + custom | Custom + Lighthouse |
| Field Data (CrUX) | มี | ไม่มี | มี (ผ่าน CrUX API) |
| Test Location | Server ของ Google | 22 location | 40+ location |
| Network throttling | Slow 4G fixed | เลือกได้ (Free: 3G only) | เลือก profile ได้หลายแบบ |
| Video recording | ไม่มี | มี | มี (frame-by-frame) |
| Waterfall chart | มี (จำกัด) | มี (ละเอียด) | มี (ละเอียดสุด) |
| Run multiple tests | 1 run | 1 run (free) / 5 run (pro) | 1-9 run |
| Filmstrip view | ไม่มี | มี | มี |
| Test from mobile device จริง | ไม่ | ไม่ | ใช่ (premium) |
| API access | ฟรี | Paid | Paid |
| เหมาะกับ | Quick check, SEO | Visual debugging | Deep analysis, R&D |
สรุปวิธีใช้:
- PageSpeed Insights ใช้ตรวจสุขภาพประจำทุก deploy + ดู CrUX field data
- GTmetrix ใช้ debug ปัญหาเฉพาะหน้าเพราะ waterfall ดี + video อ่านง่าย
- WebPageTest ใช้เวลาต้องการ deep analysis เช่น test จาก 5 locations พร้อมกัน หรือเปรียบเทียบ 2 versions
Case Study: เว็บ E-commerce ภูเก็ต จาก 35 → 95
ผมจะเล่าเคสจริงของลูกค้าร้านขายของฝากที่จังหวัดภูเก็ต (ขออนุญาตไม่เปิดเผยชื่อ) ใช้ WooCommerce + theme สำเร็จรูป มีสินค้าประมาณ 800 SKU ตอนที่ลูกค้าติดต่อมา score อยู่ที่ Mobile 35 / Desktop 67 ยอดขายตกลง 40% หลังจากที่ Google update algorithm ปลายปี 2025
Baseline Audit
| Metric | ค่าเริ่มต้น | เป้าหมาย |
|---|---|---|
| Performance Score (Mobile) | 35 | 90+ |
| LCP | 6.8s | < 2.5s |
| INP | 580ms | < 200ms |
| CLS | 0.32 | < 0.1 |
| FCP | 3.4s | < 1.8s |
| TTFB | 1,420ms | < 800ms |
| Total Page Weight | 8.4 MB | < 2 MB |
| HTTP Requests | 187 | < 60 |
Steps Taken (เรียงตาม impact)
Week 1: Quick Wins
- ย้าย hosting จาก shared hosting (TTFB 1,420ms) ไป VPS + Cloudflare (TTFB 280ms) — score เพิ่ม 12 จุด
- แปลง 340 รูปสินค้าจาก JPEG ไป WebP — ลด page weight จาก 8.4MB เหลือ 3.1MB
- ใช้ native lazy loading กับรูปทั้งหมดที่อยู่ below the fold
- เปิด Brotli compression บน Cloudflare
Week 2: Theme Optimization
5. ถอด plugin ที่ไม่ใช้ออก 12 ตัว — ลด JS bundle ลง 1.2MB
6. ใช้ Asset Cleanup plugin disable CSS/JS ของ plugin ในหน้าที่ไม่ได้ใช้
7. Defer non-critical JS ทั้งหมด (Facebook Pixel, GA4, chat widget)
8. เปลี่ยน font Google Fonts จาก dynamic load เป็น self-hosted + font-display: swap
Week 3: Advanced
9. ติดตั้ง LiteSpeed Cache + Object Cache (Redis) — TTFB ลงจาก 280ms เหลือ 95ms
10. ปรับ checkout page ใช้ AJAX แทน full page reload — INP ลงจาก 580ms เหลือ 140ms
11. กำหนด width / height ให้ทุก image — CLS ลงจาก 0.32 เหลือ 0.04
12. Preload hero image ของ landing page
Final Result
| Metric | Before | After | การเปลี่ยนแปลง |
|---|---|---|---|
| Performance Score (Mobile) | 35 | 95 | +60 จุด |
| LCP | 6.8s | 1.9s | -72% |
| INP | 580ms | 140ms | -76% |
| CLS | 0.32 | 0.04 | -88% |
| FCP | 3.4s | 1.2s | -65% |
| TTFB | 1,420ms | 95ms | -93% |
| Page Weight | 8.4 MB | 1.8 MB | -79% |
| Bounce Rate | 68% | 31% | -54% |
| Conversion Rate | 1.2% | 2.8% | +133% |
| Monthly Revenue | ฿180k | ฿420k | +133% |
ผลลัพธ์ทางธุรกิจคือ revenue เพิ่มจาก ฿180k/เดือน เป็น ฿420k/เดือน ภายใน 60 วัน เพราะ traffic จาก Google organic เพิ่มขึ้น 215% (Core Web Vitals signal) + conversion rate เพิ่มจาก 1.2% เป็น 2.8% (UX ดีขึ้น)
ถ้าคุณอยากให้เว็บคุณได้ผลแบบนี้บ้าง ลองดู บริการพัฒนาเว็บไซต์ของเรา หรือ ติดต่อทีม Southern Whale เพื่อปรึกษา web audit ฟรี
CrUX Dashboard + 28-day Field Data — Deep Dive
หลายคนไม่รู้ว่านอกจากดู Field data ใน PageSpeed Insights แล้ว ยังสามารถ access raw data ของ CrUX ได้ผ่าน 3 ทาง
1. CrUX Dashboard (Looker Studio)
Google มี dashboard สำเร็จรูปบน Looker Studio ที่ดึงข้อมูล CrUX จาก BigQuery เข้ามาแสดงเป็น chart สวย ๆ คุณแค่ใส่ origin (เช่น https://yoursite.com) มันจะสร้าง dashboard 28-day rolling พร้อม trend chart 12 เดือนย้อนหลัง
CrUX Dashboard Template — เพียงคลิก “Use my own data” แล้วใส่ origin ของคุณ
2. CrUX API
ถ้าคุณอยาก integrate ข้อมูล CrUX เข้ากับ dashboard internal ของบริษัท ใช้ CrUX API ได้ฟรี (rate limit 150 queries/minute)
// ดึง CrUX data ผ่าน API
const response = await fetch(
'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY',
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
origin: 'https://yoursite.com',
formFactor: 'PHONE',
metrics: [
'largest_contentful_paint',
'interaction_to_next_paint',
'cumulative_layout_shift'
]
})
}
);
const data = await response.json();
console.log(data.record.metrics);3. CrUX BigQuery Dataset
สำหรับ enterprise ที่ต้องการวิเคราะห์ data แบบ historical และ cross-domain Google เปิด CrUX dataset บน BigQuery (มีค่าใช้จ่ายตาม query)
-- ดู p75 LCP ของเว็บคุณย้อนหลัง 12 เดือน
SELECT
yyyymm,
effective_connection_type.name AS network,
ROUND(percentile_75(bin.start, bin.density), 0) AS lcp_p75_ms
FROM
`chrome-ux-report.materialized.metrics_summary`
WHERE
origin = 'https://yoursite.com'
AND yyyymm BETWEEN 202507 AND 202606
GROUP BY 1, 2
ORDER BY 1 DESC;อยากเข้าใจ Core Web Vitals แบบลึกซึ้งกว่านี้ อ่าน คู่มือ Core Web Vitals ฉบับสมบูรณ์ ที่อธิบายแต่ละ metric ละเอียดกว่า
5 ข้อผิดพลาดที่นักพัฒนามักทำ
จากประสบการณ์ audit เว็บมากกว่า 200 site ใน 3 ปีที่ผ่านมา ผมเจอ pattern ของความผิดพลาดที่เกิดซ้ำ ๆ จนเริ่มจดจำได้ ลองเช็คดูว่าคุณตกหลุมพรางพวกนี้ไหม
1. หมกมุ่นกับ Lab Score มากเกินไป
หลายคน obsess กับการดัน lab score ให้ถึง 100 ทั้งที่ field data ของผู้ใช้จริงดีอยู่แล้ว ผลคือเสียเวลา over-engineer ไปกับ optimization ที่ไม่มีคนได้ประโยชน์ จำไว้ว่า — ถ้า field data ของคุณ “Good” ทั้ง 3 metrics (LCP, INP, CLS) Google ก็ถือว่าผ่าน Core Web Vitals แล้ว ไม่ต้องดัน lab ให้ถึง 100
2. แก้ทุก Audit โดยไม่จัดลำดับความสำคัญ
Lighthouse แสดง audit เป็นสิบเป็นร้อยตัว ถ้าคุณไล่แก้ทีละตัวเรียงจากบนลงล่างคุณจะเสียเวลามหาศาล วิธีที่ถูกคือเปิด tab “Opportunities” และ “Diagnostics” แล้วเรียงตาม “estimated savings” จากมากไปน้อย แก้ตัวที่ savings เยอะที่สุดก่อน ตัวอย่างเช่น ถ้า “Properly size images” บอกว่าจะประหยัด 2.4s แต่ “Minify CSS” บอกว่าประหยัด 0.1s ก็ทำ image ก่อน
3. ใช้ Page Builder + Plugin เยอะเกินไป
Elementor, Divi, WPBakery + 30 plugin = JS bundle 2MB+ ที่ผู้ใช้ต้องโหลด หลีกเลี่ยง page builder ในเว็บ production ถ้าทำได้ ใช้ Astro, Next.js, หรือ static HTML แทน ถ้าจำเป็นต้องใช้ WordPress เลือก theme ที่ lightweight (เช่น GeneratePress, Kadence) และจำกัด plugin ไว้ไม่เกิน 10 ตัว
4. โหลด Third-party Script ทั้งหมดใน Head
Google Tag Manager, Facebook Pixel, Live Chat, Analytics, Heatmap… ถ้าโหลดทุกตัวใน <head> แบบ blocking score คุณจะตกลงทันที ใช้ defer หรือ async สำหรับทุก third-party script และพิจารณาใช้ Partytown เพื่อย้าย third-party script ไป run ใน Web Worker
<!-- ใช้ Partytown -->
<script type="text/partytown" src="https://www.googletagmanager.com/gtag/js?id=G-XXX"></script>5. ไม่ Monitor Continuously หลัง Optimization
ทำ optimization ครั้งเดียวแล้วทิ้ง = score จะค่อย ๆ ตกลงเรื่อย ๆ ใน 6 เดือน เพราะมี content ใหม่, image ใหม่, plugin update, theme update ที่ทำให้ performance regression แก้โดยตั้ง monitoring แบบ continuous ใช้ tools เช่น:
- PageSpeed Insights API + GitHub Actions ทดสอบทุก commit
- SpeedCurve หรือ Calibre สำหรับ continuous monitoring (paid)
- Lighthouse CI สำหรับ open-source CI/CD integration
# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [push]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: treosh/lighthouse-ci-action@v11
with:
urls: |
https://yoursite.com/
https://yoursite.com/products
uploadArtifacts: true
temporaryPublicStorage: trueคำถามที่พบบ่อย (FAQ)
Q1: PageSpeed Score 100 แปลว่าเว็บสมบูรณ์แบบใช่ไหม?
ไม่ใช่ครับ score 100 บน lab data หมายความว่าเว็บ render เร็วในสภาพแวดล้อมที่ Google ทดสอบ แต่ไม่ได้แปลว่า user จริงจะได้ประสบการณ์ดีเสมอ เพราะมีปัจจัยอื่น ๆ เช่น network ของ user, device ของ user, location ที่ user อยู่ ดังนั้นให้ดู field data (CrUX) คู่ไปด้วย
Q2: ทำไม PageSpeed Score เปลี่ยนทุกครั้งที่ test?
เพราะ lab test มีปัจจัย variable เช่น load ของ Google data center, network condition ของ test server, และ randomness ใน throttling algorithm วิธีแก้คือ test หลาย ๆ ครั้งแล้วเอา median value ไม่ใช่ดูแค่ครั้งเดียว หรือใช้ Lighthouse CI ที่ run หลาย samples อัตโนมัติ
Q3: Mobile vs Desktop score ต่างกันมากเป็นปัญหาไหม?
เป็นเรื่องปกติ เพราะ Lighthouse ใช้ throttling ต่างกันมากระหว่าง mobile (Slow 4G + Moto G Power) กับ desktop (no throttling) ส่วนใหญ่ desktop จะสูงกว่า mobile 20-40 จุด แต่ถ้าต่างกันเกิน 50 จุด แสดงว่ามีปัญหาเฉพาะกับ mobile (มักเป็น JS heavy หรือ image ใหญ่)
Q4: ทำไมไม่มี Field Data ให้ดู?
เพราะเว็บคุณยังไม่มี traffic เพียงพอที่ Google จะมั่นใจในความถูกต้องของ statistical sample ต้องมีประมาณ 4,500 visits ต่อเดือนขึ้นไป (จากผู้ใช้ Chrome ที่ opt-in) ถ้าไม่มี ใช้ lab data ไปก่อน เมื่อ traffic เพิ่มขึ้น Field data จะปรากฏเอง
Q5: INP กับ FID ต่างกันยังไง?
FID วัดแค่ delay ของ interaction ครั้งแรก ส่วน INP วัดทุก interaction ตลอด session แล้วเอาค่าที่แย่ที่สุดมารายงาน (98th percentile ถ้ามี > 50 interactions) ดังนั้น INP เข้มกว่ามาก เว็บที่เคยผ่าน FID อาจตกที่ INP ถ้ามี interaction ที่ช้า แม้แค่ตัวเดียว
Q6: ควรใช้ PageSpeed Insights หรือ Lighthouse ใน Chrome DevTools?
ใช้ทั้งสองครับ Lighthouse ใน DevTools เหมาะกับ debug ที่เครื่อง dev (local environment) ส่วน PSI ดึงข้อมูลจาก Google server + CrUX ที่เป็น production data จริง วิธี recommended คือใช้ DevTools Lighthouse ตอนพัฒนา และใช้ PSI ตอน QA หลัง deploy
Q7: Score บน PSI vs GTmetrix ต่างกันมาก เพราะอะไร?
เพราะ GTmetrix Free ใช้ Vancouver, Canada เป็น test location และ throttle เป็น 3G (ช้ากว่า PSI’s Slow 4G) ส่วน Pro version ใช้ Lighthouse engine เหมือนกัน ถ้าอยากเทียบ apples-to-apples ใช้ GTmetrix Pro + เลือก device “Moto G Power” + Slow 4G
Q8: ปรับแล้วได้ score 90+ แล้ว ต้อง maintain ยังไง?
3 อย่างที่ต้องทำต่อเนื่อง — (1) Monitor ด้วย Lighthouse CI ทุก deploy (2) Audit เต็มรูปแบบทุก 3 เดือน (3) Review CrUX field data ทุกเดือนเพื่อดู trend ถ้า field data เริ่มแย่ลง ต้อง investigate ทันทีก่อนที่ Google จะ flag เป็น “Poor URLs”
สรุป — PageSpeed Insights ปี 2026
PageSpeed Insights คือเครื่องมือสำคัญที่ทุก web developer และ digital marketer ในปี 2026 ต้องใช้เป็น ไม่ใช่แค่ดู score แล้วตกใจ แต่ต้องเข้าใจว่า Lab data กับ Field data ต่างกันยังไง อ่าน Core Web Vitals 6 ตัวให้เป็น แก้ Lighthouse audits ตามลำดับความสำคัญ และ monitor อย่างต่อเนื่อง สิ่งสำคัญที่สุดคือ — เป้าหมายคือผู้ใช้ที่มีความสุข ไม่ใช่ตัวเลข 100 บน lab test
ถ้าคุณกำลังเจอปัญหา score ต่ำ ไม่รู้จะเริ่มแก้ตรงไหน หรืออยากได้ web performance audit แบบมืออาชีพ ทีม Southern Whale ให้บริการ audit เว็บไซต์ฟรีในขั้นต้น พร้อมคำแนะนำที่ actionable + roadmap การปรับปรุง 30/60/90 วัน ที่เว็บคุณสามารถนำไปทำเองหรือให้เรารับงานต่อก็ได้
ติดต่อทีม Southern Whale วันนี้ หรือดู บริการพัฒนาเว็บไซต์ทั้งหมด ที่เรามีให้ลูกค้าทั่วประเทศไทย เรามีประสบการณ์ปรับ score เว็บ E-commerce, corporate, และ booking site จาก 30-50 ไปถึง 90+ มาแล้วหลายร้อยเว็บ พร้อมรับประกันผลลัพธ์ที่วัดได้จริง
หากต้องการอ่านเพิ่มเติมเรื่อง performance optimization แนะนำ คู่มือ Cloudflare CDN ฉบับสมบูรณ์ สำหรับการ setup edge caching, Core Web Vitals Deep Dive สำหรับการทำความเข้าใจ metrics ระดับ advanced และ WebP vs AVIF Image Format สำหรับการ optimize รูปภาพให้ได้ savings สูงสุด