วิธีวัด Web Vitals ด้วยเครื่องมือวิเคราะห์ปัจจุบัน
ความสามารถในการวัดผลและรายงานประสิทธิภาพจริงของหน้าเว็บเป็นสิ่งสำคัญสำหรับการวินิจฉัยและปรับปรุงประสิทธิภาพเมื่อเวลาผ่านไป หากไม่มีข้อมูลช่อง ก็คงเป็นไปไม่ได้ที่จะรู้แน่ชัดว่าการเปลี่ยนแปลงที่คุณทำในเว็บไซต์จะให้ผลลัพธ์ตามที่ต้องการจริงหรือไม่
ผู้ให้บริการวิเคราะห์ Real User Monitoring (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 ขั้นตอนดังนี้
- กำหนดหรือลงทะเบียนเมตริกที่กำหนดเองในผู้ดูแลระบบของเครื่องมือ (หากจำเป็น) (หมายเหตุ: ผู้ให้บริการวิเคราะห์บางรายอาจไม่ได้กำหนดให้ต้องมีการกำหนดเมตริกที่กำหนดเองล่วงหน้า)
- คำนวณค่าของเมตริกในโค้ด JavaScript ของฟรอนท์เอนด์
- ส่งค่าเมตริกไปยังแบ็กเอนด์ข้อมูลวิเคราะห์ ตรวจสอบว่าชื่อหรือรหัสตรงกับที่กำหนดไว้ในขั้นตอนที่ 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 แต่ละรายการและส่งให้กับบริการวิเคราะห์โดยใช้เมตริกหรือเหตุการณ์ที่กําหนดเองแล้ว ขั้นตอนถัดไปคือการสร้างรายงานหรือหน้าแดชบอร์ดที่แสดงค่าที่รวบรวมไว้
เพื่อให้แน่ใจว่าคุณมีคุณสมบัติตรงตามเกณฑ์ Core Web Vitals ที่แนะนำ คุณจะต้องให้รายงานแสดงค่าของแต่ละเมตริกที่เปอร์เซ็นไทล์ที่ 75
หากเครื่องมือวิเคราะห์ไม่ได้เสนอการรายงานควอนไทล์เป็นฟีเจอร์ในตัว คุณยังคงสามารถรับข้อมูลนี้ด้วยตนเองได้โดยการสร้างรายงานที่แสดงรายการค่าเมตริกทั้งหมดโดยจัดเรียงจากน้อยไปมาก เมื่อสร้างรายงานนี้แล้ว ผลลัพธ์ซึ่งอยู่ที่ 75% ของรายการค่าทั้งหมดที่จัดเรียงและสมบูรณ์ในรายงานนั้นจะเป็นเปอร์เซ็นไทล์ที่ 75 สำหรับเมตริกนั้น และนี่จะเป็นเช่นนี้ ไม่ว่าคุณจะแบ่งกลุ่มข้อมูลอย่างไร (ตามประเภทอุปกรณ์ ประเภทการเชื่อมต่อ ประเทศ ฯลฯ)
หากเครื่องมือวิเคราะห์ไม่ได้ให้ข้อมูลการรายงานระดับเมตริกแบบละเอียดโดยค่าเริ่มต้น คุณอาจได้ผลลัพธ์เดียวกันหากเครื่องมือวิเคราะห์รองรับมิติข้อมูลที่กำหนดเอง เมื่อตั้งค่ามิติข้อมูลที่กำหนดเองแบบไม่ซ้ำกันสำหรับอินสแตนซ์เมตริกแต่ละรายการที่ติดตาม คุณควรสร้างรายงานโดยแจกแจงตามอินสแตนซ์ของเมตริกแต่ละรายการได้ หากคุณรวมมิติข้อมูลที่กำหนดเองไว้ในการกำหนดค่ารายงาน เนื่องจากอินสแตนซ์แต่ละรายการจะมีค่ามิติข้อมูลที่ไม่ซ้ำกัน จะไม่มีการจัดกลุ่ม
รายงาน Web Vitals เป็นตัวอย่างของเทคนิคนี้ที่ใช้ Google Analytics โค้ดสำหรับรายงานเป็นโอเพนซอร์ส เพื่อให้นักพัฒนาซอฟต์แวร์อ้างอิงเป็นตัวอย่างของเทคนิคที่ระบุไว้ในส่วนนี้ได้
ส่งข้อมูลในเวลาที่เหมาะสม
เมตริกประสิทธิภาพบางรายการสามารถคำนวณได้เมื่อหน้าเว็บโหลดเสร็จแล้ว ขณะที่เมตริกอื่นๆ (เช่น CLS) จะคำนวณอายุการใช้งานทั้งหมดของหน้าเว็บ และจะนับว่าเป็นเมตริกสุดท้ายหลังจากที่เริ่มยกเลิกการโหลดแล้วเท่านั้น
อย่างไรก็ตาม วิธีนี้อาจสร้างปัญหาได้เนื่องจากทั้งเหตุการณ์ beforeunload และ unload ไม่น่าเชื่อถือ (โดยเฉพาะในอุปกรณ์เคลื่อนที่) และไม่แนะนําการใช้งาน (เนื่องจากอาจทำให้หน้าเว็บไม่มีสิทธิ์ใช้แคชย้อนหลัง)
สำหรับเมตริกที่ติดตามอายุการใช้งานทั้งหมดของหน้าเว็บ วิธีที่ดีที่สุดคือการส่งค่าปัจจุบันของเมตริกเท่าไรก็ตามในระหว่างเหตุการณ์ visibilitychange เมื่อใดก็ตามที่สถานะระดับการเข้าถึงของหน้าเว็บเปลี่ยนเป็น hidden ที่เป็นเช่นนี้เพราะเมื่อสถานะการเปิดเผยของหน้าเปลี่ยนเป็น hidden แล้วไม่ได้เป็นการรับประกันว่าสคริปต์ใดๆ ในหน้าเว็บนั้นจะทำงานได้อีกครั้ง โดยเฉพาะอย่างยิ่งในระบบปฏิบัติการบนอุปกรณ์เคลื่อนที่ซึ่งแอปเบราว์เซอร์สามารถปิดได้โดยที่โค้ดเรียกกลับของหน้าเว็บไม่ทำงาน
โปรดทราบว่าระบบปฏิบัติการบนอุปกรณ์เคลื่อนที่มักจะทำให้เหตุการณ์ visibilitychange เริ่มทำงานเมื่อมีการสลับแท็บ เปลี่ยนแอป หรือปิดแอปเบราว์เซอร์
และเหตุการณ์ visibilitychange ก็เริ่มทํางานเมื่อปิดแท็บหรือไปยังหน้าใหม่ด้วย ซึ่งทำให้เหตุการณ์ visibilitychange มีความเสถียรมากกว่าเหตุการณ์ unload หรือ beforeunload มาก
ตรวจสอบประสิทธิภาพเมื่อเวลาผ่านไป
เมื่อคุณอัปเดตการใช้งานข้อมูลวิเคราะห์สำหรับทั้งติดตามและรายงานเมตริก Core Web Vitals แล้ว ขั้นตอนต่อไปคือการติดตามว่าการเปลี่ยนแปลงเว็บไซต์ส่งผลต่อประสิทธิภาพเมื่อเวลาผ่านไปอย่างไร
กำหนดเวอร์ชันการเปลี่ยนแปลง
วิธีแบบซื่อๆ (และไม่น่าเชื่อถือในท้ายที่สุด) ในการติดตามการเปลี่ยนแปลงคือการทำให้การเปลี่ยนแปลงใช้งานได้จริง แล้วสมมติว่าเมตริกทั้งหมดที่ได้รับหลังจากวันที่ติดตั้งใช้งานสอดคล้องกับเว็บไซต์ใหม่ และเมตริกทั้งหมดที่ได้รับก่อนวันที่ติดตั้งใช้งานจะตรงกับเว็บไซต์เก่า อย่างไรก็ตาม ปัจจัยหลายประการ (รวมถึงการแคชที่ HTTP, Service Worker หรือเลเยอร์ CDN) อาจทำให้การทำงานหยุดชะงักได้
วิธีที่ดีกว่ามากคือการสร้างเวอร์ชันที่ไม่ซ้ำกันสำหรับการเปลี่ยนแปลงที่นำไปใช้แต่ละครั้ง จากนั้นติดตามเวอร์ชันนั้นในเครื่องมือวิเคราะห์ เครื่องมือวิเคราะห์ส่วนใหญ่ รองรับการตั้งค่าเวอร์ชัน หากไม่มี คุณสร้างมิติข้อมูลที่กำหนดเองและตั้งค่ามิติข้อมูลนั้นเป็นเวอร์ชันที่ทำให้ใช้งานได้แล้ว
ทำการทดสอบ
คุณสามารถดำเนินการสร้างเวอร์ชันเพิ่มขึ้นอีก 1 ระดับโดยการติดตามเวอร์ชัน (หรือการทดสอบ) หลายรายการพร้อมกัน
หากเครื่องมือวิเคราะห์ให้คุณกำหนดกลุ่มทดสอบได้ ให้ใช้ฟีเจอร์นั้น หรือ คุณสามารถใช้มิติข้อมูลที่กำหนดเองเพื่อให้แน่ใจว่าค่าเมตริกแต่ละค่าเชื่อมโยงกับกลุ่มทดสอบกลุ่มใดกลุ่มหนึ่งในรายงานได้
เมื่อมีการทดสอบในข้อมูลวิเคราะห์ คุณจะนำการเปลี่ยนแปลงทดสอบไปใช้กับผู้ใช้กลุ่มย่อย และเปรียบเทียบประสิทธิภาพของการเปลี่ยนแปลงนั้นกับประสิทธิภาพของผู้ใช้ในกลุ่มควบคุมได้ เมื่อคุณมั่นใจว่าการเปลี่ยนแปลงนั้นช่วยปรับปรุงประสิทธิภาพได้จริง คุณก็เปิดตัวการเปลี่ยนแปลงนั้นกับผู้ใช้ทุกคนได้
ตรวจสอบว่าการวัดผลไม่ส่งผลต่อประสิทธิภาพ
เมื่อวัดประสิทธิภาพจากผู้ใช้จริง โค้ดการวัดประสิทธิภาพที่คุณใช้จะไม่ส่งผลเชิงลบต่อประสิทธิภาพของหน้าเว็บ หากใช่ การสรุปใดๆ ที่คุณพยายามหาว่าประสิทธิภาพส่งผลต่อธุรกิจอย่างไรจะไม่น่าเชื่อถือ เนื่องจากคุณจะไม่มีทางรู้เลยว่าการมีโค้ด Analytics นั้นสร้างผลกระทบในเชิงลบได้มากที่สุดหรือไม่
โปรดทำตามหลักการเหล่านี้เสมอเมื่อติดตั้งใช้งานโค้ดการวิเคราะห์ RUM ในเว็บไซต์ที่ใช้งานจริง
เลื่อนข้อมูลวิเคราะห์
โค้ด Analytics ควรโหลดแบบไม่พร้อมกันและไม่บล็อกเสมอ และโดยทั่วไปแล้วควรจะโหลดเป็นลำดับท้ายสุด หากคุณโหลดโค้ด Analytics ในลักษณะที่เป็นการบล็อก อาจส่งผลเสียต่อ LCP ได้
API ทั้งหมดที่ใช้วัดเมตริก Core Web Vitals ออกแบบมาโดยเฉพาะเพื่อรองรับการโหลดสคริปต์แบบไม่พร้อมกันและที่มีการเลื่อนเวลา (ผ่านแฟล็ก buffered) คุณจึงไม่จำเป็นต้องรีบโหลดสคริปต์ก่อน
ในกรณีที่คุณกำลังวัดเมตริกซึ่งคำนวณภายหลังในไทม์ไลน์การโหลดหน้าเว็บไม่ได้ คุณควรแทรกโค้ดที่ต้องเรียกใช้ในตอนต้นของ <head> ของเอกสารไว้เฉพาะเท่านั้น (เพื่อไม่ให้เป็นคำขอบล็อกการแสดงผล) และเลื่อนเวลาที่เหลือออกไป อย่าโหลดข้อมูลวิเคราะห์ทั้งหมดตั้งแต่เนิ่นๆ
เพียงเพราะเมตริกเดียวจำเป็นต้องใช้
อย่าสร้างงานที่ใช้เวลานาน
โค้ด Analytics มักจะทำงานตามอินพุตของผู้ใช้ แต่หากโค้ดการวิเคราะห์ทำการวัด DOM จำนวนมากหรือใช้ API อื่นๆ ที่ใช้ตัวประมวลผลอย่างหนัก โค้ด Analytics เองอาจทำให้การตอบสนองของอินพุตแย่ลง นอกจากนี้ หากไฟล์ JavaScript ที่มีโค้ด Analytics ของคุณมีขนาดใหญ่ การเรียกใช้ไฟล์นั้นอาจบล็อกเทรดหลักและส่งผลเสียต่อ Interaction to Next Paint (INP) ของหน้าเว็บ
ใช้ API ที่ไม่บล็อก
API เช่น
sendBeacon()
และ
requestIdleCallback()
ออกแบบมาสำหรับการเรียกใช้งานที่ไม่สำคัญโดยเฉพาะ โดยไม่บล็อกงานที่สำคัญต่อผู้ใช้
API เหล่านี้เป็นเครื่องมือที่ยอดเยี่ยมสำหรับใช้ในไลบรารีข้อมูลวิเคราะห์ของ RUM
โดยทั่วไปแล้ว บีคอนการวิเคราะห์ทั้งหมดควรส่งโดยใช้ sendBeacon() API (หากมี) และโค้ดการวัดแบบแพสซีฟ Analytics ทั้งหมดควรทำงานในช่วงเวลาที่ไม่ได้ใช้งาน
ไม่ติดตามมากกว่าจำนวนที่คุณต้องการ
เบราว์เซอร์เปิดเผยข้อมูลประสิทธิภาพจำนวนมาก แต่เพียงเพราะข้อมูลพร้อมใช้งานไม่ได้หมายความว่าคุณควรบันทึกและส่งไปยังเซิร์ฟเวอร์การวิเคราะห์ของคุณเสมอไป
ตัวอย่างเช่น Resource Timing API จะให้ข้อมูลเวลาโดยละเอียดสำหรับทรัพยากรทุกรายการที่โหลดบนหน้าเว็บ อย่างไรก็ตาม มีโอกาสน้อยมากที่ข้อมูลทั้งหมดเหล่านี้อาจจำเป็นหรือเป็นประโยชน์ในการปรับปรุงประสิทธิภาพการโหลดทรัพยากร
พูดง่ายๆ ก็คือ อย่าติดตามแค่ข้อมูลเนื่องจากมีข้อมูลอยู่ในนั้น ให้มั่นใจได้ว่าจะมีการใช้ข้อมูล ก่อนที่จะใช้ทรัพยากรในการติดตามข้อมูล