ช่วงทดลองใช้การนำทางแบบนุ่มนวลใหม่

Barry Pollard
Michal Mocny

เผยแพร่: 31 ก.ค. 2025

Chrome จะเปิดตัวช่วงทดลองใช้จากต้นทางใหม่จาก Chrome 139 สำหรับ Soft Navigations API ที่เราได้ทดลองใช้ก่อนหน้านี้ การทดลองใช้ต้นทางนี้ช่วยให้เว็บไซต์ลองใช้ API ในเว็บไซต์กับผู้ใช้จริงเพื่อทดสอบ API ในภาคสนามและให้ความคิดเห็นแก่ทีม Chrome ได้

การนำทางแบบนุ่มนวลคืออะไร

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

เหตุผลที่ต้องใช้ Soft Navigation API

Soft Navigations API เป็น API ที่เสนอเพื่ออนุญาตการตรวจหาที่อิงตามฮิวริสติกของสิ่งที่เรียกว่า "การนำทางแบบนุ่มนวล" ตามที่ใช้โดยเว็บไซต์ Single Page Application (SPA) เนื่องจากไม่มีการไปยังหน้าเว็บจริงเกิดขึ้นสำหรับการไปยังแบบย่อย ซึ่งหมายความว่าการดำเนินการบางอย่างที่ปกติจะเกิดขึ้นสำหรับการไปยังส่วนต่างๆ จะต้องได้รับการจัดการด้วย JavaScript ด้วยตนเอง การดำเนินการบางอย่าง เช่น การจัดการประวัติการนำทาง สามารถทำได้ด้วย API ปัจจุบัน อย่างไรก็ตาม การดำเนินการอื่นๆ เช่น การวัด Core Web Vitals จะทำไม่ได้สำหรับการไปยังส่วนต่างๆ เหล่านี้

Soft Navigation API ช่วยให้สังเกตการนำทางแบบนุ่มนวลได้ แม้ว่า JavaScript ที่เริ่มการนำทางแบบนุ่มนวล (โดยปกติคือเฟรมเวิร์ก JavaScript) จะทราบว่าการนำทางเกิดขึ้นเมื่อใด แต่ JavaScript อื่นๆ และตัวเบราว์เซอร์เองจะไม่ทราบ

Core Web Vitals และ SPA

หนึ่งในปัจจัยหลักที่ขับเคลื่อน Soft Navigation API คือการอนุญาตให้วัด Core Web Vitals สำหรับ SPA Core Web Vitals จะวัดโดยทั้งเบราว์เซอร์ (เพื่อแสดงในเครื่องมือต่างๆ เช่น รายงานประสบการณ์ของผู้ใช้ Chrome) และโดยไลบรารี JavaScript ของการตรวจสอบผู้ใช้จริง (RUM)

เฟรมเวิร์ก JavaScript อาจวัดผลบางแง่มุมของ Core Web Vitals ได้ โดยเฉพาะ Interaction to Next Paint (INP) และ Cumulative Layout Shift (CLS) จะอิงตามองค์ประกอบพื้นฐาน (Event Timing API และ Layout Instability API ตามลําดับ) ที่วัดได้ในช่วงระยะเวลาใดก็ได้เพื่อคํานวณเมตริก INP และ CLS อย่างไรก็ตาม เมตริกอื่นๆ เช่น Largest Contentful Paint (LCP) จะปล่อยออกมาโดยเบราว์เซอร์เท่านั้น โดยอิงตามการไปยังหน้าเว็บ และจะถือว่าเสร็จสมบูรณ์เมื่อมีการโต้ตอบ

วิธีที่ Soft Navigation API ช่วยให้วัด Core Web Vitals สําหรับ SPA ได้

การทำซ้ำครั้งแรกของ Soft Navigation API ได้รวมฮิวริสติกการนำทางแบบนุ่มเข้ากับการรีเซ็ต LCP หลังจากรีเซ็ตแล้ว ระบบจะปล่อย LCP อีกครั้งสำหรับการนำทางแบบนุ่มสำหรับ Contentful Paint ใหม่ ซึ่งจะช่วยให้วัดเมตริกนี้สำหรับการนำทางแบบนุ่มได้

การทำซ้ำครั้งล่าสุดนี้ใช้วิธีการที่แตกต่างออกไป และแยกแนวคิดเหล่านี้ออกเป็น Soft Navigation API และรายการประสิทธิภาพ Interaction to Contentful Paint ใหม่ รายการ interaction-contentful-paint จะวัด "การแสดงผลเนื้อหา" หลังจากการโต้ตอบ ปัจจุบันระบบจะปล่อยข้อมูลนี้สำหรับการนำทางแบบนุ่มเท่านั้น แต่การดำเนินการนี้จะเปิด Use Case อื่นๆ ที่อาจเกิดขึ้นนอกเหนือจาก LCP หากเปิดใช้สำหรับการโต้ตอบทั้งหมด

นอกจากนี้ API ยังขยายรายการประสิทธิภาพแต่ละรายการของ largest-contentful-paint, interaction-contentful-paint, event-timing และ layout-shift เพื่อรวมตัวระบุที่รายการการนำทางมีไว้ด้วย รายการประสิทธิภาพจะแสดงหลังจากเหตุการณ์ที่วัด โดยปกติจะแสดงในช่วงเวลาที่ไม่มีการใช้งาน ซึ่งหมายความว่า URL มักจะมีการเปลี่ยนแปลงเมื่อมีการส่งรายการประสิทธิภาพ การรวมการนำทางไว้กับการเริ่มต้นจะช่วยให้วัด Core Web Vitals สำหรับ URL ที่ระบุได้ง่ายขึ้นมากโดยไม่ต้องจับคู่เวลาเริ่มต้นของรายการประสิทธิภาพกับเวลาเริ่มต้นของการนำทางแบบนุ่ม

เหตุใดจึงใช้ฮิวริสติก

Soft Navigation API จะพิจารณาการนำทางแบบนุ่มเมื่อเกิดเหตุการณ์ต่อไปนี้

  • มีการโต้ตอบตามผู้ใช้ (การอัปเดต URL โดยไม่มีการโต้ตอบของผู้ใช้จะไม่นับ)
  • ... ซึ่งส่งผลให้เกิดการแก้ไข DOM และการวาด
  • … และมีการอัปเดต URL
  • การอัปเดต URL รวมถึงการเปลี่ยนแปลงประวัติ

API ใช้แนวทางตามฮิวริสติกนี้แทนที่จะอนุญาตให้เฟรมเวิร์ก JavaScript "ปล่อย" การนำทางแบบนุ่มนวล หรือสร้างขึ้นบน Navigation API เนื่องจากวิธีนี้ช่วยให้เข้าใจได้อย่างสอดคล้องกันว่าอะไรคือการนำทางแบบนุ่มนวล ไม่ว่าจะเป็นเฟรมเวิร์กใดหรือนักพัฒนาซอฟต์แวร์จะใช้เฟรมเวิร์กนั้นอย่างไรก็ตาม

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

การสร้างการตรวจหาการนำทางแบบนุ่มลงในเบราว์เซอร์จะสร้าง "ฮิวริสติก" ที่เป็นมาตรฐาน (พร้อมความคิดเห็นของคุณจากการทดลองใช้ต้นทางนี้) ซึ่งจะช่วยให้เราวัด Core Web Vitals สำหรับการนำทางแบบนุ่มได้ในวงกว้างและทำให้การวัดดังกล่าวเปรียบเทียบกันได้ในวงกว้าง แทนที่จะอาศัยตัวเลือกเฟรมเวิร์ก

นอกจากนี้ เฟรมเวิร์กและนักพัฒนาซอฟต์แวร์ยังสามารถละเว้นฮิวริสติกของ Soft Navigations API และใช้ Event Timing, Layout Instability และ Interaction to Contentful Paint API ที่เกี่ยวข้องเพื่อวัดเมตริกประสิทธิภาพเพิ่มเติมได้ตามต้องการ แต่เราขอแนะนำให้ใช้ Core Web Vitals โดยใช้ฮิวริสติกเพื่อให้วัดผลในเว็บไซต์ต่างๆ ได้

ต้องการความช่วยเหลือในการทดสอบ Soft Navigation API

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

ตัวอย่างที่เราพบว่าทำให้เกิดปัญหา ได้แก่ เมื่อมีการอัปเดต URL ด้วย replaceState แทนที่จะเพิ่มประวัติ หรือเมื่อเกิดการนำทางที่ไม่ได้เริ่มต้นโดยผู้ใช้ (เช่น การออกจากระบบเมื่อหมดเวลา) ทั้ง 2 กรณีนี้อธิบายได้ด้วยการไม่ตรงกับฮิวริสติก และทีม Chrome ก็สบายใจที่จะไม่รวมกรณีเหล่านี้ แต่เราอยากรับฟังความคิดเห็นจากนักพัฒนาเว็บหากเห็นด้วย และเราต้องการรับฟังกรณีที่ฮิวริสติกดูเหมือนจะตรงตามเกณฑ์ แต่ API ยังคงไม่รู้จักการนำทางแบบนุ่ม

นอกจากนี้ เรายังต้องการทราบว่า API นี้และ Interaction to Contentful Paint Primitive ใหม่ตอบโจทย์ Use Case หลักในการอนุญาตให้วัด Core Web Vitals สำหรับ SPA หรือไม่

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

วิธีทดสอบ

คุณทดสอบ API ได้ในเครื่องด้วยฟีเจอร์หรือตัวเลือกบรรทัดคำสั่งของ Chrome นอกจากนี้ คุณยังทดสอบในฟิลด์ด้วยช่วงทดลองใช้จากต้นทางได้ด้วย

โปรดดูรายละเอียดทางเทคนิคเพิ่มเติมของ API ได้ที่เอกสารประกอบหรือที่เก็บข้อมูล GitHub โดยเฉพาะวิธีวัด Core Web Vitals นอกจากนี้ ยังมีไลบรารี web-vitals เวอร์ชันการนำทางแบบนุ่มที่อยู่ในระยะทดลองให้ใช้งานด้วย

ความคิดเห็น

เรากำลังขอความคิดเห็นเกี่ยวกับการทดสอบนี้ในที่ต่อไปนี้

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