เมตริกใน CrUX ขับเคลื่อนโดย API ของแพลตฟอร์มเว็บมาตรฐานที่เบราว์เซอร์แสดง ในชุดข้อมูล BigQuery โดยเฉพาะ ข้อมูลนี้จะได้รับการรวบรวมเพื่อการแก้ปัญหาที่มา เจ้าของเว็บไซต์ที่ต้องการการวิเคราะห์และข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพของเว็บไซต์อย่างละเอียดมากขึ้น (เช่น ความละเอียดระดับ URL) สามารถใช้ API เดียวกันเพื่อรวบรวมข้อมูลการวัดผลของผู้ใช้จริง (RUM) แบบละเอียดสำหรับต้นทางของตนเองได้ โปรดทราบว่าแม้ว่า API ทั้งหมดจะพร้อมใช้งานใน Chrome แต่เบราว์เซอร์อื่นๆ อาจไม่รองรับชุดเมตริกทั้งหมด
เมตริกส่วนใหญ่แสดงเป็นการรวมฮิสโตแกรม ซึ่งช่วยให้เห็นภาพการกระจายและค่าเปอร์เซ็นไทล์โดยประมาณ
การเปลี่ยนเลย์เอาต์สะสม
"Cumulative Layout Shift (CLS) เป็นเมตริกสำคัญที่มุ่งเน้นผู้ใช้เป็นหลักสำหรับการวัดความเสถียรของภาพ เนื่องจากช่วยวัดความถี่ที่ผู้ใช้พบเลย์เอาต์ที่เปลี่ยนแปลงโดยไม่คาดคิด ซึ่ง CLS ต่ำจะช่วยให้มั่นใจได้ว่าหน้าเว็บจะสร้างความพึงพอใจ"
เนื้อหา DOM ที่โหลด
"DOMContentLoaded รายงานเวลาที่เอกสาร HTML เริ่มต้นโหลดและแยกวิเคราะห์เสร็จสมบูรณ์ โดยไม่รอให้สไตล์ชีต รูปภาพ หรือ เฟรมย่อยโหลดเสร็จ"
การลงสีเป็นครั้งแรก
"First Paint รายงานเวลาที่เบราว์เซอร์แสดงผลเป็นครั้งแรกหลังการนำทาง โดยไม่รวมสีพื้นหลังเริ่มต้น แต่รวมสีพื้นหลังที่ไม่ใช่สีเริ่มต้น นี่คือช่วงเวลาสำคัญแรกที่นักพัฒนาซอฟต์แวร์ให้ความสำคัญในการโหลดหน้าเว็บ ซึ่งเป็นช่วงเวลาที่เบราว์เซอร์เริ่มแสดงผลหน้าเว็บ"
First Contentful Paint
"First Contentful Paint (FCP) รายงานเวลาที่เบราว์เซอร์แสดงผลข้อความ, รูปภาพ (รวมถึงภาพพื้นหลัง), Canvas ที่ไม่ได้เป็นสีขาว หรือ SVG เป็นครั้งแรก โดยรวมถึงข้อความที่มีเว็บฟอนต์ที่รอดำเนินการ นี่เป็นครั้งแรกที่ผู้ใช้เริ่มดูเนื้อหาในหน้าได้"
Interaction to Next Paint
"Interaction to Next Paint (INP) เป็นเมตริกภาคสนามที่ประเมินการตอบสนอง INP จะบันทึกระยะเวลาในการตอบสนองของการโต้ตอบทั้งหมดตลอดวงจรการโหลดหน้าเว็บทั้งหมด ระบบจะบันทึกค่าสูงสุดของการโต้ตอบเหล่านั้น หรือค่าที่ใกล้เคียงกับค่าสูงสุดสำหรับหน้าเว็บที่มีการโต้ตอบจำนวนมากเป็น INP ของหน้าเว็บ INP ต่ำช่วยให้มั่นใจได้ว่าหน้าเว็บจะตอบสนองได้อย่างน่าเชื่อถือตลอดเวลา"
เราได้เพิ่ม Interaction to Next Paint (INP) ลงในชุดข้อมูล CrUX ในเดือนกุมภาพันธ์ 2022 เมตริกใหม่นี้จะบันทึกเวลาในการตอบสนองแบบครบวงจรของแต่ละเหตุการณ์ และให้ภาพรวมที่ครอบคลุมมากขึ้นเกี่ยวกับความสามารถในการตอบสนองโดยรวมของหน้าเว็บตลอดอายุการใช้งาน
การแสดงผลเนื้อหาขนาดใหญ่ที่สุด
"Largest Contentful Paint (LCP) เป็นเมตริกสำคัญที่มุ่งเน้นผู้ใช้เป็นหลักสำหรับการวัดความเร็วในการโหลดที่รับรู้ได้ เนื่องจากจะระบุจุดในไทม์ไลน์การโหลดหน้าเว็บเมื่อเนื้อหาหลักของหน้าโหลดขึ้น ซึ่ง LCP ที่รวดเร็วจะช่วยให้ผู้ใช้มั่นใจได้ว่าหน้าเว็บมีประโยชน์"
ประเภททรัพยากร Largest Contentful Paint
"LCP รายงานเวลาในการแสดงผลของรูปภาพ บล็อกข้อความ หรือวิดีโอที่ใหญ่ที่สุดซึ่งมองเห็นได้ในวิวพอร์ต เมื่อเทียบกับเวลาที่ผู้ใช้เข้าชมหน้าเว็บเป็นครั้งแรก"
web.dev/articles/lcp - What elements are considered for LCP
ข้อความและรูปภาพ (รวมถึงรูปภาพเฟรมแรกของวิดีโอ) มักจะมีลักษณะการโหลดและเทคนิคการเพิ่มประสิทธิภาพที่แตกต่างกันมาก การทำความเข้าใจอัตราส่วนของประเภททรัพยากร LCP จะช่วยให้คุณเข้าใจเมตริก LCP และเส้นทางการเพิ่มประสิทธิภาพได้ดียิ่งขึ้น
ดูข้อมูลเพิ่มเติมได้ที่บล็อกโพสต์เกี่ยวกับการเปิดตัวประเภททรัพยากร LCP
ส่วนย่อยของรูปภาพ Largest Contentful Paint
"การเพิ่มประสิทธิภาพสำหรับ LCP อาจเป็นงานที่ซับซ้อนมากขึ้นเมื่อ PageSpeed Insights ไม่ได้ให้คำตอบเกี่ยวกับวิธีปรับปรุงเมตริกนี้ โดยทั่วไปแล้ว สำหรับงานที่ซับซ้อน การแบ่งงานออกเป็นงานย่อยๆ ที่จัดการได้ง่ายกว่าและจัดการไปทีละงานมักจะได้ผลดีกว่า"
web.dev/articles/optimize-lcp - การแบ่ง LCP ออกเป็นส่วนย่อย
การแยก LCP ของรูปภาพออกเป็นส่วนย่อยที่สำคัญที่สุดช่วยให้ใช้คำแนะนำและแนวทางปฏิบัติแนะนำที่เฉพาะเจาะจงเกี่ยวกับวิธีเพิ่มประสิทธิภาพแต่ละส่วนได้
ส่วนย่อยของรูปภาพ LCP จะแสดงในเมตริกแยกกัน 4 รายการ ดังนี้
largest_contentful_paint_image_time_to_first_byte
largest_contentful_paint_image_resource_load_delay
largest_contentful_paint_image_resource_load_duration
largest_contentful_paint_image_element_render_delay
ระบบจะรวมส่วนย่อยสำหรับรูปภาพเท่านั้น และจะไม่รวมรูปภาพเฟรมแรกของวิดีโอเนื่องจากมีความซับซ้อนกว่าเล็กน้อยเนื่องจากเราไม่สามารถวัดเวลาในการดาวน์โหลดทั้งหมดได้ (โปรดทราบว่าเฟรมแรกของวิดีโอจะรวมอยู่ในเมตริกประเภททรัพยากร LCP ซึ่งความซับซ้อนดังกล่าวไม่เกี่ยวข้อง)
นอกจากนี้ เราจะไม่รวมส่วนย่อยของข้อความเนื่องจากมีประโยชน์น้อยกว่าและจะบิดเบือนตัวเลข LCP ของรูปภาพ สำหรับเว็บไซต์ที่ส่วนใหญ่ประกอบด้วยข้อความ LCP เมตริก TTFB โดยรวมและเมตริก FCP โดยรวมจะเป็นรายละเอียดที่มีประโยชน์ แม้ว่าเมตริกเหล่านี้จะครอบคลุม LCP ทั้งหมดและไม่ได้เจาะจงไปที่ข้อความ LCP ก็ตาม
ดูข้อมูลเพิ่มเติมได้ที่บล็อกโพสต์เกี่ยวกับการเปิดตัวส่วนย่อยของรูปภาพ LCP
ประเภทการนำทาง
เมตริกประเภทการนําทางจะแสดงรายละเอียดเปอร์เซ็นต์การดูหน้าเว็บของการนําทางต่อไปนี้
ประเภท | คำอธิบาย |
---|---|
navigate |
การโหลดหน้าเว็บที่ไม่ตรงกับหมวดหมู่อื่นๆ |
navigate_cache |
การโหลดหน้าเว็บที่ทรัพยากรหลัก (เอกสาร HTML หลัก) แสดงผลจากแคช HTTP โดยทั่วไปแล้ว เว็บไซต์มักใช้การแคชสำหรับทรัพยากรย่อย แต่เอกสาร HTML หลักมักจะแคชน้อยกว่ามาก และเมื่อแคชได้ ก็อาจส่งผลให้ประสิทธิภาพดีขึ้นอย่างเห็นได้ชัดจากการแคชในเครื่องและที่ CDN |
reload |
ผู้ใช้โหลดหน้าเว็บซ้ำโดยกดปุ่มโหลดซ้ำ กด Enter ในแถบที่อยู่ หรือยกเลิกการปิดแท็บ การโหลดหน้าเว็บซ้ำมักส่งผลให้มีการตรวจสอบซ้ำกลับไปยังเซิร์ฟเวอร์เพื่อดูว่าหน้าหลักมีการเปลี่ยนแปลงหรือไม่ เปอร์เซ็นต์การโหลดหน้าเว็บซ้ำสูงอาจบ่งบอกถึงความไม่พอใจของผู้ใช้ |
restore |
หน้าเว็บถูกโหลดซ้ำหลังจากรีสตาร์ทเบราว์เซอร์ หรือแท็บที่ถูกนำออกเนื่องจากหน่วยความจำไม่เพียงพอ สำหรับ Chrome ใน Android ระบบจะรายงานเป็น "โหลดซ้ำ" แทน |
back_forward |
การนำทางในประวัติ ซึ่งหมายความว่ามีการดูหน้าเว็บและกลับมาที่หน้าเว็บนั้นเมื่อเร็วๆ นี้ หากแคชถูกต้อง ประสบการณ์การใช้งานเหล่านี้ควรจะค่อนข้างรวดเร็ว แต่ก็ยังต้องมีการประมวลผลหน้าเว็บและเรียกใช้ JavaScript ซึ่งทั้ง 2 อย่างนี้เป็นสิ่งที่ bfcache หลีกเลี่ยง |
back_forward_cache |
การไปยังส่วนต่างๆ ในประวัติซึ่งแสดงจาก bfcache การเพิ่มประสิทธิภาพหน้าเว็บเพื่อใช้ประโยชน์จาก bfcache โดยการนำตัวบล็อกออกจะช่วยให้ประสบการณ์การใช้งานเร็วขึ้น ดังนั้นเว็บไซต์ควรมีลักษณะดังนี้ |
prerender |
หน้าเว็บแสดงผลล่วงหน้า ซึ่งคล้ายกับ bfcache ที่ช่วยให้หน้าเว็บโหลดได้เกือบจะทันที |
ในบางกรณี การโหลดหน้าเว็บอาจเป็นการรวมการนำทางหลายประเภท ในกรณีดังกล่าว CrUX จะรายงานการจับคู่แรกในลำดับย้อนกลับของตาราง (จากล่างขึ้นบน)
ดูข้อมูลเพิ่มเติมได้ในโพสต์ประกาศประเภทการนำทาง
Onload
"เหตุการณ์การโหลดจะเริ่มทำงานเมื่อหน้าเว็บและทรัพยากรที่ขึ้นอยู่กับหน้าเว็บนั้นโหลดเสร็จแล้ว"
ระยะเวลารับส่งข้อมูล
แสดงค่าประมาณเวลาไปกลับของ HTTP (เลเยอร์แอปพลิเคชัน) เมื่อเริ่มต้นการนำทาง โดยอิงตามการเชื่อมต่อเครือข่ายล่าสุด
เมตริกนี้อิงตามพร็อพเพอร์ตี้ rtt
ของ Network Information API ซึ่งเป็น API เดียวกันกับที่รับผิดชอบมิติข้อมูลประเภทการเชื่อมต่อที่มีประสิทธิภาพ (ECT) ก่อนหน้านี้
ดูข้อมูลเพิ่มเติมได้ที่บล็อกโพสต์เกี่ยวกับการเปิดตัวประเภททรัพยากร LCP
เมตริกการทดสอบ
เมตริกเวอร์ชันทดลองจะพร้อมใช้งานในชุดข้อมูล CrUX โดยใช้ BigQuery และบางเมตริกจะพร้อมใช้งานใน CrUX API ด้วย เมตริกเหล่านี้มีแนวโน้มที่จะเปลี่ยนแปลงเป็นประจำเนื่องจากมีการปรับปรุงตามความคิดเห็นของผู้ใช้ โปรดดูบันทึกประจำรุ่นเพื่อติดตามการเปลี่ยนแปลงล่าสุด
เวลาที่ได้รับข้อมูลไบต์แรก
TTFB ใน CrUX จะรวบรวมเฉพาะการโหลดหน้าเว็บแบบเต็ม ซึ่งแตกต่างจากตัวจับเวลาอื่นๆ (เช่น LCP) ที่รวบรวมในการไปยังหน้าก่อนหน้า/ถัดไปและหน้าเว็บที่แสดงผลล่วงหน้าด้วย ดังนั้น ขนาดตัวอย่างของ TTFB จึงอาจเล็กกว่าเมตริกอื่นๆ และอาจไม่จําเป็นต้องเปรียบเทียบกับเมตริกเหล่านั้นโดยตรง
TTFB ไม่ใช่การวัดเวลาตอบสนองของเซิร์ฟเวอร์โดยตรง เนื่องจากรวมการวัดก่อนหน้านั้นด้วย ซึ่งรวมถึงเวลาเปลี่ยนเส้นทาง และได้รับผลกระทบจากว่าการตอบสนองแสดงจากแคชหรือ CDN หรือจากเซิร์ฟเวอร์ โดยเฉพาะอย่างยิ่งในข้อมูลภาคสนาม เช่น CrUX ในขณะที่การทดสอบในห้องปฏิบัติการมักได้รับผลกระทบน้อยกว่าจากปัจจัยเหล่านี้ เนื่องจาก URL ปลายทางได้รับการทดสอบและมักจะยกเลิกการเปลี่ยนแปลงการแคชซ้ำๆ
ความนิยม
เมตริกอันดับความนิยมคือการวัดความนิยมของเว็บไซต์แบบสัมพัทธ์ภายในชุดข้อมูล CrUX ซึ่งวัดจากจำนวนการนําทางทั้งหมดในต้นทาง อันดับจะอยู่ในระดับ log10 โดยมีครึ่งขั้น (เช่น 1,000 อันดับแรก 5,000 อันดับแรก 10,000 อันดับแรก 50,000 อันดับแรก 100,000 อันดับแรก 500,000 อันดับแรก 1 ล้านอันดับแรก เป็นต้น) โดยแต่ละอันดับจะยกเว้นอันดับก่อนหน้า (เช่น 5,000 อันดับแรกคือ URL 4,000 รายการ โดยยกเว้น 1,000 อันดับแรก) ขีดจำกัดบนจะเปลี่ยนแปลงไปตามการเติบโตของชุดข้อมูล
ความนิยมเป็นแนวทางสำหรับการวิเคราะห์ในวงกว้าง เช่น เพื่อพิจารณาประสิทธิภาพตามประเทศสำหรับต้นทาง 1,000 อันดับแรก
สิทธิ์การแจ้งเตือน
สำหรับเว็บไซต์ที่ขอสิทธิ์แสดงการแจ้งเตือนต่อผู้ใช้ เมตริกนี้แสดงความถี่สัมพัทธ์ของการตอบสนองของผู้ใช้ต่อข้อความแจ้ง ได้แก่ ยอมรับ ปฏิเสธ ละเว้น หรือปิด