Lighthouse Performance Audit — เมื่อเว็บไซต์ของเราได้คะแนน 60 และ Redirect ใช้เวลา 12 วินาที

"ทำไมเว็บของเราได้แค่ 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 แต่ละตัว

ตัวเลขเหล่านี้บอกเรื่องราวที่น่าสนใจ — 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 ปกติไม่ควรใช้เวลานานขนาดนี้ ซึ่งอาจเกิดจากหลายสาเหตุ:

1. Cold start overhead — server ที่ handle redirect อาจมี startup latency สูง
2. DNS / connection overhead — การ redirect ทำให้ browser ต้องสร้าง connection ใหม่
3. 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 วินาที แบ่งเป็น:

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 เดียว

แผนแก้ไข — เรียงตามความสำคัญ

Target หลังแก้ไข:

บทเรียน: ทำไมต้องวัด Performance สม่ำเสมอ

ปัญหา redirect chain 12.4 วินาทีนี้น่าจะมีมาสักพักแล้ว แต่เราไม่รู้ เพราะไม่ได้วัด เมื่อไม่ได้วัด ก็ไม่รู้ว่ามีปัญหา

Core Web Vitals ที่ Google ใช้ใน Search ranking ตั้งแต่ปี 2021 คือ LCP, FID/INP, และ CLS — ถ้า LCP แย่ ไม่ใช่แค่ผู้ใช้ที่รู้สึก แต่ search ranking ก็ได้รับผลกระทบด้วย

สิ่งที่ทีมควรทำเป็นประจำ:

1. รัน performance audit ใน CI/CD — ทุกครั้งที่ merge ควรมีรายงาน performance เปรียบเทียบ
2. ตั้ง threshold alerts — กำหนดว่า LCP ต้องไม่เกิน 3 วินาที ถ้าเกินให้ build fail
3. Monitor Real User Data — Lab test อย่างเดียวไม่พอ ต้องดูตัวเลขจาก user จริงด้วย
4. ทดสอบ URL ที่ user จริง ๆ เข้า — รวม URL ที่มี redirect ด้วย ไม่ใช่แค่ URL ปลายทาง

บทสรุป

คะแนน 60 ที่ Lighthouse ให้มาไม่ใช่เรื่องน่าอาย แต่เป็นโอกาสที่ดีในการเรียนรู้:

• ปัญหาใหญ่ที่สุดไม่ได้อยู่ใน code — แต่อยู่ใน infrastructure configuration
• Metric เดียวที่แย่มากทำลาย overall score ไปมากกว่าครึ่ง
• CLS เป็น 0 สมบูรณ์แบบ — งานที่ทีมทำมาได้ผล
• ถ้าไม่ได้วัดวันนี้ เราจะยังไม่รู้เรื่องนี้อยู่

ที่ Enersys เราเชื่อว่า transparency ต่อตัวเองสำคัญกว่า image ที่ดูดี — การยอมรับว่าเว็บตัวเองได้คะแนน 60 และแชร์ root cause ออกมา คือก้าวแรกของการพัฒนาที่ยั่งยืน

เว็บไซต์ขององค์กรคุณได้คะแนนเท่าไหร่? ถ้าอยากรู้แต่ไม่รู้จะเริ่มยังไง — ให้ทีมเราช่วยวิเคราะห์ได้