แนวทางปฏิบัติแนะนำสำหรับการวัด Web Vitals จริง

วิธีวัด Web Vitals ด้วยเครื่องมือวิเคราะห์ปัจจุบัน

Philip Walton

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

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

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

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

ใช้เมตริกหรือเหตุการณ์ที่กำหนดเอง

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

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

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

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

ตัวอย่างโค้ดต่อไปนี้แสดงให้เห็นว่าการติดตามเมตริกเหล่านี้ใน แล้วส่งไปยังบริการวิเคราะห์

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

หลีกเลี่ยงค่าเฉลี่ย

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

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

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

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

ตรวจสอบว่าคุณรายงานการเผยแพร่ได้

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

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

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

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

รายงาน Web Vitals เป็นตัวอย่างของเทคนิคนี้ที่ใช้ Google Analytics โค้ดสำหรับฟิลด์ เป็นแบบโอเพนซอร์ส เพื่อให้นักพัฒนาซอฟต์แวร์อ้างอิงว่าเป็นตัวอย่างของเทคนิคที่ระบุไว้ใน

ภาพหน้าจอของ Web Vitals รายงาน

ส่งข้อมูลในเวลาที่เหมาะสม

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

อย่างไรก็ตาม เรื่องนี้อาจเป็นปัญหาได้ เนื่องจากทั้ง beforeunload และ unload เหตุการณ์ไม่น่าเชื่อถือ (โดยเฉพาะในอุปกรณ์เคลื่อนที่) และการใช้งานนั้นไม่ใช่ แนะนำ (เนื่องจากอาจทำให้หน้าเว็บไม่มีสิทธิ์สำหรับ Back-Forward แคช)

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

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

ตรวจสอบประสิทธิภาพเมื่อเวลาผ่านไป

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

กำหนดเวอร์ชันการเปลี่ยนแปลง

วิธีการที่ไร้เดียงสา (และไม่น่าเชื่อถือในที่สุด) ในการติดตามการเปลี่ยนแปลงคือการติดตั้งใช้งาน การเปลี่ยนแปลงเป็นเวอร์ชันที่ใช้งานจริง จากนั้นจะถือว่าเมตริกทั้งหมดที่ได้รับหลังจาก วันที่ทำให้ใช้งานได้จะตรงกับเว็บไซต์ใหม่และเมตริกทั้งหมดที่ได้รับก่อน วันที่ทำให้ใช้งานได้จะตรงกับเว็บไซต์เก่า แต่ไม่ว่าจะด้วยเหตุผลใดก็ตาม (รวมถึงการแคชที่ HTTP, Service Worker หรือเลเยอร์ CDN) จะช่วยป้องกันปัญหานี้ จากการทำงาน

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

ทำการทดสอบ

คุณสามารถทำการกำหนดเวอร์ชันไปอีกขั้นด้วยการติดตามเวอร์ชันต่างๆ (หรือ ต่างๆ ในเวลาเดียวกัน

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

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

ตรวจสอบว่าการวัดผลไม่ส่งผลต่อประสิทธิภาพ

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

ปฏิบัติตามหลักการเหล่านี้เสมอเมื่อทำให้โค้ด RUM ใช้งานได้บน ไซต์ที่ใช้งานจริง:

เลื่อนข้อมูลวิเคราะห์

ควรโหลดโค้ด Analytics แบบไม่พร้อมกันและไม่บล็อกเสมอ และ โดยปกติควรจะโหลดเป็นลำดับสุดท้าย หากคุณโหลดโค้ด Analytics ใน อาจส่งผลลบต่อ LCP

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

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

อย่าสร้างงานที่ใช้เวลานาน

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

ใช้ API แบบไม่บล็อก

API เช่น sendBeacon() และ วันที่ requestIdleCallback() ได้รับการออกแบบมาเป็นพิเศษสำหรับการทำงานที่ไม่สำคัญในลักษณะที่ไม่ บล็อกงานที่สำคัญของผู้ใช้ได้

API เหล่านี้เป็นเครื่องมือที่ยอดเยี่ยมสำหรับใช้ในไลบรารีข้อมูลวิเคราะห์ของ RUM

โดยทั่วไป คุณควรส่งบีคอนการวิเคราะห์ทั้งหมดโดยใช้ sendBeacon() API (หากมี) และโค้ดการวัดการวิเคราะห์แบบแพสซีฟทั้งหมดควรทำงานระหว่าง ระยะเวลาที่ไม่มีการใช้งาน

อย่าติดตามมากกว่าสิ่งที่คุณต้องการ

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

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

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