Kisah tentang apa yang dikirim, cara mengukur dampaknya, dan kompromi yang dilakukan.
Dipublikasikan: 20 Juni 2019
Telusuri hampir semua topik di Google, dan Anda akan melihat halaman yang langsung dikenali berisi hasil yang bermakna dan relevan. Yang mungkin tidak Anda sadari adalah bahwa halaman hasil penelusuran ini, dalam skenario tertentu, ditayangkan oleh teknologi web canggih yang disebut service worker.
Meluncurkan dukungan pekerja layanan untuk Google Penelusuran tanpa berdampak negatif pada performa memerlukan puluhan engineer yang bekerja di beberapa tim. Berikut adalah kisah tentang apa yang dikirimkan, cara mengukur performa, dan kompromi yang dilakukan.
Alasan utama untuk mempelajari pekerja layanan
Menambahkan pekerja layanan ke aplikasi web, seperti melakukan perubahan arsitektur apa pun pada situs Anda, harus dilakukan dengan serangkaian sasaran yang jelas. Untuk tim Google Penelusuran, ada beberapa alasan utama mengapa penambahan pekerja layanan layak untuk dieksplorasi.
Penyimpanan cache hasil penelusuran terbatas
Tim Google Penelusuran mendapati bahwa pengguna sering kali menelusuri istilah yang sama lebih dari sekali dalam jangka waktu singkat. Daripada memicu permintaan backend baru hanya untuk mendapatkan hasil yang kemungkinan sama, tim Penelusuran ingin memanfaatkan caching dan memenuhi permintaan berulang tersebut secara lokal.
Pentingnya keaktualan tidak dapat diabaikan, dan terkadang pengguna menelusuri istilah yang sama berulang kali karena topik tersebut terus berkembang, dan mereka berharap melihat hasil yang terbaru. Dengan menggunakan pekerja layanan, tim Penelusuran dapat menerapkan logika terperinci untuk mengontrol masa aktif hasil penelusuran yang di-cache secara lokal, dan mencapai keseimbangan yang tepat antara kecepatan dan keaktualan yang mereka yakini paling sesuai untuk melayani pengguna.
Pengalaman offline yang bermakna
Selain itu, tim Google Penelusuran ingin memberikan pengalaman offline yang bermakna. Saat pengguna ingin mencari tahu tentang suatu topik, mereka ingin langsung membuka halaman Google Penelusuran dan mulai menelusuri, tanpa mengkhawatirkan koneksi Internet yang aktif.
Tanpa pekerja layanan, membuka halaman penelusuran Google saat offline hanya akan menampilkan halaman error jaringan standar browser, dan pengguna harus mengingat untuk kembali dan mencoba lagi setelah koneksi mereka kembali. Dengan pekerja layanan, respons HTML offline kustom dapat ditayangkan, dan pengguna dapat memasukkan kueri penelusuran mereka secara langsung.
Hasil tidak akan tersedia hingga ada koneksi Internet, tetapi pekerja layanan memungkinkan penelusuran ditangguhkan dan dikirim ke server Google segera setelah perangkat kembali online menggunakan API sinkronisasi latar belakang.
Caching dan penayangan JavaScript yang lebih cerdas
Motivasi lainnya adalah untuk mengoptimalkan penyimpanan dalam cache dan pemuatan kode JavaScript modular yang mendukung berbagai jenis fitur di halaman hasil penelusuran. Ada sejumlah manfaat yang ditawarkan oleh bundling JavaScript yang masuk akal jika tidak ada keterlibatan pekerja layanan, sehingga tim Penelusuran tidak ingin menghentikan bundling sepenuhnya.
Dengan menggunakan kemampuan pekerja layanan untuk membuat versi dan meng-cache potongan JavaScript yang terperinci saat runtime, tim Penelusuran menduga bahwa mereka dapat mengurangi jumlah churn cache dan memastikan bahwa JavaScript yang digunakan kembali pada masa mendatang dapat di-cache secara efisien. Logika di dalam pekerja layanan mereka dapat menganalisis permintaan HTTP keluar untuk bundle yang berisi beberapa modul JavaScript, dan memenuhinya dengan menggabungkan beberapa modul yang di-cache secara lokal—secara efektif "membuka bundle" jika memungkinkan. Tindakan ini menghemat bandwidth pengguna, dan meningkatkan responsivitas secara keseluruhan.
Ada juga manfaat performa dari penggunaan JavaScript yang di-cache yang ditayangkan oleh pekerja layanan: di Chrome, representasi kode byte yang diuraikan dari JavaScript tersebut disimpan dan digunakan kembali, sehingga mengurangi pekerjaan yang perlu dilakukan saat runtime untuk mengeksekusi JavaScript di halaman.
Tantangan dan solusi
Berikut beberapa kendala yang harus diatasi untuk mencapai tujuan yang dinyatakan tim. Meskipun beberapa tantangan ini khusus untuk Google Penelusuran, banyak di antaranya berlaku untuk berbagai situs yang mungkin mempertimbangkan deployment pekerja layanan.
Masalah: overhead pekerja layanan
Tantangan terbesar, dan satu-satunya penghalang untuk meluncurkan pekerja layanan di Google Penelusuran, adalah memastikan bahwa pekerja layanan tidak melakukan apa pun yang dapat meningkatkan latensi yang dirasakan pengguna. Google Penelusuran sangat memperhatikan performa, dan pada masa lalu, telah memblokir peluncuran fungsi baru jika hal itu menyebabkan latensi tambahan meskipun hanya puluhan milidetik untuk populasi pengguna tertentu.
Saat tim mulai mengumpulkan data performa selama eksperimen awal mereka, masalah akan terlihat jelas. HTML yang ditampilkan sebagai respons terhadap permintaan navigasi untuk halaman hasil penelusuran bersifat dinamis, dan sangat bervariasi bergantung pada logika yang perlu dijalankan di server web Penelusuran. Saat ini, tidak ada cara bagi pekerja layanan untuk mereplikasi logika ini dan langsung menampilkan HTML yang di-cache. Yang terbaik yang dapat dilakukan adalah meneruskan permintaan navigasi ke server web backend, yang memerlukan permintaan jaringan.
Tanpa pekerja layanan, permintaan jaringan ini terjadi segera setelah pengguna
melakukan navigasi. Saat didaftarkan, pekerja layanan harus selalu diaktifkan
dan diberi kesempatan untuk menjalankan
penangan peristiwa fetch,
bahkan saat penangan pengambilan data tersebut tidak mungkin melakukan apa pun selain
menuju ke jaringan. Durasi waktu yang diperlukan untuk memulai dan menjalankan kode pekerja layanan adalah overhead murni yang ditambahkan di atas setiap navigasi:
Hal ini membuat penerapan pekerja layanan terlalu banyak mengalami kerugian latensi untuk membenarkan manfaat lainnya. Selain itu, tim menemukan bahwa, berdasarkan pengukuran waktu booting pekerja layanan di perangkat dunia nyata, ada distribusi waktu mulai yang luas, dengan beberapa perangkat seluler kelas bawah membutuhkan waktu hampir sama untuk memulai pekerja layanan seperti yang mungkin diperlukan untuk membuat permintaan jaringan untuk HTML halaman hasil.
Solusi: gunakan pra-muat navigasi
Satu-satunya fitur paling penting yang memungkinkan tim Google Penelusuran melanjutkan peluncuran pekerja layanan mereka adalah pemuatan awal navigasi. Menggunakan pra-pemuatan navigasi adalah peningkatan performa utama untuk setiap pekerja layanan yang perlu menggunakan respons dari jaringan untuk memenuhi permintaan navigasi. Fitur ini memberikan petunjuk kepada browser untuk segera membuat permintaan navigasi, pada saat yang sama saat service worker dimulai:
Selama durasi waktu yang dibutuhkan pekerja layanan untuk memulai lebih singkat daripada durasi waktu yang dibutuhkan untuk mendapatkan respons kembali dari jaringan, tidak akan ada overhead latensi yang diperkenalkan oleh pekerja layanan.
Tim Penelusuran juga perlu menghindari penggunaan pekerja layanan di perangkat seluler kelas bawah yang waktu booting pekerja layanannya dapat melebihi permintaan navigasi. Karena tidak ada aturan pasti tentang apa yang termasuk perangkat "kelas bawah", mereka membuat heuristik memeriksa total RAM yang diinstal di perangkat. Perangkat dengan memori kurang dari 2 gigabyte termasuk dalam kategori perangkat kelas bawah, yang waktu mulai pekerja layanannya tidak dapat diterima.
Ruang penyimpanan yang tersedia adalah pertimbangan lain, karena set lengkap resource yang akan di-cache untuk penggunaan mendatang dapat mencapai beberapa megabyte. Antarmuka
navigator.storage
memungkinkan halaman Google Penelusuran mengetahui terlebih dahulu apakah upaya mereka untuk
meng-cache data berisiko gagal karena kegagalan kuota penyimpanan.
Hal ini membuat tim Penelusuran memiliki beberapa kriteria yang dapat mereka gunakan untuk menentukan apakah akan menggunakan pekerja layanan atau tidak: jika pengguna membuka halaman Google Penelusuran menggunakan browser yang mendukung pra-pemuatan navigasi, dan memiliki RAM minimal 2 gigabyte, serta ruang penyimpanan kosong yang cukup, maka pekerja layanan akan didaftarkan. Browser atau perangkat yang tidak memenuhi kriteria tersebut tidak akan mendapatkan pekerja layanan, tetapi akan tetap melihat pengalaman Google Penelusuran yang sama seperti biasanya.
Salah satu manfaat sampingan dari pendaftaran selektif ini adalah kemampuan untuk mengirimkan pekerja layanan yang lebih kecil dan lebih efisien. Menargetkan browser yang cukup modern untuk menjalankan kode pekerja layanan akan menghilangkan overhead transpilation dan polyfill untuk browser lama. Hal ini akhirnya memangkas sekitar 8 kilobyte kode JavaScript yang tidak dikompresi dari total ukuran penerapan pekerja layanan.
Masalah: cakupan pekerja layanan
Setelah tim Penelusuran menjalankan eksperimen latensi yang cukup dan yakin bahwa penggunaan pra-pemuatan navigasi menawarkan jalur yang layak dan netral latensi untuk menggunakan pekerja layanan, beberapa masalah praktis mulai muncul. Salah satu masalah tersebut berkaitan dengan aturan cakupan pekerja layanan. Cakupan pekerja layanan menentukan halaman mana yang berpotensi dikontrolnya.
Penetapan cakupan berfungsi berdasarkan awalan jalur URL. Untuk domain yang menghosting satu aplikasi web, hal ini tidak menjadi masalah, karena biasanya Anda hanya menggunakan pekerja layanan dengan cakupan maksimal /, yang dapat mengontrol halaman apa pun di domain tersebut.
Namun, struktur URL Google Penelusuran sedikit lebih rumit.
Jika pekerja layanan diberi cakupan maksimal /, pekerja layanan tersebut akan dapat mengontrol halaman apa pun yang dihosting di www.google.com (atau yang setara di wilayah), dan ada URL di domain tersebut yang tidak ada hubungannya dengan Google Penelusuran. Cakupan pembatasan yang lebih wajar adalah /search, yang setidaknya akan menghilangkan URL yang sama sekali tidak terkait dengan hasil penelusuran.
Sayangnya, jalur URL /search tersebut juga digunakan bersama oleh berbagai jenis hasil Google Penelusuran, dengan parameter kueri URL yang menentukan jenis hasil penelusuran tertentu yang ditampilkan. Beberapa rasa tersebut menggunakan codebase yang sama sekali berbeda dengan halaman hasil penelusuran web tradisional. Misalnya, Penelusuran Gambar dan Penelusuran Shopping keduanya ditayangkan di jalur URL /search dengan parameter kueri yang berbeda, tetapi kedua antarmuka tersebut belum siap untuk meluncurkan pengalaman pekerja layanannya sendiri (saat ini).
Solusi: buat framework pengiriman dan perutean
Meskipun ada beberapa proposal yang memungkinkan sesuatu yang lebih canggih daripada awalan jalur URL untuk menentukan cakupan pekerja layanan, tim Google Penelusuran mengalami kesulitan men-deploy pekerja layanan yang tidak melakukan apa pun untuk subset halaman yang dikontrolnya.
Untuk mengatasi hal ini, tim Google Penelusuran membuat framework pengiriman dan perutean khusus yang dapat dikonfigurasi untuk memeriksa kriteria seperti parameter kueri halaman klien, dan menggunakannya untuk menentukan jalur kode spesifik mana yang akan digunakan. Daripada membuat aturan secara hardcode, sistem ini dibuat agar fleksibel dan memungkinkan tim yang berbagi ruang URL, seperti Penelusuran Gambar dan Penelusuran Shopping, untuk menerapkan logika pekerja layanan mereka sendiri di masa mendatang, jika mereka memutuskan untuk menerapkannya.
Masalah: hasil dan metrik yang dipersonalisasi
Pengguna dapat login ke Google Penelusuran menggunakan Akun Google mereka, dan pengalaman hasil penelusuran mereka dapat disesuaikan berdasarkan data akun tertentu mereka. Pengguna yang login diidentifikasi oleh cookie browser tertentu, yang merupakan standar yang andal dan didukung secara luas.
Namun, salah satu kekurangan penggunaan cookie browser adalah cookie tersebut tidak diekspos di dalam pekerja layanan, dan tidak ada cara untuk memeriksa nilainya secara otomatis dan memastikan bahwa nilainya tidak berubah karena pengguna logout atau beralih akun. (Ada upaya yang sedang dilakukan untuk membawa akses cookie ke pekerja layanan, tetapi pada saat penulisan ini, pendekatan tersebut masih bersifat eksperimental dan tidak didukung secara luas.)
Ketidakcocokan antara tampilan pengguna yang saat ini login di pekerja layanan dan pengguna sebenarnya yang login ke antarmuka web Google Penelusuran dapat menyebabkan hasil penelusuran yang dipersonalisasi secara tidak benar atau metrik dan logging yang salah diatribusikan. Setiap skenario kegagalan tersebut akan menjadi masalah serius bagi tim Google Penelusuran.
Solusi: mengirim cookie menggunakan postMessage
Daripada menunggu peluncuran API eksperimental dan memberikan akses langsung ke
cookie browser di dalam pekerja layanan, tim Google Penelusuran memilih
solusi sementara: setiap kali halaman yang dikontrol oleh pekerja layanan dimuat, halaman tersebut membaca cookie yang relevan dan menggunakan
postMessage()
untuk mengirimkannya ke pekerja layanan.
Kemudian, pekerja layanan memeriksa nilai cookie saat ini dengan nilai yang diharapkan, dan jika ada ketidakcocokan, pekerja layanan akan mengambil langkah-langkah untuk menghapus data khusus pengguna dari penyimpanannya, dan memuat ulang halaman hasil penelusuran tanpa personalisasi yang salah.
Langkah-langkah spesifik yang dilakukan pekerja layanan untuk mereset semuanya ke dasar khusus untuk persyaratan Google Penelusuran, tetapi pendekatan umum yang sama dapat berguna bagi developer lain yang menangani data yang dipersonalisasi yang dikunci dari cookie browser.
Masalah: eksperimen dan dinamisme
Seperti yang disebutkan, tim Google Penelusuran sangat mengandalkan eksperimen yang dijalankan dalam produksi, dan menguji efek kode dan fitur baru di dunia nyata sebelum mengaktifkannya secara default. Hal ini dapat menjadi tantangan tersendiri dengan service worker statis yang sangat mengandalkan data yang di-cache, karena mengikutsertakan dan mengeluarkan pengguna dari eksperimen sering kali memerlukan komunikasi dengan server backend.
Solusi: skrip pekerja layanan yang dibuat secara dinamis
Solusi yang dipilih tim adalah menggunakan skrip service worker yang dibuat secara dinamis, yang disesuaikan oleh server web untuk setiap pengguna, bukan skrip service worker statis tunggal yang dibuat sebelumnya. Informasi tentang eksperimen yang dapat memengaruhi perilaku pekerja layanan atau permintaan jaringan secara umum disertakan langsung dalam skrip pekerja layanan yang disesuaikan ini. Perubahan set pengalaman aktif untuk pengguna dilakukan melalui kombinasi teknik tradisional, seperti cookie browser, serta penayangan kode yang diperbarui di URL pekerja layanan terdaftar.
Menggunakan skrip pekerja layanan yang dibuat secara dinamis juga mempermudah penyediaan mekanisme keluar jika terjadi bug fatal dalam penerapan pekerja layanan yang perlu dihindari. Respons pekerja layanan server dinamis dapat berupa implementasi no-op, yang secara efektif menonaktifkan pekerja layanan untuk sebagian atau semua pengguna saat ini.
Masalah: mengoordinasikan pembaruan
Salah satu tantangan terberat yang dihadapi setiap deployment pekerja layanan dunia nyata adalah menyusun kompromi yang wajar antara menghindari jaringan demi cache, sekaligus memastikan bahwa pengguna yang sudah ada mendapatkan update dan perubahan penting segera setelah di-deploy ke produksi. Keseimbangan yang tepat bergantung pada banyak faktor:
- Apakah aplikasi web Anda adalah aplikasi halaman tunggal yang berjalan lama dan pengguna terus membukanya tanpa batas waktu, tanpa membuka halaman baru.
- Frekuensi deployment untuk update ke server web backend Anda.
- Apakah pengguna rata-rata akan mentoleransi penggunaan aplikasi web Anda yang sedikit tidak terbaru, atau apakah keaktualan adalah prioritas utama.
Saat bereksperimen dengan pekerja layanan, tim Google Penelusuran memastikan untuk menjalankan eksperimen di sejumlah update backend terjadwal, untuk memastikan bahwa metrik dan pengalaman pengguna akan lebih cocok dengan apa yang akan dilihat pengguna yang kembali di dunia nyata.
Solusi: seimbangkan keaktualan dan pemanfaatan cache
Setelah menguji sejumlah opsi konfigurasi yang berbeda, tim Google Penelusuran menemukan bahwa penyiapan berikut memberikan keseimbangan yang tepat antara keaktualan dan pemanfaatan cache.
URL skrip pekerja layanan ditayangkan dengan header respons Cache-Control: private, max-age=1500 (1.500 detik, atau 25 menit), dan didaftarkan dengan updateViaCache yang ditetapkan ke 'all' untuk memastikan header tersebut dipatuhi. Backend web Google Penelusuran, seperti yang dapat Anda bayangkan, adalah sekumpulan server besar yang didistribusikan secara global dan memerlukan waktu beroperasi mendekati 100%. Penerapan perubahan yang akan memengaruhi konten skrip pekerja layanan dilakukan secara bertahap.
Jika pengguna mengakses backend yang telah diupdate, lalu dengan cepat membuka halaman lain yang mengakses backend yang belum menerima pekerja layanan yang diupdate, pengguna akan berulang kali beralih di antara versi. Oleh karena itu, memberi tahu browser untuk hanya memeriksa skrip yang diperbarui jika 25 menit telah berlalu sejak pemeriksaan terakhir tidak memiliki kerugian yang signifikan. Keuntungan memilih untuk mengaktifkan perilaku ini adalah mengurangi secara signifikan traffic yang diterima oleh endpoint yang membuat skrip pekerja layanan secara dinamis.
Selain itu, header ETag disetel pada respons HTTP skrip pekerja layanan, sehingga saat pemeriksaan update dilakukan setelah 25 menit berlalu, server dapat merespons secara efisien dengan respons HTTP 304 jika tidak ada update pada pekerja layanan yang di-deploy dalam jangka waktu tersebut.
Meskipun beberapa interaksi dalam aplikasi web Google Penelusuran menggunakan navigasi gaya aplikasi halaman tunggal (yaitu melalui History API), sebagian besar, Google Penelusuran adalah aplikasi web tradisional yang menggunakan navigasi "nyata". Hal ini berlaku saat tim memutuskan bahwa akan efektif menggunakan dua opsi yang mempercepat siklus proses update pekerja layanan:
clients.claim()
dan
skipWaiting().
Mengklik antarmuka Google Penelusuran umumnya akan membuka dokumen HTML baru. Memanggil skipWaiting memastikan bahwa pekerja layanan yang diupdate
mendapatkan kesempatan untuk segera menangani permintaan navigasi baru tersebut setelah
penginstalan. Demikian pula, memanggil clients.claim() berarti bahwa service worker yang diupdate
mendapatkan kesempatan untuk mulai mengontrol halaman Google Penelusuran terbuka yang tidak terkontrol, setelah aktivasi service worker.
Pendekatan yang digunakan Google Penelusuran belum tentu merupakan solusi yang cocok untuk semua orang. Pendekatan tersebut adalah hasil pengujian A/B yang cermat terhadap berbagai kombinasi opsi penayangan hingga mereka menemukan opsi yang paling efektif.
Developer yang infrastruktur backend-nya memungkinkan mereka men-deploy update dengan lebih cepat mungkin lebih suka browser memeriksa skrip pekerja layanan yang diupdate sesering mungkin, dengan selalu mengabaikan cache HTTP.
Jika Anda membangun aplikasi halaman tunggal yang mungkin dibiarkan terbuka oleh pengguna dalam jangka waktu yang lama, menggunakan skipWaiting() mungkin bukan pilihan yang tepat bagi Anda—Anda berisiko mengalami inkonsistensi cache jika Anda mengizinkan pekerja layanan baru diaktifkan saat ada klien yang berjalan lama.
Poin-Poin Penting
Secara default, pekerja layanan tidak netral terhadap performa
Menambahkan pekerja layanan ke aplikasi web Anda berarti menyisipkan potongan JavaScript tambahan yang perlu dimuat dan dieksekusi sebelum aplikasi web Anda mendapatkan respons terhadap permintaannya. Jika respons tersebut berasal dari cache lokal, bukan dari jaringan, overhead menjalankan pekerja layanan biasanya dapat diabaikan dibandingkan dengan peningkatan performa dari penggunaan strategi cache-first. Namun, jika Anda tahu bahwa pekerja layanan Anda harus selalu berkonsultasi dengan jaringan saat menangani permintaan navigasi, menggunakan pra-pemuatan navigasi adalah peningkatan performa yang sangat penting.
Service worker (masih!) merupakan peningkatan progresif
Kisah dukungan pekerja layanan saat ini jauh lebih cerah daripada setahun yang lalu. Semua browser modern kini menampilkan setidaknya beberapa dukungan untuk pekerja layanan, tetapi sayangnya, ada beberapa fitur pekerja layanan lanjutan—seperti sinkronisasi latar belakang dan pramuat navigasi—yang tidak diluncurkan secara universal. Pemeriksaan fitur untuk subset fitur tertentu yang Anda ketahui diperlukan, dan hanya mendaftarkan pekerja layanan jika fitur tersebut ada, masih merupakan pendekatan yang wajar untuk dilakukan.
Demikian pula, jika Anda telah menjalankan eksperimen di luar, dan mengetahui bahwa perangkat kelas bawah cenderung berperforma buruk dengan overhead tambahan dari pekerja layanan, Anda juga dapat tidak mendaftarkan pekerja layanan dalam skenario tersebut.
Anda harus terus memperlakukan pekerja layanan sebagai peningkatan progresif yang ditambahkan ke aplikasi web saat semua prasyarat terpenuhi dan pekerja layanan menambahkan sesuatu yang positif pada pengalaman pengguna dan performa pemuatan secara keseluruhan.
Mengukur semuanya
Satu-satunya cara untuk mengetahui apakah pengiriman pekerja layanan berdampak positif atau negatif terhadap pengalaman pengguna adalah dengan melakukan eksperimen dan mengukur hasilnya.
Detail penyiapan pengukuran yang bermakna bergantung pada penyedia analisis yang Anda gunakan, dan cara Anda biasanya melakukan eksperimen dalam penyiapan deployment. Salah satu pendekatan, menggunakan Google Analytics untuk mengumpulkan metrik, dijelaskan dalam studi kasus ini berdasarkan pengalaman menggunakan pekerja layanan di aplikasi web Google I/O.
Non-sasaran
Meskipun banyak orang dalam komunitas pengembangan web mengaitkan pekerja layanan dengan Progressive Web App, membangun "PWA Google Penelusuran" bukanlah tujuan awal tim. Aplikasi web Google Penelusuran tidak menyediakan metadata dalam manifest aplikasi web, dan tidak mendorong pengguna untuk melalui alur Tambahkan ke Layar Utama. Tim Penelusuran puas dengan pengguna yang membuka aplikasi web mereka dengan titik entri klasik untuk Google Penelusuran.
Daripada mencoba mengubah pengalaman web Google Penelusuran menjadi setara dengan apa yang Anda harapkan dari aplikasi yang diinstal, fokus pada rilis awal adalah untuk meningkatkan situs web yang ada secara progresif.
Ucapan terima kasih
Terima kasih kepada seluruh tim pengembangan web Google Penelusuran atas pekerjaan mereka dalam penerapan service worker, dan atas materi latar belakang yang mereka bagikan untuk penulisan artikel ini. Terima kasih khusus kepada Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono, dan Clay Woolam.
Pembaruan (Okt. 2021): Sejak artikel ini pertama kali dipublikasikan, tim Google Penelusuran telah mengevaluasi ulang manfaat dan kerugian arsitektur pekerja layanan mereka saat ini. Service worker yang dijelaskan di atas akan dihentikan. Seiring berkembangnya infrastruktur web Google Penelusuran, tim dapat meninjau kembali desain pekerja layanan mereka.