การวัดการนำทางแบบนุ่ม

Barry Pollard

Michal Mocny

เผยแพร่: 1 กุมภาพันธ์ 2023, อัปเดตล่าสุด: 24 มิถุนายน 2026

นับตั้งแต่เปิดตัว Core Web Vitals Initiative ได้พยายามวัดประสบการณ์ของผู้ใช้จริงของเว็บไซต์ แทนที่จะวัดรายละเอียดทางเทคนิคเบื้องหลังวิธีสร้างหรือโหลดเว็บไซต์ เมตริก Core Web Vitals ทั้ง 3 รายการสร้างขึ้นเพื่อเป็นเมตริกที่เน้นผู้ใช้ ซึ่งเป็นการพัฒนาต่อยอดจากเมตริกทางเทคนิคที่มีอยู่ เช่น DOMContentLoaded หรือ load ซึ่งวัดเวลาที่มักไม่เกี่ยวข้องกับวิธีที่ผู้ใช้รับรู้ถึงประสิทธิภาพของหน้าเว็บ ด้วยเหตุนี้ เทคโนโลยีที่ใช้สร้างเว็บไซต์จึงไม่ควรส่งผลต่อการให้คะแนน หากเว็บไซต์ทำงานได้ดี

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

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

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

เราได้ปรับปรุงข้อเสนอหลายอย่างตามความคิดเห็นของนักพัฒนาแอป และตั้งเป้าที่จะเปิดตัว API ประสิทธิภาพใหม่ 2 รายการเพื่อช่วยแก้ปัญหานี้จาก Chrome 151

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

เราได้กำหนดคำจำกัดความของการนำทางแบบนุ่มนวลดังนี้

• การนำทางเริ่มต้นโดยการดำเนินการของผู้ใช้
• การนำทางส่งผลให้ URL ที่ผู้ใช้เห็นมีการเปลี่ยนแปลง
• การโต้ตอบส่งผลให้เกิดการแสดงผลที่มองเห็นได้

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

การรองรับการนำทางแบบย่อยของเครื่องมือสำหรับนักพัฒนาเว็บ

เราได้เพิ่มการรองรับการนำทางแบบไม่เต็มหน้าในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บในมุมมองการติดตาม

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

ตอนนี้ฟีเจอร์นี้จะแสดงเฉพาะการนำทางแบบยืดหยุ่นและการประทับเวลา LCP ในมุมมองการติดตามเท่านั้น เราจะเพิ่มเมตริกอื่นๆ (เช่น LCP) และการรองรับในมุมมองเมตริกแบบเรียลไทม์ในภายหลัง

Chrome ใช้การนำทางแบบนุ่มนวลสำหรับนักพัฒนาเว็บอย่างไร

เมื่อเปิดใช้ฟีเจอร์การนำทางแบบนุ่มนวลแล้ว (ดูข้อมูลเพิ่มเติมได้ในส่วนถัดไป) Chrome จะเปลี่ยนวิธีรายงานเมตริกประสิทธิภาพบางอย่างดังนี้

• ระบบจะปล่อยเหตุการณ์ soft-navigation PerformanceTiming หลังจากตรวจพบการนำทางแบบนุ่มแต่ละครั้ง
• รายการ soft-navigation นี้จะมี navigationId, URL ใหม่ในแอตทริบิวต์ name รวมถึง interactionId ของการโต้ตอบที่เริ่มต้น
• ระบบจะปล่อยรายการ interaction-contentful-paint อย่างน้อย 1 รายการหลังจากการโต้ตอบที่ทำให้เกิดการแสดงผลเนื้อหา ซึ่งจะมีlargestContentfulPaintรายการที่ใช้ในการวัด Largest Contentful Paint (LCP) สำหรับการนำทางแบบไม่เข้มงวดได้
• แอตทริบิวต์ navigationId จะเพิ่มลงในเวลาในการแสดงแต่ละรายการ (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event และ layout-shift) ซึ่งสอดคล้องกับรายการการนำทางที่ปล่อยเหตุการณ์ โปรดทราบว่าเมื่อรายการเหล่านี้ครอบคลุมการนำทางแบบนุ่ม รายการอาจมี navigationId ก่อนหน้าหรือถัดไป ทั้งนี้ขึ้นอยู่กับเวลาที่ปล่อยรายการ ดูข้อมูลเพิ่มเติมได้ในส่วนรายงานเมตริกเทียบกับ URL ที่เหมาะสม
• soft-navigation จะมีฟังก์ชัน getLargestInteractionContentfulPaint() เพื่อดึงข้อมูลรายการ interaction-contentful-paint ที่ใหญ่ที่สุดสำหรับการนำทางนั้น จากนั้นจะใช้เป็น LCP เริ่มต้นสำหรับการนำทางนั้นได้ และ LCP นั้นจะอัปเดตได้เมื่อพบinteraction-contentful-paintรายการเพิ่มเติมสำหรับการโต้ตอบนั้น โปรดทราบว่าการตั้งค่านี้จะแทนที่largestInteractionContentfulPaintแอตทริบิวต์ที่มีในการทดลองใช้ต้นทางก่อนหน้า
• รายการ interaction-contentful-paint บางรายการอาจเกิดขึ้นก่อนการนำทางแบบเบา (หากการอัปเดต URL ไม่เกิดขึ้นจนกว่าจะมีการแสดงผลเหล่านั้น) ในกรณีเหล่านี้ getLargestInteractionContentfulPaint() ฟังก์ชันจะช่วยให้ไม่ต้องบัฟเฟอร์และย้อนกลับไปดูรายการเก่าหลังจากที่การนำทางแบบนุ่มเสร็จสมบูรณ์ โปรดทราบว่ารายการที่ getLargestInteractionContentfulPaint() แสดงผลคือสำเนาที่ตรงกันของรายการ interaction-contentful-paint ที่ใหญ่ที่สุด ณ เวลาที่ออก ดังนั้นรายการดังกล่าวอาจใช้ navigationId ก่อนหน้าเนื่องจากเป็นเวลาที่เกิดการแสดงผล แต่ควรวัดการแสดงผลเหล่านี้เทียบกับ navigationId ใหม่
• นอกจากนี้ รายการ soft-navigation ยังมี paintTime และ presentationTime เป็น FCP สำหรับการนำทางนั้นด้วย
• โปรดทราบว่าระบบจะปล่อยรายการ interaction-contentful-paint หลังจากมีการโต้ตอบเพิ่มเติมด้วย แต่ LCP สำหรับ URL ควรจำกัดไว้ที่รายการ interaction-contentful-paint ที่ตรงกับการนำทางแบบย่อย interactionId เพื่อยกเว้นรายการเหล่านี้ และจำกัดไว้เฉพาะพร็อพเพอร์ตี้ largestContentfulPaint ภายในรายการดังกล่าวด้วย

การเปลี่ยนแปลงเหล่านี้จะช่วยให้วัด Core Web Vitals และเมตริกการวินิจฉัยที่เกี่ยวข้องบางอย่างได้ต่อการนำทางหน้าเว็บ แม้ว่าจะมีรายละเอียดบางอย่างที่ต้องพิจารณา

การเปิดใช้การนำทางแบบนุ่มนวลใน Chrome ส่งผลกระทบอย่างไร

การเปลี่ยนแปลงบางอย่างที่เจ้าของเว็บไซต์ต้องพิจารณาหลังจากเปิดใช้ฟีเจอร์นี้มีดังนี้

• การตรวจสอบรายการ soft-navigation ช่วยให้ "แบ่ง" รายการประสิทธิภาพออกเป็นการ "นำทาง" แต่ละรายการได้
• คุณสามารถแบ่งเมตริก CLS และ INP ได้ตามต้องการ แทนที่จะวัดตลอดระยะเวลาของวงจรหน้าเว็บทั้งหมด แต่ฟีเจอร์การนำทางแบบนุ่มจะให้การวัดที่ได้มาตรฐานเมื่อเกิดเหตุการณ์นี้ขึ้น ไม่ว่าเทคโนโลยีพื้นฐานที่ใช้จะเป็นอะไรก็ตาม
• รายการ largest-contentful-paint จะเสร็จสมบูรณ์เมื่อมีการโต้ตอบ (ซึ่งจำเป็นต่อการเริ่มการนำทางแบบนุ่ม) จึงใช้ได้เฉพาะในการวัด LCP ของการนำทาง "แบบฮาร์ด" ครั้งแรกเท่านั้น ซึ่งหมายความว่าค่านี้จะไม่เปลี่ยนแปลงเมื่อมีการวัดการนำทางแบบย่อย ดังนั้นจึงวัด LCP สำหรับการโหลดหน้าเว็บครั้งแรกที่ใช้การนำทางแบบเต็มได้เช่นเดิม
• รายการ interaction-contentful-paint ใหม่ที่จะปล่อยออกมาจากการโต้ตอบสามารถใช้เพื่อวัด LCP สำหรับการนำทางแบบนุ่มได้โดยดูที่พร็อพเพอร์ตี้ largestContentfulPaint ภายในรายการนั้น แต่ก็มีข้อควรพิจารณาบางอย่างเกี่ยวกับวิธีใช้รายการนี้ที่เราจะกล่าวถึงในบทความนี้
• โปรดทราบว่าผู้ใช้บางรายอาจไม่รองรับฟีเจอร์การนำทางแบบนุ่มนวลนี้ โดยเฉพาะผู้ที่ใช้ Chrome เวอร์ชันเก่าและผู้ที่ใช้เบราว์เซอร์อื่น โปรดทราบว่าผู้ใช้บางรายอาจไม่รายงานเมตริกที่อิงตามการนำทางแบบนุ่ม แม้ว่าจะรายงานเมตริก Core Web Vitals ก็ตาม

สอบถามผู้ให้บริการ RUM ว่ารองรับการวัด Core Web Vitals โดยใช้การนำทางแบบนุ่มนวลหรือไม่ หลายๆ รายวางแผนที่จะทดสอบมาตรฐานใหม่นี้ และจะนำข้อควรพิจารณาก่อนหน้านี้มาพิจารณาด้วย ในระหว่างนี้ ผู้ให้บริการบางรายยังอนุญาตให้วัดเมตริกประสิทธิภาพแบบจำกัดตามฮิวริสติกของตนเองด้วย

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีวัดเมตริกสำหรับการนำทางแบบนุ่มนวลได้ที่ส่วนการวัด Core Web Vitals ต่อการนำทางแบบนุ่มนวล

ฉันจะเปิดใช้การนำทางแบบนุ่มนวลใน Chrome ได้อย่างไร

เราตั้งใจที่จะเปิดใช้ฟีเจอร์การนำทางแบบไม่เต็มหน้าโดยค่าเริ่มต้นใน Chrome 151 แต่คุณสามารถทดสอบฟีเจอร์นี้ได้ก่อนหน้านั้นโดยการเปิดใช้ฟีเจอร์นี้อย่างชัดเจน

สำหรับนักพัฒนาแอป คุณเปิดใช้ฟีเจอร์นี้ได้โดยเปิด Flag ที่ chrome://flags/#soft-navigation-heuristics หรือจะเปิดใช้โดยใช้อาร์กิวเมนต์บรรทัดคำสั่ง --enable-features=SoftNavigationHeuristics เมื่อเปิด Chrome ก็ได้ การเปิดใช้ฟีเจอร์ chrome://flags/#enable-experimental-web-platform-features จะเป็นการเปิดใช้การนำทางแบบนุ่มนวลด้วย

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

การรองรับ API การตรวจจับการนำทางแบบนุ่มนวล

คุณใช้โค้ดต่อไปนี้เพื่อทดสอบว่าระบบรองรับ API หรือไม่

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

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

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

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

ฉันจะวัดการนำทางแบบนุ่มได้อย่างไร

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

รายงานการนำทางแบบนุ่มนวล

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

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

ซึ่งใช้เพื่อสรุปเมตริกหน้าเว็บตลอดอายุการใช้งานสำหรับการนำทางก่อนหน้าได้

รายงานเมตริกเทียบกับ URL ที่เหมาะสม

เมื่อเห็นการนำทางแบบย่อย ควรสรุป Core Web Vitals ของหน้าก่อนหน้า จากนั้นรายงานสำหรับ URL ก่อนหน้า และควรเริ่มการตรวจสอบใหม่สำหรับ URL ใหม่

แอตทริบิวต์ name ของรายการ soft-navigation ที่เหมาะสมจะมี URL ใหม่เพื่อรายงานเมตริก และ navigationId จะเป็นการอ้างอิงที่ไม่ซ้ำกันสำหรับการนําทางนี้ (เนื่องจากอาจมีการเข้าชม URL เดียวกันหลายครั้งตลอดอายุการใช้งานของแอปพลิเคชันหน้าเว็บเดียว)

ควรตั้งค่านี้เป็นรายการ soft-navigation แต่ละรายการและใช้เพื่อรายงานเมตริกจนกว่าจะได้รับรายการ soft-navigation ถัดไป

รายงาน URL ที่ถูกต้องสำหรับ interaction-contentful-paint

ต้องพิจารณาเพิ่มเติมในการคำนวณ LCP จากรายการ interaction-contentful-paint เนื่องจากไม่ควรแมปรายการ interaction-contentful-paint ทั้งหมดโดยใช้ navigationId และรายงานเป็น LCP สำหรับ URL นั้น

• ปัญหาแรกคือระบบอาจปล่อยรายการ interaction-contentful-paint ก่อนการนำทางแบบนุ่มหากมีการแสดงผลก่อนการอัปเดต URL ในกรณีเหล่านี้ navigationId จะเป็นของ URL เก่า หากอัปเดต URL ก่อน การแสดงผลจะทำให้การนำทางแบบนุ่มเสร็จสมบูรณ์ และในกรณีนั้น ระบบจะปล่อย soft-navigation ก่อน และ interaction-contentful-paint จะมี URL ใหม่
• ปัญหาที่ 2 คือ interaction-contentful-paint ระบบจะยังคงปล่อยรายการสำหรับการโต้ตอบใหม่ๆ ต่อไป เนื่องจากขอบเขตของเมตริกประสิทธิภาพนี้ไม่ได้จำกัดอยู่แค่ LCP สำหรับการนำทางแบบนุ่มนวล เราต้องการพิจารณาเฉพาะการแสดงผลสำหรับการโหลดการนำทางแบบนุ่มสำหรับ LCP และไม่ใช่การแสดงผลสำหรับการโต้ตอบที่ตามมา

ดังนั้นควรใช้ interactionId แทน navigationId เพื่อแมปรายการ interaction-contentful-paint กับ soft-navigation-entries เพื่อให้ได้ URL ที่ถูกต้อง ซึ่งจะจัดการรายการที่มี navigationId เก่า รวมถึงกรองรายการ interaction-contentful-paint ที่ไม่ควรนำมาพิจารณาสำหรับ LCP

นอกจากนี้ คุณควรพิจารณาประมวลผลฟังก์ชัน getLargestInteractionContentfulPaint() ของรายการ soft-navigation ด้วย เพื่อจัดการรายการ interaction-contentful-paint ที่เกิดขึ้นก่อนที่จะมีการปล่อย soft-navigation entries ได้ง่ายขึ้น

การรับ startTime ของการนำทางแบบนุ่มนวล

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

คุณสามารถรับเวลาเริ่มต้นการนำทางได้ในลักษณะเดียวกันโดยการแมปกับรายการ soft-navigation ที่เหมาะสมและใช้ startTime ของรายการนั้น

startTime คือเวลาของการโต้ตอบครั้งแรก (เช่น การคลิกปุ่ม) ที่เริ่มการนำทางแบบนุ่มนวล ซึ่งแตกต่างจาก "การนำทางแบบฮาร์ด" เล็กน้อย ซึ่ง "เวลาเริ่มต้น" คือเวลาที่เบราว์เซอร์ "คอมมิต" หน้าใหม่ และหลังจากที่โค้ดตัวแฮนเดิลเหตุการณ์บางส่วนทํางาน เวลาเริ่มต้นการนำทางแบบนุ่มยังรวมถึงโค้ดตัวแฮนเดิลเหตุการณ์ด้วย เนื่องจากเราวัดจากเวลาเริ่มต้นของการโต้ตอบ

วัด Core Web Vitals ต่อการนำทางแบบนุ่มนวล

หากต้องการวัด Core Web Vitals ให้ฟังรายการ soft-navigation และรีเซ็ตเมตริกเมื่อได้รับรายการเหล่านี้ FCP จะแสดงตาม presentationTime และ LCP จะเริ่มต้นเป็นรายการ getLargestInteractionContentfulPaint() ควรเริ่มต้น INP, CLS เป็น 0 เหมือนกับการโหลดหน้าเว็บ

จากนั้นจะวัดและตรวจสอบ LCP, INP และ CLS ได้ตามปกติ (ยกเว้นการใช้ interaction-contentful-paint สำหรับ LCP ที่ให้ interactionId ตรงกัน) คุณใช้ interactionId เพื่อตั้งชื่อรายการไปยัง URL ได้ตามที่กล่าวถึงก่อนหน้านี้

ระบบจะยังคงแสดงระยะเวลาที่สัมพันธ์กับเวลาเริ่มต้นการนำทาง "จริง" เดิม ดังนั้นหากต้องการคำนวณ LCP สำหรับการนำทางแบบนุ่มนวล ตัวอย่างเช่น คุณจะต้องใช้interaction-contentful-paintช่วงเวลาและลบเวลาเริ่มต้นการนำทางแบบนุ่มนวลที่เหมาะสมตามที่อธิบายไว้ก่อนหน้านี้เพื่อให้ได้ช่วงเวลาที่สัมพันธ์กับการนำทางแบบนุ่มนวล

โดยปกติแล้ว เมตริกบางอย่างจะวัดตลอดอายุของหน้าเว็บ เช่น LCP อาจเปลี่ยนแปลงได้จนกว่าจะมีการโต้ตอบ คุณอัปเดต CLS และ INP ได้จนกว่าจะออกจากหน้าเว็บ ไม่ว่าจะมีปฏิสัมพันธ์ใดๆ ก็ตาม ดังนั้น คุณควรสรุปเมตริกของการนําทางก่อนหน้าเมื่อเกิดการนําทางแบบ Soft ใหม่แต่ละครั้ง ซึ่งหมายความว่าเมตริกการนำทาง "แบบเต็ม" เริ่มต้นอาจเสร็จสมบูรณ์เร็วกว่าปกติเมื่อวัด Core Web Vitals ด้วยการนำทางแบบย่อย

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

ควรจัดการกับเนื้อหาที่ยังคงเหมือนเดิมระหว่างการไปยังส่วนต่างๆ อย่างไร

LCP สำหรับการนำทางแบบนุ่ม (คำนวณจาก interaction-contentful-paint) จะวัดเฉพาะการแสดงผลใหม่ และเฉพาะการแสดงผลที่เชื่อมโยงกับการโต้ตอบที่ทำให้เกิดการนำทาง ซึ่งอาจส่งผลให้ LCP แตกต่างกัน เช่น จาก Cold Load ของการนำทางแบบนุ่มนั้นเป็นการโหลดแบบนุ่ม

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

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

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

วิธีวัด TTFB

เวลาที่ได้รับข้อมูลไบต์แรก (TTFB) สำหรับการโหลดหน้าเว็บแบบเดิมแสดงถึงเวลาที่ระบบส่งไบต์แรกของคำขอเดิมกลับมา

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

วิธีที่ง่ายกว่าคือการรายงาน TTFB เป็น 0 สำหรับการนำทางแบบ Soft ซึ่งคล้ายกับที่เราแนะนำสำหรับการกู้คืน Back-Forward Cache นี่คือวิธีที่ไลบรารี web-vitals ใช้สำหรับการนำทางแบบนุ่มนวล และเป็นวิธีที่เราแนะนำสำหรับเมตริกนี้ในขณะนี้

คุณควรวัด Core Web Vitals ด้วยทั้ง 2 วิธีการไหม

แม้ว่า API ใหม่เหล่านี้จะจำกัดเฉพาะเบราว์เซอร์ที่ใช้ Chromium แต่เว็บไซต์อาจต้องการวัดทั้ง 2 อย่างโดยการแบ่งตามการนำทางแบบนุ่มนวล และแบ่งตามการนำทางแบบฮาร์ดต่อไป ซึ่งจะช่วยให้เปรียบเทียบในเบราว์เซอร์ต่างๆ และแนวโน้มในอดีตได้

สำหรับ LCP การพิจารณาจึงหมายถึงการพิจารณาเฉพาะรายการ largest-contentful-paint สำหรับวิธีปัจจุบัน และทั้งรายการ largest-contentful-paint และ interaction-contentful-paint สำหรับวิธีใหม่

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

จากนั้นจะต้องส่งสัญญาณและจัดเก็บเมตริก 2 ครั้งเพื่อการวิเคราะห์

ใช้web-vitalsเพื่อวัด Core Web Vitals สำหรับการนำทางแบบนุ่มนวล

วิธีที่ง่ายที่สุดในการพิจารณาลักษณะเฉพาะทั้งหมดคือการใช้ไลบรารี JavaScript ของ web-vitals ซึ่งมีการรองรับการนำทางแบบนุ่มในเวอร์ชันทดลองในsoft-navs branch แยกต่างหาก (ซึ่งมีให้บริการใน npm และ unpkg ด้วย) คุณวัดผลได้ด้วยวิธีต่อไปนี้ (แทนที่ doTraditionalProcessing และ doSoftNavProcessing ตามความเหมาะสม)

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

web-vitals ไลบรารียังช่วยให้มั่นใจได้ว่าคุณจะรายงานเมตริกเทียบกับ URL ที่ถูกต้อง ตามที่ระบุไว้ก่อนหน้านี้ เนื่องจากมีทั้ง navigationId และ navigationURL ในรายการที่ระบุในการเรียกกลับ

web-vitals ไลบรารีจะรายงานเมตริกต่อไปนี้สำหรับการนำทางแบบนุ่มนวล

การเปลี่ยนแปลงเหล่านี้จะกลายเป็นส่วนหนึ่งของการวัด Core Web Vitals ไหม

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

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

การนำทางแบบนุ่มจะรายงานใน CrUX อย่างไร

นอกจากนี้ เรายังต้องพิจารณาด้วยว่าการนำทางแบบนุ่มจะได้รับการรายงานใน CrUX อย่างไรเมื่อเปิดตัวฟีเจอร์นี้ เราจะประกาศการเปลี่ยนแปลงของ CrUX เมื่อมีข้อมูลเพิ่มเติมที่จะแชร์ที่นี่

ความคิดเห็น

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

• ควรแสดงความคิดเห็นเกี่ยวกับ API เป็นปัญหาใน GitHub
• หากพบข้อบกพร่องในการติดตั้งใช้งาน Chromium คุณควรแจ้งในเครื่องมือติดตามปัญหาของ Chrome หากปัญหานี้ยังไม่ใช่ปัญหาที่ทราบ
• คุณแชร์ความคิดเห็นทั่วไปเกี่ยวกับ Web Vitals ได้ที่ web-vitals-feedback@googlegroups.com

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

บันทึกการเปลี่ยนแปลง

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

บทสรุป

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

การรับทราบ

ภาพขนาดย่อโดย Jordan Madrid ใน Unsplash

งานนี้เป็นการต่อยอดจากงานที่Yoav Weiss เริ่มทำไว้เมื่อครั้งที่ยังทำงานอยู่ที่ Google ขอขอบคุณ Yoav ที่ทุ่มเทให้กับการพัฒนา API นี้