Salah satu manfaat paling signifikan dari pekerja layanan (setidaknya dari perspektif performa) adalah kemampuan mereka untuk secara proaktif mengontrol penyimpanan aset dalam cache. Aplikasi web yang dapat menyimpan semua sumber daya yang diperlukan dalam cache akan dimuat jauh lebih cepat untuk pengunjung yang kembali. Tetapi seperti apa sebenarnya keuntungan ini terlihat bagi pengguna nyata? Dan bagaimana cara mengukurnya?
Google I/O web app (disingkat IOWA) adalah progressive web app yang memanfaatkan sebagian besar kemampuan baru yang ditawarkan oleh pekerja layanan untuk memberikan pengalaman yang kaya seperti aplikasi kepada penggunanya. Perusahaan ini juga menggunakan Google Analytics untuk mencatat data performa utama dan pola penggunaan dari audiens penggunanya yang besar dan beragam.
Studi kasus ini mempelajari cara IOWA menggunakan Google Analytics untuk menjawab pertanyaan performa utama dan melaporkan dampak dunia nyata pekerja layanan.
Dimulai dengan pertanyaan
Setiap kali Anda menerapkan analitik di sebuah situs web atau aplikasi, penting untuk memulainya 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 dalam cache pekerja layanan lebih efektif daripada mekanisme penyimpanan cache HTTP yang ada yang tersedia di semua browser?
Kami sudah memperkirakan halaman akan dimuat lebih cepat bagi pengunjung yang kembali daripada pengunjung baru karena browser dapat menyimpan permintaan dalam cache dan menayangkannya dengan cepat pada kunjungan berulang.
Service worker menawarkan kemampuan caching alternatif yang memberi developer kontrol terperinci atas apa dan bagaimana caching dilakukan. Di IOWA, kami mengoptimalkan implementasi pekerja layanan sehingga setiap aset akan di-cache, sehingga pengunjung yang kembali dapat menggunakan aplikasi sepenuhnya secara offline.
Tetapi, apakah upaya ini akan lebih baik dari apa yang sudah dilakukan browser secara {i>default<i}? Dan jika demikian, seberapa baik? 1
2. Bagaimana pekerja layanan memengaruhi pengalaman pemuatan situs?
Dengan kata lain, seberapa cepat situs terasa seperti dimuat, terlepas dari waktu pemuatan sebenarnya seperti yang diukur berdasarkan metrik pemuatan halaman biasa?
Menjawab pertanyaan tentang bagaimana perasaan sebuah pengalaman jelas bukan tugas yang mudah, dan tidak ada metrik yang akan merepresentasikan sentimen subjektif tersebut dengan sempurna. Meskipun demikian, pasti ada beberapa metrik yang lebih baik daripada yang lain, jadi memilih metrik yang tepat adalah penting.
Memilih metrik yang tepat
Google Analytics, secara default, melacak waktu muat halaman (melalui Navigation Timing API) untuk 1% pengunjung situs, dan membuat data tersebut tersedia melalui metrik seperti Waktu Muat Halaman Rata-Rata.
Waktu Muat Halaman Rata-Rata adalah metrik yang bagus untuk menjawab pertanyaan pertama, tetapi ini bukan metrik yang bagus untuk menjawab pertanyaan kedua. Salah satunya, peristiwa load tidak selalu sesuai dengan momen saat pengguna benar-benar dapat berinteraksi dengan aplikasi. Selain itu, dua aplikasi dengan waktu pemuatan yang sama persis mungkin terasa seperti dimuat dengan cara yang jauh berbeda. Misalnya, situs yang memiliki layar pembuka atau indikator pemuatan mungkin terasa 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 sementara aplikasi lainnya dimuat di latar belakang. Karena itu, melacak berapa lama waktu yang dibutuhkan layar pembuka untuk muncul jauh lebih masuk akal sebagai cara untuk mengukur performa pemuatan yang dirasakan. Kami memilih metrik time to first paint untuk mendapatkan nilai ini.
Setelah memutuskan pertanyaan yang ingin dijawab dan mengidentifikasi metrik yang akan berguna untuk menjawab pertanyaan tersebut, kini saatnya untuk menerapkan Google Analytics dan memulai pengukuran.
Penerapan analitik
Jika Anda pernah menggunakan Google Analytics sebelumnya, Anda mungkin sudah memahami cuplikan pelacakan JavaScript yang direkomendasikan. 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 menginisialisasi 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 akan membuka situs Anda, tetapi tidak lebih 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 pada layar.
- Apakah pekerja layanan mengontrol halaman atau tidak. Dengan informasi ini, kita dapat menyegmentasi laporan untuk membandingkan hasil dengan dan tanpa pekerja layanan.
Merekam waktu untuk menggambar pertama
Beberapa browser merekam waktu secara tepat saat piksel pertama digambar ke layar, dan menyediakan waktu tersebut bagi developer. Nilai tersebut, dibandingkan dengan nilai navigationStart yang ditampilkan melalui Navigation Timing API, akan memberi kita penghitungan yang sangat akurat tentang berapa banyak waktu yang telah berlalu antara saat pengguna pertama kali meminta halaman dan saat mereka pertama kali melihat sesuatu.
Seperti yang telah saya sebutkan, time to first paint adalah metrik penting yang perlu diukur karena ini merupakan titik pertama saat pengguna merasakan kecepatan pemuatan situs Anda. Hal tersebut menjadi kesan pertama yang didapatkan pengguna, dan kesan pertama yang baik dapat berpengaruh positif pada keseluruhan pengalaman pengguna.2
Untuk mendapatkan nilai first paint 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, sekarang kita dapat menulis fungsi lain yang mengirim peristiwa non-interaksi dengan waktu untuk menggambar pertama kali 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 tersebut, kode pelacakan 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 berjalan, piksel mungkin sudah atau belum dilukis ke layar. Untuk memastikan kita selalu menjalankan kode ini setelah paint pertama terjadi, kita menunda panggilan ke sendTimeToFirstPaint() hingga setelah peristiwa load. Bahkan, kami memutuskan untuk menunda pengiriman semua data analisis hingga halaman dimuat guna memastikan permintaan tersebut tidak akan 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 baru setengahnya. Kita masih perlu melacak status pekerja layanan; jika tidak, kita tidak akan dapat membandingkan waktu menggambar 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 mengembalikan salah satu dari tiga nilai:
- dikontrol: pekerja layanan mengontrol halaman. Dalam kasus IOWA, itu juga berarti semua aset telah di-cache dan halaman berfungsi secara offline.
- supported: browser mendukung pekerja layanan, tetapi pekerja layanan belum mengontrol halaman. Ini adalah status yang diharapkan untuk pengunjung kali pertama.
- tidak didukung: browser pengguna tidak mendukung pekerja layanan.
function getServiceWorkerStatus() {
if ('serviceWorker' in navigator) {
return navigator.serviceWorker.controller ? 'controlled' : 'supported';
} else {
return 'unsupported';
}
}
Fungsi ini mendapatkan status pekerja layanan untuk kita; langkah berikutnya adalah mengaitkan status ini dengan data yang kita kirim ke Google Analytics.
Melacak data kustom dengan dimensi kustom
Secara default, Google Analytics memberi Anda banyak cara untuk membagi total traffic menjadi grup berdasarkan atribut pengguna, sesi, atau interaksi. Atribut ini dikenal sebagai dimensi. Dimensi umum yang menjadi perhatian developer web adalah hal-hal seperti Browser, Sistem Operasi, atau Kategori Perangkat.
Status pekerja layanan bukanlah dimensi yang disediakan oleh Google Analytics secara default; namun, Google Analytics memberikan kemampuan untuk membuat dimensi kustom Anda 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 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()
});
Cara ini akan berfungsi, tetapi hanya akan mengaitkan status pekerja layanan dengan peristiwa khusus ini. Karena Status Pekerja Layanan adalah sesuatu yang berpotensi berguna untuk diketahui untuk setiap interaksi, sebaiknya sertakan dengan semua data yang dikirim ke Google Analytics.
Untuk menyertakan informasi ini di semua hit (misalnya, semua kunjungan halaman, peristiwa, dll.), kami menetapkan nilai dimensi kustom di objek pelacak itu sendiri, sebelum mengirim data 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 dirujuk 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 saya sebutkan, mengirimkan 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.
Hasil: 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 yang sebenarnya ke situs IOWA dari 16-22 Mei 2016).
Pertanyaan pertama adalah: Apakah cache pekerja layanan lebih berperforma tinggi dibandingkan mekanisme caching HTTP yang ada di semua browser?
Untuk menjawab pertanyaan tersebut, kami membuat laporan kustom yang membahas metrik Waktu Muat Halaman Rata-Rata di berbagai dimensi. Metrik ini sangat cocok untuk menjawab pertanyaan ini karena peristiwa load hanya diaktifkan setelah semua resource awal didownload. Oleh karena itu, hal 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 kunjungan pertama pengguna ke situs atau ia kembali. (Catatan: pengunjung baru tidak akan memiliki sumber daya yang disimpan dalam cache; pengunjung yang kembali mungkin akan melakukannya.)
- Kategori Perangkat, yang memungkinkan kami membandingkan hasil di perangkat seluler dan desktop.
Untuk mengontrol kemungkinan bahwa faktor yang tidak terkait dengan pekerja layanan mendistorsi hasil waktu pemuatan, 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 yang tidak dikontrol, bahkan kunjungan dari pengguna kembali yang kemungkinan besar telah meng-cache sebagian besar resource halaman. Menarik juga bahwa, rata-rata pengunjung yang menggunakan perangkat seluler dengan pekerja layanan melihat pemuatan lebih cepat daripada pengunjung desktop baru.
"...kunjungan ke aplikasi kita saat dikontrol oleh pekerja layanan yang dimuat sedikit lebih cepat daripada kunjungan yang tidak dikontrol..."
Anda dapat melihat detail lebih lanjut dalam dua tabel berikut:
| Waktu Pemuatan Halaman Rta. (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 |
| Waktu Pemuatan Halaman Rta. (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 pengunjung yang kembali yang browsernya mendukung pekerja layanan dapat berada dalam keadaan tidak terkontrol. Ada beberapa kemungkinan penjelasan untuk hal ini:
- 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. 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 lainnya.
Pertanyaan kedua kita adalah: Bagaimana pekerja layanan memengaruhi pengalaman pemuatan situs?
Untuk menjawab pertanyaan ini, kami membuat laporan kustom lain untuk metrik Nilai Peristiwa Rata-Rata dan memfilter hasilnya agar hanya menyertakan peristiwa firstpaint kami. Kami menggunakan dimensi Kategori Perangkat dan dimensi Status Pekerja Layanan kustom.
Berlawanan dengan apa yang saya kira, pekerja layanan di perangkat seluler memiliki dampak yang jauh lebih sedikit pada waktu untuk menggambar pertama kali daripada pada pemuatan halaman secara keseluruhan.
"...pekerja layanan di perangkat seluler memiliki dampak yang jauh lebih sedikit pada waktu pembuatan pertama daripada pada pemuatan halaman secara keseluruhan."
Untuk mengeksplorasi mengapa hal ini terjadi, kita harus menggali data lebih dalam. Rata-rata dapat cocok untuk ringkasan umum dan garis luas, tetapi untuk benar-benar memahami bagaimana data 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 memudahkan hal ini.
Google Analytics memungkinkan kita membagi laporan berdasarkan dimensi apa pun yang kita inginkan, tetapi penggunaan ini tidak memungkinkan penggunaan untuk memerinci laporan berdasarkan metrik. Ini bukan berarti tidak mungkin. Hal ini berarti kita harus menyesuaikan penerapan sedikit lebih banyak untuk mendapatkan hasil yang diinginkan.
Karena hasil laporan hanya dapat dikelompokkan berdasarkan dimensi, kami harus menetapkan nilai metrik (dalam kasus 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 Chart Google, kita dapat mengkueri hasil mentah, lalu 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 mengembalikan array nilai yang terlihat seperti ini (Catatan: ini hanya lima hasil pertama). Hasilnya diurutkan dari yang terkecil ke terbesar, sehingga baris ini mewakili 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 biasa:
- Ada 3 peristiwa dengan nilai
firstpaint4 md - Ada 2 peristiwa dengan nilai
firstpaint5 md - Ada 10 peristiwa dengan nilai
firstpaint6 md - Ada 8 peristiwa dengan nilai
firstpaint7 md - Ada 10 peristiwa dengan
firstpaintvalueberdurasi 8 milidetik - dll.
Dari hasil ini, kita dapat mengekstrapolasi nilai firstpaint untuk setiap peristiwa dan membuat histogram distribusi. Kita melakukan ini untuk setiap kueri yang dijalankan.
Berikut adalah 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 first paint untuk kunjungan di mana pekerja layanan mengontrol halaman.
Perhatikan bahwa saat pekerja layanan mengontrol halaman, banyak pengunjung mengalami first paint yang hampir seketika, dengan median 583 md.
"...saat pekerja layanan mengontrol halaman, banyak pengunjung mengalami first paint yang hampir terjadi..."
Untuk mendapatkan pemahaman yang lebih baik tentang bagaimana perbandingan kedua distribusi ini, diagram berikutnya menunjukkan tampilan gabungan dari keduanya. Histogram yang menunjukkan kunjungan pekerja layanan yang tidak terkontrol ditempatkan di atas histogram yang menampilkan kunjungan terkontrol, dan keduanya dihamparkan di atas histogram yang menampilkan keduanya gabungan.
Satu hal yang menurut saya menarik dari hasil ini adalah distribusi dengan pekerja layanan terkontrol masih memiliki kurva berbentuk lonceng setelah lonjakan awal. Aku mengharapkan lonjakan yang besar di awal lalu turun secara bertahap, aku tidak mengira akan ada puncak kedua di kurva.
Ketika melihat kemungkinan penyebabnya, saya mengetahui bahwa meskipun pekerja layanan dapat mengontrol halaman, threadnya mungkin tidak aktif. Browser melakukan hal ini untuk menyimpan resource - jelas bahwa Anda tidak memerlukan setiap pekerja layanan untuk setiap situs yang pernah Anda kunjungi menjadi aktif dan siap saat itu juga. Ini menjelaskan akhir dari distribusi. Untuk beberapa pengguna, terjadi penundaan saat thread pekerja layanan dimulai.
Seperti yang Anda lihat dari distribusi, bahkan dengan penundaan awal ini, browser dengan pekerja layanan mengirim konten lebih cepat daripada browser yang melewati jaringan.
Berikut tampilannya di perangkat seluler:
Meskipun kami masih mengalami peningkatan yang cukup besar dalam waktu hampir seketika, bagian ekornya sedikit lebih besar dan lebih panjang. Hal ini kemungkinan terjadi karena, di perangkat seluler, memulai thread pekerja layanan yang tidak ada aktivitas memerlukan waktu yang lebih lama daripada di desktop. Hal 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 memerlukan waktu yang lebih lama daripada di desktop."
Berikut adalah perincian dari variasi waktu median first paint di perangkat seluler dan desktop yang dikelompokkan berdasarkan status pekerja layanan:
| Median Time to First Paint (md) | ||
|---|---|---|
| Status Pekerja Layanan | Desktop | Ponsel |
| Terkontrol | 583 | 1634 |
| Didukung (tidak dikontrol) | 912 | 1933 |
Meskipun membuat visualisasi distribusi ini membutuhkan lebih banyak waktu dan upaya daripada membuat laporan kustom di Google Analytics, visualisasi tersebut memberi kami gambaran yang jauh lebih baik tentang pengaruh pekerja layanan terhadap performa 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
Service worker memungkinkan pengguna berinteraksi dengan situs Anda saat offline, dan meskipun dukungan offline tertentu mungkin sangat penting untuk aplikasi web progresif, menentukan seberapa penting hal 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 pengiriman data tersebut pada waktu yang tepat saat interaksi terjadi. Google Analytics mendukung pengiriman data interaksi setelah fakta dengan menentukan selisih waktu (melalui parameter qt).
Selama dua tahun terakhir IOWA telah menggunakan skrip pekerja layanan yang mendeteksi hit yang gagal pada Google Analytics saat pengguna offline dan memutarnya kembali nanti dengan parameter qt.
Untuk melacak apakah pengguna sedang online atau offline, kami membuat dimensi kustom yang disebut Online dan menetapkannya ke nilai navigator.onLine, lalu memproses peristiwa online dan offline dan memperbarui dimensi yang sesuai.
Dan untuk mengetahui seberapa umum pengguna offline saat menggunakan IOWA, kami membuat segmen yang menargetkan pengguna dengan setidaknya satu interaksi offline. Ternyata, ternyata hampir 5% pengguna.
Notifikasi push
Pekerja layanan memungkinkan pengguna memilih untuk menerima notifikasi push. Di IOWA, pengguna akan diberi tahu ketika sesi dalam jadwal mereka akan dimulai.
Seperti halnya bentuk notifikasi lainnya, penting untuk menemukan keseimbangan antara memberikan nilai kepada pengguna dan mengganggu mereka. Untuk lebih memahami hal yang terjadi, penting untuk melacak apakah pengguna memilih ikut serta untuk menerima notifikasi ini, apakah mereka berinteraksi dengan pemberitahuan tersebut saat datang, dan apakah ada pengguna yang sebelumnya ikut serta, ubah preferensi dan ketidakikutsertaan mereka.
Di IOWA, kami hanya mengirim notifikasi terkait jadwal personal pengguna, sesuatu yang hanya dapat dibuat oleh pengguna yang login. Pembatasan ini membatasi kumpulan pengguna yang dapat menerima notifikasi untuk pengguna yang login (dilacak melalui dimensi kustom bernama Login) yang browsernya 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 berdasarkan pengguna yang login pada waktu tertentu dan yang browsernya mendukung notifikasi push.
Kami sangat senang melihat bahwa 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 permintaan 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
});
});
});
Pengguna yang melihat banner instal aplikasi, sekitar 10% memilih untuk menambahkannya ke layar utama.
Kemungkinan peningkatan pelacakan (untuk waktu berikutnya)
Data analisis yang kami kumpulkan dari IOWA tahun ini sangat berharga. Namun, pandangan ke belakang selalu membuka jalan kecil dan peluang untuk memperbaiki hal-hal untuk lain waktu. Setelah menyelesaikan analisis tahun ini, berikut dua hal yang sebaiknya kita lakukan secara berbeda agar pembaca yang ingin menerapkan strategi serupa dapat dipertimbangkan:
1. Melacak peristiwa lainnya yang terkait dengan pengalaman pemuatan
Kami melacak beberapa peristiwa yang sesuai dengan metrik teknis (mis. HTMLImportsLoaded, WebComponentsReady, dll.), tetapi karena begitu banyak pemuatan dilakukan secara asinkron, titik saat peristiwa ini diaktifkan tidak selalu sesuai dengan momen tertentu dalam keseluruhan pengalaman pemuatan.
Peristiwa terkait pemuatan utama yang tidak kami lacak (tetapi kami harap ada) 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 kita lakukan untuk mengatasi batasan ini adalah menyimpan client ID melalui IndexedDB di kode pelacakan kita, dan nilai tersebut akan dapat diakses oleh skrip pekerja layanan.
3. Mengizinkan pekerja layanan melaporkan status online/offline
Dengan memeriksa navigator.onLine, Anda akan dapat mengetahui apakah browser dapat terhubung ke router atau jaringan area lokal, tetapi tidak selalu memberi tahu apakah Anda memiliki konektivitas sebenarnya. Dan karena skrip pekerja layanan analisis offline hanya memutar ulang hit yang gagal (tanpa mengubahnya, atau menandainya sebagai gagal), kami mungkin tidak melaporkan penggunaan offline kami dalam jumlah yang cukup.
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 telah menunjukkan bahwa penggunaan pekerja layanan memang meningkatkan performa pemuatan aplikasi web Google I/O di berbagai browser, jaringan, dan perangkat. Laporan ini juga menunjukkan bahwa ketika Anda melihat distribusi data beban di berbagai browser, jaringan, dan perangkat, Anda akan mendapatkan lebih banyak wawasan tentang bagaimana teknologi ini menangani skenario dunia nyata, dan Anda menemukan karakteristik kinerja yang mungkin tidak Anda perkirakan.
Berikut adalah beberapa hal penting yang dapat dipelajari dari studi IOWA:
- Rata-rata, halaman dimuat 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 yang dimuat hampir seketika untuk banyak pengguna.
- Service worker, jika tidak aktif, memerlukan beberapa 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 perangkat seluler daripada di desktop.
Meskipun peningkatan performa yang diamati pada satu aplikasi tertentu umumnya berguna untuk dilaporkan ke komunitas developer yang lebih besar, penting untuk diingat bahwa hasil ini spesifik untuk jenis situs IOWA (situs acara) dan jenis audiens yang dimiliki IOWA (sebagian besar developer).
Jika mengimplementasikan pekerja layanan dalam aplikasi, Anda perlu mengimplementasikan strategi pengukuran sendiri agar dapat menilai performa Anda sendiri dan mencegah regresi di masa mendatang. Jika ya, bagikan hasil Anda agar semua orang dapat memperoleh manfaat.
Catatan kaki
- Tidak sepenuhnya adil untuk membandingkan kinerja penerapan cache pekerja layanan dengan kinerja situs kami dengan cache HTTP saja. Karena kami mengoptimalkan IOWA untuk pekerja layanan, kami tidak menghabiskan banyak waktu untuk mengoptimalkan cache HTTP. Jika kami punya, hasilnya mungkin akan berbeda. Untuk mempelajari lebih lanjut cara mengoptimalkan situs untuk cache HTTP, baca Mengoptimalkan Konten secara Efisien.
- Bergantung pada cara situs Anda memuat gaya dan kontennya, mungkin saja browser dapat menggambar sebelum konten atau gaya tersedia. Dalam kasus tersebut,
firstpaintmungkin sesuai dengan layar putih kosong. Jika menggunakanfirstpaint, pastikan atribut tersebut sesuai dengan poin yang bermakna dalam pemuatan resource situs Anda. - Secara teknis, kita dapat mengirim hit waktu (yang secara default bukan interaksi) untuk mengambil informasi ini, bukan peristiwa. Faktanya, hit waktu ditambahkan ke Google Analytics secara khusus untuk melacak metrik pemuatan seperti ini; namun, hit waktu banyak diambil sampelnya pada waktu pemrosesan, dan nilainya tidak dapat digunakan di segmen. Dengan keterbatasan saat ini, peristiwa non-interaksi tetap lebih cocok.
- Untuk lebih memahami cakupan yang harus diberikan pada dimensi kustom di Google Analytics, lihat bagian Dimensi Kustom di pusat bantuan Analytics. Anda juga harus memahami model data Google Analytics, yang terdiri dari pengguna, sesi, dan interaksi (hit). 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.