Cách đo lường Các chỉ số quan trọng về trang web bằng công cụ phân tích bạn đang dùng.
Khả năng đo lường và báo cáo về hiệu suất thực tế của các trang đóng vai trò rất quan trọng trong việc chẩn đoán và cải thiện hiệu suất theo thời gian. Nếu không có dữ liệu trường, bạn không thể biết chắc liệu những thay đổi bạn đang thực hiện đối với trang web có thực sự đạt được kết quả mong muốn hay không.
Nhiều nhà cung cấp dịch vụ phân tích Giám sát người dùng thực (theo yêu cầu) phổ biến đã hỗ trợ các chỉ số Các chỉ số quan trọng về trang web trong các công cụ của họ (cũng như nhiều Các chỉ số quan trọng khác về trang web). Nếu đang dùng một trong những công cụ phân tích rum này, thì bạn đã đủ điều kiện để đánh giá mức độ các trang trên trang web đáp ứng ngưỡng đề xuất về Các chỉ số quan trọng về trang web và ngăn chặn tình trạng hồi quy trong tương lai.
Mặc dù bạn nên sử dụng một công cụ phân tích có hỗ trợ các chỉ số Chỉ số quan trọng chính của trang web, nhưng nếu công cụ phân tích bạn đang dùng không hỗ trợ các chỉ số này, thì bạn không nhất thiết phải chuyển sang. Hầu hết các công cụ phân tích đều cung cấp cách xác định và đo lường các chỉ số tuỳ chỉnh hoặc sự kiện. Tức là bạn có thể sử dụng nhà cung cấp dịch vụ phân tích hiện tại để đo lường các chỉ số Các chỉ số quan trọng về trang web và thêm các chỉ số đó vào báo cáo phân tích cũng như trang tổng quan hiện có.
Hướng dẫn này thảo luận các phương pháp hay nhất để đo lường chỉ số Các chỉ số quan trọng về trang web (hoặc mọi chỉ số tuỳ chỉnh) bằng công cụ phân tích của bên thứ ba hoặc công cụ phân tích nội bộ. Đây cũng có thể là hướng dẫn cho các nhà cung cấp dịch vụ phân tích muốn thêm tính năng hỗ trợ cho Các chỉ số quan trọng về trang web vào dịch vụ của họ.
Sử dụng sự kiện hoặc chỉ số tuỳ chỉnh
Như đã đề cập ở trên, hầu hết các công cụ phân tích đều cho phép bạn đo lường dữ liệu tuỳ chỉnh. Nếu công cụ phân tích của bạn hỗ trợ việc này, bạn sẽ có thể đo lường từng chỉ số Chỉ số quan trọng chính của trang web bằng cơ chế này.
Việc đo lường các chỉ số hoặc sự kiện tuỳ chỉnh trong một công cụ phân tích thường là quy trình gồm 3 bước:
- Xác định hoặc đăng ký chỉ số tuỳ chỉnh trong trang quản trị của công cụ (nếu cần). (Lưu ý: không phải tất cả các nhà cung cấp dịch vụ phân tích đều yêu cầu phải xác định trước các chỉ số tuỳ chỉnh.)
- Tính toán giá trị của chỉ số trong mã JavaScript giao diện người dùng của bạn.
- Gửi giá trị chỉ số đến phần phụ trợ phân tích, đảm bảo tên hoặc mã nhận dạng khớp với thông tin đã xác định ở bước 1 (xin nhắc lại, nếu cần).
Đối với bước 1 và 3, bạn có thể tham khảo tài liệu của công cụ phân tích để được hướng dẫn. Đối với bước 2, bạn có thể sử dụng thư viện JavaScript web-vitals để tính giá trị của từng chỉ số Chỉ số quan trọng chính của trang web.
Mã mẫu sau đây cho thấy bạn có thể dễ dàng theo dõi các chỉ số này trong mã và gửi chúng đến một dịch vụ phân tích.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Tránh mức trung bình
Bạn nên tổng hợp các dải giá trị cho một chỉ số hiệu suất bằng cách tính giá trị trung bình. Các số liệu trung bình thoạt nhìn có vẻ thuận tiện, vì đây là phần tóm tắt gọn gàng một lượng lớn dữ liệu, nhưng bạn nên hạn chế dựa vào chỉ số này để diễn giải hiệu suất của trang.
Số liệu trung bình gây ra vấn đề vì chúng không đại diện cho bất kỳ phiên hoạt động nào của người dùng. Các điểm ngoại lai ở một trong hai phạm vi phân phối có thể làm sai lệch giá trị trung bình theo cách gây hiểu lầm.
Ví dụ: một nhóm nhỏ người dùng có thể đang sử dụng các mạng cực kỳ chậm hoặc các thiết bị hướng đến phạm vi giá trị tối đa, nhưng không tính đến đủ số phiên của người dùng để tác động đến mức trung bình theo cách cho thấy đã xảy ra sự cố.
Bất cứ khi nào có thể, hãy dựa vào phân vị thay vì trung bình. Các phân vị trên bản phân phối cho một chỉ số hiệu suất nhất định mô tả chính xác hơn toàn bộ trải nghiệm người dùng đối với trang web của bạn. Điều này cho phép bạn tập trung vào các nhóm nhỏ trải nghiệm thực tế, mang lại cho bạn nhiều thông tin chi tiết hơn so với một giá trị duy nhất có thể đạt được.
Đảm bảo bạn có thể báo cáo phạm vi phân phối
Sau khi tính toán giá trị cho từng chỉ số Các chỉ số quan trọng về trang web và gửi các chỉ số đó đến dịch vụ phân tích bằng một chỉ số hoặc sự kiện tuỳ chỉnh, bước tiếp theo là tạo một báo cáo hoặc trang tổng quan trình bày những giá trị đã thu thập được.
Để đảm bảo đáp ứng ngưỡng đề xuất về Các chỉ số quan trọng về trang web, bạn cần có báo cáo để cho thấy giá trị của từng chỉ số ở phân vị thứ 75.
Nếu công cụ phân tích của bạn không cung cấp báo cáo số lượng tử dưới dạng tính năng tích hợp sẵn, thì bạn vẫn có thể lấy dữ liệu này theo cách thủ công bằng cách tạo một báo cáo liệt kê mọi giá trị chỉ số được sắp xếp theo thứ tự tăng dần. Sau khi báo cáo này được tạo, kết quả chiếm 75% toàn bộ danh sách tất cả các giá trị được sắp xếp trong báo cáo đó sẽ là phân vị thứ 75 của chỉ số đó. Đây sẽ là trường hợp bất kể bạn phân đoạn dữ liệu như thế nào (theo loại thiết bị, loại kết nối, quốc gia, v.v.).
Nếu theo mặc định, công cụ phân tích của bạn không cung cấp thông tin chi tiết về báo cáo ở cấp chỉ số, thì bạn có thể đạt được kết quả tương tự nếu công cụ phân tích của bạn hỗ trợ phương diện tuỳ chỉnh. Bằng cách đặt giá trị thứ nguyên tùy chỉnh duy nhất cho từng phiên bản chỉ số riêng lẻ mà bạn theo dõi, bạn sẽ có thể tạo một báo cáo được chia nhỏ theo từng trường hợp chỉ số riêng lẻ, nếu bạn đưa thứ nguyên tùy chỉnh đó vào cấu hình báo cáo. Vì mỗi trường hợp sẽ có một giá trị phương diện duy nhất, nên sẽ không có quy trình nhóm nào xảy ra.
Báo cáo Các chỉ số quan trọng về trang web là một ví dụ về kỹ thuật sử dụng Google Analytics này. Mã của báo cáo là nguồn mở, vì vậy, các nhà phát triển có thể tham khảo báo cáo này làm ví dụ về các kỹ thuật được nêu trong phần này.
Gửi dữ liệu của bạn vào đúng thời điểm
Một số chỉ số về hiệu suất có thể được tính sau khi trang tải xong, trong khi một số khác (như CLS) xem xét toàn bộ thời gian hoạt động của trang và chỉ là chỉ số cuối cùng sau khi trang bắt đầu huỷ tải.
Tuy nhiên, điều này có thể rắc rối vì cả sự kiện beforeunload và unload đều không đáng tin cậy (đặc biệt là trên thiết bị di động) và bạn không nên sử dụng các sự kiện này (vì chúng có thể khiến một trang không đủ điều kiện dùng bộ nhớ đệm Bộ nhớ đệm cho thao tác tiến/lùi).
Đối với các chỉ số theo dõi toàn bộ thời gian hoạt động của một trang, bạn nên gửi
bất kỳ giá trị hiện tại của chỉ số nào trong sự kiện visibilitychange, bất cứ khi nào
trạng thái hiển thị của trang thay đổi thành hidden. Lý do là—khi trạng thái hiển thị của trang
thay đổi thành hidden—không có gì đảm bảo rằng bất kỳ tập lệnh nào trên
trang đó sẽ có thể chạy lại. Điều này đặc biệt đúng trên các hệ điều hành của thiết bị di động, nơi bạn có thể đóng chính ứng dụng trình duyệt mà không kích hoạt bất kỳ lệnh gọi lại trang nào.
Xin lưu ý rằng hệ điều hành trên thiết bị di động thường kích hoạt sự kiện visibilitychange khi chuyển đổi các thẻ, chuyển đổi ứng dụng hoặc tự đóng ứng dụng trình duyệt.
Các trình xử lý này cũng kích hoạt sự kiện visibilitychange khi đóng thẻ hoặc chuyển đến một trang mới. Nhờ đó, sự kiện visibilitychange đáng tin cậy hơn nhiều so với sự kiện unload hoặc beforeunload.
Theo dõi hiệu suất theo thời gian
Sau khi bạn cập nhật cách triển khai số liệu phân tích thành cả theo dõi và báo cáo về Các chỉ số quan trọng về trang web, bước tiếp theo là theo dõi xem các thay đổi đối với trang web ảnh hưởng như thế nào đến hiệu suất theo thời gian.
Lập phiên bản các thay đổi
Một phương pháp đơn thuần (và rốt cuộc là không đáng tin cậy) để theo dõi các thay đổi là triển khai các thay đổi cho phiên bản chính thức, rồi giả định rằng tất cả các chỉ số nhận được sau ngày triển khai đều tương ứng với trang web mới và mọi chỉ số nhận được trước ngày triển khai đều tương ứng với trang web cũ. Tuy nhiên, bất kỳ yếu tố nào (bao gồm cả việc lưu vào bộ nhớ đệm ở HTTP, trình chạy dịch vụ hoặc lớp CDN) đều có thể ngăn cản việc này hoạt động.
Một phương pháp hiệu quả hơn nhiều là tạo một phiên bản riêng cho mỗi thay đổi đã triển khai, sau đó theo dõi phiên bản đó trong công cụ phân tích của bạn. Hầu hết các công cụ phân tích đều hỗ trợ đặt phiên bản. Nếu chưa có, bạn có thể tạo một thứ nguyên tùy chỉnh và đặt thứ nguyên đó thành phiên bản đã triển khai.
Chạy thử nghiệm
Bạn có thể cải thiện thêm phiên bản bằng cách theo dõi nhiều phiên bản (hoặc thử nghiệm) cùng lúc.
Nếu công cụ phân tích của bạn cho phép bạn xác định nhóm thử nghiệm, hãy sử dụng tính năng đó. Nếu không, bạn có thể sử dụng thứ nguyên tùy chỉnh để đảm bảo có thể liên kết mỗi giá trị chỉ số với một nhóm thử nghiệm cụ thể trong báo cáo.
Bằng việc thử nghiệm trong số liệu phân tích, bạn có thể triển khai một thay đổi thử nghiệm cho một nhóm nhỏ người dùng và so sánh hiệu suất của thay đổi đó với hiệu suất của người dùng trong nhóm đối chứng. Khi chắc chắn rằng một thay đổi thực sự giúp cải thiện hiệu suất, bạn có thể triển khai thay đổi đó cho tất cả người dùng.
Đảm bảo việc đo lường không ảnh hưởng đến hiệu suất
Khi đo lường hiệu suất trên người dùng thực, điều cực kỳ quan trọng là mọi mã đo lường hiệu suất bạn đang chạy không được ảnh hưởng tiêu cực đến hiệu suất của trang. Nếu có, thì mọi kết luận mà bạn cố gắng rút ra về mức độ ảnh hưởng của hiệu suất đến doanh nghiệp của mình sẽ không đáng tin cậy, vì bạn sẽ không bao giờ biết được liệu sự hiện diện của mã phân tích có tác động tiêu cực nhất hay không.
Luôn tuân theo các nguyên tắc sau khi triển khai mã phân tích rum trên trang web phát hành công khai:
Hoãn phân tích
Mã Analytics phải luôn được tải theo cách không đồng bộ, không chặn và thường phải được tải sau cùng. Nếu bạn tải mã phân tích theo cách chặn, việc này có thể ảnh hưởng tiêu cực đến LCP.
Tất cả các API dùng để đo lường chỉ số Các chỉ số quan trọng về trang web đều được thiết kế riêng để hỗ trợ việc tải tập lệnh không đồng bộ và bị trì hoãn (thông qua cờ buffered), vì vậy, bạn không cần phải vội tải tập lệnh của mình sớm.
Trong trường hợp đang đo lường một chỉ số không thể tính toán sau này trong tiến trình tải trang, bạn chỉ nên đặt cùng dòng mã cần chạy sớm vào <head> của tài liệu (để đó không phải là yêu cầu chặn hiển thị) rồi trì hoãn phần còn lại. Đừng tải sớm tất cả số liệu phân tích
chỉ vì một chỉ số yêu cầu.
Không tạo việc cần làm dài
Mã phân tích thường chạy để phản hồi hoạt động đầu vào của người dùng, nhưng nếu mã phân tích của bạn đang thực hiện nhiều phép đo lường DOM hoặc sử dụng các API chuyên sâu khác vào bộ xử lý, thì chính mã phân tích đó có thể gây ra khả năng phản hồi dữ liệu đầu vào kém. Ngoài ra, nếu tệp JavaScript chứa mã phân tích có kích thước lớn, việc thực thi tệp đó có thể chặn luồng chính và ảnh hưởng tiêu cực đến Mức độ tương tác với nội dung hiển thị tiếp theo (INP) của trang.
Sử dụng API không chặn
Các API như sendBeacon() và requestIdleCallback() được thiết kế riêng để chạy các tác vụ không quan trọng theo cách không chặn các tác vụ quan trọng đối với người dùng.
Các API này là công cụ tuyệt vời để sử dụng trong thư viện số liệu phân tích rum.
Nói chung, tất cả các beacon phân tích phải được gửi bằng cách sử dụng API sendBeacon() (nếu có) và tất cả các mã đo lường phân tích thụ động phải được chạy trong thời gian rảnh.
Không theo dõi nhiều hơn những gì bạn cần
Trình duyệt hiển thị nhiều dữ liệu về hiệu suất, nhưng việc dữ liệu có sẵn không nhất thiết có nghĩa là bạn cần ghi lại và gửi dữ liệu đó đến máy chủ phân tích của mình.
Ví dụ: Resource Timing API (API Thời gian tài nguyên) cung cấp dữ liệu chi tiết về thời gian cho từng tài nguyên được tải trên trang của bạn. Tuy nhiên, ít có khả năng tất cả dữ liệu đó sẽ hữu ích hoặc cần thiết trong việc cải thiện hiệu suất tải tài nguyên.
Tóm lại, đừng chỉ theo dõi dữ liệu vì dữ liệu có trong đó, hãy đảm bảo dữ liệu sẽ được dùng trước khi dùng tài nguyên theo dõi.