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

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

Philip Walton

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

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

Interaction to Next Paint (INP)

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

1. องค์ประกอบที่มีการโต้ตอบ
2. ประเภทการโต้ตอบ
3. เวลาที่เกิดการโต้ตอบ

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

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

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);
onINP(sendToGoogleAnalytics);

โค้ดนี้ใช้ได้กับ Google Analytics โดยเฉพาะ แต่แนวคิดทั่วไปควรใช้ได้กับเครื่องมือวิเคราะห์อื่นๆ ด้วย

โค้ดนี้ยังแสดงวิธีรายงานสัญญาณการแก้ไขข้อบกพร่องเพียงรายการเดียว แต่การรวบรวมและรายงานสัญญาณต่างๆ หลายรายการต่อเมตริกก็มีประโยชน์เช่นกัน

ตัวอย่างเช่น หากต้องการแก้ไขข้อบกพร่องของ INP คุณอาจต้องการรวบรวมองค์ประกอบที่ มีการโต้ตอบ ประเภทการโต้ตอบ เวลา loadState ระยะการโต้ตอบ และอื่นๆ (เช่น ข้อมูลเฟรมของภาพเคลื่อนไหวที่ใช้เวลานาน)

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);
onINP(sendToGoogleAnalytics);

ดูรายการสัญญาณการแก้ไขข้อบกพร่องทั้งหมดที่แสดงได้ในเอกสารประกอบการระบุแหล่งที่มาของ Web Vitals

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

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

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

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

สรุป

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

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

สุดท้ายนี้ หากคุณรู้สึกว่าความสามารถในการแก้ไขข้อบกพร่องของเมตริกเหล่านี้มีข้อบกพร่องเนื่องจาก ไม่มีฟีเจอร์หรือข้อมูลใน API เอง โปรดส่งความคิดเห็นไปที่ web-vitals-feedback@googlegroups.com