Salah satu manfaat yang paling signifikan dari pekerja layanan (setidaknya dari perspektif performa) adalah kemampuannya untuk mengontrol penyimpanan aset dalam cache secara proaktif. Aplikasi web yang dapat meng-cache semua sumber daya yang diperlukannya akan dimuat jauh lebih cepat bagi pengunjung yang kembali. Tetapi, seperti apa keuntungan ini terlihat bagi pengguna di dunia nyata? Dan bagaimana cara mengukurnya?
Google I/O web app (singkatnya IOWA) adalah progressive web app yang memanfaatkan sebagian besar kemampuan baru yang ditawarkan oleh pekerja layanan untuk memberikan pengalaman yang kaya dan mirip aplikasi kepada penggunanya. Perusahaan ini juga menggunakan Google Analytics untuk mengambil data performa utama dan pola penggunaan dari audiens penggunanya yang besar dan beragam.
Studi kasus ini mempelajari bagaimana IOWA menggunakan Google Analytics untuk menjawab pertanyaan tentang performa utama dan melaporkan dampak pekerja layanan di dunia nyata.
Dimulai dengan pertanyaan
Setiap kali Anda menerapkan analitik di {i>website<i} atau aplikasi, penting untuk memulai dengan mengidentifikasi pertanyaan yang Anda coba jawab dari data yang akan Anda kumpulkan.
Meskipun ada beberapa pertanyaan yang ingin kita jawab, untuk tujuan studi kasus ini, mari kita fokus pada dua pertanyaan yang lebih menarik.
1. Apakah penyimpanan cache pekerja layanan lebih berperforma tinggi daripada mekanisme penyimpanan cache HTTP yang ada di semua browser?
Kami memperkirakan halaman akan dimuat lebih cepat bagi pengunjung yang kembali daripada pengunjung baru karena browser dapat menyimpan permintaan dalam cache dan langsung menayangkannya pada kunjungan berulang.
Pekerja layanan menawarkan kemampuan caching alternatif yang memberi developer kontrol terperinci atas apa dan bagaimana caching dilakukan. Dalam IOWA, kami mengoptimalkan penerapan pekerja layanan sehingga setiap aset akan di-cache, sehingga pengunjung yang kembali dapat menggunakan aplikasi secara offline sepenuhnya.
Namun, apakah upaya ini akan lebih baik daripada apa yang sudah dilakukan browser secara default? Jika ya, bagaimana hal yang lebih baik? 1
2. Bagaimana pekerja layanan memengaruhi pengalaman pemuatan situs?
Dengan kata lain, seberapa cepat rasa pemuatan situs, terlepas dari waktu pemuatan sebenarnya yang diukur dengan metrik pemuatan halaman biasa?
Menjawab pertanyaan tentang bagaimana sebuah pengalaman terasa bukan tugas yang mudah, dan tidak ada metrik yang dapat secara sempurna mewakili sentimen subjektif tersebut. Meskipun demikian, ada beberapa metrik yang lebih baik daripada yang lain, jadi memilih yang tepat itu penting.
Memilih metrik yang tepat
Secara default, Google Analytics melacak waktu muat halaman (melalui Navigation Timing API) untuk 1% pengunjung situs, dan menyediakan data tersebut melalui metrik seperti Rta. Waktu Muat Halaman.
Jumlah Waktu Muat Halaman merupakan metrik yang tepat untuk menjawab pertanyaan pertama, tetapi bukan metrik yang terlalu baik untuk menjawab pertanyaan kedua. Salah satu alasan mengapa peristiwa load belum tentu sesuai dengan momen saat pengguna benar-benar dapat berinteraksi dengan aplikasi. Selain itu, dua aplikasi dengan waktu pemuatan yang sama persis mungkin terasa pemuatannya jauh berbeda. Misalnya, situs dengan layar pembuka atau indikator pemuatan mungkin terasa jauh lebih cepat dimuat daripada situs yang hanya menampilkan halaman kosong selama beberapa detik.
Di IOWA, kami menampilkan animasi hitung mundur layar pembuka yang (menurut saya) sangat berhasil disajikan untuk menghibur pengguna saat aplikasi lainnya dimuat di latar belakang. Oleh karena itu, melacak waktu yang diperlukan layar pembuka untuk muncul jauh lebih masuk akal sebagai cara untuk mengukur performa pemuatan yang dirasakan. Kita memilih metrik time to first paint untuk mendapatkan nilai ini.
Setelah kami memutuskan pertanyaan yang ingin kami jawab dan mengidentifikasi metrik yang akan berguna untuk menjawabnya, sekarang saatnya untuk menerapkan Google Analytics dan mulai mengukur.
Penerapan analisis
Jika Anda pernah menggunakan Google Analytics sebelumnya, berarti Anda mungkin sudah memahami cuplikan pelacakan JavaScript yang disarankan. Tampilannya terlihat seperti ini:
<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>
Baris pertama dalam kode di atas melakukan inisialisasi fungsi ga() global (jika belum ada), dan baris terakhir akan mendownload library analytics.js secara asinkron.
Bagian tengah berisi dua baris ini:
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
Kedua perintah ini melacak halaman yang dikunjungi oleh orang yang membuka situs Anda, tetapi tidak banyak lagi. Jika ingin melacak interaksi pengguna tambahan, Anda harus melakukannya sendiri.
Untuk IOWA, kami ingin melacak dua hal tambahan:
- Waktu yang berlalu antara saat halaman pertama kali mulai dimuat hingga piksel muncul di layar.
- Apakah pekerja layanan mengontrol halaman atau tidak. Dengan informasi ini kita dapat menyegmentasi laporan kita untuk membandingkan hasilnya dengan dan tanpa pekerja layanan.
Merekam waktu untuk melukis pertama kali
Beberapa browser mencatat waktu persis saat piksel pertama ditampilkan ke layar, dan waktu tersebut tersedia bagi developer. Nilai tersebut, dibandingkan dengan nilai navigationStart yang ditampilkan melalui Navigation Timing API, memberi kami penghitungan yang sangat akurat tentang berapa banyak waktu yang telah berlalu antara saat pengguna pertama kali meminta halaman dan saat pertama kali melihat sesuatu.
Seperti yang sudah saya sebutkan, time to first paint adalah metrik penting untuk diukur karena ini adalah titik pertama saat pengguna mengalami kecepatan pemuatan situs Anda. Hal tersebut merupakan kesan pertama yang didapatkan pengguna, dan kesan pertama yang baik dapat berpengaruh positif terhadap keseluruhan pengalaman pengguna.2
Untuk mendapatkan nilai paint pertama di browser yang mengeksposnya, kami membuat fungsi utilitas 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;
}
}
}
Dengan ini, kita sekarang dapat menulis fungsi lain yang mengirim peristiwa non-interaksi dengan waktu untuk mendeskripsikan sebagai nilainya: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
});
}
}
Setelah menulis kedua fungsi ini, kode pelacakan kita akan terlihat seperti ini:
// 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();
Perhatikan bahwa bergantung pada kapan kode di atas dijalankan, piksel mungkin sudah atau belum ditampilkan di layar. Untuk memastikan kita selalu menjalankan kode ini setelah penggambaran pertama terjadi, kita menunda panggilan ke sendTimeToFirstPaint() hingga setelah peristiwa load. Bahkan, kami memutuskan untuk menunda pengiriman semua data analisis hingga halaman dimuat untuk memastikan permintaan tersebut tidak bersaing dengan pemuatan resource lain.
// 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();
});
Kode di atas melaporkan firstpaint kali ke Google Analytics, tetapi itu hanya separuhnya. Kita masih perlu melacak status pekerja layanan; jika tidak, kita tidak dapat membandingkan waktu penggambaran pertama dari halaman yang dikontrol pekerja layanan dan halaman yang tidak dikontrol.
Menentukan status pekerja layanan
Untuk menentukan status pekerja layanan saat ini, kami membuat fungsi utilitas yang menampilkan salah satu dari tiga nilai:
- control: pekerja layanan mengontrol halaman. Dalam kasus IOWA, hal itu juga berarti semua aset telah di-cache dan halaman berfungsi secara offline.
- didukung: browser mendukung pekerja layanan, tetapi pekerja layanan belum mengontrol halaman. Ini adalah status yang diharapkan bagi pengunjung kali pertama.
- unsupported: browser pengguna tidak mendukung pekerja layanan.
function getServiceWorkerStatus() {
if ('serviceWorker' in navigator) {
return navigator.serviceWorker.controller ? 'controlled' : 'supported';
} else {
return 'unsupported';
}
}
Fungsi ini mendapat status pekerja layanan untuk kita; langkah berikutnya adalah mengaitkan status ini dengan data yang kami kirim ke Google Analytics.
Melacak data kustom dengan dimensi kustom
Secara default, Google Analytics memberi Anda banyak cara untuk membagi total traffic ke dalam beberapa grup berdasarkan atribut pengguna, sesi, atau interaksi. Atribut ini dikenal sebagai dimensi. Dimensi umum yang menjadi perhatian developer web adalah Browser, Sistem Operasi, atau Kategori Perangkat.
Status pekerja layanan bukan dimensi yang disediakan Google Analytics secara default; namun, Google Analytics memberi Anda kemampuan untuk membuat dimensi kustom sendiri dan menentukannya sesuai keinginan Anda.
Untuk IOWA, kami membuat dimensi kustom yang disebut Status Pekerja Layanan dan menetapkan cakupannya ke hit (yaitu per interaksi).4 Setiap dimensi kustom yang Anda buat di Google Analytics diberi indeks unik dalam properti tersebut, dan di kode pelacakan Anda, Anda dapat mereferensikan dimensi tersebut menurut indeksnya. Misalnya, jika indeks dimensi yang baru saja dibuat adalah 1, kita dapat memperbarui logika sebagai berikut untuk mengirim peristiwa firstpaint agar menyertakan status pekerja layanan:
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()
});
Ini berfungsi, tetapi hanya akan mengaitkan status pekerja layanan dengan peristiwa tertentu ini. Karena Status Pekerja Layanan adalah sesuatu yang berpotensi berguna untuk diketahui dalam setiap interaksi, sebaiknya sertakan status ini bersama semua data yang dikirim ke Google Analytics.
Untuk menyertakan informasi ini di semua hit (mis., semua kunjungan halaman, peristiwa, dll.), kami menetapkan nilai dimensi kustom di objek tracker itu sendiri, sebelum mengirim data apa pun ke Google Analytics.
ga('set', 'dimension1', getServiceWorkerStatus());
Setelah ditetapkan, nilai ini akan dikirim dengan semua hit berikutnya untuk pemuatan halaman saat ini. Jika pengguna memuat halaman lagi nanti, nilai baru kemungkinan akan ditampilkan dari fungsi getServiceWorkerStatus(), dan nilai tersebut akan ditetapkan di objek pelacak.
Catatan singkat tentang kejelasan dan keterbacaan kode: karena orang lain yang melihat kode ini mungkin tidak tahu apa yang dimaksud dengan dimension1, sebaiknya buat variabel yang memetakan nama dimensi yang bermakna ke nilai yang akan digunakan analytics.js.
// 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();
});
Seperti yang telah saya sebutkan, mengirim dimensi Status Pekerja Layanan dengan setiap hit memungkinkan kita untuk menggunakannya saat melaporkan metrik apa pun.
Seperti yang dapat Anda lihat, hampir 85% dari semua tayangan halaman untuk IOWA berasal dari browser yang mendukung pekerja layanan.
Hasilnya: menjawab pertanyaan kita
Setelah kami mulai mengumpulkan data untuk menjawab pertanyaan, kami dapat melaporkan data tersebut untuk melihat hasilnya. (Catatan: semua data Google Analytics yang ditampilkan di sini mewakili traffic web sebenarnya ke situs IOWA dari 16-22 Mei 2016).
Pertanyaan pertama kami adalah: Apakah cache pekerja layanan lebih berperforma tinggi daripada mekanisme penyimpanan cache HTTP yang ada di semua browser?
Untuk menjawab pertanyaan tersebut, kami membuat laporan khusus yang melihat metrik Rata-rata Waktu Muat Halaman di berbagai dimensi. Metrik ini sangat cocok untuk menjawab pertanyaan ini karena peristiwa load hanya diaktifkan setelah semua resource awal didownload. Dengan demikian, metrik ini secara langsung mencerminkan total waktu pemuatan untuk semua resource penting situs.5
Dimensi yang kami pilih adalah:
- Dimensi Status Pekerja Layanan kustom kami.
- Jenis Pengguna, yang menunjukkan apakah ini adalah kunjungan pertama pengguna ke situs atau apakah mereka kembali. (Catatan: pengunjung baru tidak akan memiliki sumber daya yang di-cache; pengunjung yang kembali mungkin melakukannya.)
- Kategori Perangkat, yang memungkinkan kita membandingkan hasil di perangkat seluler dan desktop.
Untuk mengontrol kemungkinan bahwa faktor yang tidak terkait dengan pekerja layanan mendistorsi hasil waktu muat, kami membatasi kueri agar hanya menyertakan browser yang mendukung pekerja layanan.
Seperti yang Anda lihat, kunjungan ke aplikasi saat dikontrol oleh pekerja layanan dimuat sedikit lebih cepat daripada kunjungan tidak terkontrol, bahkan kunjungan dari pengguna yang kembali yang kemungkinan besar telah meng-cache resource halaman. Menarik juga untuk diperhatikan bahwa, rata-rata pengunjung yang menggunakan perangkat seluler dengan pekerja layanan melihat pemuatan yang lebih cepat daripada pengunjung desktop baru.
"...kunjungan ke aplikasi kami saat dikontrol oleh pekerja layanan yang dimuat sedikit lebih cepat daripada kunjungan tidak terkontrol..."
Anda dapat melihat detail selengkapnya dalam dua tabel berikut:
| Rata-rata Waktu Pemuatan Halaman (Desktop) | |||
|---|---|---|---|
| Status Pekerja Layanan | Jenis Pengguna | Waktu Muat Halaman Rta. (milidetik) | Ukuran Sampel |
| Terkontrol | Pengunjung yang Kembali | 2568 | 30860 |
| Didukung | Pengunjung yang Kembali | 3612 | 1289 |
| Didukung | Pengunjung Baru | 4664 | 21991 |
| Rata-rata Waktu Muat Halaman (Seluler) | |||
|---|---|---|---|
| Status Pekerja Layanan | Jenis Pengguna | Waktu Muat Halaman Rta. (milidetik) | Ukuran Sampel |
| Terkontrol | Pengunjung yang Kembali | 3760 | 8162 |
| Didukung | Pengunjung yang Kembali | 4843 | 676 |
| Didukung | Pengunjung Baru | 6158 | 5779 |
Anda mungkin ingin tahu bagaimana bisa saja pengunjung kembali yang browsernya mendukung pekerja layanan berada dalam keadaan tidak terkontrol. Ada beberapa kemungkinan penjelasannya:
- Pengguna meninggalkan halaman pada kunjungan awal sebelum pekerja layanan memiliki kesempatan untuk menyelesaikan inisialisasi.
- Pengguna meng-uninstal pekerja layanan melalui alat developer.
Kedua situasi ini relatif jarang terjadi. Kita dapat melihatnya dalam data dengan melihat nilai Contoh Pemuatan Halaman di kolom keempat. Perhatikan bahwa baris tengah memiliki sampel yang jauh lebih kecil daripada dua baris lainnya.
Pertanyaan kedua kami adalah: Bagaimana pekerja layanan memengaruhi pengalaman pemuatan situs?
Untuk menjawab pertanyaan ini, kami membuat laporan khusus lain untuk metrik Rta. Nilai Peristiwa dan memfilter hasilnya agar hanya menyertakan peristiwa firstpaint. Kita menggunakan dimensi Kategori Perangkat dan dimensi Status Pekerja Layanan kustom.
Berbeda dengan yang saya harapkan, pekerja layanan di seluler memiliki dampak yang jauh lebih kecil pada waktu pertama kali melukis dibandingkan pada pemuatan halaman secara keseluruhan.
"...pekerja layanan di seluler memiliki dampak yang jauh lebih sedikit pada waktu pertama kali pengecatan daripada pada pemuatan halaman secara keseluruhan."
Untuk mengeksplorasi mengapa hal ini terjadi, kita harus menggali data lebih dalam. Rata-rata bisa berguna untuk ringkasan umum dan garis besar, tetapi untuk benar-benar memahami bagaimana angka-angka ini dikelompokkan di berbagai pengguna, kita perlu melihat distribusi firstpaint kali.
Mendapatkan distribusi metrik di Google Analytics
Untuk mendapatkan distribusi firstpaint kali, kita memerlukan akses ke hasil individual untuk setiap peristiwa. Sayangnya, Google Analytics tidak membuatnya mudah.
Google Analytics memungkinkan kita mengelompokkan laporan menurut dimensi apa pun yang kita inginkan, tetapi Google Analytics tidak mengizinkan penggunaan pengelompokan laporan berdasarkan metrik. Bukan berarti tidak mungkin, melainkan hanya berarti kita harus menyesuaikan implementasi sedikit lebih banyak untuk mendapatkan hasil yang diinginkan.
Karena hasil laporan hanya dapat diperinci menurut dimensi, kami harus menetapkan nilai metrik (dalam hal ini firstpaint kali) sebagai dimensi kustom pada peristiwa. Untuk melakukannya, kami membuat dimensi kustom lain yang disebut Nilai Metrik dan memperbarui logika pelacakan firstpaint sebagai berikut:
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);
}
}
Antarmuka web Google Analytics saat ini tidak menyediakan cara untuk memvisualisasikan distribusi nilai metrik arbitrer, tetapi dengan bantuan Google Analytics Core Reporting API dan library Google Chart, kita dapat mengkueri hasil mentah dan kemudian membuat histogram sendiri.
Misalnya, konfigurasi permintaan API berikut digunakan untuk mendapatkan distribusi nilai firstpaint di desktop dengan pekerja layanan yang tidak dikontrol.
{
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'
}
]
}
Permintaan API ini menampilkan array nilai yang terlihat seperti ini (Catatan: ini hanya lima hasil pertama). Hasilnya diurutkan dari yang terkecil hingga terbesar, sehingga baris ini menampilkan waktu tercepat.
| Hasil Respons API (lima baris pertama) | |
|---|---|
| ga:dimensi2 | ga:totalEvents |
| 4 | 3 |
| 5 | 2 |
| 6 | 10 |
| 7 | 8 |
| 8 | 10 |
Berikut ini arti hasil ini dalam bahasa Inggris sederhana:
- Ada 3 peristiwa dengan nilai
firstpaint4 md - Ada 2 peristiwa dengan nilai
firstpaintadalah 5 md - Ada 10 peristiwa dengan nilai
firstpaint6 md - Ada 8 peristiwa dengan nilai
firstpaint7 md - Ada 10 peristiwa dengan
firstpaintvalue8 md - dll.
Dari hasil ini, kita dapat melakukan ekstrapolasi nilai firstpaint untuk setiap peristiwa dan membuat histogram distribusi. Kita melakukan ini untuk
setiap kueri yang kita jalankan.
Berikut ini tampilan distribusi di desktop dengan pekerja layanan yang tidak dikontrol (tetapi didukung):
Waktu firstpaint median untuk distribusi di atas adalah 912 md.
Bentuk kurva ini cukup khas dari distribusi waktu pemuatan. Berbeda dengan histogram di bawah yang menunjukkan distribusi peristiwa paint pertama untuk kunjungan saat pekerja layanan mengontrol halaman.
Perhatikan bahwa saat pekerja layanan mengontrol halaman, banyak pengunjung mengalami cat pertama yang hampir langsung, dengan median 583 md.
"...ketika pekerja layanan mengontrol halaman, banyak pengunjung mengalami cat pertama yang hampir seketika..."
Untuk mendapatkan pemahaman yang lebih baik tentang bagaimana kedua distribusi ini dibandingkan satu sama lain, diagram berikutnya menunjukkan tampilan gabungan keduanya. Histogram yang menampilkan kunjungan pekerja layanan yang tidak dikontrol ditempatkan di atas histogram yang menunjukkan kunjungan terkontrol, dan keduanya ditempatkan di atas histogram yang menampilkan keduanya.
Satu hal yang saya temukan menarik dari hasil ini adalah bahwa distribusi dengan pekerja layanan terkontrol masih memiliki kurva berbentuk lonceng setelah lonjakan awal. Saya mengantisipasi lonjakan awal yang besar, lalu turun secara bertahap, dan saya tidak mengharapkan puncak kedua pada kurva.
Saat memeriksa kemungkinan penyebab hal ini, saya mengetahui bahwa meskipun pekerja layanan dapat mengontrol halaman, threadnya bisa jadi tidak aktif. Browser melakukan hal ini untuk menghemat resource - tentu saja Anda tidak perlu mengaktifkan setiap pekerja layanan untuk setiap situs yang pernah Anda kunjungi dan siap dengan sesegera mungkin. Ini menjelaskan ekor dari distribusi. Untuk beberapa pengguna, terjadi penundaan saat thread pekerja layanan dimulai.
Seperti yang dapat Anda lihat dari distribusi, meskipun dengan penundaan awal ini, browser dengan pekerja layanan mampu menghasilkan konten lebih cepat daripada browser yang melalui jaringan.
Berikut adalah tampilannya di perangkat seluler:
Meskipun kami masih mengalami peningkatan yang cukup besar dalam waktu pengecatan pertama yang hampir langsung, ekornya agak lebih besar dan lebih panjang. Hal ini mungkin karena, di perangkat seluler, memulai thread pekerja layanan yang tidak ada aktivitas membutuhkan waktu lebih lama daripada di desktop. Bagian ini juga menjelaskan mengapa perbedaan antara waktu firstpaint rata-rata tidak sebesar yang saya harapkan (dibahas di atas).
"...di perangkat seluler, memulai thread pekerja layanan yang tidak ada aktivitas membutuhkan waktu lebih lama daripada di desktop."
Berikut adalah perincian dari variasi median waktu cat pertama di perangkat seluler dan desktop yang dikelompokkan berdasarkan status pekerja layanan:
| Waktu Median hingga Gambar Pertama (md) | ||
|---|---|---|
| Status Pekerja Layanan | Desktop | Seluler |
| Terkontrol | 583 | 1634 |
| Didukung (tidak dikontrol) | 912 | 1933 |
Meskipun membuat visualisasi distribusi ini membutuhkan lebih banyak waktu dan tenaga dibandingkan membuat laporan khusus di Google Analytics, visualisasi tersebut memberi kami gambaran yang jauh lebih baik tentang bagaimana pekerja layanan memengaruhi kinerja situs kami dibandingkan rata-rata saja.
Dampak lain dari Service Worker
Selain dampak performa, pekerja layanan juga memengaruhi pengalaman pengguna dalam beberapa cara lain yang dapat diukur dengan Google Analytics.
Akses offline
Pekerja layanan memungkinkan pengguna berinteraksi dengan situs Anda saat offline, dan meskipun dukungan offline mungkin sangat penting untuk progressive web app, menentukan seberapa penting aplikasi web itu dalam kasus Anda sangat bergantung pada seberapa banyak penggunaan yang terjadi secara offline. Namun, bagaimana cara mengukurnya?
Pengiriman data ke Google Analytics memerlukan koneksi internet, tetapi tidak mengharuskan data tersebut dikirim pada waktu persis terjadinya interaksi. Google Analytics mendukung pengiriman data interaksi setelahnya dengan menentukan selisih waktu (melalui parameter qt).
Selama dua tahun terakhir, IOWA telah menggunakan skrip pekerja layanan yang mendeteksi hit yang gagal ke Google Analytics saat pengguna offline dan memutarnya ulang nanti dengan parameter qt.
Untuk melacak apakah pengguna sedang online atau offline, kita membuat dimensi kustom yang disebut Online dan menetapkannya ke nilai navigator.onLine. Selanjutnya, kita memproses peristiwa online dan offline serta memperbarui dimensi yang sesuai.
Dan untuk memahami seberapa umum pengguna offline saat menggunakan IOWA, kami membuat segmen yang menargetkan pengguna dengan setidaknya satu interaksi offline. Ternyata, jumlah tersebut hampir mencapai 5% pengguna.
Notifikasi push
Pekerja layanan memungkinkan pengguna memilih untuk menerima notifikasi push. Di IOWA, pengguna diberi tahu saat sesi dalam jadwal mereka akan dimulai.
Seperti semua bentuk notifikasi, penting untuk menemukan keseimbangan antara memberikan nilai kepada pengguna dan membuat mereka jengkel. Untuk lebih memahami hal yang sedang terjadi, penting untuk melacak apakah pengguna ikut serta untuk menerima notifikasi ini, apakah mereka berinteraksi dengan notifikasi saat mereka datang, dan apakah ada pengguna yang sebelumnya memilih ikut serta untuk mengubah preferensi dan tidak ikut serta.
Di IOWA, kami hanya mengirim notifikasi terkait jadwal pengguna yang dipersonalisasi, sesuatu yang hanya dapat dibuat oleh pengguna yang login. Tindakan ini membatasi kumpulan pengguna yang dapat menerima notifikasi kepada pengguna yang login (dilacak melalui dimensi kustom yang disebut Login) dengan browser yang mendukung notifikasi push (dilacak melalui dimensi kustom lain yang disebut Izin Notifikasi).
Laporan berikut didasarkan pada metrik Pengguna dan dimensi kustom Izin Notifikasi kami, yang disegmentasikan menurut pengguna yang login pada waktu tertentu dan yang browsernya mendukung notifikasi push.
Kami senang melihat lebih dari separuh pengguna yang login memilih untuk menerima notifikasi push.
Banner penginstalan aplikasi
Jika aplikasi web progres memenuhi kriteria dan sering digunakan oleh pengguna, pengguna tersebut mungkin akan melihat banner penginstalan aplikasi, yang meminta mereka untuk menambahkan aplikasi ke layar utama.
Di IOWA, kami melacak seberapa sering perintah ini ditampilkan kepada pengguna (dan apakah perintah tersebut diterima) dengan kode berikut:
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
});
});
});
Dari pengguna yang melihat banner instal aplikasi, sekitar 10% memilih untuk menambahkannya ke layar utama.
Kemungkinan peningkatan pelacakan (untuk lain waktu)
Data analisis yang kami kumpulkan dari IOWA tahun ini sangat berharga. Tapi, {i>hindsight<i} selalu menunjukkan celah dan peluang untuk memperbaiki sesuatu di lain waktu. Setelah menyelesaikan analisis tahun ini, berikut dua hal yang kami harap akan kita lakukan secara berbeda, yang mungkin perlu dipertimbangkan oleh pembaca yang ingin menerapkan strategi serupa:
1. Melacak peristiwa lainnya terkait pengalaman pemuatan
Kami melacak beberapa peristiwa yang sesuai dengan metrik teknis (mis. HTMLImportsLoaded, WebComponentsReady, dll.), namun karena begitu banyak beban dilakukan secara asinkron, titik di mana peristiwa ini diaktifkan tidak selalu sesuai dengan momen tertentu dalam keseluruhan pengalaman pemuatan.
Peristiwa utama terkait pemuatan yang tidak kami lacak (tetapi kami harapkan) adalah titik saat layar pembuka menghilang dan pengguna dapat melihat konten halaman.
2. Simpan client ID analisis di IndexedDB
Secara default, analytics.js menyimpan kolom client ID di cookie browser; sayangnya, skrip pekerja layanan tidak dapat mengakses cookie.
Hal ini menimbulkan masalah bagi kami saat kami mencoba menerapkan pelacakan notifikasi. Kita ingin mengirim peristiwa dari pekerja layanan (melalui Measurement Protocol) setiap kali notifikasi dikirim kepada pengguna, lalu melacak keberhasilan re-engagement notifikasi tersebut jika pengguna mengkliknya dan kembali ke aplikasi.
Meskipun kami dapat melacak keberhasilan notifikasi secara umum melalui parameter kampanye utm_source, kami tidak dapat mengaitkan sesi re-engagement tertentu dengan pengguna tertentu.
Apa yang bisa kami lakukan untuk mengatasi keterbatasan ini adalah menyimpan client ID melalui IndexedDB di kode pelacakan kami, lalu nilai tersebut dapat diakses oleh skrip pekerja layanan.
3. Mengizinkan pekerja layanan melaporkan status online/offline
Memeriksa navigator.onLine akan memberi tahu Anda apakah browser dapat terhubung ke router atau jaringan area lokal, tetapi tidak selalu memberi tahu apakah pengguna memiliki konektivitas sungguhan. Dan karena skrip pekerja layanan analisis offline kami hanya memutar ulang hit yang gagal (tanpa mengubahnya, atau menandainya sebagai gagal), kami mungkin tidak melaporkan penggunaan offline kami.
Di masa mendatang, kita harus melacak status navigator.onLine serta apakah hit diputar ulang oleh pekerja layanan karena kegagalan jaringan awal. Hal ini akan memberi kita gambaran yang lebih akurat tentang penggunaan offline yang sebenarnya.
Menyelesaikan
Studi kasus ini menunjukkan bahwa penggunaan pekerja layanan memang meningkatkan performa pemuatan aplikasi web Google I/O di berbagai browser, jaringan, dan perangkat. Hasil ini juga menunjukkan bahwa ketika Anda melihat distribusi data muatan di berbagai browser, jaringan, dan perangkat, Anda mendapatkan lebih banyak wawasan tentang bagaimana teknologi ini menangani skenario dunia nyata, dan Anda menemukan karakteristik kinerja yang mungkin tidak Anda duga.
Berikut adalah beberapa poin utama dari studi IOWA:
- Rata-rata, halaman dimuat sedikit lebih cepat saat pekerja layanan mengontrol halaman daripada tanpa pekerja layanan, baik untuk pengunjung baru maupun pengunjung yang kembali.
- Kunjungan ke halaman yang dikontrol oleh pekerja layanan dimuat hampir seketika bagi banyak pengguna.
- Saat tidak aktif, pekerja layanan membutuhkan waktu untuk memulai. Namun, pekerja layanan yang tidak aktif tetap berperforma lebih baik daripada tidak ada pekerja layanan.
- Waktu startup untuk pekerja layanan yang tidak aktif lebih lama di seluler daripada di desktop.
Meskipun peningkatan kinerja yang terlihat pada satu aplikasi tertentu umumnya berguna untuk dilaporkan ke komunitas developer yang lebih luas, penting untuk diingat bahwa hasil ini spesifik untuk jenis situs IOWA yaitu (situs acara) dan jenis audiens yang dimiliki IOWA (kebanyakan developer).
Jika Anda mengimplementasikan pekerja layanan di aplikasi, Anda harus mengimplementasikan strategi pengukuran Anda sendiri sehingga dapat menilai kinerja Anda sendiri dan mencegah regresi di masa mendatang. Jika ya, bagikan hasil Anda sehingga semua orang dapat memperoleh manfaat!
Catatan kaki
- Tidak sepenuhnya adil membandingkan performa implementasi cache pekerja layanan dengan performa situs hanya dengan cache HTTP. Karena kita mengoptimalkan IOWA untuk pekerja layanan, kita tidak menghabiskan banyak waktu untuk mengoptimalkan cache HTTP. Jika kita melakukannya, hasilnya mungkin akan berbeda. Untuk mempelajari lebih lanjut cara mengoptimalkan situs Anda untuk cache HTTP, baca Mengoptimalkan Konten secara Efisien.
- Bergantung pada cara situs Anda memuat gaya dan kontennya, kemungkinan browser dapat melakukan penggambaran sebelum konten atau gaya tersedia. Dalam kasus tersebut,
firstpaintmungkin sesuai dengan layar putih kosong. Jika Anda menggunakanfirstpaint, pastikan atribut tersebut sesuai dengan titik yang bermakna dalam pemuatan resource situs Anda. - Secara teknis, kami dapat mengirim hit waktu (yang secara default bukan interaksi) untuk mencatat informasi ini, bukan peristiwa. Faktanya, hit waktu ditambahkan ke Google Analytics khusus untuk melacak metrik pemuatan seperti ini; Namun, hit waktu akan banyak diambil sampelnya pada waktu pemrosesan, dan nilainya tidak dapat digunakan dalam segmen. Dengan mempertimbangkan batasan saat ini, peristiwa non-interaksi tetap lebih cocok.
- Untuk lebih memahami cakupan yang harus diberikan untuk dimensi kustom di Google Analytics, lihat bagian Dimensi Kustom di pusat bantuan Analytics. Penting juga untuk memahami model data Google Analytics, yang terdiri dari pengguna, sesi, dan interaksi (klik). Untuk mempelajari lebih lanjut, tonton pelajaran Akademi Analytics tentang Model Data Google Analytics.
- Hal ini tidak memperhitungkan resource yang dimuat dengan lambat setelah peristiwa pemuatan.