Chrome 151’s Soft Navigations API ช่วยให้ Single-page apps (SPAs) สามารถรายงานค่า Core Web Vitals สำหรับทุกการนำทางภายในแอปได้แล้ว แต่ชุดข้อมูล CrUX ของ Google ยังคงบันทึกเพียงการโหลดแบบ hard load ครั้งแรกเท่านั้น ทำให้เหล่านักพัฒนาต้องเผชิญกับภาพรวมประสิทธิภาพที่แตกต่างกันสองชุด

ทำไมตัวชี้วัดของ SPA ถึงล้าหลัง

Core Web Vitals—ได้แก่ Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) และ Cumulative Layout Shift (CLS)—ถูกกำหนดขึ้นโดยอิงจากการ hard navigations ซึ่งเป็นการดึงเอกสารใหม่ทั้งหมดและทิ้งสถานะ (state) ของหน้าเดิมไป

SPA ที่สร้างด้วย React, Vue, Next.js หรือเฟรมเวิร์กที่คล้ายกัน มักจะไม่เกิดการ hard navigations การคลิกลิงก์จะเป็นการอัปเดต URL ผ่าน History API ดึงข้อมูลในพื้นหลัง และสลับเนื้อหาโดยไม่ต้องโหลดหน้าใหม่ทั้งหมด Performance API ที่มีอยู่จะจับได้เพียงการโหลดหน้าแรกเท่านั้น ดังนั้น LCP และ INP จึงไม่เคยเห็นค่าความหน่วง (latency) ที่ผู้ใช้รู้สึกเมื่อเปลี่ยนจากเส้นทาง (route) หนึ่งไปยังอีกเส้นทางหนึ่ง

จุดบอดนี้ทำให้แดชบอร์ดที่ดึงข้อมูลจาก Performance Timeline หรือ Chrome User Experience Report (CrUX) ของ Google ผิดเพี้ยนไป โดยมักจะแสดงค่า LCP ที่ดีเยี่ยมสำหรับหน้า "shell" แต่กลับมองข้ามการโหลดที่ช้าลงในส่วนที่ลึกขึ้นของแอป ทำให้เกิดความรู้สึกที่ผิดพลาดเกี่ยวกับสุขภาพด้านประสิทธิภาพ (performance health)

Chrome’s Soft Navigations API

Chrome 151 ได้เปิดตัว Soft Navigations API ซึ่งเป็นชุดของหลักเกณฑ์ (heuristics) ที่ปฏิบัติกับปฏิสัมพันธ์บางอย่างใน SPA เสมือนเป็นการนำทางจริง โดย API นี้จะเฝ้าดูสัญญาณ 3 อย่าง:

  • ปฏิสัมพันธ์ที่เริ่มโดยผู้ใช้ (การคลิก, การแตะ, เหตุการณ์จากคีย์บอร์ด)
  • การเปลี่ยน URL ผ่าน History API
  • เหตุการณ์การวาดหน้าจอ (paint events) ที่เกิดขึ้นตามมาเพื่อแสดงเนื้อหาใหม่

เมื่อสัญญาณทั้งสามสอดคล้องกัน Chrome จะบันทึก soft navigation ลงใน Performance Timeline และค่า Core Web Vitals จะถูกคำนวณสำหรับการเปลี่ยนผ่านนั้นเหมือนกับการทำ hard navigation เลย ทั้งนี้ ไลบรารีโอเพนซอร์ส web-vitals ได้เพิ่มการรองรับเมื่อวันที่ 21 กรกฎาคม ทำให้นักพัฒนาสามารถเริ่มดึงตัวเลขเหล่านี้ได้ด้วย API เดิมที่ใช้งานอยู่

ในทางปฏิบัติ ตอนนี้คุณจะเห็นค่า LCP สำหรับการเปลี่ยนแต่ละ route, ค่า INP ที่สะท้อนถึงความหน่วงที่แท้จริงจากการป้อนข้อมูลล่าสุดของผู้ใช้ และค่า CLS ที่จับการเลื่อนของเลย์เอาต์หลังจากการทำ soft navigation

ความแตกต่างของข้อมูล: Chrome vs. CrUX

CrUX (Chrome User Experience Report) ของ Google เป็นขุมพลังให้กับ PageSpeed Insights, Search Console และส่งผลทางอ้อมต่อสัญญาณการจัดอันดับ (ranking signals) แต่ CrUX ยังคงรวบรวมเฉพาะข้อมูลจากการทำ hard-navigation เท่านั้น

ส่งผลให้คุณมีกระแสข้อมูลสองชุดที่สอดคล้องกันแต่แตกต่างกัน:

  • เครื่องมือภายใน (Internal tools) ที่อ่านจาก Performance Timeline จะแสดงค่า LCP, INP และ CLS ในระดับ route ซึ่งให้ภาพที่สมจริงเกี่ยวกับสิ่งที่ผู้ใช้ได้รับประสบการณ์ใน SPA
  • ชุดข้อมูลสาธารณะของ Google ยังคงแสดงตัวชี้วัดเฉพาะการโหลดหน้าแรกเท่านั้น ซึ่งเป็นสิ่งที่ Search Console รายงานและเป็นสิ่งที่อัลกอริทึมการจัดอันดับของ Google นำไปใช้อ้างอิง

ทั้งสองอย่างถูกต้อง เพียงแต่เป็นการวัดในช่วงเวลาที่ต่างกัน การพึ่งพาเพียง Search Console อาจทำให้มองไม่เห็นการถดถอยของประสิทธิภาพ (performance regressions) ที่เกิดขึ้นหลังจากการโหลดครั้งแรก ในขณะที่การใช้เพียงแดชบอร์ดภายในอย่างเดียวก็จะไม่สะท้อนถึงเกณฑ์มาตรฐาน (baseline) ที่ Google ใช้สำหรับ SEO

สิ่งที่นักพัฒนาต้องเฝ้าระวัง

  • การรองรับของเบราว์เซอร์ (Browser support) – ปัจจุบัน Soft Navigations API มีให้ใช้เฉพาะในเบราว์เซอร์ที่ใช้ Chromium เท่านั้น Safari และ Firefox ยังไม่มีสิ่งที่เทียบเท่ากัน ดังนั้นคุณต้องเตรียมตรรกะสำรอง (fallback logic) สำหรับผู้ใช้บางส่วนไว้ด้วย
  • ข้อจำกัดของหลักเกณฑ์ (Heuristic limits) – API ตัดสินการทำ soft navigation ตามชุดของสัญญาณ หากแอปของคุณอัปเดตเนื้อหาโดยไม่มีการเปลี่ยน URL (เช่น modal overlays หรือการเลื่อนหน้าแบบไม่สิ้นสุด/infinite scroll) API อาจพลาดการเปลี่ยนผ่านเหล่านั้น ทำให้เกิดช่องว่างในข้อมูล
  • การทดสอบก่อนที่จะเชื่อถือ (Testing before trusting) – เนื่องจากการตรวจจับใช้หลักเกณฑ์ (heuristic) คุณควรทดสอบชุดปฏิสัมพันธ์ในโลกแห่งความเป็นจริงบนแอปของคุณ และเปรียบเทียบตัวชี้วัดที่รายงานกับเวลาที่วัดด้วยตนเอง (เช่น การใช้ performance.mark) ควรตัดสินใจเรื่องการปรับแต่ง (optimisation) บนตัวเลขใหม่นี้หลังจากยืนยันความถูกต้องแล้วเท่านั้น

บทสรุป

Chrome 151 มอบความสามารถที่นักพัฒนา SPA รอคอยมานานในการวัดค่า LCP, INP และ CLS สำหรับทุกการเปลี่ยนเส้นทางภายในแอป แต่ข้อมูลการจัดอันดับของ Google ยังคงสะท้อนเพียงการโหลดแบบ hard load ครั้งแรกเท่านั้น จนกว่า CrUX จะตามทัน ทีมงานต้องบริหารจัดการชุดข้อมูลสองชุดที่ขนานกันไป: ชุดหนึ่งที่บอกเรื่องราวที่แท้จริงของผู้ใช้ และอีกชุดหนึ่งที่ขับเคลื่อนการจัดอันดับการค้นหา การสร้างสมดุลระหว่างทั้งสองอย่าง—และการเตรียมพร้อมสำหรับการรองรับของเบราว์เซอร์ที่กว้างขึ้น—จะเป็นกุญแจสำคัญในการรักษา SPA ที่เน้นประสิทธิภาพเป็นหลักในระบบนิเวศเว็บที่มีการแข่งขันสูง