เว็บเพิ่งมีบทความ ทำไมยังไม่มีข้อมูล Core Web Vitals

พอเว็บเริ่มมีบทความมากขึ้น เราก็คงอยากเปิดรายงานดูว่าคนอ่านเจอหน้าที่เร็วแค่ไหน แต่บาง URL กลับยังไม่มีข้อมูล Core Web Vitals จากผู้ใช้จริง ทั้งที่เปิดหน้าได้และเครื่องมือทดสอบก็ให้ผลออกมาตามปกติ

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

เราจึงควรแยกว่าข้อมูลมาจากผู้ใช้กลุ่มใด รายงานรวมระดับไหน และระหว่างที่ยังไม่มี field data เราสามารถตรวจอะไรต่อได้บ้าง

CrUX กับผลทดสอบไม่ได้เกิดจากการวัดแบบเดียวกัน

CrUX หรือ Chrome User Experience Report รวบรวมประสบการณ์จากผู้ใช้ Chrome ที่เข้าเงื่อนไขแล้วแสดงเป็นข้อมูลรวม ส่วน Lighthouse จำลองการเปิดหน้าภายใต้สภาพทดสอบหนึ่ง การเปิดรายงานหน้าเดียวจึงอาจมีทั้งสองส่วนที่หน้าตาต่อกันแต่มีที่มาต่างกัน

Field data ช่วยให้เห็นสิ่งที่เกิดกับการใช้งานที่ถูกรวบรวม ส่วน lab ช่วยทำเหตุการณ์ซ้ำและตามหาสาเหตุได้ละเอียดกว่า จึงใช้ประกอบกันได้ แต่ไม่ควรนำคะแนนรอบทดลองไปเติมแทนช่องข้อมูลผู้ใช้จริงที่ยังไม่มี

ผู้เข้าชมทุกคนไม่ได้ถูกนับใน CrUX เพราะมีเงื่อนไขเกี่ยวกับผู้ใช้ แพลตฟอร์ม และการแบ่งปันข้อมูลด้วย จำนวน page view ที่เครื่องมืออีกตัวแสดงจึงไม่ใช่จำนวนตัวอย่างใน CrUX โดยอัตโนมัติ และไม่ควรตั้งสูตรแปลงขึ้นมาเอง

เช่นเดียวกัน การรัน Lighthouse หลายครั้งช่วยให้เข้าใจความแปรปรวนของการทดสอบ แต่ไม่ได้เปลี่ยนรอบเหล่านั้นเป็นการใช้งานจริงใน dataset นี้ การอยากมี field data จึงไม่ใช่เหตุให้เปิดเครื่องมือซ้ำเพื่อสะสมจำนวนให้ครบ

URL หนึ่งอาจยังไม่มี แต่ข้อมูลทั้ง origin มีได้

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

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

ข้อมูลรวมยังมีประโยชน์กับการดูแนวโน้ม แต่หน้าที่มีโครงสร้างต่างกันอาจมีพฤติกรรมต่างกัน เช่น หน้าแรกกับบทความที่มีภาพมาก การเห็นผลรวมดีจึงยังไม่พอยืนยันว่าทุก template หรือทุก URL ไม่มีปัญหา

ถ้าเริ่มปรับเว็บ ควรเก็บรายการ template ที่เกี่ยวข้องไว้ด้วย จะช่วยเลือกหน้าตัวแทนมาทดสอบใน lab ระหว่างที่รายงานยังแยก URL ให้ไม่ได้ โดยระบุว่าเป็นการเลือกตรวจของเรา ไม่ใช่การแบ่งกลุ่มที่เครื่องมือรับรองมาให้

ความเป็นสาธารณะกับจำนวนตัวอย่างเป็นคนละเงื่อนไข

เอกสาร CrUX ระบุเงื่อนไขเรื่องการค้นพบหน้าได้และความนิยมที่เพียงพอ จึงควรตรวจพื้นฐานว่า URL ตอบสำเร็จและไม่มีคำสั่งไม่ให้ทำดัชนีตามขอบเขตที่เกี่ยวข้อง แต่การผ่านเงื่อนไขนี้ไม่ได้ทำให้มีจำนวนตัวอย่างเพียงพอทันที

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

การขอให้ระบบค้นหาสำรวจหน้า กับการมีประสบการณ์ผู้ใช้ที่เข้าเกณฑ์ CrUX ก็เป็นคนละเรื่องเช่นกัน บอทที่เข้ามาอ่านเนื้อหาไม่ใช่หลักฐานว่ามีคนใช้หน้าในรูปแบบที่จะถูกรวบรวมใน dataset นี้

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

ช่วงเวลาของรายงานไม่ใช่ภาพสดหลังแก้เว็บทันที

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

สำหรับรายงาน CrUX ใน PageSpeed Insights ข้อมูลเป็นช่วงย้อนหลัง 28 วัน ความเปลี่ยนแปลงหลังแก้จึงต้องค่อยๆ ดูร่วมกับวันที่เปลี่ยน ไม่เอาผลรวมช่วงเก่าไปตัดสินว่าการแก้เมื่อครู่ไม่ทำงานโดยยังไม่ได้ตรวจใน lab

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

ระหว่างรอ ยังตรวจงานที่คนอ่านใช้จริงได้

เลือกหน้าและการกระทำที่สำคัญ เช่น เปิดบทความจากลิงก์ภายนอก เลื่อนผ่านรูป และกดเมนูบนมือถือ แล้วเก็บเงื่อนไขกับ trace ไว้ จะช่วยหาปัญหาโหลดหลัก การขยับของหน้า และการตอบสนองได้โดยไม่ต้องรอข้อมูลรวมก่อนเริ่มแก้

การตรวจควรมีทั้งลักษณะการเปิดครั้งแรกกับรอบที่มีแคช และมีอุปกรณ์หรือการจำลองที่สะท้อนข้อจำกัดที่อยากเข้าใจ พร้อมระบุขอบเขตว่าผลเหล่านี้เป็นการทดสอบของเรา ไม่ใช่สถิติแทนคนอ่านทั้งหมด

หากต่อไปจะเก็บ real user monitoring เพิ่ม ก็ควรกำหนดคำถามและข้อมูลที่จำเป็นให้ชัด รวมถึงการดูแลข้อมูลตามบริบทเว็บก่อนนำมาใช้ งานนี้เป็นอีกระบบหนึ่งที่ต้องออกแบบ ไม่ใช่สิ่งที่ต้องติดตั้งทุกอย่างทันทีเพียงเพราะรายงานสาธารณะยังไม่มีตัวเลข

สำหรับเว็บเล็ก การมีบันทึกการเปลี่ยนแปลงและเงื่อนไขทดสอบที่หาเจอได้ช่วยมาก เมื่อเริ่มมี field data ภายหลัง เราจะเทียบช่วงเวลาและตั้งคำถามต่อได้ โดยไม่ต้องเดาว่าหน้าเคยเปลี่ยนส่วนใดในวันที่ตัวเลขเริ่มขยับ

การไม่มีข้อมูล Core Web Vitals จาก CrUX หมายถึงยังไม่มีข้อมูลในขอบเขตรายงานนั้นให้สรุป ไม่ได้บอกว่าเว็บเร็วหรือช้าเอง ควรตรวจระดับ URL กับ origin เงื่อนไขที่เกี่ยวข้อง และช่วงเวลาของข้อมูลให้ชัด แล้วใช้ lab ตามหาปัญหาที่ทำซ้ำได้ระหว่างรอ เมื่อข้อมูลผู้ใช้จริงพร้อมจึงนำมาดูร่วมกันโดยรักษาความหมายของหลักฐานแต่ละแบบไว้ครับ