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