Kisah tentang produk yang diluncurkan, bagaimana dampaknya diukur, dan konsekuensi yang diberikan.
Latar belakang
Telusuri hampir semua topik di Google, dan Anda akan langsung melihat halaman hasil yang bermakna dan relevan yang dapat langsung dikenali. Yang mungkin tidak Anda sadari, dalam skenario tertentu, halaman hasil penelusuran ini ditayangkan oleh teknologi web canggih yang disebut pekerja layanan.
Meluncurkan dukungan pekerja layanan untuk Google Penelusuran tanpa berdampak negatif pada performa memerlukan puluhan engineer yang bekerja di beberapa tim. Bagian ini berisi kisah tentang produk yang dikirimkan, cara pengukuran performa, dan kerugian yang diakibatkan.
Alasan utama untuk mempelajari pekerja layanan
Menambahkan pekerja layanan ke aplikasi web, seperti membuat perubahan arsitektur pada situs, harus dilakukan dengan mempertimbangkan serangkaian sasaran yang jelas. Bagi tim Google Penelusuran, ada beberapa alasan utama mengapa menambahkan pekerja layanan layak untuk dieksplorasi.
Penyimpanan dalam cache hasil penelusuran terbatas
Tim Google Penelusuran mendapati bahwa pengguna biasanya menelusuri istilah yang sama lebih dari sekali dalam waktu singkat. Alih-alih memicu permintaan backend baru hanya untuk mendapatkan hasil yang 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 ini adalah topik yang terus berkembang, dan mereka berharap melihat hasil baru. Dengan menggunakan pekerja layanan, tim Penelusuran dapat menerapkan logika yang terperinci untuk mengontrol masa aktif hasil penelusuran yang di-cache secara lokal, dan mencapai keseimbangan yang tepat antara kecepatan vs. keaktualan yang menurut mereka paling tepat melayani 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 mencemaskan 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, respons HTML offline kustom dapat ditayangkan, dan memungkinkan pengguna untuk langsung memasukkan kueri penelusuran mereka.
Hasilnya 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.
Penyimpanan dalam cache dan penyaluran JavaScript yang lebih cerdas
Motivasi lainnya adalah 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 pemaketan JavaScript yang masuk akal jika tidak ada keterlibatan pekerja layanan, sehingga tim Penelusuran tidak ingin berhenti melakukan pemaketan sepenuhnya.
Dengan menggunakan kemampuan pekerja layanan untuk membuat versi dan meng-cache potongan JavaScript yang mendetail saat runtime, tim Penelusuran menduga bahwa mereka dapat mengurangi jumlah churn cache dan memastikan bahwa JavaScript yang digunakan kembali di masa mendatang dapat disimpan dalam cache secara efisien. Logika di dalam pekerja layanan dapat menganalisis permintaan HTTP keluar untuk paket yang berisi beberapa modul JavaScript, dan memenuhinya dengan merangkai beberapa modul yang di-cache secara lokal, dan secara efektif "unbundling" jika memungkinkan. Ini akan menghemat bandwidth pengguna dan meningkatkan responsivitas secara keseluruhan.
Ada juga manfaat performa dari penggunaan JavaScript yang di-cache yang disalurkan oleh pekerja layanan: di Chrome, representasi kode byte yang diurai dari JavaScript tersebut disimpan dan digunakan kembali, sehingga mengurangi pekerjaan yang harus dilakukan pada runtime untuk mengeksekusi JavaScript di halaman.
Tantangan dan solusi
Berikut adalah beberapa rintangan yang perlu diatasi untuk mencapai tujuan yang ditetapkan tim. Meskipun beberapa tantangan ini khusus untuk Google Penelusuran, banyak di antaranya berlaku untuk berbagai situs yang mungkin sedang mempertimbangkan deployment pekerja layanan.
Masalah: overhead pekerja layanan
Tantangan terbesar, dan satu-satunya pemblokir sejati 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 menangani performa dengan sangat secara serius, dan sebelumnya, Google Penelusuran telah memblokir peluncuran fungsi baru jika fungsi tersebut memberikan kontribusi latensi tambahan yang bahkan puluhan milidetik untuk populasi pengguna tertentu.
Ketika tim mulai mengumpulkan data performa selama eksperimen paling awal, jelas akan ada masalah. HTML yang ditampilkan sebagai respons terhadap permintaan navigasi untuk halaman hasil penelusuran bersifat dinamis, dan sangat bervariasi, bergantung pada logika yang harus dijalankan di server web Penelusuran. Saat ini, tidak ada cara bagi pekerja layanan untuk mereplikasi logika ini dan langsung menampilkan HTML yang di-cache. Cara terbaik yang dapat dilakukan adalah meneruskan permintaan navigasi ke server web backend, yang memerlukan permintaan jaringan.
Tanpa pekerja layanan, permintaan jaringan ini akan langsung terjadi setelah navigasi pengguna. Saat didaftarkan, pekerja layanan harus selalu dimulai dan diberi kesempatan untuk menjalankan pengendali peristiwa fetch-nya, meskipun tidak ada kemungkinan pengendali pengambilan tersebut akan melakukan apa pun selain membuka jaringan. Jumlah waktu yang diperlukan untuk memulai dan menjalankan kode
pekerja layanan adalah overhead murni yang ditambahkan di atas setiap navigasi:
Dengan demikian, implementasi pekerja layanan tidak akan menguntungkan jika terdapat terlalu banyak kerugian latensi untuk membenarkan manfaat lainnya. Selain itu, tim menemukan bahwa, berdasarkan pengukuran waktu booting pekerja layanan di perangkat sebenarnya, ada distribusi waktu startup yang luas, dengan beberapa perangkat seluler kelas bawah memerlukan waktu yang hampir sama untuk memulai pekerja layanan seperti yang mungkin diperlukan untuk membuat permintaan jaringan untuk HTML halaman hasil.
Solusi: gunakan pramuat navigasi
Satu fitur paling penting yang memungkinkan tim Google Penelusuran bergerak mempercepat peluncuran pekerja layanan mereka adalah pramuat navigasi. Menggunakan pramuat navigasi adalah peningkatan performa utama bagi setiap pekerja layanan yang perlu menggunakan respons dari jaringan untuk memenuhi permintaan navigasi. Kode ini memberikan petunjuk kepada browser untuk segera mulai membuat permintaan navigasi, bersamaan dengan saat pekerja layanan dimulai:
Selama jumlah waktu yang diperlukan pekerja layanan untuk memulai kurang dari jumlah waktu yang diperlukan untuk mendapatkan respons kembali dari jaringan, seharusnya tidak ada overhead latensi yang diperkenalkan oleh pekerja layanan.
Tim Penelusuran juga perlu menghindari penggunaan pekerja layanan di perangkat seluler kelas bawah yang membuat waktu booting pekerja layanan dapat melebihi permintaan navigasi. Karena tidak ada aturan keras dan cepat mengenai apa saja yang dapat dianggap sebagai perangkat "low-end", mereka datang dengan heuristik untuk memeriksa total RAM yang terinstal pada perangkat. Jika memori berukuran kurang dari 2 gigabyte dimasukkan ke dalam kategori perangkat low-end, waktu startup pekerja layanan tidak akan dapat diterima.
Ruang penyimpanan yang tersedia adalah pertimbangan lain, karena kumpulan lengkap
resource yang akan di-cache untuk digunakan di masa mendatang dapat mencapai beberapa megabyte. Antarmuka navigator.storage
memungkinkan halaman Google Penelusuran mengetahui di awal apakah upaya untuk
menyimpan data dalam cache berisiko gagal karena kegagalan kuota penyimpanan.
Oleh karena itu, tim Penelusuran memiliki beberapa kriteria yang dapat digunakan untuk menentukan apakah akan menggunakan pekerja layanan atau tidak: jika pengguna membuka halaman Google Penelusuran menggunakan browser yang mendukung pramuat navigasi, dan memiliki RAM minimal 2 gigabyte, serta ruang penyimpanan kosong yang cukup, maka pekerja layanan sudah terdaftar. 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 dari pendaftaran selektif ini adalah kemampuan untuk mengirim pekerja layanan yang lebih kecil dan lebih efisien. Menargetkan browser yang cukup modern untuk menjalankan kode pekerja layanan menghilangkan overhead transpilasi dan polyfill untuk browser lama. Proses ini berhasil memotong sekitar 8 kilobyte kode JavaScript yang tidak dikompresi dari total ukuran implementasi pekerja layanan.
Masalah: cakupan pekerja layanan
Setelah tim Penelusuran menjalankan eksperimen latensi yang cukup dan yakin bahwa penggunaan pramuat navigasi menawarkan jalur yang layak dan netral latensi untuk menggunakan pekerja layanan, beberapa masalah praktis mulai berlanjut. Salah satu masalah tersebut berkaitan dengan aturan pencakupan pekerja layanan. Cakupan pekerja layanan menentukan halaman mana yang berpotensi untuk dikendalikan.
Pencakupan 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 bawah domain.
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 setara regional), dan ada URL dalam domain tersebut yang tidak ada hubungannya dengan Google Penelusuran. Cakupan yang lebih wajar dan ketat adalah /search, yang setidaknya akan menghilangkan URL yang sama sekali tidak terkait dengan hasil penelusuran.
Sayangnya, meskipun jalur URL /search tersebut digunakan bersama oleh berbagai
ragam hasil Google Penelusuran, dengan parameter kueri URL yang menentukan jenis
hasil penelusuran tertentu yang ditampilkan. Beberapa ragam itu menggunakan codebase yang sangat
berbeda dengan halaman hasil penelusuran web tradisional. Misalnya, Penelusuran Gambar
dan Penelusuran Shopping ditayangkan di jalur URL /search dengan parameter kueri
yang berbeda, tetapi belum ada antarmuka yang siap mengirimkan
pengalaman pekerja layanannya sendiri.
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 saat 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 harus dituju. Sistem dibuat agar fleksibel, bukan aturan hardcode, dan memungkinkan tim yang berbagi ruang URL, seperti Penelusuran Gambar dan Penelusuran Shopping, untuk melanjutkan logika pekerja layanan mereka sendiri, 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 berdasarkan cookie browser tertentu, yang merupakan standar lama dan didukung secara luas.
Namun, satu kelemahan menggunakan cookie browser adalah cookie tersebut tidak terekspos di dalam pekerja layanan, dan tidak ada cara untuk memeriksa nilai mereka secara otomatis serta memastikan bahwa nilai tidak berubah karena pengguna logout atau beralih akun. (Ada upaya sedang dilakukan untuk memberikan akses cookie ke pekerja layanan, tetapi saat tulisan ini dibuat, pendekatan tersebut bersifat eksperimental dan tidak didukung secara luas.)
Ketidakcocokan antara tampilan pekerja layanan terhadap pengguna yang sedang login saat ini dan pengguna sebenarnya yang login ke antarmuka web Google Penelusuran dapat menyebabkan hasil penelusuran yang tidak dipersonalisasi dengan benar atau metrik dan logging salah diatribusikan. Salah satu 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 menggunakan
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.
Pekerja layanan kemudian memeriksa nilai cookie saat ini dengan nilai yang diharapkan. Jika terdapat 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 diambil pekerja layanan untuk mereset berbagai hal ke dasar pengukuran khusus untuk persyaratan Google Penelusuran, tetapi pendekatan umum yang sama mungkin 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 bergantung pada menjalankan eksperimen di produksi, serta menguji efek kode dan fitur baru di dunia nyata sebelum mengaktifkannya secara default. Hal ini dapat menjadi sedikit tantangan bagi pekerja layanan statis yang sangat mengandalkan data yang di-cache, karena mengizinkan pengguna untuk ikut serta atau tidak ikut eksperimen sering kali memerlukan komunikasi dengan server backend.
Solusi: skrip pekerja layanan yang dihasilkan 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 dihasilkan sebelumnya. Informasi tentang eksperimen yang mungkin memengaruhi perilaku pekerja layanan atau permintaan jaringan secara umum disertakan langsung dalam skrip pekerja layanan yang disesuaikan ini. Perubahan rangkaian pengalaman aktif bagi pengguna dilakukan melalui kombinasi teknik tradisional, seperti cookie browser, serta menayangkan kode yang telah diperbarui di URL pekerja layanan yang terdaftar.
Menggunakan skrip pekerja layanan yang dihasilkan secara dinamis juga akan mempermudah penyediaan solusi keluar jika implementasi pekerja layanan memiliki bug fatal yang perlu dihindari. Respons pekerja server dinamis dapat berupa penerapan tanpa pengoperasian, yang secara efektif menonaktifkan pekerja layanan untuk sebagian atau semua pengguna saat ini.
Masalah: mengoordinasikan pembaruan
Salah satu tantangan terberat yang dihadapi dalam deployment pekerja layanan di dunia nyata adalah menyusun kompromi yang wajar untuk menghindari jaringan dan memprioritaskan cache, sekaligus memastikan pengguna yang ada mendapatkan update dan perubahan penting segera setelah di-deploy ke produksi. Keseimbangan yang tepat tergantung pada banyak faktor:
- Apakah aplikasi web Anda merupakan aplikasi web satu halaman yang aktif dalam waktu lama dan tetap dibuka pengguna tanpa batas waktu, tanpa membuka halaman baru.
- Frekuensi deployment untuk update server web backend Anda.
- Apakah pengguna rata-rata akan menoleransi penggunaan versi aplikasi web yang sedikit usang, atau apakah keaktualan menjadi prioritas utama.
Selagi bereksperimen dengan pekerja layanan, tim Google Penelusuran memastikan untuk terus menjalankan eksperimen melalui sejumlah update backend terjadwal, guna memastikan bahwa metrik dan pengalaman pengguna akan lebih cocok dengan apa yang akan dilihat pengguna kembali di dunia nyata.
Solusi: menyeimbangkan keaktualan dan penggunaan cache
Setelah menguji sejumlah opsi konfigurasi yang berbeda, tim Google Penelusuran menemukan 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 (1500 detik, atau 25 menit), dan
didaftarkan dengan updateViaCache yang ditetapkan ke 'all'
untuk memastikan header dipatuhi. Backend web Google Penelusuran, seperti yang Anda bayangkan, adalah sekumpulan server yang besar dan terdistribusi secara global yang memerlukan waktu beroperasi mendekati 100%. Men-deploy perubahan yang akan memengaruhi
konten skrip pekerja layanan dilakukan secara bergantian.
Jika pengguna membuka backend yang telah diperbarui, lalu dengan cepat membuka halaman lain yang membuka backend yang belum menerima pekerja layanan yang diperbarui, mereka akan berpindah antarversi beberapa kali. Oleh karena itu, memberi tahu browser agar hanya repot-repot memeriksa skrip yang diperbarui jika 25 menit telah berlalu sejak pemeriksaan terakhir tidak memiliki kelemahan yang signifikan. Keuntungan keikutsertaan dalam perilaku ini sangat mengurangi traffic yang diterima oleh endpoint yang secara dinamis menghasilkan skrip pekerja layanan.
Selain itu, header ETag disetel 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 untuk sementara.
Meskipun beberapa interaksi dalam aplikasi web Google Penelusuran menggunakan navigasi gaya aplikasi satu halaman (yaitu melalui History API), pada umumnya, Google Penelusuran adalah aplikasi web tradisional yang menggunakan navigasi "sebenarnya". Hal ini ikut berperan saat tim memutuskan bahwa akan
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 akan mendapatkan kesempatan untuk menangani permintaan navigasi baru tersebut segera setelah penginstalan. Demikian pula, memanggil clients.claim() berarti pekerja layanan yang diperbarui akan memiliki kesempatan untuk mulai mengontrol halaman Google Penelusuran terbuka yang tidak terkontrol, setelah aktivasi pekerja layanan.
Pendekatan yang digunakan Google Penelusuran belum tentu merupakan solusi yang
cocok untuk semua orang—hal tersebut merupakan hasil dari pengujian A/B secara cermat terhadap berbagai
kombinasi opsi penayangan sampai mereka menemukan opsi yang paling cocok untuk mereka.
Developer yang infrastruktur backend-nya memungkinkan mereka men-deploy update dengan lebih
cepat mungkin lebih memilih agar browser memeriksa skrip pekerja layanan yang diupdate
sesering mungkin, dengan
selalu mengabaikan cache HTTP.
Jika Anda mem-build aplikasi web satu halaman yang mungkin akan tetap dibuka pengguna dalam jangka waktu yang lama, penggunaan skipWaiting() mungkin bukan pilihan yang tepat untuk Anda—Anda berisiko mengalami inkonsistensi cache jika Anda mengizinkan pekerja layanan baru untuk diaktifkan saat ada klien yang berumur panjang.
Poin-Poin Penting
Secara default, pekerja layanan tidak netral dalam performa
Menambahkan pekerja layanan ke aplikasi web Anda berarti memasukkan bagian JavaScript tambahan yang perlu dimuat dan dieksekusi sebelum aplikasi web Anda mendapatkan respons terhadap permintaannya. Jika respons tersebut akhirnya berasal dari cache lokal, bukan dari jaringan, maka overhead menjalankan pekerja layanan biasanya dapat diabaikan dibandingkan dengan keuntungan performa jika tidak beralih ke cache terlebih dahulu. Namun, jika Anda mengetahui bahwa pekerja layanan harus selalu berkonsultasi dengan jaringan saat menangani permintaan navigasi, menggunakan pramuat navigasi adalah keberhasilan performa yang penting.
Service worker (masih) merupakan progressive enhancement
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 butuhkan, dan hanya mendaftarkan pekerja layanan saat fitur tersebut ada, masih merupakan pendekatan yang wajar untuk dilakukan.
Demikian pula, jika Anda telah menjalankan eksperimen di luar sana, dan mengetahui bahwa perangkat kelas bawah ternyata berperforma buruk dengan overhead tambahan pekerja layanan, Anda juga dapat tidak mendaftarkan pekerja layanan dalam skenario tersebut.
Anda harus tetap memperlakukan pekerja layanan sebagai progressive enhancement yang ditambahkan ke aplikasi web jika semua prasyarat terpenuhi dan pekerja layanan menambahkan sesuatu yang positif pada pengalaman pengguna dan performa pemuatan secara keseluruhan.
Ukur semuanya
Satu-satunya cara untuk mengetahui apakah pengiriman pekerja layanan berdampak positif atau negatif terhadap pengalaman pengguna adalah dengan bereksperimen dan mengukur hasilnya.
Detail penyiapan pengukuran yang penting 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 pekerja layanan asosiasi di komunitas pengembangan web yang menggunakan Progressive Web App, membuat "PWA Google Penelusuran" bukanlah tujuan awal dari tim. Aplikasi web Google Penelusuran saat ini tidak menyediakan metadata melalui manifes aplikasi web, serta tidak 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.
Alih-alih mencoba mengubah pengalaman web Google Penelusuran menjadi pengalaman yang setara dengan yang Anda harapkan dari aplikasi terinstal, fokus pada peluncuran awal adalah untuk secara bertahap meningkatkan kualitas situs yang ada.
Ucapan terima kasih
Terima kasih kepada seluruh tim pengembangan web Google Penelusuran atas pekerjaan mereka dalam implementasi pekerja layanan, dan karena telah berbagi materi latar belakang untuk menulis artikel ini. Terima kasih khususnya kepada Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono, dan Clay Woolam.
Pembaruan (Okt 2021): Karena artikel ini awalnya dipublikasikan, tim Google Penelusuran telah mengevaluasi kembali manfaat dan kekurangan arsitektur pekerja layanan mereka saat ini. Pekerja layanan yang dijelaskan di atas sedang dihentikan. Seiring dengan berkembangnya infrastruktur web Google Penelusuran, tim mungkin akan meninjau kembali desain pekerja layanan mereka.