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

ดูวิธีระบุแหล่งที่มาของข้อมูลประสิทธิภาพด้วยข้อมูลการแก้ไขข้อบกพร่อง เพื่อช่วยคุณระบุและแก้ไขปัญหาของผู้ใช้จริงด้วย Analytics

Philip Walton

Google มีเครื่องมือ 2 หมวดหมู่เพื่อใช้ในการวัดและแก้ไขข้อบกพร่องด้านประสิทธิภาพ ได้แก่

• เครื่องมือ Lab: เครื่องมือต่างๆ เช่น Lighthouse ซึ่งโหลดหน้าเว็บใน สภาพแวดล้อมจำลองที่สามารถเลียนแบบเงื่อนไขต่างๆ (ตัวอย่างเช่น และอุปกรณ์เคลื่อนที่ระดับโลว์เอนด์)
• เครื่องมือภาคสนาม: เครื่องมือ เช่น ประสบการณ์ของผู้ใช้ Chrome รายงาน (CrUX) ซึ่งอิงตามข้อมูลรวมของผู้ใช้จริงจาก Chrome (โปรดทราบว่า ข้อมูลที่เครื่องมือรายงาน เช่น PageSpeed ข้อมูลเชิงลึกและการค้นหา Console มีแหล่งที่มาจาก CrUX)

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

ข้อมูล CrUX เป็นตัวแทนของประสิทธิภาพจริง ของหน้าเว็บมากกว่า แต่ คะแนน CrUX ไม่น่าจะช่วยคุณคิดวิธีปรับปรุง ด้านประสิทธิภาพ

ในทางกลับกัน Lighthouse จะระบุปัญหาและทำให้ คำแนะนำในการปรับปรุง อย่างไรก็ตาม Lighthouse จะแสดงคำแนะนำเท่านั้น สำหรับปัญหาด้านประสิทธิภาพที่พบเมื่อโหลดหน้าเว็บ ไม่พบปัญหา ที่แสดงเฉพาะผลจากการโต้ตอบของผู้ใช้ เช่น การเลื่อนหรือคลิก ปุ่มบนหน้าเว็บ

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

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

API สำหรับการระบุแหล่งที่มาและการแก้ไขข้อบกพร่อง

Cumulative Layout Shift (CLS)

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

ลองใช้รายงานต่อไปนี้จาก PageSpeed Insights

วันที่

PageSpeed Insights จะแสดงทั้งข้อมูลภาคสนามและห้องทดลอง (หากมี) และข้อมูลดังกล่าวอาจแตกต่าง

ค่า CLS ที่รายงานจาก Lab (Lighthouse) เทียบกับ CLS จาก ฟิลด์ (ข้อมูล CrUX) ค่อนข้างจะแตกต่างออกไป และวิธีนี้น่าจะเหมาะสมหากลอง หน้านั้นอาจมีเนื้อหาแบบอินเทอร์แอกทีฟจำนวนมาก ไม่มีการใช้เมื่อทดสอบใน Lighthouse

แต่ถ้าคุณเข้าใจว่าการโต้ตอบของผู้ใช้มีผลต่อข้อมูลภาคสนาม แต่คุณยังคง ต้องการทราบว่าองค์ประกอบใดในหน้าเว็บเปลี่ยนแปลงและส่งผลให้ได้คะแนน 0.28 ที่เปอร์เซ็นไทล์ที่ 75 LayoutShiftAttribution ก็ทำได้จริง

รับการระบุแหล่งที่มาของการเปลี่ยนเลย์เอาต์

LayoutShiftAttribution แสดงในอินเทอร์เฟซแต่ละรายการของ layout-shift ที่ ความไม่เสถียรของเลย์เอาต์ 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 ไปยัง ของ Google Analytics

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

เมื่อทราบองค์ประกอบของตัวเลือก LCP แล้ว คุณสามารถส่งองค์ประกอบดังกล่าวไปยังเครื่องมือวิเคราะห์ได้ พร้อมกับค่าเมตริก วิธีนี้จะช่วยให้คุณระบุได้ว่า องค์ประกอบสำคัญที่สุดที่ต้องเพิ่มประสิทธิภาพก่อน

นอกจากองค์ประกอบตัวเลือก LCP แล้ว การวัด เวลาของส่วนย่อย LCP ซึ่งอาจเป็นประโยชน์ ในการพิจารณาขั้นตอนการเพิ่มประสิทธิภาพที่เฉพาะเจาะจงซึ่งเกี่ยวข้องกับเว็บไซต์ของคุณ

การโต้ตอบกับ Next Paint (INP)

เคล็ดลับ: ดูบทความหัวข้อค้นหาการโต้ตอบช้าในช่องโดยเฉพาะเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขข้อบกพร่อง INP ด้วยข้อมูลภาคสนาม

ข้อมูลที่สำคัญที่สุดที่ควรบันทึกในฟิลด์สำหรับ INP มีดังนี้

1. องค์ประกอบที่โต้ตอบกับ
2. ทำไมการโต้ตอบจึงเป็น
3. เวลาที่เกิดการโต้ตอบนั้น

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

เมตริก INP จะพิจารณาเวลาในการตอบสนองแบบเต็มของ การโต้ตอบ รวมถึงเวลาที่ใช้ในการเรียกใช้ 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 เพราะตรรกะดังกล่าวเกี่ยวข้องมากกว่า แต่ส่วนต่อไปนี้จะอธิบาย วิธีรับข้อมูลนี้โดยใช้ web-vitals ไลบรารี JavaScript

การใช้งานไลบรารี JavaScript ของ Web-vitals

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

ตั้งแต่เวอร์ชัน 3 เป็นต้นไป วิดีโอวิตามินจากเว็บ ไลบรารี JavaScript จะมีการระบุแหล่งที่มา สร้างที่ จะแสดงข้อมูลทั้งหมดนี้ และข้อมูลเพิ่มเติมอีกเล็กน้อย สัญญาณได้ด้วย

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

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);

โปรดดูการระบุแหล่งที่มาของวิดีโอที่เกี่ยวข้องกับเว็บ สำหรับ รายการสัญญาณการแก้ไขข้อบกพร่องทั้งหมดถูกเปิดเผย

รายงานและแสดงข้อมูลเป็นภาพ

เมื่อเริ่มรวบรวมข้อมูลการแก้ไขข้อบกพร่องพร้อมค่าเมตริกแล้ว ขั้นตอนต่อไปคือรวมข้อมูลจากผู้ใช้ทั้งหมด เพื่อเริ่มค้นหา รูปแบบและแนวโน้มต่างๆ

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

สําหรับ GA4 โปรดดูบทความเกี่ยวกับวิธีค้นหาและแสดงข้อมูลเป็นภาพโดยใช้ BigQuery

สรุป

หวังว่าโพสต์นี้จะอธิบายวิธีการต่างๆ ที่คุณสามารถใช้ API ด้านประสิทธิภาพที่มีอยู่และไลบรารี web-vitals เพื่อรับข้อมูลการแก้ไขข้อบกพร่อง เพื่อช่วยวิเคราะห์ประสิทธิภาพโดยอิงจากการเข้าชมจริงของผู้ใช้ภาคสนาม ขณะที่รายการนี้ มุ่งเน้นที่ Core Web Vitals ซึ่งแนวคิดนี้ยังใช้กับการแก้ไขข้อบกพร่องด้วย เมตริกประสิทธิภาพใดๆ ที่วัดได้ใน JavaScript

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

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

สุดท้าย หากคุณรู้สึกว่ายังมีช่องโหว่ในความสามารถในการแก้ไขข้อบกพร่องของเมตริกเหล่านี้เนื่องจาก ฟีเจอร์หรือข้อมูลใน API ที่ขาดหายไปส่งความคิดเห็นของคุณถึง [e-mail]