Cerita tentang apa yang dikirimkan, bagaimana dampaknya diukur, dan kompromi yang dibuat.
Latar belakang
Telusuri hampir semua topik di Google, dan Anda akan melihat halaman yang langsung dapat dikenali berisi hasil yang bermakna dan relevan. Yang mungkin tidak Anda sadari adalah bahwa halaman hasil penelusuran ini, dalam skenario tertentu, ditampilkan oleh teknologi web yang canggih yang disebut service worker.
Meluncurkan dukungan pekerja layanan untuk Google Penelusuran tanpa memengaruhi performa secara negatif memerlukan puluhan engineer yang bekerja di beberapa tim. Ini adalah kisah tentang apa yang dikirimkan, cara performa diukur, dan kompromi yang dibuat.
Alasan utama untuk mempelajari pekerja layanan
Menambahkan pekerja layanan ke aplikasi web, sama seperti melakukan perubahan arsitektur apa pun ke situs Anda, harus dilakukan dengan mempertimbangkan serangkaian sasaran yang jelas. Bagi tim Google Penelusuran, ada beberapa alasan utama mengapa menambahkan pekerja layanan perlu dijelajahi.
Penyimpanan dalam cache hasil penelusuran terbatas
Tim Google Penelusuran mendapati bahwa pengguna sering kali menelusuri istilah yang sama lebih dari sekali dalam jangka waktu yang singkat. Daripada memicu permintaan backend baru hanya untuk mendapatkan hasil yang kemungkinan sama, tim Penelusuran ingin memanfaatkan penyimpanan dalam cache dan memenuhi permintaan berulang tersebut secara lokal.
Pentingnya keaktualan tidak dapat diabaikan, dan terkadang pengguna menelusuri istilah yang sama berulang kali karena merupakan topik yang berkembang, dan mereka berharap untuk melihat hasil yang baru. 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 vs. keaktualan yang mereka yakini paling memuaskan pengguna.
Pengalaman offline yang bermakna
Selain itu, tim Google Penelusuran ingin memberikan pengalaman offline yang bermakna. Saat ingin mencari tahu tentang suatu topik, pengguna ingin langsung membuka halaman Google Penelusuran dan mulai menelusuri, tanpa perlu khawatir tentang koneksi Internet yang aktif.
Tanpa pekerja layanan, mengunjungi halaman penelusuran Google saat offline hanya akan mengarah ke halaman error jaringan standar browser, dan pengguna harus ingat untuk kembali dan mencoba lagi setelah koneksi mereka kembali. Dengan pekerja layanan, Anda dapat menayangkan respons HTML offline kustom, dan memungkinkan pengguna memasukkan kueri penelusuran mereka dengan segera.
Hasil tidak akan tersedia hingga ada koneksi Internet, tetapi pekerja layanan memungkinkan penelusuran ditangguhkan dan dikirim ke server Google begitu perangkat kembali online menggunakan API sinkronisasi latar belakang.
Penyimpanan dalam cache dan penayangan JavaScript yang lebih cerdas
Motivasi lainnya adalah untuk mengoptimalkan penyimpanan dalam cache dan pemuatan kode JavaScript yang dimodulasi yang mendukung berbagai jenis fitur di halaman hasil penelusuran. Ada sejumlah manfaat yang ditawarkan oleh penggabungan JavaScript yang membuat sense jika tidak ada keterlibatan pekerja layanan, sehingga tim Penelusuran tidak ingin berhenti melakukan penggabungan 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 perubahan cache dan memastikan bahwa JavaScript yang digunakan kembali di masa mendatang dapat di-cache secara efisien. Logika di dalam pekerja layanan dapat menganalisis permintaan HTTP keluar untuk paket yang berisi beberapa modul JavaScript, dan memenuhinya dengan menggabungkan beberapa modul yang di-cache secara lokal—yang secara efektif "membubarkan paket" jika memungkinkan. Hal ini menghemat bandwidth pengguna, dan meningkatkan responsivitas secara keseluruhan.
Ada juga manfaat performa dari penggunaan JavaScript yang di-cache dan 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 menjalankan JavaScript di halaman.
Tantangan dan solusi
Berikut beberapa kendala yang perlu 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 pemblokir sebenarnya 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 sebelumnya, telah memblokir peluncuran fungsi baru jika fungsi tersebut berkontribusi pada latensi tambahan puluhan milidetik untuk populasi pengguna tertentu.
Saat tim mulai mengumpulkan data performa selama eksperimen awal, jelas bahwa akan ada masalah. 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—hal terbaik yang dapat dilakukannya adalah meneruskan permintaan navigasi ke server web backend, yang memerlukan permintaan jaringan.
Tanpa pekerja layanan, permintaan jaringan ini akan segera terjadi setelah navigasi
pengguna. Saat didaftarkan, pekerja layanan selalu perlu dimulai
dan diberi kesempatan untuk menjalankan
pengendali peristiwa fetch,
meskipun tidak ada kemungkinan pengendali pengambilan tersebut akan melakukan apa pun selain pergi
ke jaringan. Jumlah waktu yang diperlukan untuk memulai dan menjalankan kode pekerja
layanan adalah overhead murni yang ditambahkan di atas setiap navigasi:
Hal ini membuat implementasi pekerja layanan memiliki terlalu banyak kelemahan latensi untuk membenarkan manfaat lainnya. Selain itu, tim menemukan bahwa, berdasarkan pengukuran waktu booting pekerja layanan di perangkat dunia nyata, ada distribusi waktu startup yang luas, dengan beberapa perangkat seluler kelas bawah memerlukan waktu hampir sama untuk memulai pekerja layanan seperti yang mungkin diperlukan untuk membuat permintaan jaringan untuk HTML halaman hasil.
Solusi: gunakan pramuat navigasi
Satu fitur terpenting yang memungkinkan tim Google Penelusuran melanjutkan peluncuran pekerja layanan mereka adalah pramuat navigasi. Menggunakan pramuat navigasi adalah peningkatan performa utama untuk setiap pekerja layanan yang perlu menggunakan respons dari jaringan untuk memenuhi permintaan navigasi. Hal ini memberikan petunjuk kepada browser untuk segera mulai membuat permintaan navigasi, secara bersamaan dengan pekerja layanan dimulai:
Selama jumlah waktu yang diperlukan untuk memulai pekerja layanan kurang dari jumlah waktu yang diperlukan untuk mendapatkan respons kembali dari jaringan, tidak boleh ada overhead latensi yang diperkenalkan oleh pekerja layanan.
Tim Penelusuran juga perlu menghindari penggunaan pekerja layanan di perangkat seluler bawah dengan waktu booting pekerja layanan yang dapat melebihi permintaan navigasi. Karena tidak ada aturan pasti tentang apa yang dimaksud dengan perangkat "low-end", mereka menemukan heuristik untuk memeriksa total RAM yang diinstal di perangkat. Memori kurang dari 2 gigabyte termasuk dalam kategori perangkat kelas bawah, dengan waktu startup pekerja layanan yang tidak dapat diterima.
Ruang penyimpanan yang tersedia adalah pertimbangan lainnya, karena kumpulan lengkap
resource yang akan di-cache untuk penggunaan mendatang dapat berjalan hingga beberapa megabyte. Antarmuka navigator.storage memungkinkan halaman Google Penelusuran mengetahui terlebih dahulu apakah upayanya 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 pramuat navigasi, dan memiliki setidaknya 2 gigabyte RAM, serta ruang penyimpanan kosong yang cukup, maka pekerja layanan akan terdaftar. Browser atau perangkat yang tidak memenuhi kriteria tersebut tidak akan memiliki 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 transpilasi dan polyfill untuk browser lama. Hal ini akhirnya memotong sekitar 8 kilobyte kode JavaScript yang tidak dikompresi dari total ukuran penerapan pekerja layanan.
Masalah: cakupan pekerja layanan
Setelah tim Penelusuran menjalankan cukup banyak eksperimen latensi dan yakin bahwa menggunakan pramuat navigasi menawarkan jalur yang layak dan netral latensi untuk menggunakan pekerja layanan, beberapa masalah praktis mulai menjadi prioritas. Salah satu masalah tersebut berkaitan dengan aturan cakupan pekerja layanan. Cakupan pekerja layanan menentukan halaman mana yang berpotensi dapat dikontrolnya.
Cakupan berfungsi berdasarkan awalan jalur URL. Untuk domain yang menghosting satu aplikasi web, hal ini tidak menjadi masalah, karena Anda biasanya hanya menggunakan pekerja layanan dengan cakupan maksimum /, yang dapat mengontrol halaman apa pun di bawah domain.
Namun, struktur URL Google Penelusuran sedikit lebih rumit.
Jika pekerja layanan diberi cakupan maksimum /, pekerja layanan tersebut akan
dapat mengontrol halaman apa pun yang dihosting di www.google.com (atau yang setara
regional), dan ada URL di domain tersebut yang tidak ada hubungannya dengan
Google Penelusuran. Cakupan yang lebih wajar dan membatasi adalah /search, yang setidaknya akan menghapus URL yang sama sekali tidak terkait dengan hasil penelusuran.
Sayangnya, bahkan jalur URL /search tersebut digunakan bersama di berbagai jenis
hasil Google Penelusuran, dengan parameter kueri URL yang menentukan jenis
tertentu dari hasil penelusuran yang ditampilkan. Beberapa ragam tersebut menggunakan codebase yang benar-benar berbeda
dari halaman hasil penelusuran web tradisional. Misalnya, Penelusuran Gambar
dan Penelusuran Shopping ditayangkan di jalur URL /search dengan parameter kueri
yang berbeda, tetapi tidak satu pun dari antarmuka tersebut yang siap mengirimkan pengalaman pekerja layanannya sendiri (belum).
Solusi: membuat framework pengiriman dan pemilihan rute
Meskipun ada beberapa proposal yang memungkinkan sesuatu yang lebih canggih daripada awalan jalur URL untuk menentukan cakupan pekerja layanan, tim Google Penelusuran mengalami kesulitan dalam men-deploy pekerja layanan yang tidak melakukan apa pun untuk sebagian halaman yang dikontrolnya.
Untuk mengatasi hal ini, tim Google Penelusuran membuat framework pengiriman dan pemilihan rute khusus yang dapat dikonfigurasi untuk memeriksa kriteria seperti parameter kueri halaman klien, dan menggunakannya untuk menentukan jalur kode tertentu yang akan dihentikan. Daripada membuat aturan hard code, sistem ini dibuat agar fleksibel dan memungkinkan tim yang berbagi ruang URL, seperti Penelusuran Gambar dan Penelusuran Shopping, untuk memasukkan 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. Pengguna yang login diidentifikasi oleh cookie browser tertentu, yang merupakan standar yang sudah lama digunakan dan didukung secara luas.
Namun, satu kelemahan menggunakan cookie browser adalah cookie tersebut tidak ditampilkan di dalam pekerja layanan, dan tidak ada cara untuk memeriksa nilainya secara otomatis dan memastikan bahwa nilai tersebut tidak berubah karena pengguna logout atau beralih akun. (Upaya sedang dilakukan untuk memberikan akses cookie ke pekerja layanan, tetapi pada saat penulisan ini, pendekatannya bersifat eksperimental dan tidak didukung secara luas.)
Ketidakcocokan antara tampilan pekerja layanan tentang pengguna yang saat ini login dan pengguna sebenarnya yang login ke antarmuka web Google Penelusuran dapat menyebabkan hasil penelusuran yang dipersonalisasi secara salah 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 API eksperimental diluncurkan 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 akan membaca cookie yang relevan dan menggunakan
postMessage()
untuk mengirimkannya ke pekerja layanan.
Kemudian, pekerja layanan akan memeriksa nilai cookie saat ini dengan nilai yang diharapkan, dan jika ada ketidakcocokan, pekerja layanan akan mengambil langkah-langkah untuk menghapus semua 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 pengukuran khusus untuk persyaratan Google Penelusuran, tetapi pendekatan umum yang sama mungkin berguna bagi developer lain yang menangani data yang dipersonalisasi yang diaktifkan 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 sedikit tantangan dengan pekerja layanan statis yang sangat mengandalkan data dalam cache, karena mengaktifkan dan menonaktifkan pengguna dalam eksperimen sering kali memerlukan komunikasi dengan server backend.
Solusi: skrip pekerja layanan yang dibuat secara dinamis
Solusi yang digunakan tim adalah menggunakan skrip pekerja layanan yang dihasilkan secara dinamis, yang disesuaikan oleh server web untuk setiap pengguna, bukan satu skrip pekerja layanan statis yang dibuat sebelumnya. Informasi tentang eksperimen yang mungkin memengaruhi perilaku pekerja layanan atau permintaan jaringan secara umum disertakan langsung dalam skrip pekerja layanan yang disesuaikan ini. Mengubah kumpulan pengalaman aktif untuk pengguna dilakukan melalui kombinasi teknik tradisional, seperti cookie browser, serta menayangkan kode yang diperbarui di URL pekerja layanan terdaftar.
Menggunakan skrip pekerja layanan yang dibuat secara dinamis juga memudahkan untuk memberikan jalan keluar jika implementasi pekerja layanan memiliki bug fatal yang perlu dihindari. Respons pekerja server dinamis dapat berupa implementasi tanpa operasi, yang secara efektif menonaktifkan pekerja layanan untuk beberapa atau semua pengguna saat ini.
Masalah: mengoordinasikan update
Salah satu tantangan terberat yang dihadapi deployment pekerja layanan di dunia nyata adalah merumuskan kompromi yang wajar antara menghindari jaringan untuk mendukung cache, sekaligus memastikan bahwa pengguna lama mendapatkan update dan perubahan kritis segera setelah di-deploy ke produksi. Keseimbangan yang tepat bergantung pada banyak faktor:
- Apakah aplikasi web Anda adalah aplikasi web satu halaman yang terus dibuka pengguna tanpa batas waktu, tanpa membuka halaman baru.
- Ritme deployment untuk update pada server web backend Anda.
- Apakah pengguna rata-rata akan mentolerir penggunaan versi aplikasi web Anda yang sedikit usang, atau apakah keaktualan adalah prioritas utama.
Saat bereksperimen dengan pekerja layanan, tim Google Penelusuran memastikan eksperimen tetap berjalan di sejumlah update backend terjadwal, untuk memastikan bahwa metrik dan pengalaman pengguna akan lebih cocok dengan apa yang akan dilihat pengguna di dunia nyata.
Solusi: menyeimbangkan keaktualan dan penggunaan cache
Setelah menguji sejumlah opsi konfigurasi yang berbeda, tim Google Penelusuran mendapati bahwa penyiapan berikut memberikan keseimbangan yang tepat antara keaktualan dan penggunaan cache.
URL skrip pekerja layanan ditayangkan dengan header respons Cache-Control: private, max-age=1500 (1.500 detik, atau 25 menit), dan terdaftar dengan updateViaCache ditetapkan ke 'all' untuk memastikan header dihormati. Seperti yang mungkin Anda bayangkan, backend web Google Penelusuran adalah kumpulan server besar yang didistribusikan secara global dan memerlukan uptime sebesar mungkin, yaitu mendekati 100%. Men-deploy perubahan yang akan memengaruhi
konten skrip pekerja layanan dilakukan secara bertahap.
Jika pengguna membuka backend yang telah diupdate, lalu dengan cepat membuka halaman lain yang membuka backend yang belum menerima pekerja layanan yang diupdate, mereka akan beralih antara versi beberapa kali. Oleh karena itu, memberi tahu browser untuk hanya memeriksa skrip yang diperbarui jika 25 menit telah berlalu sejak pemeriksaan terakhir tidak memiliki kelemahan yang signifikan. Keuntungan memilih ikut serta dalam perilaku ini adalah mengurangi traffic yang diterima oleh endpoint yang secara dinamis menghasilkan skrip pekerja layanan secara signifikan.
Selain itu, header ETag ditetapkan pada respons HTTP skrip pekerja layanan, yang memastikan bahwa saat pemeriksaan update dilakukan setelah 25 menit berlalu, server dapat merespons secara efisien dengan respons HTTP 304 jika belum ada update pada pekerja layanan yang di-deploy dalam waktu tersebut.
Meskipun beberapa interaksi dalam aplikasi web Google Penelusuran menggunakan navigasi gaya aplikasi
satu halaman (yaitu melalui
History API),
sebagian besar Google Penelusuran adalah aplikasi web tradisional yang menggunakan navigasi "sebenarnya". Hal ini berlaku saat tim memutuskan bahwa akan lebih efektif menggunakan dua opsi yang mempercepat siklus proses update pekerja layanan: clients.claim() dan skipWaiting().
Mengklik antarmuka Google Penelusuran biasanya akan membuka dokumen HTML baru. Memanggil skipWaiting memastikan bahwa pekerja layanan yang diupdate
mendapatkan kesempatan untuk menangani permintaan navigasi baru tersebut segera setelah
penginstalan. Demikian pula, memanggil clients.claim() berarti pekerja layanan yang diperbarui
mendapatkan kesempatan untuk mulai mengontrol halaman Google Penelusuran terbuka
yang tidak terkontrol, setelah aktivasi pekerja layanan.
Pendekatan yang digunakan Google Penelusuran tidak selalu merupakan solusi yang
berhasil untuk semua orang—pendekatan ini adalah hasil dari pengujian A/B yang cermat terhadap berbagai
kombinasi opsi penayangan hingga mereka menemukan yang paling sesuai.
Developer yang infrastruktur backend-nya memungkinkan mereka men-deploy update dengan lebih cepat
mungkin lebih memilih agar browser memeriksa skrip pekerja layanan yang diperbarui
sering mungkin, dengan
selalu mengabaikan cache HTTP.
Jika Anda mem-build aplikasi web satu halaman yang mungkin akan terus terbuka oleh pengguna selama
jangka waktu yang lama, penggunaan skipWaiting() mungkin bukan pilihan yang tepat bagi
Anda—Anda
berisiko mengalami inkonsistensi cache
jika mengizinkan pekerja layanan baru diaktifkan saat ada klien
yang berumur panjang.
Poin-Poin Penting
Secara default, pekerja layanan tidak netral performa
Menambahkan pekerja layanan ke aplikasi web berarti menyisipkan potongan JavaScript tambahan yang perlu dimuat dan dieksekusi sebelum aplikasi web Anda mendapatkan respons atas permintaannya. Jika respons tersebut akhirnya berasal dari cache lokal, bukan dari jaringan, overhead menjalankan pekerja layanan biasanya dapat diabaikan dibandingkan dengan peningkatan performa dari cache-first. Namun, jika Anda tahu bahwa pekerja layanan selalu harus berkonsultasi dengan jaringan saat menangani permintaan navigasi, menggunakan pramuat navigasi adalah peningkatan performa yang penting.
Pekerja layanan (masih) merupakan peningkatan progresif
Cerita dukungan pekerja layanan saat ini jauh lebih baik daripada tahun lalu. Semua browser modern kini memiliki 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 tahu diperlukan, dan hanya mendaftarkan pekerja layanan jika ada, masih merupakan pendekatan yang wajar.
Demikian pula, jika Anda telah menjalankan eksperimen di dunia nyata, dan mengetahui bahwa perangkat kelas bawah akhirnya berperforma buruk dengan overhead tambahan pekerja layanan, Anda juga dapat memilih untuk tidak mendaftarkan pekerja layanan dalam skenario tersebut.
Anda harus terus memperlakukan pekerja layanan sebagai progressive enhancement yang ditambahkan ke aplikasi web saat semua prasyarat terpenuhi dan pekerja layanan menambahkan sesuatu yang positif ke pengalaman pengguna dan performa pemuatan secara keseluruhan.
Mengukur semuanya
Satu-satunya cara untuk mengetahui apakah pengiriman pekerja layanan telah memiliki dampak positif atau negatif terhadap pengalaman pengguna adalah dengan bereksperimen 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 di komunitas pengembangan web mengaitkan pekerja layanan dengan Progressive Web App, mem-build "PWA Google Penelusuran" bukanlah sasaran awal tim. Aplikasi web Google Penelusuran saat ini tidak menyediakan metadata melalui manifes aplikasi web, atau mendorong pengguna untuk melalui alur Tambahkan ke Layar Utama. Tim Penelusuran saat ini puas dengan pengguna yang membuka aplikasi web mereka melalui titik entri tradisional untuk Google Penelusuran.
Daripada mencoba mengubah pengalaman web Google Penelusuran menjadi setara dengan yang Anda harapkan dari aplikasi yang diinstal, fokus pada peluncuran awal adalah untuk meningkatkan situs web yang ada secara bertahap.
Ucapan terima kasih
Terima kasih kepada seluruh tim pengembangan web Google Penelusuran atas pekerjaan mereka dalam penerapan pekerja layanan, dan atas berbagi materi latar belakang yang digunakan untuk menulis 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 (Oktober 2021): Sejak artikel ini pertama kali dipublikasikan, tim Google Penelusuran telah mengevaluasi ulang manfaat dan kompromi dari arsitektur pekerja layanan mereka saat ini. Pekerja layanan yang dijelaskan di atas tidak digunakan lagi. Seiring perkembangan infrastruktur web Google Penelusuran, tim dapat meninjau kembali desain pekerja layanan mereka.