"ทำไมเว็บของเราได้แค่ 60?"
มีคำถามหนึ่งที่ไม่ควรถามทีมงานตอนก่อนเลิกงานวันศุกร์ นั่นคือ "ลองรัน Lighthouse บนเว็บเราหน่อยได้ไหม?"
เพราะเมื่อผลออกมา — ตัวเลขที่เห็นทำให้ต้องนั่งต่ออีกสักพัก
Performance Score: 60/100
ไม่ใช่คะแนนที่น่าภาคภูมิใจ โดยเฉพาะเมื่อเว็บไซต์นี้สร้างด้วย framework ชั้นนำ, static export, deploy บน CDN และผ่านการ optimize มาพอสมควร แต่นั่นคือจุดที่น่าสนใจ — ถ้าทุกอย่างดูดีบนกระดาษ แต่ Lighthouse บอกว่า 60 แสดงว่ามีบางอย่างซ่อนอยู่ที่เรายังไม่รู้
บทความนี้คือบันทึกการขุดหาต้นตอ วิเคราะห์ root cause และวางแผนแก้ไข — เขียนอย่างตรงไปตรงมา ไม่ปิดบังตัวเลขที่น่าเขินอาย เพราะเราเชื่อว่าการแชร์บทเรียนดีกว่าการซ่อนปัญหา
Filmstrip: เว็บโหลดยังไงในสายตา Lighthouse
ก่อนดูตัวเลข มาดูก่อนว่า Lighthouse "เห็น" อะไรระหว่างที่เว็บโหลด:
สังเกตว่า filmstrip มีแค่ 3 สถานะ — จอขาว, เริ่มเห็นเนื้อหา, แล้วก็โหลดเสร็จ ไม่มี intermediate state ระหว่างกลางเลย เพราะช่วง 12 วินาทีแรกที่เสียไปกับ redirect chain นั้น browser ไม่ได้ render อะไรเลยแม้แต่ pixel เดียว — นี่คือหลักฐานที่ชัดเจนว่าปัญหาไม่ได้อยู่ที่ rendering แต่อยู่ที่ network-level redirect
วิเคราะห์ Score แต่ละตัว
| Metric |
ค่าที่วัดได้ |
Score |
ระดับ |
| Performance Score |
— |
60 |
ต้องปรับปรุง |
| First Contentful Paint (FCP) |
1.6s |
0.95 |
ดีมาก |
| Largest Contentful Paint (LCP) |
9.1s |
0.01 |
แย่มาก |
| Total Blocking Time (TBT) |
570ms |
0.52 |
ต้องปรับปรุง |
| Cumulative Layout Shift (CLS) |
0 |
1.0 |
สมบูรณ์แบบ |
| Speed Index |
2.8s |
0.96 |
ดีมาก |
| Time to Interactive (TTI) |
9.6s |
0.29 |
แย่ |
ตัวเลขเหล่านี้บอกเรื่องราวที่น่าสนใจ — FCP และ Speed Index ดีมาก หมายความว่าเนื้อหาเริ่มแสดงผลเร็ว แต่ LCP แย่มากผิดปกติ สิ่งที่ทำให้ performance score พังทั้งหมดคือ LCP เพียงตัวเดียว
ความขัดแย้งระหว่าง FCP ดีแต่ LCP แย่ คือสัญญาณคลาสสิกของปัญหาที่เกิดขึ้น ก่อน ที่ browser จะเริ่ม render — และนั่นคือเส้นทางนำไปสู่ root cause
Root Cause #1: Redirect Chain 12.4 วินาที — ตัวการตัวจริง
นี่คือ ตัวการหลัก ที่ทำลาย performance ทั้งหมด:
Redirect Chain:
enersys.co.th/ → enersys.co.th/th
เวลาที่เสียไป: 12,400ms (12.4 วินาที!)
ใช่ ไม่ใช่ 1.2 วินาที — สิบสองจุดสี่วินาที
ทำไมถึงเกิด?
เว็บไซต์รองรับหลายภาษา โดยค่าเริ่มต้นคือภาษาไทย — เมื่อผู้ใช้เข้า / ระบบจะ redirect ไปที่ /th โดยอัตโนมัติ
ในกรณีปกติ redirect ใช้เวลาไม่กี่ millisecond แต่ปัญหาอยู่ที่ Lighthouse วัด LCP จาก URL ต้นทาง และนับเวลาตั้งแต่ navigation เริ่มต้นจนกว่า largest element จะ render — รวมเวลาที่เสียไปกับ redirect ทั้งหมด
ตัวเลข 12.4 วินาทีนั้นผิดปกติมาก redirect ปกติไม่ควรใช้เวลานานขนาดนี้ ซึ่งอาจเกิดจากหลายสาเหตุ:
- Cold start overhead — server ที่ handle redirect อาจมี startup latency สูง
- DNS / connection overhead — การ redirect ทำให้ browser ต้องสร้าง connection ใหม่
- Redirect ไม่ถูก cache — ทำให้ทุก request ต้องผ่าน origin server
ผลกระทบต่อ Score
LCP มีน้ำหนักสูงที่สุดใน Performance Score (~25%) และค่า 9.1s ให้ score เพียง 0.01 จากสูงสุด 1.0 — metric ตัวเดียวทำลาย performance score จาก 95+ ลงมาเหลือ 60
Root Cause #2: Unused JavaScript — 65KB ที่ไม่ได้ใช้
Lighthouse ตรวจพบ unused JavaScript ใน bundle กลางขนาดประมาณ 65KB คิดเป็น potential savings ราว 300ms
สิ่งที่มักซ่อนอยู่ใน bundle หลักโดยไม่รู้ตัว:
- Library ที่ import ทั้ง package แทนที่จะ import เฉพาะที่ใช้
- Component ที่โหลดตั้งแต่แรกแต่ผู้ใช้ยังไม่เห็น
- Code ที่ถูก compile ออกมาเพื่อรองรับ browser เก่าที่ไม่จำเป็น
Root Cause #3: Image Optimization — ยังส่ง PNG อยู่
Lighthouse ระบุรูปภาพหลายไฟล์ที่ยังเป็น PNG ทั้ง ๆ ที่แปลงเป็น format ที่เบากว่าได้ — potential savings รวม ~76KB
เว็บไซต์ใช้ static export ซึ่งไม่มี automatic image optimization ทำให้ต้องจัดการ format เองทั้งหมด
Main Thread Work: 3.1 วินาที
Lighthouse รายงาน main thread work รวม 3.1 วินาที แบ่งเป็น:
| งานที่ทำ |
เวลา |
| Style & Layout calculation |
1.1s |
| Other |
0.9s |
| Script Evaluation |
0.8s |
| Parse HTML & CSS |
0.3s |
TBT 570ms บอกว่า main thread ถูก block จาก JavaScript รวม 570ms — เกิน threshold "needs improvement" (200ms) แต่ยังไม่ถึง "poor" (600ms)
สิ่งที่ทำได้ดี — ไม่ใช่แค่ปัญหา
เพื่อความยุติธรรม Lighthouse ก็ให้คะแนนเต็มหลายจุด:
Server Response Time: สมบูรณ์แบบ (score 1.0) — server ตอบสนองเร็ว infrastructure ไม่ใช่ปัญหา
CLS: 0 — สมบูรณ์แบบ — ไม่มี layout shift เลย ผู้ใช้ไม่เจอปัญหาปุ่มกระโดดหนี
FCP 1.6s — ดีมาก — เนื้อหาแรกปรากฏเร็ว ไม่มี render-blocking resources
Speed Index 2.8s — ดีมาก — หน้าเว็บดูเหมือนโหลดเสร็จเร็ว (เมื่อเข้าโดยตรง)
สรุป: ถ้าเข้าหน้าเว็บโดยตรง (ไม่ผ่าน redirect) performance ดีมาก ปัญหาใหญ่ที่สุดซ่อนอยู่ใน redirect chain เดียว
แผนแก้ไข — เรียงตามความสำคัญ
| Priority |
ปัญหา |
แนวทาง |
Expected Impact |
| 1 |
Redirect chain 12.4s |
จัดการ redirect ที่ infrastructure layer |
LCP ลด 5+ วินาที |
| 2 |
Unused JS 65KB |
Code splitting, lazy load below-fold |
TBT ลด 200-300ms |
| 3 |
PNG images |
แปลงเป็น modern format |
ลด 76KB+ |
| 4 |
Style/Layout cost 1.1s |
Audit CSS usage |
Main thread ลด |
Target หลังแก้ไข:
| Metric |
ปัจจุบัน |
Target |
| Performance Score |
60 |
85+ |
| LCP |
9.1s |
< 2.5s |
| TBT |
570ms |
< 200ms |
| TTI |
9.6s |
< 5s |
บทเรียน: ทำไมต้องวัด Performance สม่ำเสมอ
ปัญหา redirect chain 12.4 วินาทีนี้น่าจะมีมาสักพักแล้ว แต่เราไม่รู้ เพราะไม่ได้วัด เมื่อไม่ได้วัด ก็ไม่รู้ว่ามีปัญหา
Core Web Vitals ที่ Google ใช้ใน Search ranking ตั้งแต่ปี 2021 คือ LCP, FID/INP, และ CLS — ถ้า LCP แย่ ไม่ใช่แค่ผู้ใช้ที่รู้สึก แต่ search ranking ก็ได้รับผลกระทบด้วย
สิ่งที่ทีมควรทำเป็นประจำ:
- รัน performance audit ใน CI/CD — ทุกครั้งที่ merge ควรมีรายงาน performance เปรียบเทียบ
- ตั้ง threshold alerts — กำหนดว่า LCP ต้องไม่เกิน 3 วินาที ถ้าเกินให้ build fail
- Monitor Real User Data — Lab test อย่างเดียวไม่พอ ต้องดูตัวเลขจาก user จริงด้วย
- ทดสอบ URL ที่ user จริง ๆ เข้า — รวม URL ที่มี redirect ด้วย ไม่ใช่แค่ URL ปลายทาง
บทสรุป
คะแนน 60 ที่ Lighthouse ให้มาไม่ใช่เรื่องน่าอาย แต่เป็นโอกาสที่ดีในการเรียนรู้:
- ปัญหาใหญ่ที่สุดไม่ได้อยู่ใน code — แต่อยู่ใน infrastructure configuration
- Metric เดียวที่แย่มากทำลาย overall score ไปมากกว่าครึ่ง
- CLS เป็น 0 สมบูรณ์แบบ — งานที่ทีมทำมาได้ผล
- ถ้าไม่ได้วัดวันนี้ เราจะยังไม่รู้เรื่องนี้อยู่
ที่ Enersys เราเชื่อว่า transparency ต่อตัวเองสำคัญกว่า image ที่ดูดี — การยอมรับว่าเว็บตัวเองได้คะแนน 60 และแชร์ root cause ออกมา คือก้าวแรกของการพัฒนาที่ยั่งยืน
เว็บไซต์ขององค์กรคุณได้คะแนนเท่าไหร่? ถ้าอยากรู้แต่ไม่รู้จะเริ่มยังไง — ให้ทีมเราช่วยวิเคราะห์ได้
