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

Barry Pollard

Yoav Weiss

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

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

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

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

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

เราได้ให้คําจํากัดความของการไปยังส่วนต่างๆ แบบนุ่มนวลดังต่อไปนี้

• การนำทางเริ่มต้นขึ้นจากการดำเนินการของผู้ใช้
• การนำทางจะส่งผลให้เกิดการเปลี่ยนแปลง URL ที่แสดงต่อผู้ใช้และการเปลี่ยนแปลงประวัติ
• การนำทางส่งผลให้เกิดการเปลี่ยนแปลง DOM

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

Chrome ปรับใช้การนำทางแบบนุ่มนวลอย่างไร

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

• เหตุการณ์ soft-navigation PerformanceTiming จะออกหลังจากตรวจพบการไปยังส่วนต่างๆ แบบนุ่มนวล
• Performance API จะให้สิทธิ์เข้าถึงรายการช่วงเวลาของ soft-navigation ตามที่ได้จากเหตุการณ์ PerformanceTiming ของ soft-navigation
• ระบบจะรีเซ็ตเมตริก First Paint (FP), First Contentful Paint (FCP), Largest Contentful Paint (LCP) แล้วแสดงเมตริกเหล่านี้อีกครั้งเมื่อมีการตรวจพบการเข้าชมเหล่านี้ (หมายเหตุ: ยังไม่ได้ใช้ FP และ FCP)
• ระบบจะเพิ่มแอตทริบิวต์ navigationId ลงในช่วงเวลาประสิทธิภาพแต่ละช่วง (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event และ layout-shift) ที่สอดคล้องกับรายการการนำทางที่เกี่ยวข้องกับเหตุการณ์ ทำให้สามารถคำนวณ Cumulative Layout Shift (CLS) และ การโต้ตอบกับ Next Paint (INP)

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

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

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

• ระบบอาจส่งเหตุการณ์ FP, FCP และ LCP เพิ่มเติมอีกครั้งสำหรับการนำทางชั่วคราว รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) จะไม่สนใจค่าเพิ่มเติมเหล่านี้ แต่อาจส่งผลต่อการตรวจสอบการวัดผู้ใช้จริง (RUM) ในเว็บไซต์ โปรดสอบถามผู้ให้บริการ RUM ของคุณหากมีข้อกังวลว่าการดำเนินการนี้จะส่งผลต่อการวัดผลเหล่านั้นหรือไม่ ดูส่วนการวัด Core Web Vitals สำหรับการไปยังส่วนต่างๆ แบบนุ่มนวล
• คุณอาจต้องพิจารณาแอตทริบิวต์ navigationID ใหม่ (ไม่บังคับ) ในรายการประสิทธิภาพในโค้ดของแอปพลิเคชันโดยใช้รายการเหล่านี้
• เฉพาะเบราว์เซอร์แบบ Chromium เท่านั้นที่รองรับโหมดใหม่นี้ แม้ว่าเมตริกที่ใหม่กว่าจำนวนมากจะพร้อมใช้งานในเบราว์เซอร์แบบ Chromium เท่านั้น แต่บางเมตริก (FCP, LCP) ก็อาจใช้ได้ในเบราว์เซอร์อื่นๆ และอาจมีบางคนที่ยังไม่ได้อัปเกรดเป็นเบราว์เซอร์แบบ Chromium เวอร์ชันล่าสุด ดังนั้นโปรดทราบว่าผู้ใช้บางรายอาจไม่รายงานเมตริกการนําทางแบบซอฟต์
• เนื่องจากเป็นฟีเจอร์ใหม่เวอร์ชันทดลองที่ไม่ได้เปิดใช้โดยค่าเริ่มต้น เว็บไซต์ควรทดสอบฟีเจอร์นี้เพื่อให้มั่นใจว่าไม่มีผลข้างเคียงอื่นๆ ที่ไม่ตั้งใจ

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

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

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

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

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

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

ฉันจะวัดการไปยังส่วนต่างๆ แบบนุ่มนวลได้อย่างไร

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

รายงานการนำทางที่เลือก

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

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

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

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

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

ใช้แอตทริบิวต์ navigationId ของ PerformanceEntry ที่เหมาะสมเพื่อเชื่อมโยงเหตุการณ์กลับไปยัง 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;

ควรใช้ pageUrl นี้เพื่อรายงานเมตริกกับ URL ที่ถูกต้อง แทนที่จะเป็น URL ปัจจุบันที่เคยใช้ในอดีต

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

คุณสามารถดูเวลาเริ่มต้นของการไปยังส่วนต่างๆ ได้ในลักษณะเดียวกัน ดังนี้

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

startTime คือเวลาที่เกิดการโต้ตอบครั้งแรก (เช่น การคลิกปุ่ม) ที่เริ่มต้นการนําทางแบบนุ่มนวล

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

วัด Core Web Vitals ต่อการไปยังส่วนต่างๆ แบบนุ่มนวล

หากต้องการรวมรายการเมตริกการไปยังส่วนต่างๆ แบบซอฟต์ คุณต้องใส่ includeSoftNavigationObservations: true ในการเรียก observe ของผู้สังเกตการณ์ประสิทธิภาพ

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

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

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

ควรดำเนินการกับเนื้อหาที่ยังคงเหมือนเดิมระหว่างการนำทางอย่างไร

FP, FCP และ LCP สำหรับการนำทางชั่วคราวจะวัดสีใหม่เท่านั้น ซึ่งอาจส่งผลให้มี LCP ที่ต่างออกไป เช่น จาก Cold Load ของการนำทางแบบนุ่มนวลนั้นไปจนถึงซอฟต์โหลด

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

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

วิธีวัด TTFB

Time to First Byte (TTFB) สำหรับการโหลดหน้าเว็บตามปกติ จะแสดงเวลาที่มีการส่งคืนไบต์แรกของคำขอเดิม

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

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

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

วิธีวัดผลทั้งแบบเก่าและใหม่

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

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

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

ใช้ไลบรารี 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';

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});

ตรวจสอบว่ารายงานเมตริกกับ URL ที่ถูกต้องตามที่ระบุไว้ก่อนหน้านี้

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

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

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

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

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

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

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

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

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

ความคิดเห็น

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

• วิธีการแบบซอฟต์การนำทางและการกำหนดมาตรฐาน
• ปัญหาการใช้งาน Chrome ของวิธีการเหล่านั้น
• แสดงความคิดเห็นทั่วไปเกี่ยวกับ Web Vitals ได้ที่ web-vitals-feedback@googlegrouops.com

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

เนื่องจาก API นี้อยู่ระหว่างการทดสอบ มีการเปลี่ยนแปลงหลายอย่างเกิดขึ้นมากกว่า API ที่เสถียร โปรดดูรายละเอียดเพิ่มเติมใน Soft Navigation Heuristics Changelog

บทสรุป

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

ข้อความแสดงการยอมรับ

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