Core Web Vitals สำหรับอีคอมเมิร์ซ: อะไรที่ทำให้ตัวเลขขยับจริง ๆ

คำแนะนำเรื่องความเร็วเว็บไซต์มักมาในรูปแบบรายการสี่สิบข้อ แต่ในทางปฏิบัติ จากร้านค้าส่วนใหญ่ที่เราเคยตรวจสอบ มีสาเหตุจำนวนน้อยที่สร้างปัญหาส่วนใหญ่ และมักเป็นสาเหตุเดิม ๆ ซ้ำกัน

นี่คือสิ่งที่ Google วัดจริง ๆ เกณฑ์คืออะไร และจุดที่มักได้ผลลัพธ์จริงอยู่ตรงไหน

สามตัวชี้วัด และเกณฑ์ที่ถือว่าดี

Core Web Vitals ของ Google คือตัวชี้วัดภาคสนามสามตัว หน้าเว็บจะถูกจัดว่า ดี สำหรับตัวชี้วัดหนึ่ง ๆ เมื่ออย่างน้อย 75% ของการเข้าชมจริงผ่านเกณฑ์ นี่คือเหตุผลที่การทดสอบด้วยเบราว์เซอร์ของคุณเองบนไวไฟออฟฟิศเป็นการทดสอบที่ไม่แม่นยำ

หมายเหตุ: INP เข้ามาแทนที่ First Input Delay ในฐานะ Core Web Vital หากคุณยังใช้เช็กลิสต์เก่าที่ยังเน้นปรับแต่ง FID นั่นล้าสมัยแล้ว — INP เป็นตัวชี้วัดที่ผ่านเกณฑ์ยากกว่ามาก เพราะวัดทุกการโต้ตอบ ไม่ใช่แค่ครั้งแรก

ก่อนจะแตะสามตัวชี้วัดนี้: เวลาตอบสนองของเซิร์ฟเวอร์คือพื้นฐานที่กำหนดเพดาน

ถ้าเวลา Time to First Byte ช้า ไม่มีตัวชี้วัดตัวไหนใน 3 ตัวจะดีได้เลย เพราะทุกตัวชี้วัดวัดจากจุดเริ่มต้น ที่เซิร์ฟเวอร์ที่ช้าดันให้ล่าช้าออกไปอยู่แล้ว โฮสติ้งแชร์ที่รับโหลดจริง คำสั่ง query ฐานข้อมูลที่ไม่ได้แคชทุกครั้ง ที่มีคนดูหน้าสินค้า หรือ CDN ที่ตั้งค่าผิดจนข้ามการแคชในหน้าที่สำคัญที่สุด — ล้วนแสดงผลเป็นปัญหา Core Web Vitals ทั้งที่สาเหตุจริงอยู่ที่ฝั่งเซิร์ฟเวอร์ ตรวจ TTFB ก่อนแตะรูปภาพหรือสคริปต์เสมอ ไม่งั้นคุณจะปรับแต่ง front end อยู่บน backend ที่กำลังจำกัดผลลัพธ์ที่ดีที่สุดอยู่เงียบ ๆ

LCP: ส่วนใหญ่คือปัญหาเรื่องรูปภาพ

บนหน้าอีคอมเมิร์ซ องค์ประกอบที่ใหญ่ที่สุดมักเป็นรูปภาพฮีโร่หรือรูปสินค้าแรก นั่นทำให้ LCP ส่วนใหญ่เป็นคำถามเรื่องการส่งมอบรูปภาพ

สิ่งที่มักช่วยได้มากที่สุด:

• ใช้ฟอร์แมตสมัยใหม่ WebP หรือ AVIF แทน JPEG ในขนาดที่เหมาะสม เรามักพบว่ารูปสินค้าถูกส่งมาที่ความกว้าง 2000px ลงในช่องที่กว้างแค่ 600px
• อย่า lazy-load รูปฮีโร่ Lazy loading ดีสำหรับทุกอย่างที่อยู่ใต้ fold แต่เป็นผลเสียโดยตรงต่อสิ่งที่ LCP วัด
• Preload รูปฮีโร่ เพื่อให้เบราว์เซอร์เริ่มดึงรูปก่อนที่จะแปลผลหน้าเว็บเสร็จ
• ระวังเรื่องฟอนต์ เว็บฟอนต์ที่บล็อกการแสดงข้อความจะทำให้ LCP ช้าลงเมื่อองค์ประกอบที่ใหญ่ที่สุดคือข้อความ วิธีแก้ทั่วไปคือ font-display: swap และการ preload ไฟล์ฟอนต์

INP: ส่วนใหญ่คือปัญหาเรื่อง JavaScript

INP วัดความล่าช้าระหว่างที่มีคนโต้ตอบกับหน้าเว็บ จนถึงตอนที่หน้าเว็บตอบสนองให้เห็นจริง ๆ INP ที่ช้าเกือบทั้งหมดหมายความว่า main thread กำลังทำงานหนักอยู่

สาเหตุที่พบบ่อยบนร้านค้าออนไลน์:

• สคริปต์จากบุคคลที่สามเยอะเกินไป Analytics, วิดเจ็ตแชท, heatmap, พิกเซลโฆษณา, วิดเจ็ตรีวิว, A/B testing แต่ละตัวมีเหตุผลรองรับได้เมื่อดูทีละตัว แต่เมื่อรวมกันแล้วมักเป็นสาเหตุอันดับหนึ่งที่ทำให้หน้าเว็บอืด
• ปลั๊กอินและแอปที่หนัก ทั้งบน WooCommerce และ Shopify แอปที่เพิ่มสคริปต์ในทุกหน้าจะถูกคำนวณต้นทุนในทุกหน้า ไม่ใช่แค่หน้าที่ใช้งานจริง
• ทำงานซ้ำในทุกการโต้ตอบ ทั้งที่ควรทำแค่ครั้งเดียวหรือทำทีหลังได้

สิ่งที่ได้ผลที่สุดที่เราทำตรงนี้มักเป็นการตรวจสอบ (audit) มากกว่าการรีแฟกเตอร์ระบบ: ลิสต์สคริปต์จากบุคคลที่สามทุกตัว หาว่าใครเป็นคนขอให้ใส่เข้ามา แล้วเอาตัวที่ไม่มีใครอธิบายเหตุผลได้ออกไป มันไม่หวือหวา แต่ได้ผลจริง

สคริปต์จากบุคคลที่สามต้องมีเจ้าของ ไม่ใช่แค่ทำความสะอาดครั้งเดียว

การตรวจสอบสคริปต์แก้ปัญหาได้แค่หนึ่งเดือน จนกว่าพิกเซลติดตามหรือวิดเจ็ตตัวใหม่จะถูกเพิ่มเข้ามาโดยคนที่ไม่รู้ว่า เพิ่งมีการทำความสะอาดไปแล้ว ร้านค้าที่ควบคุม INP ได้ดีจะปฏิบัติกับสคริปต์ใหม่ทุกตัวเป็นการตัดสินใจที่ต้อง ขออนุมัติก่อน — ใครเป็นคนขอ วัดอะไร ทบทวนอีกครั้งเมื่อไหร่ — ไม่ใช่ปล่อยให้ใครก็ตามที่มีสิทธิ์เข้าถึง tag manager เพิ่มเองได้ฝ่ายเดียว ไม่มีเจ้าของแบบนี้เมื่อไหร่ ความอืดแบบเดิมก็จะกลับมาในรอบเวลาใกล้เคียงกับ ครั้งล่าสุดที่ทำความสะอาดไปนั่นแหละ

CLS: ส่วนใหญ่คือปัญหาเรื่องพื้นที่ที่ไม่ได้จองไว้

Layout shift เกิดขึ้นเมื่อบางอย่างโหลดเข้ามาแล้วดันเนื้อหาที่มีอยู่แล้วให้เลื่อนตำแหน่ง เป็นตัวชี้วัดที่มักทำให้เว็บไซต์ดูไม่มืออาชีพมากที่สุด

วิธีแก้ส่วนใหญ่เป็นเรื่องเชิงกลไก:

• ตั้งค่า width และ height ให้รูปภาพเสมอ เพื่อให้เบราว์เซอร์จองพื้นที่ไว้ล่วงหน้า
• จองพื้นที่ให้แบนเนอร์และแจ้งเตือนคุกกี้ แทนที่จะแทรกเข้ามาทับเนื้อหาที่มีอยู่แล้ว
• ระวังเรื่องฟอนต์ ฟอนต์สำรองที่มีขนาดต่างจากฟอนต์จริงมากจะทำให้เกิดการเลื่อนตำแหน่งที่เห็นได้ชัด เมื่อเว็บฟอนต์โหลดมาถึง
• กำหนดขนาดตายตัวให้พื้นที่โฆษณาและ embed ต่าง ๆ

วัดสิ่งที่ถูกต้อง

มีสองประเด็นที่ควรเข้าใจให้ชัดเจน เพราะเป็นสาเหตุของความสับสนบ่อยครั้ง:

ข้อมูล Lab เทียบกับข้อมูล Field Lighthouse บนเบราว์เซอร์ของคุณคือการทดสอบแบบ lab บนเครื่องและการเชื่อมต่อของคุณเอง ส่วน Core Web Vitals ที่ Google ใช้จริงคือข้อมูล field จากการเข้าชมจริง คะแนน Lighthouse ที่สมบูรณ์แบบแต่ข้อมูล field แย่เป็นเรื่องที่พบได้บ่อย และหมายความว่าผู้ใช้จริงกำลังเจอประสบการณ์ที่แย่กว่าที่โน้ตบุ๊กของคุณเจอ

อุปกรณ์ของคุณเทียบกับอุปกรณ์ของลูกค้า หากทราฟฟิกส่วนใหญ่มาจาก Android ระดับกลางบนเน็ตมือถือ — ซึ่งในไทยมีความเป็นไปได้สูงมาก — การทดสอบบน iPhone รุ่นใหม่บนไวไฟแทบไม่บอกอะไรที่เป็นประโยชน์เลย ให้จำลองการเชื่อมต่อที่ช้าลงและ CPU ที่ช้าลงด้วย

แหล่งข้อมูลจริงที่มีประโยชน์: รายงาน Core Web Vitals ใน Google Search Console และส่วนข้อมูล field ใน PageSpeed Insights

ความเร็วให้ผลตอบแทนตรงไหนจริง ๆ

ควรพูดตรง ๆ เรื่องเหตุผลทางธุรกิจ ความเร็วไม่ใช่กลยุทธ์การเติบโตด้วยตัวมันเอง และเว็บไซต์ที่เร็วแต่ใช้งานสับสนก็ยังขายไม่ได้อยู่ดี

แต่หน้าเว็บที่ช้าจะยิ่งทบต้นกับปัญหาอื่น ๆ มันทำให้เสียเน็ตมือถือ ซึ่งเป็นที่ที่ทราฟฟิกไทยส่วนใหญ่อยู่ มันทำให้สินค้าที่ดีดูน่าเชื่อถือน้อยลง และมันเป็นปัจจัยในการจัดอันดับ ซึ่งหมายความว่าเว็บไซต์ที่ช้ากำลังจ่ายแพงกว่าเงียบ ๆ สำหรับทราฟฟิกจำนวนเท่าเดิม

ลำดับที่เราทำงานจริง: ตรวจเวลาตอบสนองของเซิร์ฟเวอร์ก่อน แก้รูปภาพ ตัดสคริปต์ที่ไม่มีใครต้องการออก จองพื้นที่ให้ทุกอย่างไม่กระโดด แล้วค่อยวัดใหม่ด้วยข้อมูล field วิธีนี้มักได้ผลลัพธ์ส่วนใหญ่ที่เป็นไปได้ ก่อนที่จะต้องทำอะไรที่ซับซ้อนกว่านั้น

แหล่งอ้างอิง

• Web Vitals — web.dev
• Largest Contentful Paint (LCP) — web.dev
• Interaction to Next Paint (INP) — web.dev
• Understanding Core Web Vitals and Google search results — Google Search Central