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

Barry Pollard

Michal Mocny

เผยแพร่: 1 กุมภาพันธ์ 2023, อัปเดตล่าสุด: 2 กันยายน 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) แบบเดิม

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

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

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

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

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

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

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

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 เวอร์ชันก่อน 151 โปรดทราบว่าผู้ใช้บางรายอาจไม่รายงานเมตริกที่อิงตามการนำทางแบบนุ่ม แม้ว่าจะรายงานเมตริก Core Web Vitals ก็ตาม

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

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

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

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

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

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

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

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

ตัวอย่างเช่น พิจารณาหน้าเว็บที่มีรูปภาพแบนเนอร์ขนาดใหญ่ซึ่งเป็นองค์ประกอบ 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 ซึ่งรองรับการนำทางแบบย่อยตั้งแต่ v6.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 ในรายการที่ระบุไว้ในการเรียกกลับ

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

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

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

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

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

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

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

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

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

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

ความคิดเห็น

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

• ควรแจ้งความคิดเห็นเกี่ยวกับ API เป็นปัญหาใน GitHub
• หากพบข้อบกพร่องในการติดตั้งใช้งาน Chromium คุณควรแจ้งในเครื่องมือติดตามปัญหาของ 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 นี้