วิธีตรวจสอบ Core Web Vitals: คู่มือฉบับสมบูรณ์สำหรับทีมเว็บ

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

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

ตอบ-สรุปข้อแรก

การตรวจสอบ Core Web Vitals จำเป็นต้องรวมการตรวจสอบในห้องปฏิบัติการ Lighthouse สังเคราะห์ (สำหรับการทดสอบการถดถอยที่ทำซ้ำได้ในระหว่าง CI/CD) เข้ากับข้อมูลภาคสนามของผู้ใช้จริงจากรายงาน Chrome UX (CrUX) สำหรับการประเมินเปอร์เซ็นไทล์ที่ 75 ในอุปกรณ์จริงตัวชี้วัดทั้งสาม ได้แก่ Largest Contentful Paint ($\le 2.5\text {s} $), การโต้ตอบกับ Next Paint ($\le 200\text {ms} $) และ Cumulative Layout Shift ($\le 0.1$)แพลตฟอร์มอัตโนมัติ เช่น SimpleOps ติดตามทั้งตัววัดในห้องปฏิบัติการและภาคสนาม จัดส่งการแจ้งเตือนผ่าน Slack, Telegram หรือ Webhooks เมื่อตัววัดเปอร์เซ็นไทล์ที่ 75 ละเมิดงบประมาณด้านประสิทธิภาพ

อธิบายเมตริกหลัก 3 ประการของ Web Vitals

Google ประเมินประสิทธิภาพของเว็บไซต์โดยพิจารณาจากตัวชี้วัดหลักสามประการ:

1. Largest Contentful Paint (LCP): วัดความเร็วในการโหลดหน้าเว็บที่รับรู้โดยจับเวลาเมื่อเนื้อหาหลักหรือบล็อกรูปภาพ/ข้อความที่ใหญ่ที่สุดเสร็จสิ้นการเรนเดอร์ในวิวพอร์ตเป้าหมาย: $\le 2.5\text {s} $
2. การโต้ตอบกับ Next Paint (INP): วัดการตอบสนองของอินเทอร์เฟซโดยรวมโดยการติดตามเวลาแฝงของการคลิก การแตะ และการกดปุ่มของผู้ใช้ตลอดการเข้าชมเพจเป้าหมาย: $\le 200\text {ms} $
3. Cumulative Layout Shift (CLS): วัดความเสถียรของการมองเห็นโดยการคำนวณการเคลื่อนไหวของเลย์เอาต์ที่ไม่คาดคิดระหว่างการแสดงเพจเป้าหมาย: $\le 0.1$.

ข้อมูลห้องปฏิบัติการเทียบกับข้อมูลภาคสนาม: แนวทางการใช้เครื่องยนต์คู่

การตรวจสอบ Core Web Vitals ที่มีประสิทธิภาพต้องใช้ทั้งข้อมูลในห้องปฏิบัติการ (สังเคราะห์) และภาคสนาม (ผู้ใช้จริง):

1. ข้อมูลห้องปฏิบัติการสังเคราะห์ (การตรวจสอบประภาคาร)

ข้อมูลห้องปฏิบัติการจะถูกรวบรวมในสภาพแวดล้อมที่มีการควบคุมด้วยเครือข่ายมือถือจำลองและการควบคุมปริมาณ CPUการทดสอบในห้องปฏิบัติการมีตัววัดการวินิจฉัยที่สามารถทำซ้ำได้ เช่น Total Blocking Time (TBT) และดัชนีความเร็ว ทำให้เหมาะสำหรับการทดสอบการถดถอย CI/CD ก่อนการผลิตจริง

2. ข้อมูลภาคสนามของผู้ใช้จริง (การรวม CrUX)

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

รายละเอียดโดยละเอียดของแต่ละเมตริก

1. สีเนื้อหาที่ใหญ่ที่สุด (LCP)

LCP ประเมินเวลาที่ต้องใช้สำหรับองค์ประกอบที่มองเห็นได้ที่ใหญ่ที่สุดภายในวิวพอร์ตเริ่มต้นในการวาดภาพบนหน้าจอองค์ประกอบที่มีสิทธิ์ ได้แก่ แท็ก <img>, <svg> ไฟล์รูปภาพ, กรอบโปสเตอร์วิดีโอ, ภาพพื้นหลังที่โหลดผ่าน CSS url() และที่เก็บข้อความระดับบล็อกเวลาแฝงของ LCP ประกอบด้วยสี่ส่วนย่อย:

• Time to First Byte (TTFB): การประมวลผลเซิร์ฟเวอร์และระยะเวลาการนำส่งเครือข่าย
• ความล่าช้าในการโหลดทรัพยากร: เวลาที่ผ่านไปก่อนที่เบราว์เซอร์จะค้นพบ URL รูปภาพ LCP
• ระยะเวลาการโหลดทรัพยากร: ระยะเวลาการดาวน์โหลดเครือข่ายสำหรับเนื้อหา LCP
• ความล่าช้าในการเรนเดอร์องค์ประกอบ: เวลาที่จำเป็นสำหรับการคำนวณเลย์เอาต์และการลงสีพิกเซล

2. การโต้ตอบกับ Next Paint (INP)

INP วัดการตอบสนองของ UI ในการโต้ตอบของผู้ใช้ทั้งหมด (การคลิกเมาส์ การแตะหน้าจอสัมผัส การกดแป้นพิมพ์) ในระหว่างเซสชั่นINP latency ประกอบด้วยสามขั้นตอน:

• Input Delay: หน่วงเวลาในการรองาน CPU ของเธรดหลักเพื่อล้างก่อนที่ Listener เหตุการณ์จะทำงาน
• ระยะเวลาการประมวลผล: เวลาดำเนินการของเครื่องจัดการเหตุการณ์ JavaScript
• ความล่าช้าในการนำเสนอ: การคำนวณเฟรม การคำนวณรูปแบบใหม่ และระยะเวลาการทาสีฮาร์ดแวร์ที่แสดง

3. การเปลี่ยนแปลงเค้าโครงสะสม (CLS)

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

ข้อผิดพลาดทั่วไปและการแก้ไขปัญหาการวินิจฉัย

ทีมวิศวกรมักพบกับการถดถอยของประสิทธิภาพที่เกิดจากปัญหาการใช้งานส่วนหน้าที่ละเอียดอ่อน:

1. Lazy Loading Hero Images: การใช้ loading="lazy" กับรูปภาพแบนเนอร์ของ Hero จะทำให้การค้นหาทรัพยากรล่าช้า ส่งผลให้ LCP แย่ลงใช้ fetchpriority="high" บนเนื้อหา LCP แทนเสมอ
2. รูปภาพและโฆษณาแบบไดนามิกที่ไม่ได้ปรับขนาด: การแทรกโฆษณาแบนเนอร์แบบไดนามิกหรือรูปภาพบนเว็บโดยไม่มีแอตทริบิวต์ width และ height CSS ที่ชัดเจนจะกระตุ้นให้เกิดการเปลี่ยนแปลงเลย์เอาต์ ส่งผลให้คะแนน CLS สูงขึ้น
3. Listeners เหตุการณ์แบบซิงโครนัสหนัก: การรันการคำนวณที่มีราคาแพงภายใน scroll หรือ keyup Listeners จะบล็อกเธรดหลัก ซึ่งจะทำให้ INP ลดลง

ขั้นตอนการดำเนินงานทีละขั้นตอน

หากต้องการสร้างการตรวจสอบ Web Vitals แบบอัตโนมัติสำหรับแอปพลิเคชันของคุณ ให้ทำดังนี้

1. กำหนดเป้าหมายพื้นฐาน: กำหนดเกณฑ์สูงสุดที่อนุญาต (เช่น LCP $\le 2.2\text {s} $, INP $\le 180\text {ms} $, CLS $\le 0.05$)
2. กำหนดค่าการตรวจสอบสังเคราะห์: กำหนดเวลาการตรวจสอบ Lighthouse อัตโนมัติทุกชั่วโมงใน SimpleOps จากโหนดผู้ปฏิบัติงานทั่วโลก
3. เชื่อมต่อการซิงค์ฟิลด์ CrUX: เปิดใช้งานการซิงโครไนซ์ชุดข้อมูลฟิลด์ CrUX รายวันสำหรับโปรไฟล์โดเมนที่ลงทะเบียนของคุณ
4. ตั้งค่าการแจ้งเตือนแบบหลายช่องทาง: กำหนดเส้นทางการแจ้งเตือนไปยัง Slack, Telegram หรือ Webhooks เมื่อตัวชี้วัดเปอร์เซ็นไทล์ที่ 75 ละเมิดงบประมาณประสิทธิภาพของคุณ
5. สร้างประตูประสิทธิภาพ CI/CD: เรียกใช้การตรวจสอบสังเคราะห์อัตโนมัติในไปป์ไลน์คำขอดึงเพื่อป้องกันการถดถอยก่อนที่จะรวมเข้าด้วยกัน

การตรวจสอบ Web Vitals อัตโนมัติด้วย SimpleOps

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