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

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 ตามที่ได้มาจากเหตุการณ์ soft-navigation PerformanceTiming
• ระบบจะรีเซ็ตเมตริก 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 หรือไม่ เราตื่นเต้นมากกับโอกาสในการทดสอบนี้ แต่ไม่สามารถรับประกันได้ว่าการทดสอบนี้จะเข้ามาแทนที่การวัดผลปัจจุบันหรือไม่และเมื่อใด

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