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

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

จำเป็นต้องมีแฟล็ก 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 สำหรับการนำทางชั่วคราว ในลักษณะเดียวกันกับที่เราแนะนำสำหรับการกู้คืนแคชย้อนหลัง นี่เป็นวิธีที่ไลบรารี 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 หรือไม่

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

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

ระบบจะรายงานการนำทางชั่วคราวใน CrUX อย่างไร

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

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

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

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

ความคิดเห็น

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

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

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

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

บทสรุป

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

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

ภาพขนาดย่อโดย Jordan Madrid ในหัวข้อ Unsplash