Cách đo lường Các chỉ số quan trọng về trang web bằng công cụ phân tích mà 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ò 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 thực tế, thì bạn sẽ không thể biết chắc chắn liệu những thay đổi mà bạn 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 Theo dõi người dùng thực (RUM) phổ biến đã hỗ trợ các chỉ số Chỉ số quan trọng chính của trang web trong các công cụ của họ (cũng như nhiều Chỉ số quan trọng khác về trang web). Nếu đang sử dụng một trong những công cụ phân tích RUM này, bạn có thể đánh giá mức độ phù hợp của các trang trên trang web với ngưỡng Các chỉ số quan trọng về trang web được đề xuất và ngăn chặn sự 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 hỗ trợ các chỉ số về chỉ số Lõi của web, nhưng nếu công cụ phân tích bạn đang sử 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 đổi. 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 chỉ số tuỳ chỉnh hoặc sự kiện. Điều này có nghĩa 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ố Core Web Vitals và thêm các chỉ số đó vào các báo cáo và trang tổng quan phân tích hiện có.
Hướng dẫn này thảo luận về các phương pháp hay nhất để đo lường các chỉ số của Chỉ số quan trọng chính của trang web (hoặc bất kỳ chỉ số tuỳ chỉnh nào) bằng công cụ phân tích nội bộ hoặc của bên thứ ba. Tài liệu này cũng có thể đóng vai trò 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ợ 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ố quan trọng chính của trang web bằng cơ chế này.
Quy trình đ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 bao gồm 3 bước:
- Xác định hoặc đăng ký chỉ số tuỳ chỉnh trong phần quản trị của công cụ (nếu cần). (Lưu ý: không phải nhà cung cấp phân tích nào cũng yêu cầu bạn 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 giá trị đã xác định ở bước 1 (lần nữa, 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 để biết hướng dẫn. Ở bước 2, bạn có thể sử dụng thư viện JavaScript web-vitals để tính toán giá trị của từng chỉ số Core Web Vitals.
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 các chỉ số đó đế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 sử dụng giá trị trung bình
Bạn muốn tổng hợp một loạt giá trị cho một chỉ số hiệu suất bằng cách tính giá trị trung bình. Thoạt nhìn, giá trị trung bình có vẻ thuận tiện vì đây là thông tin tóm tắt gọn gàng về một lượng lớn dữ liệu, nhưng bạn không nên dựa vào giá trị này để diễn giải hiệu suất trang.
Giá trị trung bình có vấn đề vì không thể hiện phiên của bất kỳ người dùng nào. Các giá trị ngoại lai ở một trong hai dải của 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 chậm hoặc thiết bị sắp đạt đế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 có vấn đề.
Bất cứ khi nào có thể, hãy dựa vào các phân vị thay vì giá trị trung bình. Phân vị trên một phân phối cho một chỉ số hiệu suất nhất định mô tả rõ hơn toàn bộ trải nghiệm người dùng trên trang web của bạn. Nhờ đó, bạn có thể tập trung vào các nhóm nhỏ trải nghiệm thực tế, giúp cung cấp cho bạn nhiều thông tin chi tiết hơn so với một giá trị đơn lẻ.
Đảm bảo bạn có thể báo cáo một bản phân phối
Sau khi bạn tính toán giá trị cho từng chỉ số Core Web Vitals và gửi các giá trị đó đế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 hiển thị các giá trị đã thu thập.
Để đảm bảo bạn đang đáp ứng các ngưỡng đề xuất của Các chỉ số quan trọng về trang web, báo cáo của bạn cần 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 tứ phân vị dưới dạng một tính năng tích hợp, 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% trong danh sách đầy đủ, được sắp xếp của tất cả các giá trị trong báo cáo đó sẽ là phân vị thứ 75 cho chỉ số đó. Đây sẽ là trường hợp bất kể bạn phân đoạn dữ liệu của mình 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 cho bạn thông tin báo cáo chi tiết ở cấp chỉ số, thì có thể bạn sẽ đạ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 mỗi phiên bản chỉ số riêng lẻ mà bạn theo dõi, bạn sẽ có thể tạo báo cáo (được chia nhỏ theo các phiên bản 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ó nhóm nào xảy ra.
Báo cáo chỉ số quan trọng của web là một ví dụ về kỹ thuật này sử dụng Google Analytics. Mã cho báo cáo này là nguồn mở, vì vậy, nhà phát triển có thể tham khảo mã 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 khi trang đã tải xong, trong khi các chỉ số khác (như CLS) xem xét toàn bộ thời gian hoạt động của trang và chỉ cuối cùng khi trang bắt đầu bị huỷ tải.
Tuy nhiên, điều này có thể gây ra vấn đề 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 sử dụng 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, tốt nhất bạn nên gửi bất kỳ giá trị hiện tại nào của chỉ số 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à sau 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 mọi tập lệnh 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 dành cho thiết bị di động, nơi có thể đóng chính ứng dụng trình duyệt mà không cần 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 thẻ, chuyển đổi ứng dụng hoặc đóng chính ứng dụng trình duyệt.
Các thành phần 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. Điều này giúp sự kiện visibilitychange đáng tin cậy hơn nhiều so với các 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 công cụ phân tích để theo dõi và báo cáo về các chỉ số của Các chỉ số quan trọng về trang web, bước tiếp theo là theo dõi mức độ ảnh hưởng của các thay đổi đối với trang web đến hiệu suất theo thời gian.
Lập phiên bản các thay đổi của bạn
Một phương pháp đơn giản (và không đáng tin cậy) để theo dõi các thay đổi là triển khai các thay đổi cho môi trường phát hành công khai, sau đó giả định rằng tất cả chỉ số nhận được sau ngày triển khai tương ứng với trang web mới và tất cả chỉ số nhận được trước ngày triển khai tương ứng với trang web cũ. Tuy nhiên, có thể có nhiều yếu tố (bao gồm cả việc lưu vào bộ nhớ đệm ở lớp HTTP, worker dịch vụ hoặc CDN) khiến tính năng này không hoạt động.
Một phương pháp tốt hơn nhiều là tạo một phiên bản riêng biệt cho từng 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ợ việc đặt phiên bản. Nếu không, bạn có thể tạo một phương diện tuỳ chỉnh và đặt phương diện đó thành phiên bản đã triển khai.
Chạy thử nghiệm
Bạn có thể nâng cấp việc tạo phiên bản lên một tầm cao mới bằng cách theo dõi nhiều phiên bản (hoặc thử nghiệm) cùng một lúc.
Nếu công cụ phân tích của bạn cho phép bạn xác định các 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 phương diện tuỳ chỉnh để đảm bảo từng giá trị chỉ số có thể được liên kết với một nhóm thử nghiệm cụ thể trong báo cáo.
Khi đã triển khai tính năng 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 đã tự tin 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 hoạt động đ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 quan trọng là mọi mã đo lường hiệu suất bạn đang chạy không tác độ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ề cách hiệu suất ảnh hưởng đến công việc kinh doanh của bạn sẽ không đáng tin cậy, vì bạn sẽ không bao giờ biết liệu sự hiện diện của mã phân tích có phải là yếu tố gây ảnh hưởng tiêu cực lớn nhất hay không.
Luôn tuân thủ các nguyên tắc sau khi triển khai mã phân tích RUM trên trang web chính thức:
Trì hoãn số liệu 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 là tải sau cùng. Nếu bạn tải mã phân tích theo cách chặn, thì điều này có thể ảnh hưởng tiêu cực đến LCP.
Tất cả API dùng để đo lường các chỉ số Core Web Vitals đều được thiết kế riêng để hỗ trợ tính năng tải tập lệnh không đồng bộ và trì hoãn (thông qua cờ buffered). Vì vậy, bạn không cần phải vội vàng tải tập lệnh sớm.
Trong trường hợp bạn đang đo lường một chỉ số không thể tính toán sau trong tiến trình tải trang, bạn chỉ nên nội tuyến mã cần chạy sớm vào <head> của tài liệu (vì vậy, đây không phải là yêu cầu chặn kết xuất) và 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 tải sớm.
Không tạo tác vụ dài
Mã Analytics 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ã Analytics của bạn đang tiến hành nhiều phép đo DOM hoặc sử dụng các API khác chuyên xử lý, thì chính mã Analytics có thể khiến khả năng phản hồi đầu vào kém. Ngoài ra, nếu tệp JavaScript chứa mã phân tích của bạn có kích thước lớn, việc thực thi tệp đó có thể chặn luồng chính và gây ảnh hưởng tiêu cực đến Lượt 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.
Những 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.
Nhìn chung, bạn nên gửi tất cả beacon phân tích bằng API sendBeacon() (nếu có) và chạy tất cả mã đo lường phân tích thụ động trong khoảng thời gian rảnh.
Không theo dõi nhiều hơn mức cần thiết
Trình duyệt hiển thị nhiều dữ liệu 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 phải ghi lại và gửi dữ liệu đó đến máy chủ phân tích.
Ví dụ: Resource Timing API cung cấp dữ liệu thời gian chi tiết cho mỗi tài nguyên đơn lẻ được tải trên trang của bạn. Tuy nhiên, không phải tất cả dữ liệu đó đều cần thiết hoặc hữu ích 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ó sẵn, hãy đảm bảo dữ liệu sẽ được sử dụng trước khi tiêu tốn tài nguyên để theo dõi dữ liệu đó.