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

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 เปลี่ยนแปลง

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

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) และ การโต้ตอบกับการแสดงผลถัดไป (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 แต่สามารถทำการทดสอบได้โดยการเปิดใช้ฟีเจอร์นี้อย่างชัดเจน

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

ฉันจะวัดการนําทางแบบเบาได้อย่างไร

เมื่อเปิดใช้การทดสอบการนําทางแบบเบาแล้ว เมตริกจะรายงานโดยใช้ 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});

ต้องใช้ Flag 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 จะอัปเดตได้จนกว่าผู้ใช้จะออกจากหน้าเว็บ ดังนั้น "การนำทาง" แต่ละรายการ (รวมถึงการนำทางเดิม) อาจต้องทำให้เมตริกของหน้าก่อนหน้าเสร็จสมบูรณ์เมื่อการนำทางแบบชั่วคราวแต่ละรายการเกิดขึ้นใหม่ ซึ่งหมายความว่าเมตริกการนําทาง "แบบเจาะจง" เริ่มต้นอาจเสร็จสมบูรณ์เร็วกว่าปกติ

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

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

FP, FCP และ LCP สําหรับการนําทางแบบนุ่มจะวัดเฉพาะหน้าเว็บใหม่เท่านั้น ซึ่งอาจส่งผลให้ LCP แตกต่างกัน เช่น จาก Cold Load ของ Soft Navigation นั้นเป็นการโหลดแบบ Soft

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

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

วิธีวัด TTFB

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

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

วิธีง่ายกว่านั้นคือการรายงาน TTFB เป็น 0 สําหรับการนําทางแบบ Soft ซึ่งคล้ายกับที่เราแนะนําสําหรับการกู้คืนแคชย้อนกลับ/ไปข้างหน้า นี่เป็นวิธีที่ไลบรารี 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 ไหม

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

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

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

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

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

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

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

ความคิดเห็น

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

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

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

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

บทสรุป

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

กิตติกรรมประกาศ

ภาพปกโดย Jordan Madrid ใน Unsplash