Men-deploy pekerja layanan dapat mengubah perilaku situs dengan cara yang tidak terduga. Karena Workbox memudahkan untuk menulis dan men-deploy pekerja layanan, maka akan lebih mudah untuk kehilangan beberapa efek yang dimiliki pekerja layanan pada situs setelah di-deploy.
Penggunaan Workbox tidak akan memberikan hasil yang buruk, tetapi hanya karena kemudahan yang ditawarkan, pengguna akan lebih mudah mengalami beberapa jebakan jika tidak mengetahui apa yang terjadi dalam deployment pekerja layanan.
Kesalahan pra-cache
Precaching telah dibahas sebelumnya dalam dokumen ini tanpa sepenuhnya membahas bagaimana praktik tersebut dapat menimbulkan dampak negatif. Anda mungkin mengalami masalah jika menerapkan precaching ke terlalu banyak aset, atau jika pekerja layanan didaftarkan sebelum halaman memiliki kesempatan untuk menyelesaikan pemuatan aset penting.
Karena perilaku default workbox-webpack-plugin adalah menginstruksikan pekerja layanan untuk melakukan precache aset yang dihasilkan secara otomatis, hal ini dapat menjadi masalah yang mudah terlewatkan, karena batasan terhadap adopsi ini rendah.
workbox-webpack-plugin.
Dalam contoh ini, 14 aset di-cache dalam project saat ini secara default sebesar 352 kilobyte.Saat pekerja layanan melakukan pra-cache aset selama penginstalan, satu atau beberapa permintaan jaringan akan dimulai secara bersamaan. Hal ini dapat menimbulkan masalah bagi pengalaman pengguna jika waktunya tidak tepat. Meskipun waktunya tepat, hal ini masih dapat menyia-nyiakan data jika jumlah aset yang di-cache tidak dibatasi.
Semua bergantung pada waktunya
Jika pekerja layanan melakukan precache apa pun, maka waktu pendaftarannya adalah hal penting.
Pekerja layanan sering didaftarkan menggunakan elemen <script> inline.
Ini berarti parser HTML dapat menemukan kode pendaftaran pekerja layanan sebelum aset penting halaman dimuat.
Ini adalah sebuah masalah. Dalam kasus terburuk, pekerja layanan harus netral performa, bukan memperburuk performa. Bantu pengguna dan daftarkan pekerja layanan saat peristiwa load halaman diaktifkan.
Hal ini mengurangi kemungkinan bahwa precaching akan mengganggu pemuatan aset penting halaman,
sehingga halaman dapat menjadi lebih cepat interaktif tanpa harus menghadapi permintaan jaringan untuk aset yang mungkin tidak diperlukan hingga nanti.
Pertimbangkan penggunaan data
Terlepas dari waktu, pra-cache melibatkan pengiriman permintaan jaringan. Jika manifes aset yang akan di-precache tidak diseleksi dengan cermat, hasilnya mungkin akan sia-sia.
Data yang terbuang adalah konsekuensi yang mungkin didapat dari pra-cache, tetapi tidak semua orang memiliki akses ke internet cepat atau bahkan paket data tanpa batas. Saat precaching, pertimbangkan untuk memotong aset yang sangat besar dan andalkan cache runtime untuk menangkapnya, bukan membuat asumsi yang mahal.
Startup pekerja layanan dapat menunda permintaan jaringan
Service worker berjalan dalam proses yang terpisah dari kode situs lainnya. Proses ini sering dimulai dan dihentikan. Ketika pekerja layanan perlu menangani peristiwa pengambilan setelah tidak aktif, browser harus terlebih dahulu meluangkan waktu untuk memulai pekerja layanan. Overhead tambahan sebelum permintaan dapat ditangani ini kecil dibandingkan dengan manfaat menayangkan respons dari cache, bukan dari jaringan.
Saat menggunakan strategi yang tidak dapat disalurkan dari cache, dan harus menuju ke jaringan—khususnya saat menangani permintaan navigasi—waktu booting selalu menambahkan penundaan. Bergantung pada kemampuan perangkat dan/atau tekanan CPU, permintaan navigasi dapat mengalami penundaan yang cukup terasa karena booting pekerja layanan yang lambat. Men-deploy pekerja layanan tanpa menyadari penundaan ini berarti pengguna dapat mengalami performa yang tidak disengaja.
Masalah ini telah diatasi dengan Pramuat Navigasi, tetapi belum didukung di semua browser. Namun, penggunaannya patut dipertimbangkan, dan akan dibahas nanti dalam dokumentasi ini.
Strategi yang mengutamakan cache dapat menjadi bumerang
Strategi caching yang memeriksa cache terlebih dahulu—atau hanya memeriksa cache—sangat cocok untuk akses dan performa offline. Namun, mereka cenderung menyebabkan masalah dalam beberapa kasus tertentu.
Penyimpanan dalam cache aset statis tanpa versi
Bundler biasanya membuat versi aset statis dengan hash berbasis konten dalam nama file (misalnya, styles.a4edf38c.css).
Pada pekerja layanan yang menggunakan strategi caching yang memeriksa cache terlebih dahulu untuk aset statis,
dan menggunakan strategi yang mengutamakan jaringan untuk markup halaman,
seharusnya tidak ada masalah caching karena aset yang diperbarui direferensikan dalam markup yang selalu diambil dari jaringan.
Masalah akan muncul dalam situasi ketika aset statis tanpa versi di-cache selama runtime dengan menggunakan strategi ini.
Jika fungsi situs disediakan oleh app.js dan strategi runtime cache-first digunakan,
app.js akan diupdate nanti tanpa perubahan pada nama filenya,
versi awal yang di-cache akan terus disajikan dari cache, bukan diperbarui.
Solusinya adalah menggunakan strategi yang berkonsultasi dengan jaringan untuk update, seperti network-first atau usang saat divalidasi ulang. Atau, alat build dapat membuat manifes precache untuk aset tersebut, karena logika precache Workbox akan terus memperbaruinya.
Terlepas dari itu, sebaiknya pertimbangkan untuk membuat versi aset statis, baik dengan hash pada nama aset, atau di string kueri. Hal ini akan menghindari masalah dengan aset usang di pekerja layanan yang menggunakan strategi runtime cache-first untuk aset statis.
Kuota penyimpanan pikiran
Meluncurkan update pekerja layanan dari waktu ke waktu adalah hal yang umum, dan saat update diluncurkan, cache lama dengan nama yang sudah tidak berlaku biasanya dipangkas selama aktivasi pekerja layanan baru.
Namun, beberapa iterasi pekerja layanan berumur panjang, atau nama cache mungkin tidak diperbarui dalam update baru. Jika ini terjadi, aset statis lama dapat menumpuk di cache saat update terhadap aset tersebut diluncurkan. Browser menetapkan kuota dan batas penyimpanan dapat berbeda-beda. Itu alasan yang baik untuk memperhatikan mereka!
Workbox berhasil menangani masalah ini, tetapi kuota penyimpanan masih dapat terlampaui. Anda dapat memperoleh kontrol cache yang lebih baik dengan modul masa berlaku kotak kerja.
Jangan takut
Men-deploy pekerja layanan bukanlah hal yang kecil. Namun, seharusnya ini tidak menakutkan jika Anda hanya memerlukan sedikit perencanaan dan perhatian terhadap apa yang diperlukan untuk menempatkan pekerja layanan dengan Workbox. Saat Anda melanjutkan, dokumentasi ini akan membantu Anda mengatasi masalah ini dengan hati-hati dan percaya diri.