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

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

Philip Walton

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

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

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

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

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

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

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

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

สำหรับขั้นตอนที่ 1 และ 3 โปรดดูวิธีการในเอกสารประกอบของเครื่องมือวิเคราะห์ ในขั้นตอนที่ 2 คุณสามารถใช้ไลบรารี JavaScript ของ web-vitals เพื่อคํานวณค่าของเมตริก 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 แต่ละรายการและส่งไปยังบริการวิเคราะห์โดยใช้เมตริกหรือเหตุการณ์ที่กําหนดเองแล้ว ขั้นตอนถัดไปคือการสร้างรายงานหรือหน้าแดชบอร์ดที่แสดงค่าที่รวบรวม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ทำการทดสอบ

คุณสามารถใช้การทําเวอร์ชันไปอีกขั้นด้วยการติดตามหลายเวอร์ชัน (หรือการทดสอบ) พร้อมกัน

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

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

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

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

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

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

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

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

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

อย่าสร้างงานที่ยาว

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

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

API เช่น sendBeacon() และ requestIdleCallback() ได้รับการออกแบบมาโดยเฉพาะสำหรับการเรียกใช้งานที่ไม่ใช่งานที่สำคัญในลักษณะที่ไม่บล็อกงานที่สําคัญต่อผู้ใช้

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

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

อย่าติดตามมากกว่าที่จำเป็น

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

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

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