นับตั้งแต่เปิดตัว โครงการริเริ่ม 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
จะรายงานเมตริกต่อไปนี้สำหรับการนำทางชั่วคราว
เมตริก | รายละเอียด |
---|---|
TTFB | รายงานเป็น 0 |
FCP | ปัจจุบันไลบรารี web-vitals จะรายงานเฉพาะ FCP แรกของหน้าเว็บเท่านั้น |
LCP | เวลาของ Contentful Paint ที่ใหญ่เป็นอันดับถัดไป เมื่อเทียบกับเวลาเริ่มต้นของการไปยังส่วนต่างๆ แบบนุ่มนวล ไม่พิจารณาสีที่มีจากการนำทางก่อนหน้า ดังนั้น LCP จะเท่ากับ >= 0 เช่นเคย ระบบจะรายงานจำนวนนี้เมื่อมีการโต้ตอบหรือเมื่อหน้าเว็บอยู่ในเบื้องหลัง เนื่องจาก LCP จะสรุปได้หลังจากนั้นเท่านั้น |
CLS | กรอบเวลาที่มากที่สุดของการเปลี่ยนแปลงระหว่างเวลาการนำทาง ตามปกติ ปัญหานี้จะเกิดขึ้นเมื่อหน้าเว็บอยู่ในพื้นหลังเท่านั้นที่สามารถสรุป CLS ได้ ระบบจะรายงานค่า 0 หากไม่มีการเปลี่ยนแปลง |
INP | INP ระหว่างเวลาการนำทาง ตามปกติจะมีการรายงานเรื่องนี้เมื่อมีการโต้ตอบ หรือเมื่อหน้าเว็บอยู่ในเบื้องหลังเพียงแค่นี้จะสามารถสรุป INP ได้ ระบบจะไม่รายงานค่า 0 หากไม่มีการโต้ตอบ |
การเปลี่ยนแปลงเหล่านี้จะกลายเป็นส่วนหนึ่งของการวัดผล 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