เร่งความเร็วเว็บด้วย Core Web Vitals: คู่มือเริ่มต้นสำหรับทีมพัฒนา

เว็บที่โหลดช้าเพียง 1 วินาทีอาจทำให้ Conversion ลดลงอย่างมีนัยสำคัญ บทความนี้สรุปแนวทางจากคอร์ส Learn Performance ของ Google web.dev อธิบายตัวชี้วัด Core Web Vitals ทั้ง LCP, INP และ CLS พร้อมเทคนิคปรับปรุงที่ทีมพัฒนาไทยนำไปใช้ได้ทันที

ทำไมความเร็วเว็บถึงเป็นเรื่องธุรกิจ ไม่ใช่แค่เรื่องเทคนิค

ความเร็วของเว็บไซต์ส่งผลตรงต่อรายได้ งานวิจัยที่ Google รวบรวมไว้ใน web.dev ชี้ว่าเมื่อเวลาโหลดหน้าเพิ่มจาก 1 วินาทีเป็น 3 วินาที โอกาสที่ผู้ใช้จะกดออก (Bounce) เพิ่มขึ้นราว 32% และสำหรับเว็บอีคอมเมิร์ซ ทุก ๆ 100 มิลลิวินาทีที่เร็วขึ้นสามารถเพิ่ม Conversion ได้อย่างวัดผลได้จริง

นอกจากนี้ Google ใช้ Core Web Vitals เป็นหนึ่งในสัญญาณจัดอันดับผลการค้นหา (Page Experience) ดังนั้นเว็บที่เร็วกว่าไม่เพียงทำให้ลูกค้าพึงพอใจ แต่ยังช่วยงาน SEO ของธุรกิจไทยที่แข่งขันบนหน้าค้นหาเดียวกันด้วย

รู้จักตัวชี้วัดหลัก: LCP, INP และ CLS

Core Web Vitals ประกอบด้วย 3 ตัวชี้วัด ได้แก่ LCP (Largest Contentful Paint) วัดเวลาที่เนื้อหาชิ้นใหญ่ที่สุดปรากฏ ควรไม่เกิน 2.5 วินาที, INP (Interaction to Next Paint) วัดความไวในการตอบสนองต่อการคลิกหรือพิมพ์ ควรไม่เกิน 200 มิลลิวินาที และ CLS (Cumulative Layout Shift) วัดการกระตุกของเลย์เอาต์ ควรไม่เกิน 0.1

เกณฑ์เหล่านี้วัดที่เปอร์เซ็นไทล์ที่ 75 ของผู้ใช้จริง หมายความว่าอย่างน้อย 3 ใน 4 ของการเข้าชมต้องผ่านเกณฑ์ ไม่ใช่แค่ทดสอบผ่านบนเครื่องของนักพัฒนาที่ต่อ Wi-Fi เร็ว ๆ เท่านั้น ควรทดสอบบนมือถือระดับกลางและเครือข่าย 4G ซึ่งเป็นสภาพจริงของผู้ใช้ส่วนใหญ่ในไทย

ปรับรูปภาพ: จุดที่ได้ผลเร็วที่สุด

รูปภาพมักกินน้ำหนักมากกว่าครึ่งของหน้าเว็บ แนวทางจาก web.dev คือใช้ฟอร์แมตสมัยใหม่อย่าง WebP หรือ AVIF ซึ่งเล็กกว่า JPEG ราว 25-50% ใช้แอตทริบิวต์ srcset เพื่อส่งภาพขนาดพอดีกับหน้าจอ และกำหนด width/height เสมอเพื่อป้องกัน CLS

รูปที่อยู่นอกจอควรใส่ loading="lazy" ส่วนรูปฮีโร่ที่เป็น LCP ให้ทำตรงข้าม คือใส่ fetchpriority="high" และ preload เพื่อให้เบราว์เซอร์ดาวน์โหลดก่อน เทคนิคง่าย ๆ ชุดนี้มักลดเวลา LCP ได้ 30-50% โดยไม่ต้องแก้สถาปัตยกรรมเลย

จัดการ JavaScript และ CSS ที่บล็อกการเรนเดอร์

JavaScript ที่โหลดแบบ synchronous จะหยุดการเรนเดอร์หน้าไว้ทั้งหมด ควรใส่ defer หรือ async กับสคริปต์ที่ไม่จำเป็นต่อการแสดงผลแรก และแยกโค้ดด้วย Code Splitting เพื่อส่งเฉพาะส่วนที่หน้านั้นใช้จริง สคริปต์ third-party เช่นแชตวิดเจ็ตหรือ analytics ควรโหลดหลังหน้าโต้ตอบได้แล้ว

ฝั่ง CSS ให้ inline เฉพาะ Critical CSS ที่ใช้วาดส่วนบนของหน้า แล้วโหลดที่เหลือแบบ non-blocking การลด JavaScript ยังช่วย INP โดยตรง เพราะงาน Long Task ที่เกิน 50 มิลลิวินาทีบน Main Thread คือสาเหตุหลักที่ทำให้หน้าตอบสนองช้าเมื่อผู้ใช้คลิก

ใช้แคชและ CDN ให้เป็นประโยชน์

ตั้งค่า HTTP Caching ให้ไฟล์ static เช่น JS, CSS และรูปภาพมี Cache-Control อายุยาว (เช่น 1 ปี) ร่วมกับการตั้งชื่อไฟล์แบบมี hash เพื่อให้เบราว์เซอร์ไม่ต้องดาวน์โหลดซ้ำ ส่วนหน้า HTML ใช้อายุสั้นหรือ validate ทุกครั้ง

สำหรับเว็บที่มีผู้ใช้ทั้งในไทยและต่างประเทศ การใช้ CDN ที่มี Edge Node ในภูมิภาค เช่นสิงคโปร์หรือกรุงเทพฯ ช่วยลด Latency ของ Time to First Byte ได้มาก โดยทั่วไป TTFB ที่ดีควรต่ำกว่า 800 มิลลิวินาที

วัดผลอย่างต่อเนื่องด้วยเครื่องมือฟรี

เริ่มจาก PageSpeed Insights ซึ่งรวมทั้งข้อมูล Lab (Lighthouse) และข้อมูลผู้ใช้จริงจาก Chrome UX Report ไว้ในที่เดียว จากนั้นใช้ Lighthouse CI ผูกเข้ากับ Pipeline เพื่อกันไม่ให้โค้ดใหม่ทำคะแนนตก

แนวปฏิบัติที่ web.dev แนะนำคือกำหนด Performance Budget เช่น JavaScript รวมไม่เกิน 300KB (หลังบีบอัด) และ LCP ไม่เกิน 2.5 วินาที แล้วให้ระบบแจ้งเตือนอัตโนมัติเมื่อเกินงบ วิธีนี้เปลี่ยนเรื่องความเร็วจาก "งานแก้ไฟ" เป็นวินัยประจำทีม