การทดสอบการวัดการนำทางที่นุ่มนวล

Barry Pollard

Michal Mocny

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ระบบจะปล่อยเหตุการณ์ soft-navigation PerformanceTiming หลังจากตรวจพบการนำทางแบบนุ่มแต่ละครั้ง
• รายการ soft-navigation นี้จะมี navigationId, URL ใหม่ในแอตทริบิวต์ name รวมถึง interactionId ของการโต้ตอบที่เริ่มต้น
• ระบบจะปล่อยรายการ interaction-contentful-paint อย่างน้อย 1 รายการหลังจากการโต้ตอบที่ทำให้เกิดการแสดงผลเนื้อหา ซึ่งใช้เพื่อวัด 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 จะมีรายการ largestInteractionContentfulPaint ซึ่งรวมถึงรายการ interaction-contentful-paint ที่ใหญ่ที่สุดซึ่งปล่อยออกมาเป็นส่วนหนึ่งของการนำทาง จากนั้นจะใช้เป็น LCP เริ่มต้นสำหรับการนำทางนั้นได้ และ LCP นั้นจะอัปเดตได้เมื่อพบinteraction-contentful-paintรายการเพิ่มเติมสำหรับการโต้ตอบนั้น
• รายการ interaction-contentful-paint บางรายการอาจเกิดขึ้นก่อนการนำทางแบบนุ่ม (หากการอัปเดต URL ไม่เกิดขึ้นจนกว่าจะมีการแสดงผลเหล่านั้น) ในกรณีเหล่านี้ largestInteractionContentfulPaintรายการที่ใหญ่ที่สุดจะช่วยให้ไม่ต้องบัฟเฟอร์และย้อนกลับไปดูรายการเก่า โปรดทราบว่า largestInteractionContentfulPaint เป็นสำเนาที่ตรงกันของรายการ interaction-contentful-paint ที่ใหญ่ที่สุด ดังนั้นรายการดังกล่าวจะใช้ navigationId ก่อนหน้าเนื่องจากเป็นเวลาที่เกิดการแสดงผล แต่ควรวัดการแสดงผลเหล่านี้เทียบกับ navigationId ใหม่
• รายการ soft-navigation จะมี paintTime และ presentationTime เป็น FCP สำหรับการนำทางนั้นด้วย
• โปรดทราบว่าระบบจะปล่อยรายการ interaction-contentful-paint หลังจากมีการโต้ตอบเพิ่มเติมด้วย แต่ควรจำกัด LCP สำหรับ URL ไว้ที่รายการ interaction-contentful-paint ที่ตรงกับการนำทางแบบย่อย interactionId เพื่อยกเว้นรายการเหล่านี้

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

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

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

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

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

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

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

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

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

สำหรับเว็บไซต์ที่ต้องการเปิดใช้ฟีเจอร์นี้เพื่อให้ผู้เข้าชมทั้งหมดเห็นผลกระทบ จะมีช่วงทดลองใช้จากต้นทางที่ทำงานตั้งแต่ Chrome 147 ซึ่งเปิดใช้ได้โดยลงชื่อสมัครเข้าร่วมช่วงทดลองใช้และรวมองค์ประกอบเมตาที่มีโทเค็นช่วงทดลองใช้จากต้นทางใน HTML หรือส่วนหัว HTTP ดูข้อมูลเพิ่มเติมได้ที่โพสต์เริ่มต้นใช้งาน Origin Trials

เจ้าของเว็บไซต์สามารถเลือกที่จะรวมช่วงทดลองใช้จากต้นทางในหน้าเว็บสำหรับผู้ใช้ทั้งหมดหรือเฉพาะกลุ่มย่อยของผู้ใช้ก็ได้ โปรดทราบส่วนผลกระทบก่อนหน้าเกี่ยวกับวิธีที่การเปลี่ยนแปลงนี้อาจส่งผลต่อการรายงานตัวชี้วัด โดยเฉพาะอย่างยิ่งหากเปิดใช้ช่วงทดลองใช้จากต้นทางนี้สำหรับผู้ใช้จำนวนมาก โปรดทราบว่า CrUX จะยังคงรายงานเมตริกในลักษณะเดิมโดยไม่คำนึงถึงการตั้งค่าการนำทางแบบนุ่มนวลนี้ จึงไม่ได้รับผลกระทบจากผลกระทบเหล่านั้น นอกจากนี้ โปรดทราบว่าการทดลองใช้ต้นทางยังจำกัดการเปิดใช้ฟีเจอร์ทดลองในหน้าเว็บ Chrome ทั้งหมดไม่เกิน 0.5% โดยเฉลี่ยในช่วง 14 วัน แต่ปัญหานี้ควรเกิดขึ้นกับเว็บไซต์ขนาดใหญ่มากเท่านั้น

การรองรับ 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 เดียวกันหลายครั้งตลอดอายุการใช้งานของแอปพลิเคชันหน้าเว็บเดียว) คุณค้นหาได้โดยใช้ PerformanceEntry API

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

รายงาน 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

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

ทำความเข้าใจstartTimeของการนำทางแบบนุ่มนวล

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

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

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

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

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

จากนั้นจะวัดและตรวจสอบ LCP, INP และ CLS ได้ตามปกติ (ยกเว้นการใช้ interaction-contentful-paint สำหรับ LCP ที่ให้ interactionId ตรงกัน) คุณใช้ interactionId และ navigationId เพื่อตั้งชื่อรายการไปยัง 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 วิธีการไหม

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

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

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

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

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

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

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

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

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

ดังนั้น เราอาจตัดสินใจที่จะรายงานการนำทางแบบย่อยเหล่านี้แยกกันใน CrUX หรืออาจให้น้ำหนักเมื่อคำนวณ Core Web Vitals สำหรับหน้าเว็บหรือกลุ่มหน้าเว็บที่กำหนด นอกจากนี้ เรายังอาจยกเว้นการนำทางแบบนุ่มนวลที่โหลดบางส่วนทั้งหมดได้ด้วยเมื่อฮิวริสติกมีการพัฒนา

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

ความคิดเห็น

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

• ควรแสดงความคิดเห็นเกี่ยวกับ 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 นี้