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

Barry Pollard

Michal Mocny

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

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

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

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

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

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

การนําทางแบบซอฟต์คืออะไร

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

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

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

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

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

Chrome ใช้การนําทางแบบซอฟต์สําหรับนักพัฒนาเว็บอย่างไร

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

• ระบบจะส่งเหตุการณ์ soft-navigation PerformanceTiming หลังจากตรวจพบการนําทางแบบซอฟต์แต่ละครั้ง
• รายการ soft-navigation นี้จะมี navigationId, URL ใหม่ในแอตทริบิวต์ name และ interactionId ของการโต้ตอบที่เริ่มต้น
• ระบบจะแสดงรายการ interaction-contentful-paint อย่างน้อย 1 รายการหลังจากการโต้ตอบที่ทำให้เกิด Contentful Paint ซึ่งจะมีรายการ 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 เวอร์ชันก่อน 151 โปรดทราบว่าผู้ใช้บางรายอาจไม่รายงานเมตริกที่อิงตามการนําทางแบบซอฟต์ แม้ว่าจะรายงานเมตริก Core Web Vitals ก็ตาม

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

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

ฉันจะเปิดใช้การนําทางแบบซอฟต์ใน Chrome ได้อย่างไร

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

การตรวจหาฟีเจอร์ที่รองรับ Soft Navigations API

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

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

หรืออีกวิธีหนึ่งคือ

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 สำหรับการนำทางแบบซอฟต์ เราต้องการพิจารณาเฉพาะการแสดงผลสำหรับการโหลดการนําทางแบบ Soft สำหรับ 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 จะรายงานเป็นเวลาจากเวลาในการนำทางหน้าเว็บแบบ "ฮาร์ด" เริ่มต้น ดังนั้น คุณควรลบเวลาเริ่มต้นการนำทางแบบนุ่มนวลออกจากเวลาเมตริกการโหลดการนำทางแบบนุ่มนวล (เช่น LCP) เพื่อรายงานเวลาดังกล่าวโดยสัมพันธ์กับเวลาการนำทางแบบนุ่มนวลนี้แทน

เวลาเริ่มต้นการนำทางสามารถรับได้ในลักษณะที่คล้ายกันโดยการแมปกับรายการ 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 สามารถอัปเดตได้จนกว่าจะมีการออกจากหน้าเว็บ ไม่ว่าจะมีการโต้ตอบใดๆ หรือไม่ก็ตาม ดังนั้น เมตริกของการนําทางก่อนหน้าควรได้รับการสรุปเมื่อมีการนําทางแบบซอฟต์ใหม่แต่ละครั้ง ซึ่งหมายความว่าเมตริกการนําทาง "แบบฮาร์ด" เริ่มต้นอาจสรุปได้เร็วกว่าปกติเมื่อวัด Core Web Vitals ด้วยการนําทางแบบซอฟต์

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

How should content that remains the same between navigations be treated?

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

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

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

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

วิธีวัด TTFB

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

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

วิธีที่ง่ายกว่าคือการรายงาน TTFB เป็น 0 สำหรับการนำทางแบบซอฟต์ ซึ่งคล้ายกับที่เราแนะนำสำหรับการกู้คืน 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 ซึ่งรองรับการนําทางแบบซอฟต์ตั้งแต่เวอร์ชัน 6.0.0 ซึ่งวัดได้ด้วยวิธีต่อไปนี้ (แทนที่ 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 ในรายการที่ระบุไว้ใน Callback

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

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

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

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

เราได้เปิดตัวเมตริก Core Web Vitals เวอร์ชันทดลองใน CrUX แล้ว ซึ่งจะสิ้นสุด CLS และ INP ของ "การนําทางแบบฮาร์ด" หลังจากการนําทางแบบซอฟต์ครั้งแรก และยังรวมการวัด LCP, CLS และ INP เพิ่มเติมสําหรับการนําทางแบบซอฟต์แต่ละครั้งด้วย เราวางแผนที่จะเปลี่ยนเมตริกทดลองเหล่านี้เป็นเมตริกที่เสถียรในเดือนพฤษภาคม 2027 ดูข้อมูลเพิ่มเติมได้ที่บล็อกโพสต์เมตริกการนําทางแบบซอฟต์เวอร์ชันทดลองเผยแพร่แล้วใน CrUX

วิธีจัดการการนําทางแบบซอฟต์ในเบราว์เซอร์อื่นๆ

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

คุณสามารถใช้ Navigation API เพื่อตรวจสอบการเปลี่ยนแปลง URL ซึ่งอาจช่วยให้แบ่ง INP ตาม URL ได้ (และ CLS ในลักษณะเดียวกัน แม้ว่าตอนนี้จะใช้ได้เฉพาะ Chromium เท่านั้น จึงไม่สามารถวัดได้) อย่างไรก็ตาม วิธีนี้ไม่ได้ระบุเมตริกการแสดงผล (FCP และ LCP) ซึ่งประมาณค่าได้เท่านั้น

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

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

ความคิดเห็น

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

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

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

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

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

บทสรุป

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

การรับทราบ

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

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