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

Barry Pollard

Michal Mocny

เผยแพร่: 1 กุมภาพันธ์ 2023, อัปเดตล่าสุด: 22 กรกฎาคม 2025

นับตั้งแต่เปิดตัว 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) แบบเดิม

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

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

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

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

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

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

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

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

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

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

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

• คุณอาจแบ่งเมตริก CLS และ INP ตาม URL การนำทางแบบนุ่ม แทนที่จะวัดตลอดระยะเวลาของวงจรหน้าเว็บทั้งหมด
• รายการ largest-contentul-paint ได้รับการสรุปแล้วในการโต้ตอบ จึงใช้เพื่อวัด LCP ของการนำทาง "แบบฮาร์ด" ครั้งแรกเท่านั้น จึงไม่จำเป็นต้องมีตรรกะเพิ่มเติมเพื่อเปลี่ยนวิธีวัด
• interaction-contentful-paint ใหม่จะปล่อยออกมาจากการโต้ตอบ ซึ่งอาจใช้เพื่อวัด LCP สำหรับการนำทางแบบนุ่มนวลได้
• หากต้องการระบุแหล่งที่มาของการนำทางแบบนุ่มไปยัง URL ที่ถูกต้อง คุณอาจต้องพิจารณาแอตทริบิวต์ navigationID ใหม่ในรายการประสิทธิภาพในโค้ดแอปพลิเคชันโดยใช้รายการเหล่านี้
• ผู้ใช้บางรายอาจไม่รองรับ Soft Navigation API นี้ โดยเฉพาะผู้ที่ใช้ Chrome เวอร์ชันเก่าและผู้ที่ใช้เบราว์เซอร์อื่นๆ โปรดทราบว่าผู้ใช้บางรายอาจไม่รายงานเมตริกการนำทางแบบนุ่ม แม้ว่าจะรายงานเมตริก Core Web Vitals ก็ตาม
• เนื่องจากเป็นฟีเจอร์ใหม่ที่เปิดให้ทดลองใช้และไม่ได้เปิดใช้โดยค่าเริ่มต้น เว็บไซต์จึงควรทดสอบฟีเจอร์นี้เพื่อดูผลข้างเคียงที่ไม่คาดคิด

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

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

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

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

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

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

เจ้าของเว็บไซต์สามารถเลือกที่จะรวมช่วงทดลองใช้แหล่งที่มาในหน้าเว็บของตนสำหรับผู้ใช้ทั้งหมดหรือเฉพาะกลุ่มย่อยของผู้ใช้ก็ได้ โปรดทราบส่วนผลกระทบก่อนหน้าเกี่ยวกับวิธีที่การเปลี่ยนแปลงนี้อาจส่งผลต่อการรายงานเมตริก โดยเฉพาะอย่างยิ่งหากเปิดใช้ Origin Trial นี้สำหรับผู้ใช้จำนวนมาก โปรดทราบว่า CrUX จะยังคงรายงานเมตริกในลักษณะเดิมโดยไม่คำนึงถึงการตั้งค่าการนำทางแบบนุ่มนี้ จึงไม่ได้รับผลกระทบจากผลกระทบเหล่านั้น นอกจากนี้ โปรดทราบว่าการทดลองใช้ต้นทางยังจำกัดการเปิดใช้ฟีเจอร์ทดลองในหน้าเว็บ Chrome ทั้งหมดไม่เกิน 0.5% โดยเฉลี่ยในช่วง 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});

การเปลี่ยนแปลงล่าสุดใน API ทำให้ไม่จำเป็นต้องใช้ฟีเจอร์แฟล็ก includeSoftNavigationObservations อีกต่อไป และมีแนวโน้มว่าจะนำออกในอนาคต แต่ในตอนนี้ คุณจะต้องเลือกใช้ที่ระดับ Performance Observer อย่างชัดเจน นอกเหนือจากการเปิดใช้ฟีเจอร์การนำทางแบบนุ่มนวลใน Chrome

ระบบจะยังคงแสดงเวลาที่สัมพันธ์กับเวลาเริ่มต้นการนำทาง "แบบตายตัว" เดิม ดังนั้น หากต้องการคำนวณ LCP สำหรับการนำทางแบบนุ่ม ตัวอย่างเช่น คุณจะต้องใช้interaction-contentful-paintเวลาและลบเวลาเริ่มต้นการนำทางแบบนุ่มที่เหมาะสมตามที่อธิบายไว้ก่อนหน้านี้เพื่อให้ได้เวลาที่สัมพันธ์กับการนำทางแบบนุ่ม เช่น สำหรับ 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

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

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

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

วิธีวัด TTFB

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

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

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

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

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

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

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

สำหรับ LCP นั่นหมายถึงการพิจารณาเฉพาะรายการ largest-contentful-paint สำหรับวิธีเก่า และทั้งรายการ largest-contentful-paint และ interaction-contentful-paint สำหรับวิธีใหม่

สําหรับ CLS และ INP หมายถึงการวัดค่าเหล่านี้ตลอดวงจรหน้าเว็บทั้งหมดเช่นเดียวกับวิธีเก่า และการแบ่งไทม์ไลน์ตามการนำทางแบบนุ่มแยกกันเพื่อวัดค่า CLS และ INP แยกกันสําหรับวิธีใหม่

ใช้ไลบรารี 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 สำหรับหน้าเว็บหรือกลุ่มหน้าเว็บที่กำหนด นอกจากนี้ เรายังอาจยกเว้นการนำทางแบบนุ่มนวลที่โหลดบางส่วนทั้งหมดได้ด้วยเมื่อฮิวริสติกมีการพัฒนา

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

ความคิดเห็น

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

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

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

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

บทสรุป

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

การรับทราบ

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

งานนี้เป็นผลสืบเนื่องจากงานที่Yoav Weiss เริ่มทำเป็นครั้งแรกเมื่ออยู่ที่ Google ขอขอบคุณ Yoav ที่ทุ่มเทให้กับการพัฒนา API นี้