Họ đang đo gì
Bạn có coi hiệu năng là thứ cần bảo vệ liên tục không, hay là một dự án làm một lần.
Trả lời ngắn~30 giây
Đặt ngân sách và cho CI thất bại khi vượt: kích thước bundle theo từng entry, số truy vấn cho các endpoint chính, và Core Web Vitals đo trên môi trường giống production. Điểm mấu chốt là ngưỡng phải CHẶN merge — một dashboard mà không ai bị chặn thì chỉ ghi lại quá trình xuống dốc chứ không ngăn được nó.
Giải thích sâu
Ngân sách chỉ hoạt động khi con số đến từ yêu cầu chứ không từ hiện trạng. “Giữ ở mức hôm nay” thì bạn khoá lại cả những gì đã tệ; “LCP dưới 2,5 giây trên mạng 4G ở thiết bị tầm trung” thì bạn có một mục tiêu nói được với cả người không viết code. Con số thứ hai còn sống sót qua các cuộc tranh luận về ưu tiên, con số thứ nhất thì không.
Đo trong CI có một cái bẫy: máy CI có hiệu năng dao động, nên đo thời gian trực tiếp sẽ cho kết quả rung và đội sẽ học cách bỏ qua nó. Những chỉ số ỔN ĐỊNH thì đáng chặn: kích thước byte, số truy vấn, số request — chúng xác định và không phụ thuộc máy. Còn LCP và INP thì đo trên dữ liệu người dùng thật và theo dõi theo xu hướng, chứ đừng chặn PR bằng chúng.
Phần khó nhất không phải kỹ thuật: khi ngân sách chặn một PR quan trọng lúc 5 giờ chiều thứ Sáu, ai đó sẽ đề nghị nới ngưỡng. Nên quy trình cần một đường thoát tường minh — được phép vượt ngân sách với một ticket ghi lý do và hạn xử lý. Không có đường thoát thì ngân sách sẽ bị gỡ bỏ hoàn toàn trong lần đầu tiên nó gây bất tiện.
Câu hỏi tiếp theo họ sẽ hỏi
?Đo Core Web Vitals của người dùng thật bằng cách nào?
Thư viện web-vitals gửi số đo về endpoint của bạn, hoặc lấy từ CrUX nếu site đủ lưu lượng. Điểm quan trọng là chia theo nhóm — thiết bị, quốc gia, loại trang — vì một trung vị đẹp có thể che hoàn toàn việc trang danh mục trên Android tầm thấp đang rất tệ.
Trả lời thế này là mất điểm
- Có dashboard mà không có ngưỡng chặn. Nó ghi lại việc trang chậm dần, và ghi lại rất chính xác.