เว็บโหลดเร็วแค่ 1.5 วินาที แต่ทำไม Google ยังไม่ยอมดันอันดับให้? นี่คือคำถามที่คนทำเว็บจำนวนไม่น้อยเจอ แล้วก็งงจนต้องไปเปิด PageSpeed Insights ดูซ้ำสองสามรอบ เพราะตัวเลขที่เห็นในเครื่องมือแต่ละตัวมันไม่ตรงกันสักอัน บางทีเขียวหมดทุกช่อง แต่อันดับก็ยังไม่ขยับ บางทีแดงเป็นไฟแต่ทราฟฟิกก็ไม่ได้ร่วงไปไหน ความสับสนนี้เกิดจากการเข้าใจผิดพื้นฐานอย่างหนึ่ง คือคนส่วนใหญ่มองว่าความเร็วเว็บคือตัวเลขเดียว ทั้งที่จริงมันคือการวัดสามมุมที่ไม่เกี่ยวกันโดยตรงเลย
คำตอบตรงๆ คือ Core Web Vitals ไม่ใช่แค่เรื่องเว็บโหลดเร็ว มันคือชุดตัวชี้วัดสามตัวที่ Google ใช้ประเมินประสบการณ์การใช้งานจริงของคนที่เข้าเว็บ แบ่งเป็นความเร็วในการเห็นเนื้อหาหลัก ความนิ่งของหน้าเว็บตอนโหลด และความไวในการตอบสนองตอนคนคลิก สามตัวนี้ต้องผ่านเกณฑ์พร้อมกัน ไม่ใช่แค่ตัวใดตัวหนึ่ง เพราะเว็บที่โหลดไว แต่ปุ่มขยับไปมาจนคนกดผิด ก็ถือว่าประสบการณ์ผู้ใช้แย่อยู่ดี และ Google รู้เรื่องนี้ผ่านข้อมูลพฤติกรรมจริงจากผู้ใช้ Chrome หลายล้านคน ไม่ใช่แค่การจำลองในแล็บ
LCP คืออะไร ทำไมวัดจากหน้าจอไม่ใช่โค้ด
LCP หรือ Largest Contentful Paint คือเวลาที่องค์ประกอบใหญ่ที่สุดในหน้าจอ เช่น รูปภาพหลัก วิดีโอ หรือบล็อกข้อความก้อนใหญ่ ปรากฏให้เห็นเต็มตา เกณฑ์ที่ควรผ่านคือไม่เกิน 2.5 วินาที ปัญหาที่คนทำเว็บพลาดบ่อยคือไปโฟกัสที่ความเร็วเซิร์ฟเวอร์อย่างเดียว ทั้งที่จริง LCP ผูกกับสิ่งที่คนมองเห็นบนหน้าจอโดยตรง ถ้าเซิร์ฟเวอร์ตอบกลับเร็วมาก แต่ภาพ Hero Banner ตัวใหญ่โหลดช้าเพราะไฟล์หนักเกินไป LCP ก็จะพังทันที
เรื่องที่คนมักไม่รู้คือ Font ที่โหลดจากภายนอกก็ทำให้ LCP แย่ได้ เพราะถ้า Browser ต้องรอโหลดฟอนต์ก่อนแสดงข้อความ หน้าจอจะค้างเปล่าอยู่พักหนึ่ง แก้ได้ด้วยการทำ font-display: swap หรือโหลดฟอนต์หลักไว้ในเซิร์ฟเวอร์ตัวเอง
CLS คือความนิ่งของหน้าเว็บ ไม่ใช่ความเร็ว
CLS หรือ Cumulative Layout Shift วัดว่าหน้าเว็บมีการขยับตำแหน่งองค์ประกอบระหว่างโหลดมากแค่ไหน เกณฑ์ที่ควรอยู่คือต่ำกว่า 0.1 ปัญหาคลาสสิกที่เจอบ่อยคือโฆษณาที่โหลดมาทีหลังแล้วดันเนื้อหาทั้งหน้าให้เลื่อนลง หรือรูปภาพที่ไม่ได้กำหนดขนาดไว้ล่วงหน้า ทำให้พื้นที่หน้าจอขยายตัวกะทันหันตอนรูปโหลดเสร็จ คนอ่านที่กำลังจะกดปุ่มหนึ่ง อาจกดพลาดไปโดนโฆษณาแทน เพราะหน้าเว็บขยับไปแล้วในเสี้ยววินาที
สัญญาณที่บอกว่าเว็บมีปัญหา CLS หนัก มักมาในรูปแบบที่คล้ายกันทุกครั้ง การรู้จักสัญญาณเหล่านี้ช่วยให้ตรวจเจอจุดพังได้เร็วกว่าไล่ดูโค้ดทั้งหน้า
- รูปภาพหรือวิดีโอที่ไม่ได้กำหนด width และ height ไว้ล่วงหน้าในโค้ด
- แบนเนอร์โฆษณาหรือ Pop-up ที่แทรกเข้ามาแบบไม่มีพื้นที่จองไว้ก่อน
- ฟอนต์เว็บที่สลับจาก Fallback Font ไปเป็นฟอนต์จริงแล้วขนาดตัวอักษรเปลี่ยน
- ปุ่มหรือฟอร์มที่โหลดมาทีหลังแล้วดันเนื้อหาส่วนอื่นให้เลื่อน
ทางแก้ที่ตรงจุดที่สุดคือการจองพื้นที่ (Reserve Space) ให้ทุกองค์ประกอบที่โหลดช้ากว่าปกติ ไม่ว่าจะเป็นรูปภาพ วิดีโอ หรือโฆษณา เพื่อไม่ให้หน้าเว็บต้องขยับตัวหนีตอนของจริงโหลดมาถึง
INP เข้ามาแทน FID แล้วมันต่างกันตรงไหน
ตั้งแต่เดือนมีนาคม 2024 Google เปลี่ยนตัวชี้วัดจาก First Input Delay มาเป็น Interaction to Next Paint หรือ INP อย่างเป็นทางการ ความต่างสำคัญคือ FID วัดแค่การคลิกครั้งแรกครั้งเดียว แต่ INP วัดทุกการโต้ตอบตลอดที่คนอยู่ในหน้าเว็บ แล้วเลือกค่าที่แย่ที่สุดมาเป็นตัวแทน เกณฑ์ที่ควรผ่านคือต่ำกว่า 200 มิลลิวินาที การเปลี่ยนแบบนี้ทำให้เว็บที่เคยผ่าน FID สบายๆ อาจตกเกณฑ์ INP ทันที เพราะปัญหาจริงมักซ่อนอยู่ในการคลิกครั้งที่สามหรือสี่ ไม่ใช่ครั้งแรก
สาเหตุหลักที่ทำให้ INP แย่มักมาจาก JavaScript ที่ทำงานหนักเกินไปในเธรดหลัก เช่น สคริปต์ติดตามพฤติกรรมผู้ใช้ (Analytics) หลายตัวที่รันพร้อมกัน หรือ Third-party Script จากปลั๊กอินที่ไม่ได้ถูกโหลดแบบ Async การแก้ไขต้องเริ่มจากการแบ่งงานหนักออกเป็นชิ้นเล็ก (Code Splitting) และเลื่อนสคริปต์ที่ไม่จำเป็นเร่งด่วนออกไปโหลดทีหลัง
ควรเริ่มแก้จากตัวไหนก่อน เมื่อมีเวลาและทรัพยากรจำกัด
นี่คือคำถามที่คนทำเว็บจริงต้องเจอ เพราะแทบไม่มีใครมีเวลาไล่แก้ทั้งสามตัวพร้อมกันในทีเดียว การเลือกจุดเริ่มต้นต้องดูจากบริบทของเว็บตัวเอง ไม่ใช่ทำตามลำดับตัวอักษร LCP CLS INP แบบตายตัว
- ถ้าเว็บเป็น E-commerce ที่มีรูปสินค้าหนัก ให้แก้ LCP ก่อน เพราะภาพสินค้าคือสิ่งแรกที่ลูกค้าต้องเห็นเพื่อตัดสินใจซื้อ
- ถ้าเว็บมีโฆษณาหรือ Affiliate Banner จำนวนมาก ให้แก้ CLS ก่อน เพราะความเสี่ยงเรื่องคนคลิกโฆษณาผิดจะกระทบทั้งประสบการณ์และความน่าเชื่อถือ
- ถ้าเว็บเป็นแอปพลิเคชันที่มีฟอร์มหรือปุ่มโต้ตอบเยอะ เช่น เว็บจองที่พักหรือระบบตะกร้าสินค้า ให้ให้ความสำคัญกับ INP เป็นอันดับแรก
- ถ้าทรัพยากรจำกัดมากและต้องเลือกแก้ทีละตัว ให้ดูจากรายงานใน Google Search Console ว่าตัวไหนมีหน้าเว็บติด URL สีแดงมากที่สุด แล้วไล่แก้จากตัวนั้นก่อน
ข้อควรระวังคือการแก้ตัวหนึ่งอาจไปกระทบอีกตัวโดยไม่รู้ตัว เช่น การใส่ Lazy Load ให้รูปภาพเพื่อช่วยความเร็วโหลดหน้าโดยรวม แต่ถ้าตั้งค่าผิดจนรูป Hero Banner ที่ควรโชว์ทันทีถูก Lazy Load ไปด้วย ผลคือ LCP แย่ลงทั้งที่ตั้งใจจะแก้เรื่องอื่น การทดสอบซ้ำหลังแก้ทุกครั้งจึงเป็นเรื่องจำเป็นเสมอ
ดูค่าพวกนี้จากไหน แล้วตัวเลขในแล็บกับตัวเลขจริงต่างกันยังไง
เครื่องมือหลักที่ใช้ตรวจสอบคือ Google Search Console ในหมวด Core Web Vitals ซึ่งดึงข้อมูลจากผู้ใช้จริง (Field Data) ผ่าน Chrome User Experience Report ต่างจาก PageSpeed Insights หรือ Lighthouse ที่จำลองการโหลดในสภาพแวดล้อมควบคุม (Lab Data) ความต่างนี้สำคัญมาก เพราะเว็บอาจได้คะแนนดีเยี่ยมใน Lighthouse แต่กลับมีปัญหาในข้อมูลจริง เนื่องจากผู้ใช้จริงเข้าเว็บผ่านเน็ตมือถือช้า หรือใช้เครื่องรุ่นเก่าที่ประมวลผล JavaScript ได้ไม่เร็วเท่าคอมพิวเตอร์ที่ใช้ทดสอบ
เว็บไซต์ที่อยากแข่งขันด้านการตลาดดิจิทัลจริงจัง ต้องมองข้อมูลทั้งสองชุดควบคู่กัน ใช้ Lab Data เพื่อดีบักหาสาเหตุตอนพัฒนา และใช้ Field Data เพื่อยืนยันว่าผู้ใช้จริงได้ประสบการณ์ที่ดีตามที่ตั้งใจไว้หรือไม่
สิ่งที่ต้องทำต่อจากนี้ไม่ใช่การไล่ไล่ตามตัวเลขให้เขียวหมดทุกช่องในคืนเดียว แต่คือการเลือกแก้ปัญหาที่ส่งผลกระทบกับผู้ใช้จริงมากที่สุดก่อน แล้ววัดผลซ้ำเป็นรอบ ไม่ใช่ทำครั้งเดียวจบ เพราะเว็บที่มีการอัปเดตเนื้อหาบ่อย ค่าพวกนี้จะขยับเปลี่ยนตลอดเวลาตามพฤติกรรมผู้ใช้จริง คำถามที่ควรถามตัวเองต่อจากนี้คือ เว็บของคุณกำลังเสียโอกาสทางธุรกิจจากจุดไหนมากที่สุด ระหว่างคนที่รอภาพโหลดจนเบื่อ คนที่กดปุ่มผิดเพราะหน้าเว็บขยับ หรือคนที่รอฟอร์มตอบสนองจนหมดความอดทนแล้วปิดแท็บไปก่อน
