เมตริกที่กำหนดเอง

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

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

เมตริกสากลเป็นเกณฑ์พื้นฐานที่ดี แต่ในหลายกรณี คุณต้องวัดมากกว่าเมตริกเหล่านี้เพื่อให้ได้ประสบการณ์ทั้งหมดสําหรับเว็บไซต์ของคุณ

เมตริกที่กําหนดเองช่วยให้คุณวัดแง่มุมของประสบการณ์ในเว็บไซต์ที่อาจใช้ได้กับเว็บไซต์ของคุณเท่านั้น เช่น

  • ระยะเวลาที่แอปหน้าเดียว (SPA) ใช้ในการเปลี่ยนจาก "หน้า" หนึ่งไปยังอีกหน้าหนึ่ง
  • ระยะเวลาที่หน้าเว็บใช้ในการแสดงข้อมูลที่ดึงมาจากฐานข้อมูลสำหรับผู้ใช้ที่ลงชื่อเข้าสู่ระบบ
  • ระยะเวลาที่แอปที่แสดงผลฝั่งเซิร์ฟเวอร์ (SSR) ใช้ในการไฮเดรต
  • อัตราการเข้าชมแคชสำหรับทรัพยากรที่โหลดโดยผู้เข้าชมที่กลับมา
  • เวลาในการตอบสนองของเหตุการณ์คลิกหรือเหตุการณ์แป้นพิมพ์ในเกม

API สำหรับวัดเมตริกที่กำหนดเอง

ในอดีต นักพัฒนาเว็บมี API ระดับต่ำไม่มากนักที่จะใช้วัดประสิทธิภาพ จึงต้องหันไปใช้การแฮ็กเพื่อวัดว่าเว็บไซต์ทำงานได้ดีหรือไม่

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

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

Performance Observer API

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 57.
  • Safari: 11.

Source

Performance Observer API เป็นกลไกที่รวบรวมและแสดงข้อมูลจาก API ประสิทธิภาพอื่นๆ ทั้งหมดที่กล่าวถึงในหน้านี้ การทำความเข้าใจเรื่องนี้เป็นสิ่งสำคัญในการรับข้อมูลที่ดี

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

หากต้องการสร้าง PerformanceObserver ให้ส่ง Callback เพื่อเรียกใช้ทุกครั้งที่มีการส่งรายการประสิทธิภาพใหม่ จากนั้นคุณจะบอกผู้สังเกตการณ์ว่าควรฟังรายการประเภทใดโดยใช้วิธี observe() ดังนี้

const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

po.observe({type: 'some-entry-type'});

ส่วนต่อไปนี้แสดงรายการประเภทรายการต่างๆ ทั้งหมดที่พร้อมใช้งานสำหรับการสังเกตการณ์ แต่ในเบราว์เซอร์รุ่นใหม่กว่า คุณจะตรวจสอบประเภทรายการที่พร้อมใช้งานได้ผ่านพร็อพเพอร์ตี้ PerformanceObserver.supportedEntryTypes แบบคงที่

สังเกตรายการที่เกิดขึ้นแล้ว

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

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

po.observe({
  type: 'some-entry-type',
  buffered: true,
});

API ประสิทธิภาพเดิมที่ควรหลีกเลี่ยง

ก่อนที่จะมี Performance Observer API นักพัฒนาแอปสามารถเข้าถึงรายการประสิทธิภาพได้โดยใช้วิธีการ 3 วิธีต่อไปนี้ที่กำหนดไว้ในออบเจ็กต์ performance

แม้ว่าระบบจะยังรองรับ API เหล่านี้อยู่ แต่เราไม่แนะนำให้ใช้งานเนื่องจาก API เหล่านี้ไม่ช่วยให้คุณฟังได้เมื่อมีการส่งรายการใหม่ นอกจากนี้ API ใหม่หลายรายการ (เช่น largest-contentful-paint) จะไม่แสดงผ่านออบเจ็กต์ performance แต่จะแสดงผ่าน PerformanceObserver เท่านั้น

หากคุณไม่ได้ต้องการความเข้ากันได้กับ Internet Explorer โดยเฉพาะ เราขอแนะนำให้หลีกเลี่ยงการใช้วิธีการเหล่านี้ในโค้ดและใช้ PerformanceObserver ต่อไป

User Timing API

Browser Support

  • Chrome: 28.
  • Edge: 12.
  • Firefox: 38.
  • Safari: 11.

Source

User Timing API เป็น API การวัดผลอเนกประสงค์ สำหรับเมตริกตามเวลา ซึ่งช่วยให้คุณทำเครื่องหมายจุดต่างๆ ใน เวลาได้ตามต้องการ แล้ววัดระยะเวลาระหว่างเครื่องหมายเหล่านั้นในภายหลัง

// Record the time immediately before running a task.
performance.mark('myTask:start');
await doMyTask();

// Record the time immediately after running a task.
performance.mark('myTask:end');

// Measure the delta between the start and end of the task
performance.measure('myTask', 'myTask:start', 'myTask:end');

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

หากต้องการรายงานการวัดเวลาของผู้ใช้ คุณสามารถใช้ PerformanceObserver และลงทะเบียนเพื่อสังเกตรายการประเภท measure ได้

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `measure` entries to be dispatched.
po.observe({type: 'measure', buffered: true});

Long Tasks API

Browser Support

  • Chrome: 58.
  • Edge: 79.
  • Firefox: not supported.
  • Safari: not supported.

Source

Long Tasks API มีประโยชน์ในการทราบเมื่อเทรดหลักของเบราว์เซอร์ถูกบล็อกนานพอที่จะส่งผลต่ออัตราเฟรมหรือเวลาในการตอบสนองต่ออินพุต API จะรายงานงานที่ดำเนินการนานกว่า 50 มิลลิวินาที

เมื่อใดก็ตามที่คุณต้องเรียกใช้โค้ดที่มีค่าใช้จ่ายสูง หรือโหลดและเรียกใช้สคริปต์ขนาดใหญ่ การติดตามว่าโค้ดนั้นบล็อกเทรดหลักหรือไม่ก็จะมีประโยชน์ ที่จริงแล้ว เมตริกระดับสูงหลายรายการสร้างขึ้นจาก Long Tasks API เอง (เช่น เวลาในการตอบสนอง (TTI) และเวลาที่ถูกบล็อกทั้งหมด (TBT))

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

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `longtask` entries to be dispatched.
po.observe({type: 'longtask', buffered: true});

Long Animation Frames API

Browser Support

  • Chrome: 123.
  • Edge: 123.
  • Firefox: not supported.
  • Safari: not supported.

Source

Long Animation Frames API เป็นการทำซ้ำ Long Tasks API ใหม่ที่ดูเฟรมที่ใช้เวลานานแทนที่จะเป็นงานที่ใช้เวลานานซึ่งมีระยะเวลามากกว่า 50 มิลลิวินาที ซึ่งจะช่วยแก้ข้อบกพร่องบางอย่างของ Long Tasks API รวมถึงการระบุแหล่งที่มาที่ดีขึ้นและขอบเขตที่กว้างขึ้นของความล่าช้าที่อาจทำให้เกิดปัญหา

หากต้องการพิจารณาว่าเฟรมที่ใช้เวลานานเกิดขึ้นเมื่อใด คุณสามารถใช้ PerformanceObserver และลงทะเบียนเพื่อสังเกตรายการประเภท long-animation-frame ได้

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `long-animation-frame` entries to be dispatched.
po.observe({type: 'long-animation-frame', buffered: true});

Element Timing API

Browser Support

  • Chrome: 77.
  • Edge: 79.
  • Firefox: not supported.
  • Safari: not supported.

Source

เมตริก Largest Contentful Paint (LCP) มีประโยชน์ในการทราบเวลาที่แสดงผลรูปภาพหรือบล็อกข้อความที่ใหญ่ที่สุดบนหน้าจอ แต่ในบางกรณี คุณอาจต้องการวัดเวลาในการแสดงผลขององค์ประกอบอื่น

สําหรับกรณีเหล่านี้ ให้ใช้ Element Timing API LCP API สร้างขึ้นจาก Element Timing API และเพิ่มการรายงานอัตโนมัติขององค์ประกอบที่มีเนื้อหาขนาดใหญ่ที่สุด แต่คุณยังรายงานองค์ประกอบอื่นๆ ได้ด้วยการเพิ่มแอตทริบิวต์ elementtiming ลงในองค์ประกอบเหล่านั้นอย่างชัดเจน และลงทะเบียน PerformanceObserver เพื่อสังเกตประเภทรายการ element

<img elementtiming="hero-image" />
<p elementtiming="important-paragraph">This is text I care about.</p>
<!-- ... -->

<script>
  const po = new PerformanceObserver((entryList) => {
    for (const entry of entryList.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  // Start listening for `element` entries to be dispatched.
  po.observe({type: 'element', buffered: true});
</script>

Event Timing API

Browser Support

  • Chrome: 76.
  • Edge: 79.
  • Firefox: 89.
  • Safari: 26.2.

Source

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

เมตริก INP ทำงานได้ด้วย Event Timing API API นี้จะแสดงการประทับเวลาหลายรายการที่เกิดขึ้นในวงจรของเหตุการณ์ ซึ่งรวมถึง

  • startTime: เวลาที่เบราว์เซอร์ได้รับเหตุการณ์
  • processingStart: เวลาที่เบราว์เซอร์เริ่มประมวลผลเครื่องจัดการเหตุการณ์สำหรับเหตุการณ์ได้
  • processingEnd: เวลาที่เบราว์เซอร์เรียกใช้โค้ดแบบซิงโครนัสทั้งหมดที่เริ่มต้นจากตัวแฮนเดิลเหตุการณ์สําหรับเหตุการณ์นี้เสร็จสิ้น
  • duration: เวลา (ปัดเป็น 8 มิลลิวินาทีเพื่อความปลอดภัย) ตั้งแต่เมื่อเบราว์เซอร์ได้รับเหตุการณ์จนกว่าจะแสดงเฟรมถัดไปได้หลังจากรันโค้ดแบบซิงโครนัสทั้งหมดที่เริ่มต้นจากตัวแฮนเดิลเหตุการณ์เสร็จแล้ว

ตัวอย่างต่อไปนี้แสดงวิธีใช้ค่าเหล่านี้เพื่อสร้างการวัดผลที่กำหนดเอง

const po = new PerformanceObserver((entryList) => {
  // Get the last interaction observed:
  const entries = Array.from(entryList.getEntries()).forEach((entry) => {
    // Get various bits of interaction data:
    const inputDelay = entry.processingStart - entry.startTime;
    const processingTime = entry.processingEnd - entry.processingStart;
    const presentationDelay = entry.startTime + entry.duration - entry.processingEnd;
    const duration = entry.duration;
    const eventType = entry.name;
    const target = entry.target || "(not set)"

    console.log("----- INTERACTION -----");
    console.log(`Input delay (ms): ${inputDelay}`);
    console.log(`Event handler processing time (ms): ${processingTime}`);
    console.log(`Presentation delay (ms): ${presentationDelay}`);
    console.log(`Total event duration (ms): ${duration}`);
    console.log(`Event type: ${eventType}`);
    console.log(target);
  });
});

// A durationThreshold of 16ms is necessary to include more
// interactions, since the default is 104ms. The minimum
// durationThreshold is 16ms.
po.observe({type: 'event', buffered: true, durationThreshold: 16});

Resource Timing API

Browser Support

  • Chrome: 29.
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

Source

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

  • initiatorType: วิธีดึงข้อมูลทรัพยากร เช่น จากแท็ก <script> หรือ <link> หรือจากการเรียก fetch()
  • nextHopProtocol: โปรโตคอลที่ใช้ในการดึงข้อมูลทรัพยากร เช่น h2 หรือ quic
  • encodedBodySize/decodedBodySize]: ขนาดของทรัพยากรในรูปแบบที่เข้ารหัสหรือถอดรหัส (ตามลำดับ)
  • transferSize: ขนาดของทรัพยากรที่โอนผ่านเครือข่ายจริง เมื่อแคชเป็นผู้จัดหาทรัพยากร ค่านี้อาจน้อยกว่า encodedBodySize มาก และในบางกรณีอาจเป็น 0 (หากไม่จำเป็นต้องตรวจสอบแคชซ้ำ)

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

ตัวอย่างต่อไปนี้จะบันทึกทรัพยากรทั้งหมดที่หน้าเว็บขอ และระบุว่าแคชได้จัดหาทรัพยากรแต่ละรายการหรือไม่

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log(entry.name, entry.transferSize === 0);
  }
});

// Start listening for `resource` entries to be dispatched.
po.observe({type: 'resource', buffered: true});

Browser Support

  • Chrome: 57.
  • Edge: 12.
  • Firefox: 58.
  • Safari: 15.

Source

Navigation Timing API คล้ายกับ Resource Timing API แต่จะรายงานเฉพาะคำขอการนำทาง navigation ประเภทรายการยังคล้ายกับประเภทรายการ resource แต่มีข้อมูลเพิ่มเติมบางอย่างที่เฉพาะเจาะจงสำหรับคำขอการนำทางเท่านั้น (เช่น เมื่อเหตุการณ์ DOMContentLoaded และ load ทริกเกอร์)

เมตริกหนึ่งที่นักพัฒนาซอฟต์แวร์หลายคนติดตามเพื่อทำความเข้าใจเวลาตอบสนองของเซิร์ฟเวอร์ (Time to First Byte (TTFB)) จะใช้ได้โดยใช้ Navigation Timing API ซึ่งก็คือการประทับเวลาของรายการ responseStart โดยเฉพาะ

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log('Time to first byte', entry.responseStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

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

คุณสามารถกำหนดเวลาเริ่มต้นของ Service Worker สำหรับคำขอไปยังส่วนต่างๆ ที่เฉพาะเจาะจงได้จากส่วนต่างระหว่าง entry.responseStart กับ entry.workerStart

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Service Worker startup time:',
        entry.responseStart - entry.workerStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

Server Timing API

Browser Support

  • Chrome: 65.
  • Edge: 79.
  • Firefox: 61.
  • Safari: 16.4.

Source

Server Timing API ช่วยให้คุณส่งข้อมูลเวลาที่เฉพาะเจาะจงคำขอจากเซิร์ฟเวอร์ไปยังเบราว์เซอร์ผ่านส่วนหัวของการตอบกลับได้ เช่น คุณระบุระยะเวลาที่ใช้ในการค้นหาข้อมูลในฐานข้อมูลสำหรับคำขอหนึ่งๆ ได้ ซึ่งอาจเป็นประโยชน์ในการแก้ไขข้อบกพร่องด้านประสิทธิภาพที่เกิดจากเซิร์ฟเวอร์ทำงานช้า

สำหรับนักพัฒนาซอฟต์แวร์ที่ใช้ผู้ให้บริการวิเคราะห์บุคคลที่สาม Server Timing API เป็นวิธีเดียวในการเชื่อมโยงข้อมูลประสิทธิภาพของเซิร์ฟเวอร์กับเมตริกทางธุรกิจอื่นๆ ที่เครื่องมือวิเคราะห์เหล่านี้อาจวัด

หากต้องการระบุข้อมูลการกำหนดเวลาของเซิร์ฟเวอร์ในการตอบกลับ คุณสามารถใช้ส่วนหัวการตอบกลับ Server-Timing ได้ ตัวอย่างเช่น

HTTP/1.1 200 OK

Server-Timing: miss, db;dur=53, app;dur=47.2

จากนั้นคุณจะอ่านข้อมูลนี้ได้ทั้งในรายการ resource หรือ navigation จาก Resource Timing และ Navigation Timing API

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Logs all server timing data for this response
    console.log('Server Timing', entry.serverTiming);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});