Các phương pháp hay nhất để đo lường Các chỉ số quan trọng về trang web tại hiện trường

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 hiệu suất thực tế của các trang là yếu tố quan trọng để 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 chắn liệu những thay đổi mà 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 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ợ tính năng này, bạn có thể đo lường từng chỉ số trong Các chỉ số quan trọng về 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:

  1. 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.)
  2. Tính toán giá trị của chỉ số trong mã JavaScript giao diện người dùng.
  3. 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. Đối với 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ố trong Các chỉ số quan trọng về 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 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 có thể muốn tính tổng một dải giá trị cho một chỉ số hiệu suất bằng cách tính 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 đại diện cho 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 mạng hoặc thiết bị cực kỳ chậm, gần với phạm vi giá trị tối đa, nhưng không tính đủ số phiên 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. Điều này cho phép bạn tập trung vào các tập hợp con của trải nghiệm thực tế, nhờ đó, bạn sẽ có được thông tin chi tiết hơn so với một giá trị duy nhất.

Đả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ị phương diện tuỳ chỉnh, duy nhất cho từng thực thể chỉ số riêng lẻ mà bạn theo dõi, bạn có thể tạo báo cáo, được chia nhỏ theo từng thực thể chỉ số riêng lẻ, nếu bạn đưa phương diện tuỳ chỉnh vào cấu hình báo cáo. Vì mỗi thực thể sẽ có một giá trị phương diện riêng biệt, nên sẽ không có hoạt động 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.

Ảnh chụp màn hình Báo cáo Các chỉ số quan trọng về web

Gửi dữ liệu vào đúng thời điểm

Một số chỉ số hiệu suất có thể được tính toán sau 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ỉ được tính toán sau khi trang bắt đầu tải xuống.

Tuy nhiên, điều này có thể gây ra vấn đề vì cả sự kiện beforeunloadunload đề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 di động, trong đó ứng dụng trình duyệt có thể tự đóng mà không có lệnh gọi lại trang nào được kích hoạt.

Xin lưu ý rằng các hệ điều hành 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 sự kiệ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 cho các thay đổi

Một phương pháp đơn giản (và cuối cùng là 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ả cá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ả cá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. 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 mỗi 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 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 tối quan trọng là mọi mã đo lường hiệu suất mà bạn đang chạy không ả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ề 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à tác độ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:

Tạm 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 chỉ 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 tất cả số liệu phân tích sớm chỉ vì một chỉ số yêu cầu điều đó.

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ó dung lượng lớn, thì việc thực thi tệp đó có thể chặn luồng chính và ảnh hưởng tiêu cực đến Số lượt tương tác đến lượt vẽ tiếp theo (INP) của trang.

Sử dụng các API không chặn

Các API như sendBeacon()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.

Đây là những API hữu ích để sử dụng trong thư viện 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 nên 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 từng tài nguyên đượ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 đó.