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

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

Philip Walton

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

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

การโต้ตอบกับ 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 จะมีบิลด์การระบุแหล่งที่มาที่แสดงข้อมูลทั้งหมดนี้ รวมถึงสัญญาณเพิ่มเติมอีก 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);
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

สรุป

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

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

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

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