แก้ไขข้อบกพร่องของประสิทธิภาพในฟิลด์

เรียนรู้วิธีระบุแหล่งที่มาของข้อมูลประสิทธิภาพด้วยข้อมูลการแก้ไขข้อบกพร่อง เพื่อช่วยให้คุณระบุและแก้ไขปัญหาของผู้ใช้จริงด้วย 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 มากตรงที่ข้อมูลที่เป็นประโยชน์มากที่สุดซึ่งสามารถจับต้องได้มีดังนี้

1. องค์ประกอบที่มีการโต้ตอบกับองค์ประกอบ
2. ประเภทของการโต้ตอบที่เกิดขึ้น
3. การโต้ตอบเกิดขึ้นเมื่อใด

สาเหตุหลักของการโต้ตอบที่ช้าคือเทรดหลักที่ถูกบล็อก เช่นเดียวกับ 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