เรียนรู้วิธีระบุแหล่งที่มาของข้อมูลประสิทธิภาพด้วยข้อมูลการแก้ไขข้อบกพร่อง เพื่อช่วยให้คุณระบุและแก้ไขปัญหาของผู้ใช้จริงได้ด้วยข้อมูลวิเคราะห์
Google มีเครื่องมือ 2 หมวดหมู่เพื่อใช้ในการวัดและแก้ไขข้อบกพร่องด้านประสิทธิภาพ ได้แก่
- เครื่องมือห้องทดลอง: เครื่องมือต่างๆ เช่น Lighthouse ซึ่งโหลดหน้าเว็บในสภาพแวดล้อมจำลองที่เลียนแบบสภาวะต่างๆ ได้ (เช่น เครือข่ายที่ช้าและอุปกรณ์เคลื่อนที่ระดับโลว์เอนด์)
- เครื่องมือภาคสนาม: เครื่องมือต่างๆ เช่น รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งอิงตามข้อมูลรวมของผู้ใช้จริงจาก Chrome (โปรดทราบว่าข้อมูลภาคสนามที่รายงานโดยเครื่องมือ เช่น PageSpeed Insights และ Search Console มาจากข้อมูล CrUX)
แม้ว่าเครื่องมือภาคสนามจะให้ข้อมูลที่แม่นยำมากขึ้น ซึ่งเป็นข้อมูลที่แสดงถึงประสบการณ์ของผู้ใช้จริง แต่เครื่องมือห้องทดลองมักจะช่วยคุณระบุและแก้ไขปัญหาได้ดีกว่า
ข้อมูล CrUX แสดงให้เห็นถึงประสิทธิภาพที่แท้จริงของหน้าเว็บมากกว่า แต่การทราบคะแนน CrUX มักไม่อาจช่วยคุณค้นหาวิธีปรับปรุงประสิทธิภาพได้
ในทางกลับกัน Lighthouse จะระบุปัญหาและให้คำแนะนำเกี่ยวกับวิธีปรับปรุง อย่างไรก็ตาม Lighthouse จะแนะนำเฉพาะปัญหาด้านประสิทธิภาพที่พบเมื่อโหลดหน้าเว็บ แต่จะไม่ตรวจจับปัญหาที่ปรากฏเฉพาะผลจากการโต้ตอบของผู้ใช้ เช่น การเลื่อนหรือการคลิกปุ่มในหน้า
ซึ่งทำให้เกิดคำถามสำคัญขึ้น ซึ่งก็คือคุณจะบันทึกข้อมูลการแก้ไขข้อบกพร่องสำหรับ Core Web Vitals หรือเมตริกประสิทธิภาพอื่นๆ จากผู้ใช้จริงในภาคสนามได้อย่างไร
โพสต์นี้จะอธิบายรายละเอียดว่า API ใดที่คุณใช้เพื่อรวบรวมข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติมสำหรับเมตริก Core Web Vitals แต่ละรายการในปัจจุบันได้ และจะให้ไอเดียเกี่ยวกับวิธีรวบรวมข้อมูลนี้ในเครื่องมือวิเคราะห์ที่มีอยู่
API สำหรับการระบุแหล่งที่มาและการแก้ไขข้อบกพร่อง
Cumulative Layout Shift (CLS)
ในเมตริกทั้งหมดของ Core Web Vitals นั้น CLS อาจเป็นเมตริกที่การเก็บรวบรวมข้อมูลการแก้ไขข้อบกพร่องในภาคสนามมีความสำคัญที่สุด ระบบจะวัด CLS ตลอดอายุการใช้งานหน้าเว็บ ดังนั้นวิธีที่ผู้ใช้โต้ตอบกับหน้าเว็บ เช่น ระยะเลื่อน สิ่งที่คลิก และอื่นๆ มีผลกระทบอย่างมากต่อการเปลี่ยนแปลงเลย์เอาต์และองค์ประกอบที่มีการเปลี่ยนแปลง
ลองใช้รายงานต่อไปนี้จาก PageSpeed Insights
ค่าที่รายงานสำหรับ CLS จากห้องทดลอง (Lighthouse) เทียบกับ CLS จากช่อง (ข้อมูล CrUX) นั้นค่อนข้างแตกต่างกัน และเหมาะสมหากคุณพิจารณาว่าหน้าอาจมีเนื้อหาแบบอินเทอร์แอกทีฟจำนวนมากซึ่งไม่ได้ใช้เมื่อทดสอบใน Lighthouse
แต่แม้ว่าคุณจะเข้าใจว่าการโต้ตอบของผู้ใช้ส่งผลต่อข้อมูลในช่อง คุณก็ยังจำเป็นต้องทราบว่าองค์ประกอบใดในหน้าเว็บที่ขยับไปทำให้ได้คะแนน 0.28 ที่เปอร์เซ็นไทล์ที่ 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
ข้อมูลเมตาอื่นๆ บางส่วนที่อาจเป็นประโยชน์ในการจับภาพร่วมกับองค์ประกอบต้นทางของการเปลี่ยนแปลงที่ใหญ่ที่สุดมีดังนี้
- ช่วงเวลาแห่งการเปลี่ยนแปลงครั้งใหญ่ที่สุด
- เส้นทาง URL ในช่วงเวลาที่มีการเปลี่ยนแปลงมากที่สุด (สำหรับเว็บไซต์ที่อัปเดต URL แบบไดนามิก เช่น แอปพลิเคชันหน้าเว็บเดียว)
Largest Contentful Paint (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 แล้ว คุณก็ส่งองค์ประกอบดังกล่าวไปยังเครื่องมือวิเคราะห์พร้อมกับค่าเมตริกได้ ซึ่งจะช่วยให้คุณระบุได้ว่าองค์ประกอบใดสำคัญที่สุดที่ต้องเพิ่มประสิทธิภาพเป็นอันดับแรก
นอกเหนือจากองค์ประกอบตัวเลือก LCP แล้ว การวัดเวลาของส่วนย่อย LCP อาจเป็นประโยชน์ในการระบุขั้นตอนการเพิ่มประสิทธิภาพที่เจาะจงซึ่งเกี่ยวข้องกับเว็บไซต์ของคุณ
การโต้ตอบกับ Next Paint (INP)
ข้อมูลที่สำคัญที่สุดที่ควรบันทึกในฟิลด์สำหรับ INP มีดังนี้
- องค์ประกอบที่โต้ตอบกับ
- ทำไมการโต้ตอบจึงเป็น
- เวลาที่เกิดการโต้ตอบนั้น
สาเหตุหลักของการโต้ตอบช้าคือเทรดหลักที่ถูกบล็อก ซึ่งอาจพบได้บ่อยในขณะที่ JavaScript กำลังโหลด การรู้ว่าการโต้ตอบที่ช้าที่สุดเกิดขึ้นระหว่างการโหลดหน้าเว็บหรือไม่มีประโยชน์ในการระบุสิ่งที่ต้องทำเพื่อแก้ไขปัญหา
เมตริก INP จะพิจารณาเวลาในการตอบสนองทั้งหมดของการโต้ตอบ รวมถึงเวลาที่ใช้ในการเรียกใช้ Listener เหตุการณ์ที่ลงทะเบียนไว้ รวมถึงเวลาที่ใช้ในการวาดเฟรมถัดไปหลังจากที่ Listener เหตุการณ์ทั้งหมดทำงานแล้ว ซึ่งหมายความว่าสำหรับ INP การได้ทราบว่าองค์ประกอบเป้าหมายใดมีแนวโน้มที่จะทำให้มีการโต้ตอบช้าและมีการโต้ตอบประเภทใดจึงเป็นประโยชน์มาก
โค้ดต่อไปนี้จะบันทึกองค์ประกอบเป้าหมายและเวลาของรายการ INP
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
โปรดทราบว่าโค้ดนี้ไม่ได้แสดงวิธีระบุว่ารายการ event ใดเป็นรายการ INP เนื่องจากตรรกะนั้นเกี่ยวข้องมากกว่า อย่างไรก็ตาม ส่วนต่อไปนี้จะอธิบายวิธีรับข้อมูลนี้โดยใช้ไลบรารี JavaScript web-vitals
การใช้งานไลบรารี JavaScript ของ Web-vitals
ส่วนก่อนหน้านี้มีคำแนะนำทั่วไปและตัวอย่างโค้ดสำหรับบันทึกข้อมูลการแก้ไขข้อบกพร่องไว้ในข้อมูลที่คุณส่งไปยังเครื่องมือวิเคราะห์
ตั้งแต่เวอร์ชัน 3 ไลบรารี JavaScript web-vitals จะมีบิลด์การระบุแหล่งที่มาที่แสดงข้อมูลทั้งหมดนี้ รวมถึงสัญญาณเพิ่มเติมอีก 2-3 รายการด้วย
ตัวอย่างโค้ดต่อไปนี้แสดงวิธีการตั้งค่าพารามิเตอร์เหตุการณ์เพิ่มเติม (หรือมิติข้อมูลที่กำหนดเอง) ซึ่งมีสตริงการแก้ไขข้อบกพร่องซึ่งมีประโยชน์ในการช่วยระบุสาเหตุของปัญหาด้านประสิทธิภาพ
import {onCLS, 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 'INP':
eventParams.debug_target = attribution.interactionTarget;
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 แสดงข้อมูลการระบุแหล่งที่มาเพิ่มเติม ตามที่แสดงในตัวอย่างต่อไปนี้สำหรับ INP
import {onCLS, 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.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
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