แนวทางปฏิบัติแนะนำสำหรับการวัด 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 ให้ข้อมูลเวลาโดยละเอียดของทรัพยากรทุกรายการที่โหลดในหน้าเว็บ อย่างไรก็ตาม ข้อมูลทั้งหมดนั้นไม่จําเป็นหรือมีประโยชน์ในการปรับปรุงประสิทธิภาพการโหลดทรัพยากร

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