Bắt đầu từ các hành trình, không phải trung bình toàn trang
Liệt kê ba đến năm hành trình mà độ trễ gây chi phí rõ ràng cho khách hàng hoặc vận hành: truy cập trang chiến dịch, tìm một sản phẩm, gửi form khách hàng tiềm năng, đăng nhập, hoặc hoàn thành yêu cầu hỗ trợ. Với mỗi hành trình, ghi điểm bắt đầu, kết quả hữu ích, lớp thiết bị chính, và trang hoặc tương tác cần hoạt động tốt.
Cho mỗi hành trình một hàng ngân sách riêng. Một bảng điều khiển (dashboard) có thể mang nhiều mã hơn một bài viết công khai, nhưng hành động lọc của nó cần một mục tiêu về độ phản hồi. Một trang sản phẩm nhiều media có thể chấp nhận ảnh lớn hơn, nhưng cần giới hạn cho hình ảnh chính hiển thị. Điều này ngăn con đường quan trọng yếu bị che lấp trong một giá trị trung bình theo origin.
Ghi rõ khách truy cập có thể thấy hoặc làm gì, chẳng hạn đọc ưu đãi, thấy kết quả, hoặc nhận xác nhận gửi form.
Bộ nhớ đệm (caching) có thể thay đổi đáng kể chi phí tài nguyên, vì vậy ghi liệu ngân sách áp dụng cho lần truy cập đầu tiên, truy cập lặp lại, hay cả hai.
Chọn kết quả và các đầu vào có thể kiểm soát
Sử dụng cả chỉ số kết quả và giới hạn đầu vào. Google mô tả Largest Contentful Paint (LCP) là hiệu năng tải, Interaction to Next Paint (INP) là độ phản hồi tương tác, và Cumulative Layout Shift (CLS) là ổn định hình ảnh. Ngưỡng tốt được khuyến nghị là LCP ≤ 2.5 giây, INP ≤ 200 mili giây, và CLS ≤ 0.1 tại bách phân vị thứ 75, xét riêng cho mobile và desktop.
Thêm các giới hạn giúp lộ nguyên nhân sớm: JavaScript ban đầu, ảnh cần thiết trước khi nội dung chính xuất hiện, tổng dung lượng truyền cho tuyến đường, các yêu cầu bên thứ ba, và widget đã biết tốn kém. Theo dõi kích thước truyền nén một cách nhất quán. Các chẩn đoán như Time to First Byte có thể giúp điều tra tải chậm, nhưng bản thân nó không phải là kết quả khách hàng.
Dùng LCP khi hành trình phụ thuộc vào việc nội dung chính hiển thị.
Dùng INP từ dữ liệu trường (field INP) cho tìm kiếm, lọc, menu và thanh toán; chỉ dùng proxy phòng thí nghiệm trước khi có dữ liệu trường.
Giới hạn tuyến đường khởi tạo và các thành phần đóng góp lớn nhất để người chịu trách nhiệm biết cần thay đổi gì sau khi vi phạm.
Đặt con số từ mức cơ sở của bạn
Ghi nhận một mức cơ sở cho mỗi hành trình. Trong PageSpeed Insights, phân biệt dữ liệu trường từ Chrome User Experience Report (CrUX), vốn tổng hợp trải nghiệm thực tế của người dùng Chrome, với dữ liệu phòng thí nghiệm của Lighthouse, là một bài kiểm tra có điều kiện. Dữ liệu trường kiểm tra trải nghiệm tới người dùng; bài kiểm tra phòng thí nghiệm giúp lặp lại thay đổi trước khi phát hành.
Phân đoạn ít nhất theo mobile và desktop và, nếu có thể, theo template quan trọng hoặc URL. PageSpeed Insights có thể lui về dữ liệu origin khi không có dữ liệu URL, và một số trang không có dữ liệu CrUX. Gắn nhãn trường hợp đó là mức cơ sở phòng thí nghiệm và thêm phép đo người dùng thực cho các hành trình quan trọng. Giữ lại URL kiểm tra, cấu hình thiết bị và mạng, trạng thái cache, ngày tháng và phiên bản công cụ cùng với mỗi mức cơ sở.
Chọn mục tiêu cải thiện mức cơ sở theo một bước có kế hoạch, rồi thử trên các điều kiện đại diện. Một ngân sách chặn các bản phát hành bình thường sẽ bị bỏ qua; một ngân sách ở trên trải nghiệm hiện tại sẽ không bảo vệ ai cả.
Bách phân vị thứ 75 là giá trị mà 75% các trải nghiệm quan sát được có giá trị bằng hoặc nhỏ hơn; nó không phải là một giá trị trung bình.
Biến ngân sách thành quy tắc phát hành
Giữ ngân sách ở nơi có phiên bản và có thể xem xét kèm theo mã hoặc danh sách kiểm tra phát hành. Mỗi hàng cần hành trình, chỉ số, cấu hình thử nghiệm hoặc dân số, ngưỡng cảnh báo, ngưỡng lỗi, chủ sở hữu, phương pháp đo và lộ trình ngoại lệ. MDN khuyến nghị có mức cảnh báo và mức lỗi: cảnh báo hỗ trợ lập kế hoạch chủ động, trong khi lỗi là giới hạn trên với ảnh hưởng tiêu cực dễ nhận biết.
Tự động hoá các kiểm tra đáng tin cậy. Một bundler có thể từ chối tài nguyên quá lớn hoặc điểm vào ban đầu; webpack hỗ trợ giới hạn kích thước tài sản tối đa và điểm vào cùng gợi ý lỗi trong production. Chạy các bài kiểm tra phòng thí nghiệm có thể lặp lại cho hành trình liên quan trong pull request hoặc release candidate. Giữ chỉ số trường để xác minh và ưu tiên sau phát hành thay vì dùng một cổng build không đáng tin cậy.
Khi vượt ngưỡng, giảm kích thước tài nguyên, trì hoãn mã không thiết yếu, thay đổi trải nghiệm, tách bản phát hành, hoặc phê duyệt ngoại lệ. Không âm thầm nâng ngưỡng để vượt build.
Ghi lại chủ sản phẩm và chủ kỹ thuật, tác động tới khách hàng, ngày hết hạn và nhiệm vụ khắc phục trước khi phát hành.
Chặn ngưỡng lỗi có thể tái tạo trên hành trình được bảo vệ; thông báo và điều tra các ngưỡng cảnh báo.
Xác minh và khắc phục sau khi ra mắt
Trọng lượng trang không dự đoán đầy đủ trải nghiệm. Thứ tự yêu cầu, công việc chặn render, khả năng thiết bị, điều kiện mạng, bộ nhớ đệm và bên thứ ba cũng quan trọng. Giữ giới hạn đầu vào để phát hiện tăng trưởng và các chỉ số kết quả để kiểm tra liệu con đường có thể sử dụng được hay không. Giao diện W3C Resource Timing tiết lộ thời lượng tài nguyên và kích thước truyền, kích thước mã hóa và giải mã để chẩn đoán sâu hơn. Chi tiết thời gian cross-origin có thể bị hạn chế bởi quyền timing, nên một biểu đồ waterfall không đầy đủ không chứng minh không có chi phí bên thứ ba.
Xem lại kết quả trường sau các thay đổi lớn về template, nền tảng, tag tiếp thị hoặc lưu lượng. Nếu LCP xấu đi, kiểm tra phản hồi máy chủ, tài nguyên gây LCP và công việc chặn render. Nếu INP xấu đi, kiểm tra các tương tác thực tế; Lighthouse không thể đo INP vì không có đầu vào người dùng, dù Total Blocking Time là một proxy phòng thí nghiệm. Dùng quy trình tối ưu hóa chủ động của SIU để phân loại sự vi phạm, ổn định con đường quan trọng và xác minh bản sửa trong cùng ngữ cảnh đo lường.
Ngoại lệ đã hết hạn nhanh chóng cho thấy nợ hiệu năng tạm thời đã trở thành cố định.