1. Xác định kết quả và phạm vi
Ghi tên một người chịu trách nhiệm và viết kết quả trước khi mở công cụ audit. Nêu rõ đối tượng, hành trình, các trang hoặc route, khung thời gian và quyết định mà công việc nên hỗ trợ. Một mục tiêu hữu ích mô tả một nhiệm vụ, chẳng hạn hoàn tất luồng từ sản phẩm tới giỏ hàng trên di động, chứ không phải mong muốn mơ hồ là làm cho site “nhanh hơn”.
Liệt kê những điều không thể thương lượng: luồng mua hàng hoặc gửi yêu cầu phải hoạt động, truy cập tài khoản, hành vi đồng ý (consent), khả năng truy cập (accessibility), khả năng thu thập thông tin của công cụ tìm kiếm, và nội dung đã được phê duyệt. Việc tăng điểm tổng hợp giả định không phải là chiến thắng nếu một biểu mẫu bị lỗi, nội dung bị ẩn khỏi tìm kiếm, hoặc việc sử dụng bàn phím trở nên khó khăn hơn.
Viết trang bắt đầu, hành động người dùng và trạng thái kết thúc thành công trong một câu.
Chọn một kết quả không được phép xấu đi, chẳng hạn gửi biểu mẫu thành công hoặc không phát sinh rào cản khả năng tiếp cận mới.
2. Ghi lại mức nền tương đương
Trước khi thay đổi mã, nội dung, cấu hình hoặc thẻ, lưu danh sách URL, ngày, điều kiện kiểm tra, phiên bản phát hành, báo cáo hoặc trace, và kết quả nhiệm vụ thủ công. web.dev khuyến nghị ghi lại trạng thái site trước khi thay đổi và kiểm tra nhiều loại trang; đối với single-page applications, bao gồm các route, thành phần và luồng thay vì chỉ lần tải đầu tiên.
Sử dụng nhiều góc nhìn hơn một. Lighthouse cung cấp các audit tự động về hiệu năng, khả năng truy cập, SEO và các mục khác. Kiểm tra lần tải đầu với bộ nhớ lưu trữ đã xóa hoặc profile sạch, rồi thực hiện nhiệm vụ mục tiêu. Khi có đủ dữ liệu người dùng thực, so sánh các nhóm trang và lớp thiết bị quan trọng. Core Web Vitals là các phép đo trường (field): LCP phản ánh tải, INP phản ánh tương tác, và CLS phản ánh độ ổn định hình ảnh.
Dữ liệu trường phản ánh lượt truy cập thực; kiểm tra lab giúp tái tạo vấn đề dễ hơn. Dùng cả hai khi có thể.
Một lần tải giả lập không thể đo INP vì không có tương tác người dùng; Total Blocking Time trong lab chỉ là đại diện (proxy).
3. Audit hành trình từ đầu đến cuối
Nhóm các phát hiện theo hành trình và cơ chế. Xem xét kích thước, thời điểm và phụ thuộc của yêu cầu cho tài sản trang và bên thứ ba. Kiểm tra viewport trên di động, đường dẫn bàn phím, tiêu điểm hiển thị (visible focus), nhãn, lỗi, tiêu đề, mục đích liên kết, thu-phóng, và chuyện gì xảy ra nếu một ảnh, script, hoặc dịch vụ phụ thuộc consent chậm hoặc không khả dụng.
Xem đầu ra tự động về khả năng truy cập như một công đoạn phân loại (triage). W3C nói rằng không có công cụ nào một mình xác định liệu một site có đáp ứng tiêu chuẩn khả năng truy cập hay không; cần đánh giá con người có chuyên môn. Đối với tìm kiếm, đảm bảo các tài nguyên được render quan trọng vẫn có thể truy cập bởi crawler cũng như người dùng. Bao gồm chuyển hướng, canonical, liên kết nội bộ, directives robots, sitemap và dữ liệu có cấu trúc khi thay đổi ảnh hưởng đến chúng.
Liệt kê tag managers, analytics, chat, payment, fonts, CDN, API và công cụ consent mà nhiệm vụ dựa vào.
Đối với các thay đổi liên quan đến thanh toán, xác thực, dữ liệu người dùng, header hoặc biện pháp kiểm soát bảo mật, cần có đánh giá của bộ phận bảo mật và bộ phận thanh toán có thẩm quyền.
4. Xây dựng backlog được xếp hạng
Viết một giả thuyết nhỏ cho mỗi mục: trên trang hoặc luồng này, thay đổi cơ chế này vì bằng chứng chỉ ra nó gây ra vấn đề này; đo kết quả mong đợi và bảo vệ các rào chắn đã nêu. Giữ sự quan sát tách biệt khỏi chẩn đoán. Một trace lưu có thể cho thấy một ảnh lớn làm trì hoãn nội dung, nhưng biện pháp khắc phục vẫn cần được rà soát thiết kế và nội dung.
Xếp hạng các mục theo Impact (tác động), Confidence (độ tin cậy), Effort (nỗ lực) và Risk (rủi ro). Impact là hành trình ưu tiên bị ảnh hưởng. Confidence là mức độ mà lab, trường và kiểm tra thủ công đồng thuận. Effort bao gồm cả phối hợp, không chỉ code. Risk gồm phụ thuộc, bảo mật, độ phức tạp khi phát hành và khả năng phục hồi. Các rủi ro nghiêm trọng về chức năng hoặc bảo mật có thể được ưu tiên cao hơn mô hình này và cần được chuyên gia sàng lọc.
Giữ thông tin chủ sở hữu, liên kết bằng chứng, giả thuyết, trang, phép đo, rào chắn, phụ thuộc, phương pháp phát hành và trigger rollback.
Không gộp các refactor không liên quan vào một thay đổi đo lường được trừ khi an toàn yêu cầu.
5. Phát hành an toàn và giữ đường lui
Trước khi triển khai, ghi lại những gì thay đổi, người phê duyệt, cửa sổ phát hành, người xác minh, điều kiện thành công, trigger rollback và phương pháp phục hồi. Kiểm tra trong môi trường thử nghiệm đại diện khi có thể, bao gồm nội dung, quyền, tích hợp, chuyển hướng, lựa chọn consent và các kịch bản lỗi phổ biến. Production vẫn có thể khác do dữ liệu, cache, cấu hình và bên thứ ba.
Dùng phát hành nhỏ, feature flag, tài sản phiên bản (versioned asset) hoặc cấu hình có thể đảo ngược khi nền tảng hỗ trợ. Xác nhận hành vi cache và CDN trước khi so sánh kết quả. OWASP coi quản lý cấu hình và triển khai là một khu vực kiểm thử bảo mật; headers, quyền, lộ thông tin file và cài đặt domain hoặc cloud không nên là các thay đổi tối ưu hóa sơ sài.
Định nghĩa một trigger quan sát được, như thanh toán thất bại, điều hướng hỏng, lỗi client bất thường hoặc suy giảm khả năng truy cập.
Kế hoạch rollback có thể giảm thời gian khôi phục nhưng không thể loại bỏ mọi rủi ro; cần thử phục hồi trước khi dựa vào nó.
6. Xác minh, quyết định và lặp lại
Sau khi phát hành, lặp lại các kiểm tra chức năng nền và các kiểm tra lab tương đương. Kiểm tra lại các thiết bị, trình duyệt, trạng thái và tích hợp liên quan. So sánh tương đồng: URL, trạng thái cache, lớp thiết bị, vùng địa lý khi khả thi và cửa sổ đo lường. Xác nhận các rào chắn cũng như chỉ số mục tiêu.
Hãy để dữ liệu có đủ thời gian tích lũy. Google lưu ý rằng thay đổi tìm kiếm có thể mất từ vài giờ đến vài tháng để xuất hiện và đề nghị chờ vài tuần để đánh giá liệu chúng có hữu ích hay không. Dữ liệu hiệu năng người dùng thực là bằng chứng tổng hợp, không phải phán quyết ngay lập tức. Ghi lại quyết định giữ, chỉnh sửa, điều tra hoặc rollback, rồi thiết lập mức nền mới sau khi có thay đổi đáng kể về template, nền tảng, thẻ, nội dung hoặc phụ thuộc.
Kết quả hành trình mong đợi cải thiện và các rào chắn được thống nhất vẫn nguyên vẹn.
Hành động khi bằng chứng trường hoặc nhiệm vụ mâu thuẫn với kết quả lab, hoặc một rào chắn quan trọng bị suy giảm.