เรียนรู้วิธีระบุแหล่งที่มาของข้อมูลประสิทธิภาพด้วยข้อมูลการแก้ไขข้อบกพร่อง เพื่อช่วยให้คุณระบุและแก้ไขปัญหาของผู้ใช้จริงด้วย Analytics
Google มีเครื่องมือ 2 หมวดหมู่สำหรับใช้วัดและแก้ไขข้อบกพร่องของประสิทธิภาพ ดังนี้
- เครื่องมือ Lab: เครื่องมืออย่าง Lighthouse ซึ่งโหลดหน้าเว็บในสภาพแวดล้อมจำลองที่สามารถเลียนแบบเงื่อนไขต่างๆ (เช่น เครือข่ายที่ทำงานช้าและอุปกรณ์เคลื่อนที่ระดับล่าง)
- เครื่องมือภาคสนาม: เครื่องมือต่างๆ เช่น รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งอิงตามข้อมูลรวมจากผู้ใช้จริงจาก Chrome (โปรดทราบว่าข้อมูลในช่องที่เครื่องมืออย่างเช่น PageSpeed Insights และ Search Console มาจากข้อมูล CrUX)
ขณะที่เครื่องมือภาคสนามจะให้ข้อมูลที่แม่นยำยิ่งขึ้น ซึ่งเป็นข้อมูลที่แสดงถึงประสบการณ์จริงของผู้ใช้ แต่เครื่องมือห้องทดลองมักจะช่วยให้คุณระบุและแก้ปัญหาได้ดีกว่า
ข้อมูล CrUX แสดงถึงประสิทธิภาพที่แท้จริงของหน้าเว็บได้มากกว่า แต่การทราบคะแนน CrUX ไม่ได้ช่วยให้คุณทราบถึงวิธีปรับปรุงประสิทธิภาพ
ในทางกลับกัน Lighthouse จะระบุปัญหาและให้คำแนะนำที่เจาะจงเกี่ยวกับวิธีปรับปรุง อย่างไรก็ตาม Lighthouse จะแสดงคำแนะนำเกี่ยวกับปัญหาด้านประสิทธิภาพที่พบเมื่อโหลดหน้าเว็บเท่านั้น แต่จะไม่ตรวจหาปัญหาที่ปรากฏขึ้นจากการโต้ตอบของผู้ใช้เท่านั้น เช่น การเลื่อนหรือการคลิกปุ่มในหน้าเว็บ
ซึ่งทําให้เกิดคําถามสําคัญว่าคุณจะบันทึกข้อมูลการแก้ไขข้อบกพร่องสําหรับ Core Web Vitals หรือเมตริกประสิทธิภาพอื่นๆ จากผู้ใช้จริงในภาคสนามได้อย่างไร
โพสต์นี้จะอธิบายรายละเอียดว่าคุณใช้ API ใดได้บ้างเพื่อรวบรวมข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติมสำหรับเมตริก Core Web Vitals ปัจจุบันแต่ละรายการ และให้แนวคิดเกี่ยวกับวิธีบันทึกข้อมูลนี้ในเครื่องมือวิเคราะห์ที่มีอยู่
API สำหรับการระบุแหล่งที่มาและการแก้ไขข้อบกพร่อง
CLS
ในเมตริก Core Web Vitals ทั้งหมด CLS อาจเป็นเมตริกที่การรวบรวมข้อมูลการแก้ไขข้อบกพร่องในภาคสนามเป็นสิ่งสำคัญที่สุด ระบบวัด CLS ตลอดอายุของหน้าเว็บ ดังนั้นวิธีที่ผู้ใช้โต้ตอบกับหน้าเว็บ ไม่ว่าจะเป็นการเลื่อนหน้าจอ สิ่งที่คลิก และอื่นๆ จะมีผลกระทบอย่างมากต่อการเปลี่ยนแปลงของเลย์เอาต์หรือไม่และองค์ประกอบใดบ้างที่มีการเปลี่ยนแปลง
ลองดูรายงานต่อไปนี้จาก PageSpeed Insights
ค่าที่รายงานสำหรับ CLS จากห้องทดลอง (Lighthouse) เมื่อเทียบกับ CLS จากภาคสนาม (ข้อมูล CrUX) นั้นค่อนข้างแตกต่างกันและสมเหตุสมผลหากคุณพิจารณาว่าหน้าเว็บอาจมีเนื้อหาอินเทอร์แอกทีฟจำนวนมากที่ไม่ได้ใช้เมื่อทดสอบใน Lighthouse
แม้ว่าคุณจะเข้าใจว่าการโต้ตอบของผู้ใช้ส่งผลต่อข้อมูลภาคสนาม คุณก็ยังต้องทราบว่าองค์ประกอบใดในหน้าเว็บที่เปลี่ยนแปลงจนได้คะแนน 0.3 ที่เปอร์เซ็นไทล์ที่ 75
อินเทอร์เฟซ LayoutShiftAttribution ช่วยให้การดำเนินการดังกล่าวเป็นไปได้
รับการระบุแหล่งที่มาของการเปลี่ยนแปลงเลย์เอาต์
อินเทอร์เฟซ LayoutShiftAttribution แสดงในแต่ละรายการของ layout-shift
ที่ Layout Instability
API ปล่อย
ดูคำอธิบายโดยละเอียดของอินเทอร์เฟซทั้ง 2 รายการนี้ได้ที่แก้ไขข้อบกพร่องของการเปลี่ยนเลย์เอาต์ สำหรับวัตถุประสงค์ของโพสต์นี้ สิ่งสำคัญที่คุณจำเป็นต้องทราบคือในฐานะนักพัฒนาซอฟต์แวร์ คุณสามารถสังเกตการเปลี่ยนแปลงของเลย์เอาต์ทั้งหมดที่เกิดขึ้นในหน้าเว็บ รวมถึงดูว่าองค์ประกอบใดกำลังเปลี่ยนแปลง
ต่อไปนี้คือตัวอย่างโค้ดที่บันทึกการเปลี่ยนเลย์เอาต์แต่ละครั้ง รวมถึงองค์ประกอบที่เปลี่ยนไป
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
การวัดและส่งข้อมูลไปยังเครื่องมือวิเคราะห์สำหรับการเปลี่ยนเลย์เอาต์ที่เกิดขึ้นทุกครั้งนั้นคงไม่มีประโยชน์ อย่างไรก็ตาม หากติดตามดูการเปลี่ยนแปลงทั้งหมด คุณจะติดตามการเปลี่ยนแปลงที่แย่ที่สุดและรายงานข้อมูลเกี่ยวกับการเปลี่ยนแปลงเหล่านั้นได้
เป้าหมายไม่ใช่การระบุและแก้ไขเลย์เอาต์ของทุกการเปลี่ยนของเลย์เอาต์ที่เกิดขึ้นสำหรับผู้ใช้ทุกคน แต่เป้าหมายคือการระบุการเปลี่ยนแปลงที่ส่งผลต่อผู้ใช้จำนวนมากที่สุด และทำให้ CLS ของหน้าเว็บของคุณเกิดประโยชน์สูงสุดที่เปอร์เซ็นไทล์ที่ 75
นอกจากนี้ คุณไม่จำเป็นต้องคำนวณองค์ประกอบต้นทางที่ใหญ่ที่สุดทุกครั้งที่มีการเปลี่ยนแปลง และทำเฉพาะเมื่อคุณพร้อมส่งค่า CLS ไปยังเครื่องมือวิเคราะห์เท่านั้น
โค้ดต่อไปนี้จะแสดงรายการของ layout-shift
ที่ส่งผลต่อ CLS และแสดงผลองค์ประกอบต้นทางที่ใหญ่ที่สุดจากการเปลี่ยนแปลงมากที่สุด
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
เมื่อคุณระบุองค์ประกอบที่ใหญ่ที่สุดที่ทำให้เกิดการเปลี่ยนแปลงมากที่สุดแล้ว คุณสามารถรายงานไปยังเครื่องมือวิเคราะห์ได้
องค์ประกอบที่มีผลต่อ CLS มากที่สุดสำหรับหน้าเว็บหนึ่งๆ มีแนวโน้มที่จะแตกต่างกันไปตามผู้ใช้แต่ละคน แต่หากคุณรวมองค์ประกอบเหล่านั้นจากผู้ใช้ทั้งหมด คุณจะสร้างรายการองค์ประกอบที่เปลี่ยนแปลงซึ่งส่งผลต่อจำนวนผู้ใช้มากที่สุดได้
หลังจากที่คุณระบุและแก้ไขสาเหตุของการเปลี่ยนแปลงขององค์ประกอบเหล่านั้นแล้ว โค้ดการวิเคราะห์จะเริ่มรายงานการเปลี่ยนแปลงเล็กๆ น้อยๆ เป็นการเปลี่ยนแปลงที่ "แย่ที่สุด" สำหรับหน้าเว็บ ท้ายที่สุดแล้ว การเปลี่ยนแปลงทั้งหมดที่รายงานจะมีขนาดเล็กพอที่จะทำให้หน้าเว็บอยู่ในเกณฑ์ "ดี" ที่ 0.1
ข้อมูลเมตาอื่นๆ ที่อาจเป็นประโยชน์ในการจับภาพพร้อมกับองค์ประกอบ Shift แหล่งที่มาขนาดใหญ่ที่สุด ได้แก่
- เวลาที่เกิดการเปลี่ยนแปลงมากที่สุด
- เส้นทาง URL ในช่วงที่มีการเปลี่ยนแปลงมากที่สุด (สำหรับเว็บไซต์ที่อัปเดต URL แบบไดนามิก เช่น แอปพลิเคชันหน้าเว็บเดียว)
LCP
หากต้องการแก้ไขข้อบกพร่องของ LCP ในช่อง ข้อมูลหลักที่คุณต้องมีคือองค์ประกอบใดเป็นองค์ประกอบที่ใหญ่ที่สุด (องค์ประกอบตัวเลือก LCP) สำหรับการโหลดหน้าเว็บนั้นๆ
โปรดทราบว่าอันที่จริงก็เป็นเรื่องธรรมดาได้เช่นกัน องค์ประกอบผู้สมัคร LCP จะแตกต่างจากผู้ใช้รายหนึ่งๆ แม้จะอยู่ในหน้าเดียวกันก็ตาม
ปัญหานี้อาจเกิดขึ้นได้จากหลายสาเหตุดังนี้
- อุปกรณ์ของผู้ใช้มีความละเอียดหน้าจอที่แตกต่างกัน ซึ่งส่งผลให้เกิดเลย์เอาต์หน้าเว็บที่ต่างกัน ทำให้มองเห็นองค์ประกอบที่แตกต่างกันภายในวิวพอร์ตได้
- ผู้ใช้ไม่ได้โหลดหน้าเว็บเมื่อเลื่อนจนสุดเสมอไป บ่อยครั้งที่ลิงก์จะมีตัวระบุส่วนย่อยหรือแม้กระทั่งส่วนย่อยข้อความ ซึ่งหมายความว่าหน้าเว็บสามารถโหลดและแสดงในตำแหน่งการเลื่อนบนหน้าเว็บใดก็ได้
- เนื้อหาอาจได้รับการปรับเปลี่ยนให้เหมาะกับผู้ใช้ปัจจุบัน ดังนั้นองค์ประกอบตัวเลือก LCP จึงอาจแตกต่างกันไปตามผู้ใช้แต่ละคน
ซึ่งหมายความว่าคุณจะคาดเดาไม่ได้ว่าองค์ประกอบใดหรือชุดองค์ประกอบใดจะเป็นองค์ประกอบตัวเลือก LCP ที่พบบ่อยที่สุดสำหรับหน้าเว็บหนึ่งๆ คุณต้องวัดผลจากพฤติกรรมของผู้ใช้จริง
ระบุองค์ประกอบตัวเลือก LCP
หากต้องการระบุองค์ประกอบตัวเลือก LCP ใน JavaScript คุณสามารถใช้ Largest Contentful Paint API ซึ่งเป็น API เดียวกับที่คุณใช้ระบุค่าเวลา LCP
เมื่อสังเกตรายการ largest-contentful-paint
คุณจะระบุองค์ประกอบตัวเลือก LCP ปัจจุบันได้โดยดูที่พร็อพเพอร์ตี้ element
ของรายการสุดท้าย
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
เมื่อทราบองค์ประกอบตัวเลือก LCP แล้ว คุณสามารถส่งองค์ประกอบดังกล่าวไปยังเครื่องมือวิเคราะห์ไปพร้อมกับค่าเมตริก การใช้ CLS จะช่วยให้คุณระบุได้ว่าองค์ประกอบใดสำคัญที่สุดที่ต้องเพิ่มประสิทธิภาพก่อน
นอกเหนือจากองค์ประกอบตัวเลือก LCP แล้ว คุณยังควรวัดเวลาของส่วนย่อยของ LCP ด้วย ซึ่งอาจเป็นประโยชน์ในการระบุขั้นตอนการเพิ่มประสิทธิภาพที่เฉพาะเจาะจงซึ่งเกี่ยวข้องกับเว็บไซต์ของคุณ
FID
หากต้องการแก้ไขข้อบกพร่องของ FID ในช่องดังกล่าว โปรดทราบว่า FID จะวัดเฉพาะส่วนที่ล่าช้าของเวลาในการตอบสนองของเหตุการณ์อินพุตแรกโดยรวม ซึ่งหมายความว่าสิ่งที่ผู้ใช้โต้ตอบด้วยนั้นไม่สำคัญเท่ากับสิ่งที่เกิดขึ้นในเทรดหลักในขณะที่โต้ตอบ
ตัวอย่างเช่น แอปพลิเคชัน JavaScript จำนวนมากที่รองรับการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) จะแสดง HTML แบบคงที่ที่แสดงไปยังหน้าจอได้ก่อนที่จะมีการตอบสนองต่ออินพุตของผู้ใช้ กล่าวคือ ก่อนที่ JavaScript จะต้องจำเป็นในการทำให้เนื้อหาแบบอินเทอร์แอกทีฟโหลดเสร็จ
สำหรับการใช้งานเหล่านี้ คุณควรทราบว่าข้อมูลที่ป้อนแรกเกิดขึ้นก่อนหรือหลังการดื่มน้ำ หากผลปรากฏว่ามีคนจำนวนมากพยายามโต้ตอบกับหน้าเว็บก่อนที่ปริมาณน้ำจะหมดลง ให้ลองแสดงผลหน้าเว็บในสถานะปิดใช้งานหรือกำลังโหลด แทนการแสดงสถานะที่โต้ตอบได้
หากเฟรมเวิร์กของแอปพลิเคชันแสดงการประทับเวลาการดื่มน้ำ คุณเปรียบเทียบกับการประทับเวลาของรายการ first-input
ได้เพื่อระบุว่าข้อมูลที่ป้อนแรกเกิดขึ้นก่อนหรือหลังการดื่มน้ำ หากเฟรมเวิร์กของคุณไม่แสดงการประทับเวลาหรือไม่ได้ใช้ hydration เลย สัญญาณที่มีประโยชน์อีกอย่างคือ อาจมีการป้อนข้อมูลขึ้นก่อนหรือหลังจากที่ JavaScript โหลดเสร็จแล้ว
เหตุการณ์ DOMContentLoaded
จะเริ่มทำงานหลังจากที่ HTML ของหน้าเว็บโหลดและแยกวิเคราะห์เสร็จสมบูรณ์แล้ว ซึ่งรวมถึงการรอให้สคริปต์แบบซิงโครนัส การเลื่อนเวลาเลื่อน หรือสคริปต์โมดูล (รวมถึงโมดูลที่นำเข้าแบบคงที่ทั้งหมด) โหลดด้วย คุณจึงใช้ลำดับเวลาของเหตุการณ์ดังกล่าวและเปรียบเทียบกับเวลาที่ FID เกิดขึ้นได้
โค้ดต่อไปนี้จะติดตามรายการ first-input
และบันทึกว่าอินพุตแรกเกิดขึ้นก่อนสิ้นสุดเหตุการณ์ DOMContentLoaded
หรือไม่
new PerformanceObserver((list) => {
const fidEntry = list.getEntries()[0];
const navEntry = performance.getEntriesByType('navigation')[0];
const wasFIDBeforeDCL =
fidEntry.startTime < navEntry.domContentLoadedEventStart;
console.log('FID occurred before DOMContentLoaded:', wasFIDBeforeDCL);
}).observe({type: 'first-input', buffered: true});
ระบุองค์ประกอบเป้าหมาย FID และประเภทเหตุการณ์
สัญญาณการแก้ไขข้อบกพร่องอื่นๆ ที่อาจเป็นประโยชน์คือองค์ประกอบที่มีการโต้ตอบ ตลอดจนประเภทการโต้ตอบที่เกิดขึ้น (เช่น mousedown
, keydown
, pointerdown
) แม้ว่าการโต้ตอบกับองค์ประกอบเองไม่ได้มีส่วนเกี่ยวข้องกับ FID (อย่าลืมว่า FID เป็นเพียงส่วนความล่าช้าของเวลาในการตอบสนองของเหตุการณ์ทั้งหมด) การทราบว่าองค์ประกอบใดที่ผู้ใช้โต้ตอบกับองค์ประกอบนั้นอาจเป็นประโยชน์ในการกำหนดวิธีที่ดีที่สุดในการปรับปรุง FID
ตัวอย่างเช่น หากการโต้ตอบครั้งแรกของผู้ใช้ส่วนใหญ่เกิดขึ้นกับองค์ประกอบใดองค์ประกอบหนึ่ง ให้พิจารณาแทรกโค้ด JavaScript ที่จำเป็นสำหรับองค์ประกอบนั้นไว้ใน HTML และทำการโหลดแบบ Lazy Loading ในส่วนที่เหลือ
หากต้องการดูประเภทและองค์ประกอบการโต้ตอบที่เชื่อมโยงกับเหตุการณ์อินพุตแรก
ให้อ้างอิงพร็อพเพอร์ตี้ target
และ name
ของรายการ first-input
ดังนี้
new PerformanceObserver((list) => {
const fidEntry = list.getEntries()[0];
console.log('FID target element:', fidEntry.target);
console.log('FID interaction type:', fidEntry.name);
}).observe({type: 'first-input', buffered: true});
INP
INP คล้ายกับ FID มากตรงที่ข้อมูลที่เป็นประโยชน์มากที่สุดซึ่งสามารถจับต้องได้มีดังนี้
- องค์ประกอบที่มีการโต้ตอบกับองค์ประกอบ
- ประเภทของการโต้ตอบที่เกิดขึ้น
- การโต้ตอบเกิดขึ้นเมื่อใด
สาเหตุหลักของการโต้ตอบที่ช้าคือเทรดหลักที่ถูกบล็อก เช่นเดียวกับ FID ซึ่งอาจเกิดขึ้นได้ขณะโหลด JavaScript การรู้ว่าการโต้ตอบที่ช้าที่สุดเกิดขึ้นระหว่างการโหลดหน้าเว็บจะช่วยในการพิจารณาสิ่งที่ต้องทำเพื่อแก้ไขปัญหาหรือไม่
เมตริก INP ต่างจาก FID ตรงที่จะพิจารณาเวลาในการตอบสนองทั้งหมดของการโต้ตอบ ซึ่งรวมถึงเวลาที่ใช้ในการเรียกใช้ Listener เหตุการณ์ที่บันทึกไว้ รวมถึงระยะเวลาที่ใช้ในการระบายเฟรมถัดไปหลังจากที่ Listener เหตุการณ์ทั้งหมดทำงานไปแล้ว ซึ่งหมายความว่าสำหรับ INP การรู้ว่าองค์ประกอบเป้าหมายใดมีแนวโน้มที่จะส่งผลให้มีการโต้ตอบช้า และการโต้ตอบเหล่านั้นเป็นประเภทใดจึงมีประโยชน์ยิ่งขึ้น
เนื่องจากทั้ง INP และ FID อิงตาม Event Timing API วิธีที่คุณกำหนดข้อมูลนี้ใน JavaScript จะคล้ายกับตัวอย่างก่อนหน้านี้มาก โค้ดต่อไปนี้จะบันทึกองค์ประกอบและเวลาเป้าหมาย (สัมพันธ์กับ DOMContentLoaded
) ของรายการ INP
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
const navEntry = performance.getEntriesByType('navigation')[0];
const wasINPBeforeDCL =
inpEntry.startTime < navEntry.domContentLoadedEventStart;
console.log('INP occurred before DCL:', wasINPBeforeDCL);
}
โปรดทราบว่าโค้ดนี้ไม่ได้แสดงวิธีระบุว่ารายการ event
ใดเป็นรายการ INP เนื่องจากตรรกะดังกล่าวมีความเกี่ยวข้องมากกว่า อย่างไรก็ตาม ส่วนต่อไปนี้อธิบายวิธีรับข้อมูลนี้โดยใช้ไลบรารี JavaScript web-vitals
การใช้งานกับไลบรารี JavaScript Web-vitals
ส่วนด้านบนจะให้คำแนะนำทั่วไปและตัวอย่างโค้ดเพื่อบันทึกข้อมูลการแก้ไขข้อบกพร่องเพื่อรวมไว้ในข้อมูลที่คุณส่งไปยังเครื่องมือวิเคราะห์
ตั้งแต่เวอร์ชัน 3 ไลบรารี JavaScript web-vitals จะมีการระบุแหล่งที่มาที่แสดงข้อมูลทั้งหมด และสัญญาณเพิ่มเติมอีก 2-3 รายการด้วย
ตัวอย่างโค้ดต่อไปนี้แสดงวิธีตั้งค่าพารามิเตอร์เหตุการณ์ (หรือมิติข้อมูลที่กําหนดเอง) เพิ่มเติมซึ่งมีสตริงการแก้ไขข้อบกพร่อง ซึ่งมีประโยชน์ในการช่วยระบุสาเหตุหลักของปัญหาด้านประสิทธิภาพ
import {onCLS, onFID, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'FID':
case 'INP':
eventParams.debug_target = attribution.eventTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
โค้ดนี้ใช้เฉพาะกับ Google Analytics แต่แนวคิดทั่วไปก็ควรแปลงเป็นเครื่องมือวิเคราะห์อื่นๆ ได้เช่นกัน
โค้ดนี้ยังแสดงวิธีรายงานสัญญาณการแก้ไขข้อบกพร่องรายการเดียวเท่านั้น แต่อาจมีประโยชน์ในการรวบรวมและรายงานสัญญาณต่างๆ หลายรายการต่อเมตริก เช่น หากต้องการแก้ไขข้อบกพร่องของ INP คุณอาจต้องรวบรวมประเภทการโต้ตอบ เวลา และองค์ประกอบที่มีการโต้ตอบด้วย บิลด์การระบุแหล่งที่มา web-vitals
จะแสดงข้อมูลนี้ทั้งหมดตามที่แสดงในตัวอย่างต่อไปนี้
import {onCLS, onFID, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.eventTarget;
eventParams.debug_type = attribution.eventType;
eventParams.debug_time = attribution.eventTime;
eventParams.debug_load_state = attribution.loadState;
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
โปรดดูเอกสารประกอบการระบุแหล่งที่มาของ Web-vitals สําหรับรายการสัญญาณการแก้ไขข้อบกพร่องทั้งหมดที่แสดง
รายงานและแสดงข้อมูลเป็นภาพ
เมื่อเริ่มรวบรวมข้อมูลการแก้ไขข้อบกพร่องพร้อมกับค่าเมตริกแล้ว ขั้นตอนถัดไปคือการรวบรวมข้อมูลจากผู้ใช้ทั้งหมดเพื่อเริ่มมองหารูปแบบและแนวโน้ม
ดังที่กล่าวไว้ข้างต้น คุณไม่จำเป็นต้องจัดการทุกปัญหาที่ผู้ใช้พบ โดยเฉพาะปัญหาที่ส่งผลกระทบต่อผู้ใช้จำนวนมากที่สุด ซึ่งควรเป็นปัญหาที่มีผลกระทบเชิงลบต่อคะแนน Core Web Vitals มากที่สุดด้วย โดยเฉพาะปัญหาแรก
สําหรับ GA4 โปรดดูบทความเกี่ยวกับวิธีค้นหาและแสดงข้อมูลโดยใช้ BigQuery โดยเฉพาะ
สรุป
เราหวังว่าโพสต์นี้จะอธิบายวิธีการต่างๆ ที่คุณสามารถใช้ API ประสิทธิภาพที่มีอยู่และไลบรารี web-vitals
เพื่อรับข้อมูลการแก้ไขข้อบกพร่องเพื่อช่วยวิเคราะห์ประสิทธิภาพตามการเข้าชมของผู้ใช้จริงในภาคสนาม แม้ว่าคู่มือนี้จะมุ่งเน้นที่ Core Web Vitals แต่แนวคิดเหล่านี้ยังนําไปใช้ในการแก้ไขข้อบกพร่องของเมตริกประสิทธิภาพที่วัดผลได้ใน JavaScript ด้วย
หากคุณเพิ่งเริ่มต้นวัดประสิทธิภาพและเป็นผู้ใช้ Google Analytics อยู่แล้ว เครื่องมือรายงาน Web Vitals ก็อาจเป็นจุดเริ่มต้นที่ดี เนื่องจากเครื่องมือดังกล่าวรองรับการรายงานข้อมูลการแก้ไขข้อบกพร่องสำหรับเมตริก Core Web Vitals อยู่แล้ว
หากคุณเป็นผู้ให้บริการวิเคราะห์ข้อมูลและต้องการปรับปรุงผลิตภัณฑ์และให้ข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติมแก่ผู้ใช้ โปรดพิจารณาเทคนิคบางส่วนที่อธิบายไว้ที่นี่ แต่อย่าจำกัดตัวเองไว้เพียงเฉพาะแนวคิดที่นำเสนอในที่นี้ โดยทั่วไปแล้ว โพสต์นี้มีจุดประสงค์เพื่อนำไปใช้ได้กับเครื่องมือวิเคราะห์ทั้งหมด แต่เครื่องมือวิเคราะห์แต่ละรายการน่าจะสามารถ (และควร) บันทึกและรายงานข้อมูลการแก้ไขข้อบกพร่องได้มากขึ้น
และสุดท้าย หากคุณรู้สึกว่ายังมีช่องว่างในความสามารถในการแก้ไขข้อบกพร่องของเมตริกเหล่านี้เนื่องจากไม่มีฟีเจอร์หรือข้อมูลใน API เอง โปรดส่งความคิดเห็นไปที่ web-vitals-feedback@googlegroups.com