Một trong những lợi ích đáng kể nhất của nhân viên dịch vụ (ít nhất là từ góc độ hiệu suất) là khả năng chủ động kiểm soát việc lưu tài sản vào bộ nhớ đệm. Ứng dụng web có thể lưu vào bộ nhớ đệm tất cả tài nguyên cần thiết sẽ tải nhanh hơn đáng kể cho các khách truy cập cũ. Nhưng những lợi ích này trông như thế nào với người dùng thực? Và làm cách nào để đo lường chỉ số này?
Ứng dụng web Google I/O (gọi tắt là IOWA) là một ứng dụng web tiến bộ khai thác hầu hết tính năng mới do worker dịch vụ cung cấp để mang lại trải nghiệm phong phú giống như ứng dụng cho người dùng. Ngoài ra, họ cũng sử dụng Google Analytics để thu thập dữ liệu quan trọng về hiệu suất và quy luật sử dụng của đối tượng người dùng rộng lớn và đa dạng.
Nghiên cứu điển hình này khám phá cách IOWA sử dụng Google Analytics để trả lời các câu hỏi quan trọng về hiệu suất và báo cáo về tác động thực tế của nhân viên dịch vụ.
Bắt đầu với những câu hỏi
Bất cứ khi nào bạn triển khai số liệu phân tích trong một trang web hoặc ứng dụng, điều quan trọng là bạn phải bắt đầu bằng cách xác định những câu hỏi mà bạn muốn trả lời từ dữ liệu bạn sẽ thu thập.
Mặc dù chúng tôi có một vài câu hỏi muốn giải đáp, nhưng trong nghiên cứu điển hình này, hãy cùng tập trung vào hai câu hỏi thú vị hơn.
1. Việc lưu vào bộ nhớ đệm của trình chạy dịch vụ có hiệu quả cao hơn các cơ chế lưu vào bộ nhớ đệm HTTP hiện có trong mọi trình duyệt không?
Chúng tôi đã mong đợi trang tải nhanh hơn đối với khách truy cập cũ so với khách truy cập mới vì trình duyệt có thể lưu yêu cầu vào bộ nhớ đệm và phân phát yêu cầu ngay lập tức đối với các lần truy cập lặp lại.
Service worker cung cấp khả năng lưu vào bộ nhớ đệm thay thế giúp nhà phát triển kiểm soát chi tiết chính xác việc lưu vào bộ nhớ đệm là gì và như thế nào. Trong IOWA, chúng tôi đã tối ưu hoá việc triển khai trình chạy dịch vụ để mọi nội dung sẽ được lưu vào bộ nhớ đệm, nhờ đó, khách truy cập cũ có thể sử dụng ứng dụng hoàn toàn ngoại tuyến.
Tuy nhiên, liệu nỗ lực này có tốt hơn những gì trình duyệt đã làm theo mặc định không? Và nếu có thì tốt hơn bao nhiêu? 1
2. Trình chạy dịch vụ ảnh hưởng như thế nào đến trải nghiệm tải trang web?
Nói cách khác, trang web cảm thấy tải nhanh đến mức nào, bất kể thời gian tải thực tế đo bằng các chỉ số tải trang truyền thống là như thế nào?
Trả lời các câu hỏi về cảm giác của một trải nghiệm rõ ràng không phải là một nhiệm vụ dễ dàng và không có chỉ số nào có thể thể hiện một cách hoàn hảo một cảm giác chủ quan như vậy. Mặc dù vậy, chắc chắn có một vài chỉ số tốt hơn các chỉ số khác, vì vậy việc chọn chỉ số phù hợp là rất quan trọng.
Chọn chỉ số phù hợp
Theo mặc định, Google Analytics sẽ theo dõi thời gian tải trang (qua Navigation Timing API) cho 1% khách truy cập trang web và cung cấp dữ liệu đó thông qua các chỉ số như Thời gian tải trang tr. bình.
Thời gian tải trang trung bình là chỉ số phù hợp để trả lời câu hỏi đầu tiên của chúng tôi, nhưng không phải là chỉ số đặc biệt tốt để trả lời câu hỏi thứ hai. Có một điều, sự kiện load không nhất thiết tương ứng với khoảnh khắc người dùng thực sự có thể tương tác với ứng dụng. Hơn nữa, 2 ứng dụng có cùng thời gian tải có thể cảm thấy chúng tải khác nhau rất nhiều. Ví dụ: một trang web có màn hình chờ hoặc chỉ báo tải có thể cho cảm giác tải nhanh hơn nhiều so với một trang web chỉ hiển thị một trang trống trong vài giây.
Trong IOWA, chúng tôi đã cho thấy một ảnh động đếm ngược trên màn hình chờ (theo ý kiến của tôi) đã rất hiệu quả trong việc giúp người dùng giải trí trong khi phần còn lại của ứng dụng được tải trong nền. Do đó, việc theo dõi khoảng thời gian cần để màn hình chờ xuất hiện sẽ có ý nghĩa hơn nhiều vì đây là một cách để đo lường hiệu suất tải dự kiến. Chúng tôi đã chọn chỉ số thời gian hiển thị lần đầu để nhận được giá trị này.
Sau khi quyết định những câu hỏi mà chúng tôi muốn trả lời và xác định được các chỉ số có thể giúp trả lời các câu hỏi đó, chúng tôi đã đến lúc triển khai Google Analytics và bắt đầu đo lường.
Triển khai Analytics
Nếu bạn đã sử dụng Google Analytics trước đây, thì bạn có thể quen thuộc với đoạn mã theo dõi JavaScript được đề xuất. Thông báo sẽ có dạng như sau:
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src="https://www.google-analytics.com/analytics.js"></script>
Dòng đầu tiên trong mã ở trên khởi chạy hàm ga() toàn cục (nếu chưa có) và dòng cuối cùng tải xuống không đồng bộ thư viện analytics.js.
Phần giữa chứa hai dòng sau:
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
Hai lệnh này theo dõi những trang mà người dùng truy cập vào trang web của bạn, nhưng không thực hiện thêm tác vụ nào khác. Nếu muốn theo dõi các lượt tương tác khác của người dùng, bạn phải tự mình theo dõi.
Đối với IOWA, chúng tôi muốn theo dõi thêm hai yếu tố:
- Khoảng thời gian đã trôi qua kể từ khi trang bắt đầu tải lần đầu tiên cho đến khi pixel xuất hiện trên màn hình.
- Liệu một trình chạy dịch vụ có đang kiểm soát trang hay không. Với thông tin này, chúng ta có thể phân đoạn các báo cáo của mình để so sánh kết quả khi có và không có trình chạy dịch vụ.
Đang chụp thời gian để vẽ lần đầu tiên
Một số trình duyệt ghi lại thời điểm chính xác mà pixel đầu tiên được hiển thị lên màn hình và cung cấp thời gian đó cho nhà phát triển. Giá trị đó, so với giá trị navigationStart được hiển thị qua API Thời gian điều hướng cung cấp cho chúng ta kết quả tính toán rất chính xác về khoảng thời gian đã trôi qua giữa thời điểm người dùng bắt đầu yêu cầu trang cho đến khi họ nhìn thấy nội dung nào đó lần đầu tiên.
Như tôi đã đề cập, thời gian hiển thị nội dung lần đầu tiên là một chỉ số quan trọng cần đo lường bởi vì đó là điểm đầu tiên mà người dùng trải nghiệm tốc độ tải của trang web. Đó là ấn tượng đầu tiên mà người dùng nhận được và ấn tượng ban đầu tốt có thể tác động tích cực đến phần còn lại của trải nghiệm người dùng.2
Để nhận giá trị sơn đầu tiên trong các trình duyệt hiển thị giá trị đó, chúng ta đã tạo hàm tiện ích getTimeToFirstPaintIfSupported:
function getTimeToFirstPaintIfSupported() {
// Ignores browsers that don't support the Performance Timing API.
if (window.performance && window.performance.timing) {
var navTiming = window.performance.timing;
var navStart = navTiming.navigationStart;
var fpTime;
// If chrome, get first paint time from `chrome.loadTimes`.
if (window.chrome && window.chrome.loadTimes) {
fpTime = window.chrome.loadTimes().firstPaintTime * 1000;
}
// If IE/Edge, use the prefixed `msFirstPaint` property.
// See http://msdn.microsoft.com/ff974719
else if (navTiming.msFirstPaint) {
fpTime = navTiming.msFirstPaint;
}
if (fpTime && navStart) {
return fpTime - navStart;
}
}
}
Với hàm này, giờ đây chúng ta có thể viết một hàm khác gửi một sự kiện không tương tác với thời gian để hiển thị đầu tiên làm giá trị:3
function sendTimeToFirstPaint() {
var timeToFirstPaint = getTimeToFirstPaintIfSupported();
if (timeToFirstPaint) {
ga('send', 'event', {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true
});
}
}
Sau khi viết cả hai hàm này, mã theo dõi của chúng tôi sẽ trông giống như sau:
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
Xin lưu ý rằng tuỳ thuộc vào thời điểm chạy mã trên, các pixel có thể đã được vẽ hoặc chưa được vẽ lên màn hình. Để đảm bảo chúng ta luôn chạy mã này sau khi lần hiển thị đầu tiên xảy ra, chúng ta đã trì hoãn lệnh gọi đến sendTimeToFirstPaint() cho đến sau sự kiện load. Trên thực tế, chúng tôi đã quyết định trì hoãn việc gửi tất cả dữ liệu phân tích cho đến sau khi trang được tải để đảm bảo những yêu cầu đó sẽ không cạnh tranh với việc tải các tài nguyên khác.
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
});
Mã ở trên báo cáo firstpaint lần cho Google Analytics, nhưng đó chỉ là một nửa câu chuyện. Chúng tôi vẫn cần theo dõi trạng thái của nhân viên bảo dưỡng; nếu không, chúng tôi sẽ không thể so sánh thời gian hiển thị đầu tiên của trang do nhân viên bảo dưỡng kiểm soát và trang không do nhân viên kiểm soát.
Xác định trạng thái của trình chạy dịch vụ
Để xác định trạng thái hiện tại của trình chạy dịch vụ, chúng ta đã tạo một hàm hiệu dụng trả về một trong ba giá trị:
- được kiểm soát: một trình chạy dịch vụ đang kiểm soát trang. Trong trường hợp IOWA, điều đó cũng có nghĩa là tất cả nội dung đã được lưu vào bộ nhớ đệm và trang hoạt động ngoại tuyến.
- supported: trình duyệt hỗ trợ trình chạy dịch vụ, nhưng trình chạy dịch vụ chưa kiểm soát trang. Đây là trạng thái dự kiến cho khách truy cập lần đầu.
- không được hỗ trợ: trình duyệt của người dùng không hỗ trợ trình chạy dịch vụ.
function getServiceWorkerStatus() {
if ('serviceWorker' in navigator) {
return navigator.serviceWorker.controller ? 'controlled' : 'supported';
} else {
return 'unsupported';
}
}
Hàm này đã có trạng thái trình chạy dịch vụ cho chúng ta; bước tiếp theo là liên kết trạng thái này với dữ liệu mà chúng ta đã gửi đến Google Analytics.
Theo dõi dữ liệu tuỳ chỉnh bằng phương diện tuỳ chỉnh
Theo mặc định, Google Analytics cung cấp cho bạn nhiều cách để chia nhỏ tổng lưu lượng truy cập thành các nhóm dựa trên các thuộc tính của người dùng, phiên hoạt động hoặc lượt tương tác. Các thuộc tính này được gọi là phương diện. Các phương diện mà các nhà phát triển web thường quan tâm là Trình duyệt, Hệ điều hành hoặc Danh mục thiết bị.
Trạng thái của trình chạy dịch vụ không phải là thứ nguyên mà Google Analytics cung cấp theo mặc định; tuy nhiên, Google Analytics cho phép bạn tạo thứ nguyên tùy chỉnh của riêng bạn và xác định các thứ nguyên đó theo cách bạn muốn.
Đối với IOWA, chúng tôi đã tạo thứ nguyên tùy chỉnh có tên là Trạng thái trình chạy dịch vụ và đặt phạm vi của thứ nguyên đó là lượt truy cập (tức là mỗi lượt tương tác).4 Mỗi thứ nguyên tùy chỉnh bạn tạo trong Google Analytics được cấp một chỉ mục duy nhất trong thuộc tính đó và trong mã theo dõi, bạn có thể tham chiếu thứ nguyên đó theo chỉ mục của nó. Ví dụ: nếu chỉ mục của phương diện vừa tạo là 1, chúng ta có thể cập nhật logic như sau để gửi sự kiện firstpaint nhằm đưa trạng thái của trình chạy dịch vụ vào:
ga('send', 'event', {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true,
// Sets the current service worker status as the value of
// `dimension1` for this event.
dimension1: getServiceWorkerStatus()
});
Thao tác này hoạt động nhưng chỉ liên kết trạng thái của trình chạy dịch vụ với sự kiện cụ thể này. Do Trạng thái trình chạy dịch vụ là thông tin có thể hữu ích cần biết cho bất kỳ tương tác nào, tốt nhất bạn nên đưa trạng thái này vào cùng với tất cả dữ liệu được gửi đến Google Analytics.
Để đưa thông tin này vào tất cả các lượt truy cập (ví dụ: tất cả lượt xem trang, sự kiện, v.v.), chúng tôi đặt giá trị thứ nguyên tùy chỉnh trong chính đối tượng công cụ theo dõi, trước khi gửi bất kỳ dữ liệu nào đến Google Analytics.
ga('set', 'dimension1', getServiceWorkerStatus());
Sau khi đặt, giá trị này được gửi cùng với tất cả các lượt truy cập tiếp theo cho tải trang hiện tại. Nếu sau đó người dùng tải trang lại, một giá trị mới có thể sẽ được trả về từ hàm getServiceWorkerStatus() và giá trị đó sẽ được đặt trên đối tượng trình theo dõi.
Lưu ý nhanh về tính rõ ràng và dễ đọc của mã: vì những người khác khi xem mã này có thể không biết dimension1 đề cập đến điều gì, tốt nhất bạn nên tạo một biến ánh xạ tên thứ nguyên có ý nghĩa với giá trị mà analytics.js sẽ sử dụng.
// Creates a map between custom dimension names and their index.
// This is particularly useful if you define lots of custom dimensions.
var customDimensions = {
SERVICE_WORKER_STATUS: 'dimension1'
};
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Sets the service worker status on the tracker,
// so its value is included in all future hits.
ga('set', customDimensions.SERVICE_WORKER_STATUS, getServiceWorkerStatus());
// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
});
Như tôi đã đề cập, việc gửi thứ nguyên Trạng thái trình chạy dịch vụ với mỗi lượt truy cập cho phép chúng ta sử dụng thứ nguyên này khi báo cáo về bất kỳ chỉ số nào.
Như bạn có thể thấy, gần 85% tổng số lượt xem trang cho IOWA là đến từ các trình duyệt hỗ trợ trình chạy dịch vụ.
Kết quả: trả lời câu hỏi của chúng tôi
Sau khi bắt đầu thu thập dữ liệu để trả lời cho các câu hỏi của mình, chúng tôi có thể báo cáo dựa trên dữ liệu đó để xem kết quả. (Lưu ý: tất cả dữ liệu Google Analytics hiển thị ở đây đều thể hiện lưu lượng truy cập web thực tế vào trang web IOWA từ ngày 16 đến 22 tháng 5 năm 2016).
Câu hỏi đầu tiên chúng tôi nhận được là: Việc lưu vào bộ nhớ đệm của trình chạy dịch vụ có hiệu quả hơn các cơ chế lưu vào bộ nhớ đệm HTTP hiện có trong mọi trình duyệt không?
Để trả lời câu hỏi đó, chúng tôi đã tạo một báo cáo tùy chỉnh xem xét chỉ số Thời gian tải trang trung bình trên các phương diện khác nhau. Chỉ số này rất phù hợp để trả lời câu hỏi này vì sự kiện load chỉ kích hoạt sau khi tất cả tài nguyên ban đầu được tải xuống. Do đó, chỉ số này phản ánh trực tiếp tổng thời gian tải cho tất cả tài nguyên quan trọng của trang web.5
Các tham số mà chúng tôi chọn là:
- Phương diện Trạng thái trình chạy dịch vụ tuỳ chỉnh.
- Loại người dùng: cho biết đây là lần đầu tiên người dùng truy cập vào trang web hay họ quay lại. (Lưu ý: khách truy cập mới sẽ không có bất kỳ tài nguyên nào được lưu trong bộ nhớ đệm; khách truy cập cũ thì có thể.)
- Danh mục thiết bị: Tính năng này cho phép chúng tôi so sánh kết quả trên thiết bị di động và máy tính.
Để kiểm soát khả năng các yếu tố liên quan đến dịch vụ không liên quan đến dịch vụ làm sai lệch kết quả thời gian tải của chúng tôi, chúng tôi đã giới hạn truy vấn chỉ bao gồm các trình duyệt hỗ trợ trình chạy dịch vụ.
Như bạn có thể thấy, các lượt truy cập vào ứng dụng của chúng tôi khi được kiểm soát bởi trình chạy dịch vụ sẽ tải nhanh hơn một chút so với các lượt truy cập không được kiểm soát, ngay cả các lượt truy cập của những người dùng cũ có thể đã lưu vào bộ nhớ đệm hầu hết các tài nguyên của trang. Một cũng thú vị khi nhận thấy rằng, trung bình, khách truy cập trên thiết bị di động có nhân viên dịch vụ thấy tải nhanh hơn khách truy cập mới trên máy tính để bàn.
"...các lượt truy cập vào ứng dụng của chúng tôi khi được kiểm soát bởi nhân viên dịch vụ sẽ tải nhanh hơn một chút so với các lượt truy cập không được kiểm soát..."
Bạn có thể xem thêm thông tin chi tiết trong hai bảng sau:
| Thời gian tải trang tr. bình (Máy tính) | |||
|---|---|---|---|
| Trạng thái trình chạy dịch vụ | Kiểu người dùng | Thời gian tải trang tr.bình (mili giây) | Kích thước mẫu |
| Đã kiểm soát | Khách truy cập cũ | 2568 | 30860 |
| Có thể làm | Khách truy cập cũ | 3612 | 1289 |
| Có thể làm | Khách truy cập mới | 4664 | 21991 |
| Thời gian tải trang tr. bình (Thiết bị di động) | |||
|---|---|---|---|
| Trạng thái trình chạy dịch vụ | Kiểu người dùng | Thời gian tải trang tr.bình (mili giây) | Kích thước mẫu |
| Đã kiểm soát | Khách truy cập cũ | 3760 | 8162 |
| Có thể làm | Khách truy cập cũ | 4843 | 676 |
| Có thể làm | Khách truy cập mới | 6158 | 5779 |
Bạn có thể đang tự hỏi làm thế nào để một khách truy cập cũ có trình duyệt hỗ trợ trình chạy dịch vụ có thể ở trong trạng thái không được kiểm soát. Có một vài cách giải thích có thể chấp nhận cho điều này:
- Người dùng rời khỏi trang vào lần truy cập đầu tiên, trước khi worker có thể hoàn tất việc khởi tạo.
- Người dùng gỡ cài đặt trình chạy dịch vụ thông qua công cụ cho nhà phát triển.
Cả hai trường hợp này đều tương đối hiếm gặp. Chúng ta có thể thấy điều đó trong dữ liệu bằng cách xem các giá trị Mẫu tải trang trong cột thứ tư. Lưu ý rằng các hàng ở giữa có mẫu nhỏ hơn nhiều so với hai hàng còn lại.
Câu hỏi thứ hai của chúng tôi là: Trình chạy dịch vụ ảnh hưởng như thế nào đến trải nghiệm tải trang web?
Để trả lời câu hỏi này, chúng tôi đã tạo một báo cáo tuỳ chỉnh khác cho chỉ số Giá trị sự kiện trung bình và lọc kết quả để chỉ bao gồm các sự kiện firstpaint. Chúng tôi sử dụng phương diện Danh mục thiết bị và phương diện Trạng thái trình chạy dịch vụ tuỳ chỉnh.
Không giống như những gì tôi kỳ vọng, trình chạy dịch vụ trên thiết bị di động tác động đến thời gian vẽ đầu tiên ít hơn nhiều so với tổng thể tải trang.
"...nhân viên dịch vụ trên thiết bị di động có tác động ít đến thời gian vẽ đầu tiên hơn nhiều so với tải trang tổng thể."
Để tìm hiểu lý do dẫn đến tình trạng này, chúng ta phải nghiên cứu kỹ hơn dữ liệu. Điểm trung bình có thể phù hợp với thông tin tổng quan chung và nét rộng, nhưng để thực sự hiểu được cách những con số này được phân chia theo nhiều nhóm người dùng, chúng ta cần xem xét tỷ lệ phân bổ firstpaint lần.
Nhận thông tin phân phối một chỉ số trong Google Analytics
Để nhận được dữ liệu phân phối firstpaint lần, chúng ta cần truy cập vào từng kết quả của mỗi sự kiện. Thật không may, Google Analytics không làm cho điều này dễ dàng.
Google Analytics cho phép chúng ta chia nhỏ báo cáo theo bất kỳ phương diện nào chúng ta muốn, nhưng không cho phép chúng ta chia nhỏ báo cáo theo các chỉ số. Điều đó không có nghĩa là không thể, mà chỉ có nghĩa là chúng ta phải tuỳ chỉnh quá trình triển khai của mình nhiều hơn một chút để có được kết quả mong muốn.
Vì kết quả báo cáo chỉ có thể được chia nhỏ theo phương diện, nên chúng tôi phải đặt giá trị chỉ số (trong trường hợp này là firstpaint lần) làm phương diện tuỳ chỉnh cho sự kiện. Để làm việc này, chúng tôi đã tạo một thứ nguyên tùy chỉnh khác có tên là Giá trị chỉ số và cập nhật logic theo dõi firstpaint như sau:
var customDimensions = {
SERVICE_WORKER_STATUS: 'dimension1',
<strong>METRIC_VALUE: 'dimension2'</strong>
};
// ...
function sendTimeToFirstPaint() {
var timeToFirstPaint = getTimeToFirstPaintIfSupported();
if (timeToFirstPaint) {
var fields = {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true
}
<strong>// Sets the event value as a dimension to allow for breaking down the
// results by individual metric values at reporting time.
fields[customDimensions.METRIC_VALUE] = String(fields.eventValue);</strong>
ga('send', 'event', fields);
}
}
Giao diện web của Google Analytics hiện không cung cấp cách trực quan hoá việc phân phối các giá trị chỉ số tuỳ ý, nhưng với sự trợ giúp của API Báo cáo chính của Google Analytics và thư viện Google Biểu đồ, chúng tôi có thể truy vấn các kết quả thô rồi tự tạo biểu đồ.
Ví dụ: cấu hình yêu cầu API sau đây đã được dùng để phân phối giá trị firstpaint trên máy tính bằng một trình chạy dịch vụ không được kiểm soát.
{
dateRanges: [{startDate: '2016-05-16', endDate: '2016-05-22'}],
metrics: [{expression: 'ga:totalEvents'}],
dimensions: [{name: 'ga:dimension2'}],
dimensionFilterClauses: [
{
operator: 'AND',
filters: [
{
dimensionName: 'ga:eventAction',
operator: 'EXACT',
expressions: ['firstpaint']
},
{
dimensionName: 'ga:dimension1',
operator: 'EXACT',
expressions: ['supported']
},
{
dimensionName: 'ga:deviceCategory',
operator: 'EXACT',
expressions: ['desktop']
}
],
}
],
orderBys: [
{
fieldName: 'ga:dimension2',
orderType: 'DIMENSION_AS_INTEGER'
}
]
}
Yêu cầu API này trả về một mảng các giá trị giống như sau (Lưu ý: đây chỉ là 5 kết quả đầu tiên). Kết quả được sắp xếp theo thứ tự từ nhỏ nhất đến lớn nhất, do đó, các hàng này đại diện cho thời gian nhanh nhất.
| Kết quả phản hồi của API (5 hàng đầu tiên) | |
|---|---|
| ga:dimension2 | ga:totalEvents |
| 4 | 3 |
| 5 | 2 |
| 6 | 10 |
| 7 | 8 |
| 8 | 10 |
Dưới đây là ý nghĩa của những kết quả này bằng tiếng Anh thuần tuý:
- Có 3 sự kiện mà giá trị
firstpaintlà 4 mili giây - Có 2 sự kiện mà giá trị
firstpaintlà 5 mili giây - Có 10 sự kiện mà giá trị
firstpaintlà 6 mili giây - Có 8 sự kiện mà giá trị
firstpaintlà 7 mili giây - Có 10 sự kiện mà
valuecủafirstpaintlà 8 mili giây - v.v.
Từ những kết quả này, chúng ta có thể ngoại suy giá trị firstpaint cho mỗi sự kiện đơn lẻ và tạo biểu đồ phân phối. Chúng tôi làm điều này cho mỗi truy vấn mà chúng tôi đã chạy.
Dưới đây là ví dụ về hoạt động phân phối trên máy tính với một trình chạy dịch vụ không được kiểm soát (nhưng được hỗ trợ):
Thời gian firstpaint trung bình cho mức phân phối ở trên là 912 mili giây.
Hình dạng của đường cong này là khá điển hình của phân phối thời gian tải. Trái ngược với biểu đồ bên dưới, cho thấy sự phân phối các sự kiện hiển thị đầu tiên cho những lượt truy cập mà một trình chạy dịch vụ đang kiểm soát trang.
Lưu ý rằng khi một nhân viên dịch vụ đang kiểm soát trang, nhiều khách truy cập đã trải qua lần hiển thị đầu tiên gần như ngay lập tức, với trung bình là 583 mili giây.
"...khi một nhân viên dịch vụ đang kiểm soát trang, nhiều khách truy cập gặp phải hiện tượng hiển thị đầu tiên gần như ngay lập tức..."
Để hiểu rõ hơn về sự khác biệt giữa hai phân phối này so với nhau, biểu đồ tiếp theo sẽ hiển thị chế độ xem hợp nhất của hai phân phối. Biểu đồ thể hiện số lượt truy cập của nhân viên dịch vụ không kiểm soát được phủ lên trên biểu đồ thể hiện số lượt truy cập có kiểm soát và cả hai lượt truy cập này đều nằm trên biểu đồ thể hiện cả hai lượt truy cập kết hợp.
Một điều tôi thấy thú vị về những kết quả này là việc phân phối với nhân viên dịch vụ được kiểm soát vẫn có đường cong hình chuông sau đợt tăng đột biến ban đầu. Tôi đã kỳ vọng sẽ có một mức tăng đột biến ban đầu lớn, sau đó giảm dần, tôi không nghĩ là đường cong sẽ đạt đỉnh thứ hai.
Khi xem xét nguyên nhân có thể gây ra vấn đề này, tôi biết được rằng mặc dù một trình chạy dịch vụ có thể kiểm soát một trang, nhưng luồng của trang đó có thể không hoạt động. Trình duyệt thực hiện việc này để tiết kiệm tài nguyên – rõ ràng là bạn không cần tất cả trình chạy dịch vụ cho mọi trang web bạn từng truy cập phải hoạt động và sẵn sàng ngay lập tức. Điều này giải thích đuôi của phân phối. Đối với một số người dùng, có sự chậm trễ trong khi luồng worker dịch vụ bắt đầu.
Như bạn có thể thấy từ quá trình phân phối, ngay cả với độ trễ ban đầu này, các trình duyệt có trình chạy dịch vụ vẫn phân phối nội dung nhanh hơn các trình duyệt đi qua mạng.
Dưới đây là giao diện của các mục trên thiết bị di động:
Mặc dù chúng tôi vẫn có được sự gia tăng đáng kể về thời gian hiển thị gần như ngay lập tức, nhưng phần đuôi của xe lại lớn hơn và dài hơn một chút. Điều này có thể là do trên thiết bị di động, việc bắt đầu một luồng worker dịch vụ ở trạng thái rảnh sẽ mất nhiều thời gian hơn so với trên máy tính. Điều này cũng giải thích lý do sự khác biệt giữa thời gian firstpaint trung bình không lớn như tôi kỳ vọng (đã thảo luận ở trên).
"...trên thiết bị di động, việc bắt đầu một luồng worker dịch vụ ở trạng thái rảnh sẽ mất nhiều thời gian hơn so với trên máy tính."
Dưới đây là thông tin chi tiết từ các biến thể của thời gian hiển thị lần đầu trung bình trên thiết bị di động và máy tính được nhóm theo trạng thái của trình chạy dịch vụ:
| Thời gian trung bình so với lần hiển thị đầu tiên (mili giây) | ||
|---|---|---|
| Trạng thái trình chạy dịch vụ | Máy tính | Di động |
| Đã kiểm soát | 583 | 1634 |
| Được hỗ trợ (không được kiểm soát) | 912 | 1933 |
Mặc dù việc xây dựng những hình ảnh trực quan này tốn nhiều thời gian và công sức hơn một chút so với việc tạo báo cáo tuỳ chỉnh trong Google Analytics, nhưng chúng giúp chúng tôi hiểu rõ hơn về cách trình chạy dịch vụ ảnh hưởng đến hiệu suất của trang web so với việc chỉ dựa trên mức trung bình.
Tác động khác của Trình chạy dịch vụ
Ngoài tác động đến hiệu suất, nhân viên dịch vụ cũng tác động đến trải nghiệm người dùng theo một số cách khác có thể đo lường được bằng Google Analytics.
Xem không cần mạng
Trình chạy dịch vụ cho phép người dùng tương tác với trang web của bạn khi không có kết nối mạng. Mặc dù một số hình thức hỗ trợ ngoại tuyến có thể rất quan trọng đối với mọi ứng dụng web tiến bộ, việc xác định mức độ quan trọng trong trường hợp của bạn phụ thuộc phần lớn vào mức độ sử dụng diễn ra ngoại tuyến. Nhưng làm cách nào để đo lường điều đó?
Để gửi dữ liệu đến Google Analytics, bạn cần có kết nối Internet, nhưng không bắt buộc phải gửi dữ liệu vào đúng thời điểm diễn ra hoạt động tương tác. Google Analytics hỗ trợ gửi dữ liệu về lượt tương tác sau khi xảy ra sự kiện bằng cách chỉ định khoảng thời gian chênh lệch (thông qua tham số qt).
Trong 2 năm qua, IOWA đã sử dụng tập lệnh trình chạy dịch vụ để phát hiện lượt truy cập không thành công vào Google Analytics khi người dùng không có kết nối mạng và sau đó phát lại bằng thông số qt.
Để theo dõi xem người dùng đang trực tuyến hay ngoại tuyến, chúng tôi đã tạo một phương diện tuỳ chỉnh có tên là Trực tuyến rồi đặt phương diện đó thành giá trị navigator.onLine. Sau đó, chúng tôi theo dõi các sự kiện online và offline rồi cập nhật phương diện đó cho phù hợp.
Ngoài ra, để nắm được mức độ phổ biến của việc một người dùng không kết nối mạng trong khi sử dụng IOWA, chúng tôi đã tạo một phân khúc nhắm đến những người dùng có ít nhất một lượt tương tác ngoại tuyến. Hoá ra, đó là gần 5% người dùng.
Thông báo đẩy
Trình chạy dịch vụ cho phép người dùng chọn nhận thông báo đẩy. Trong IOWA, người dùng được thông báo khi một phiên trong lịch biểu của họ sắp bắt đầu.
Giống như bất kỳ hình thức thông báo nào, điều quan trọng là phải cân bằng giữa việc cung cấp giá trị cho người dùng và làm phiền họ. Để hiểu rõ hơn điều gì đang xảy ra, bạn cần phải theo dõi xem người dùng có chọn nhận những thông báo này hay không, họ có tương tác với thông báo khi đến nơi hay không và có người dùng nào đã chọn nhận trước đó trước đó đã thay đổi lựa chọn ưu tiên và chọn không nhận hay không.
Trong IOWA, chúng tôi chỉ gửi thông báo liên quan đến lịch biểu dành riêng cho người dùng, chỉ người dùng đã đăng nhập mới có thể tạo thông báo. Điều này giới hạn nhóm người dùng có thể nhận thông báo từ người dùng đã đăng nhập (được theo dõi qua phương diện tuỳ chỉnh có tên là Đã đăng nhập) có trình duyệt hỗ trợ thông báo đẩy (theo dõi qua một phương diện tuỳ chỉnh khác có tên là Quyền thông báo).
Báo cáo sau đây dựa trên chỉ số Người dùng và phương diện tuỳ chỉnh Quyền gửi thông báo, được phân chia theo người dùng đã đăng nhập tại một thời điểm và trình duyệt có hỗ trợ thông báo đẩy.
Tôi rất vui khi thấy hơn một nửa số người dùng đăng nhập của chúng tôi đã chọn nhận thông báo đẩy.
Biểu ngữ cài đặt ứng dụng
Nếu ứng dụng web về tiến trình đáp ứng các tiêu chí và được người dùng sử dụng thường xuyên, thì người dùng đó có thể thấy một biểu ngữ cài đặt ứng dụng, nhắc họ thêm ứng dụng vào màn hình chính.
Trong IOWA, chúng tôi đã theo dõi tần suất hiển thị những lời nhắc này cho người dùng (và liệu chúng có được chấp nhận hay không) bằng mã sau:
window.addEventListener('beforeinstallprompt', function(event) {
// Tracks that the user saw a prompt.
ga('send', 'event', {
eventCategory: 'installprompt',
eventAction: 'fired'
});
event.userChoice.then(function(choiceResult) {
// Tracks the users choice.
ga('send', 'event', {
eventCategory: 'installprompt',
// `choiceResult.outcome` will be 'accepted' or 'dismissed'.
eventAction: choiceResult.outcome,
// `choiceResult.platform` will be 'web' or 'android' if the prompt was
// accepted, or '' if the prompt was dismissed.
eventLabel: choiceResult.platform
});
});
});
Trong số người dùng đã nhìn thấy biểu ngữ cài đặt ứng dụng, có khoảng 10% chọn thêm biểu ngữ này vào màn hình chính.
Cải thiện tính năng theo dõi (cho lần tiếp theo)
Dữ liệu phân tích mà chúng tôi thu thập được từ IOWA năm nay là vô giá. Tuy nhiên, cảnh quay sau luôn mang đến những lỗ hổng và cơ hội để cải thiện mọi thứ cho tương lai. Sau khi kết thúc nội dung phân tích của năm nay, tôi muốn cân nhắc hai điều sau đây mà những độc giả muốn triển khai chiến lược tương tự nên cân nhắc khi triển khai một số cách khác:
1. Theo dõi thêm các sự kiện liên quan đến trải nghiệm tải
Chúng tôi đã theo dõi một số sự kiện tương ứng với chỉ số kỹ thuật (ví dụ: HTMLImportsLoaded, WebComponentsReady, v.v.), nhưng vì quá nhiều tải được thực hiện không đồng bộ, điểm mà các sự kiện này được kích hoạt không nhất thiết phải tương ứng với một thời điểm cụ thể trong trải nghiệm tải tổng thể.
Sự kiện chính liên quan đến lượt tải mà chúng tôi không theo dõi (nhưng ước gì chúng tôi đã theo dõi) là thời điểm mà màn hình chờ biến mất và người dùng có thể xem nội dung của trang.
2. Lưu trữ mã ứng dụng khách Analytics trong IndexedDB
Theo mặc định, analytics.js lưu trữ trường ID ứng dụng khách trong cookie của trình duyệt; rất tiếc, tập lệnh trình chạy dịch vụ không thể truy cập cookie.
Điều này đã gây ra vấn đề cho chúng tôi khi cố gắng triển khai tính năng theo dõi thông báo. Chúng ta muốn gửi một sự kiện từ trình chạy dịch vụ (thông qua Measurement Protocol) mỗi khi gửi thông báo đến người dùng, sau đó theo dõi mức độ thành công của thông báo tương tác lại nếu người dùng nhấp vào thông báo và quay lại ứng dụng.
Mặc dù có thể theo dõi mức độ thành công của thông báo nói chung thông qua thông số chiến dịch utm_source, nhưng chúng tôi không thể liên kết một phiên tương tác lại cụ thể với một người dùng cụ thể.
Những gì chúng tôi có thể đã làm để khắc phục giới hạn này là lưu trữ ID ứng dụng khách qua IndexedDB trong mã theo dõi và sau đó, tập lệnh trình chạy dịch vụ có thể truy cập được vào giá trị đó.
3. Cho phép nhân viên dịch vụ báo cáo trạng thái trực tuyến/ngoại tuyến
Việc kiểm tra navigator.onLine sẽ cho bạn biết trình duyệt của bạn có thể kết nối với bộ định tuyến hoặc mạng cục bộ hay không, nhưng không nhất thiết cho biết liệu người dùng có kết nối thực sự hay không. Và do tập lệnh trình chạy dịch vụ phân tích ngoại tuyến của chúng tôi chỉ phát lại các lượt truy cập không thành công (mà không sửa đổi hoặc đánh dấu chúng là không thành công), nên có thể chúng tôi đã báo cáo thiếu mức sử dụng ngoại tuyến.
Trong tương lai, chúng ta sẽ theo dõi cả trạng thái của navigator.onLine, cũng như liệu lượt truy cập có được trình chạy dịch vụ phát lại do lỗi mạng ban đầu hay không. Việc này sẽ giúp chúng tôi hiểu rõ hơn về mức sử dụng ngoại tuyến thực tế.
Kết thúc
Nghiên cứu điển hình này đã chỉ ra rằng việc sử dụng trình chạy dịch vụ đã thực sự cải thiện hiệu suất tải của ứng dụng web Google I/O trên nhiều trình duyệt, mạng và thiết bị. Nghiên cứu cũng cho thấy rằng khi xem xét sự phân phối dữ liệu tải trên nhiều trình duyệt, mạng và thiết bị, bạn sẽ hiểu rõ hơn về cách công nghệ này xử lý các tình huống thực tế và bạn khám phá ra các đặc điểm hiệu suất mà bạn có thể không mong đợi.
Dưới đây là một số nội dung chính cần ghi nhớ từ nghiên cứu của IOWA:
- Trung bình, trang tải nhanh hơn khá nhiều khi nhân viên dịch vụ kiểm soát trang so với khi không có nhân viên dịch vụ, cho cả khách truy cập mới và khách truy cập cũ.
- Các lượt truy cập vào các trang do một nhân viên dịch vụ kiểm soát đã tải gần như ngay lập tức của nhiều người dùng.
- Service worker, khi không hoạt động, mất một chút thời gian để khởi động. Tuy nhiên, một nhân viên dịch vụ không hoạt động vẫn hoạt động tốt hơn so với khi không có nhân viên dịch vụ nào.
- Thời gian khởi động của một trình chạy dịch vụ không hoạt động trên thiết bị di động dài hơn trên máy tính.
Mặc dù mức tăng hiệu suất ghi nhận được trong một ứng dụng cụ thể thường hữu ích khi báo cáo cho cộng đồng nhà phát triển lớn hơn, nhưng điều quan trọng cần nhớ là những kết quả này là dành riêng cho loại trang web IOWA (trang web sự kiện) và loại đối tượng IOWA có (chủ yếu là nhà phát triển).
Nếu đang triển khai trình chạy dịch vụ trong ứng dụng của mình, thì bạn cần phải triển khai chiến lược đo lường của riêng mình để có thể đánh giá hiệu suất của riêng mình và ngăn chặn sự hồi quy trong tương lai. Nếu có, hãy chia sẻ kết quả để mọi người cùng tham gia!
Chú thích chân trang
- Không hoàn toàn công bằng khi so sánh hiệu suất triển khai bộ nhớ đệm của trình chạy dịch vụ với hiệu suất của trang web chỉ có bộ nhớ đệm HTTP. Vì đang tối ưu hoá IOWA cho trình chạy dịch vụ, nên chúng tôi không dành nhiều thời gian để tối ưu hoá bộ nhớ đệm HTTP. Nếu chúng tôi làm như vậy, kết quả có lẽ đã khác. Để tìm hiểu thêm về cách tối ưu hoá trang web cho bộ nhớ đệm HTTP, hãy đọc bài viết Tối ưu hoá nội dung một cách hiệu quả.
- Tùy thuộc vào cách trang web của bạn tải kiểu và nội dung, có thể trình duyệt có thể vẽ trước khi nội dung hoặc kiểu có sẵn. Trong những trường hợp như vậy,
firstpaintcó thể tương ứng với một màn hình trắng trống. Nếu bạn sử dụngfirstpaint, điều quan trọng là phải đảm bảo điểm này tương ứng với một điểm có ý nghĩa trong quá trình tải tài nguyên của trang web. - Về mặt kỹ thuật, chúng tôi có thể gửi lượt truy cập thời điểm (không phải là tương tác theo mặc định) để thu thập thông tin này thay vì một sự kiện. Trên thực tế, lượt truy cập thời gian đã được thêm riêng vào Google Analytics để theo dõi các chỉ số tải như thế này; tuy nhiên, lượt truy cập thời gian được lấy mẫu rất nhiều tại thời điểm xử lý và không thể sử dụng giá trị của chúng trong phân đoạn. Do những quy định hạn chế hiện tại này, các sự kiện không tương tác vẫn phù hợp hơn.
- Để hiểu rõ hơn về phạm vi cung cấp phương diện tuỳ chỉnh trong Google Analytics, hãy tham khảo mục Phương diện tuỳ chỉnh trong trung tâm trợ giúp Analytics. Điều quan trọng là bạn cũng phải hiểu rõ mô hình dữ liệu của Google Analytics, bao gồm số người dùng, số phiên và lượt tương tác (lượt truy cập). Để tìm hiểu thêm, hãy xem bài học về Mô hình dữ liệu của Google Analytics của Học viện Analytics.
- Phương pháp này không tính đến các tài nguyên được tải từng phần sau sự kiện tải.