Salah satu fitur service worker adalah kemampuan untuk menyimpan file ke cache saat service worker diinstal. Hal ini disebut sebagai "precaching". Pra-cache memungkinkan file yang di-cache ditayangkan ke browser tanpa mengakses jaringan. Gunakan pra-caching untuk aset penting yang diperlukan situs Anda bahkan saat offline: halaman utama, gaya, gambar penggantian, dan skrip penting.
Mengapa Anda harus menggunakan Workbox?
Menggunakan Workbox untuk precaching bersifat opsional. Anda dapat menulis kode Anda sendiri untuk melakukan pra-cache aset penting saat pekerja layanan sedang diinstal. Manfaat utama menggunakan Workbox adalah kontrol versi siap pakai. Anda akan mengalami lebih sedikit masalah saat memperbarui aset yang di-cache sebelumnya menggunakan Workbox daripada jika Anda harus mengelola pembuatan versi dan pembaruan file ini sendiri.
Menyimpan manifes dalam cache
Precaching didorong oleh daftar URL dan informasi pembuatan versi terkait untuk setiap URL. Secara keseluruhan, informasi ini dikenal sebagai manifes pra-cache. Manifes adalah "sumber tepercaya" untuk status semua hal yang dimaksudkan untuk berada di precache untuk versi aplikasi web tertentu. Manifes precache, dalam format yang digunakan oleh Workbox, terlihat seperti ini:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Saat pekerja layanan diinstal, tiga entri cache dibuat di
Penyimpanan Cache, untuk setiap dari tiga URL yang tercantum. Aset pertama memiliki informasi
versi yang sudah disertakan dalam URL-nya (app adalah nama file sebenarnya, dan
.abcd1234 berisi informasi versi, tepat sebelum ekstensi file
.js). Alat build Workbox dapat mendeteksi hal ini dan mengecualikan kolom revisi. Dua
aset lainnya tidak menyertakan info pembuatan versi apa pun di URL-nya, sehingga alat build
Workbox membuat kolom revision terpisah, yang berisi hash konten
file lokal.
Menayangkan resource yang di-cache sebelumnya
Menambahkan aset ke cache hanyalah salah satu bagian dari cerita pra-cache—setelah
aset di-cache, aset tersebut harus merespons permintaan keluar. Hal ini memerlukan pemroses peristiwa fetch di pekerja layanan Anda yang dapat memeriksa URL mana yang telah dipra-cache, dan menampilkan respons yang di-cache tersebut dengan andal, dengan mengabaikan jaringan dalam prosesnya. Karena pekerja layanan memeriksa cache untuk respons
(dan menggunakannya sebelum jaringan), hal ini disebut
strategi cache-first.
Update yang efisien
Manifes pra-cache memberikan representasi yang tepat dari status cache yang diharapkan; jika kombinasi URL/revisi dalam manifes berubah, pekerja layanan mengetahui bahwa entri yang di-cache sebelumnya tidak lagi valid, dan perlu diperbarui. Hanya diperlukan satu permintaan jaringan, yang dibuat secara otomatis oleh browser sebagai bagian dari pemeriksaan update pekerja layanan, untuk menentukan URL yang di-cache sebelumnya yang perlu dimuat ulang.
Update pada resource yang telah dipra-cache
Saat merilis versi baru aplikasi web dari waktu ke waktu, Anda harus terus memperbarui URL yang sebelumnya di-pra-cache, melakukan pra-cache aset baru, dan menghapus entri yang usang. Selama Anda terus menghasilkan manifes pra-cache lengkap setiap kali Anda mem-build ulang situs, manifes tersebut akan berfungsi sebagai "sumber kebenaran" untuk status pra-cache Anda kapan saja.
Jika ada URL yang ada dengan kolom revisi baru, atau jika ada URL yang telah
ditambahkan atau dihapus dari manifes, itu adalah tanda bagi pekerja layanan Anda bahwa
update perlu dilakukan, sebagai bagian dari
pengendali peristiwa
install
dan
activate. Misalnya, jika Anda telah melakukan beberapa perubahan pada situs dan
mem-build ulang, manifes pra-cache terbaru mungkin telah mengalami perubahan
berikut:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Setiap perubahan ini memberi tahu pekerja layanan bahwa permintaan baru perlu
dibuat untuk memperbarui entri yang di-cache sebelumnya ('offline.svg' dan 'index.html')
dan meng-cache URL baru ('app.ffaa4455.js'), serta penghapusan untuk membersihkan URL
yang tidak lagi digunakan ('app.abcd1234.js').
Pengalaman penginstalan "app store" yang sebenarnya
Manfaat lain dari pra-cache adalah Anda dapat memberikan pengalaman kepada pengguna yang akan sulit dicapai di luar penginstalan "app store". Setelah pengguna mengunjungi halaman apa pun di aplikasi web Anda untuk pertama kalinya, Anda berpotensi melakukan pra-cache semua URL yang diperlukan untuk menampilkan semua tampilan aplikasi web Anda terlebih dahulu, tanpa harus menunggu hingga mereka mengunjungi setiap tampilan.
Saat menginstal aplikasi, pengguna berharap setiap bagiannya ditampilkan dengan cepat, bukan hanya tampilan yang sudah mereka lihat di masa lalu. Pra-caching menghadirkan pengalaman yang sama ke aplikasi web.
Manakah aset Anda yang harus di-pra-cache?
Lihat kembali panduan Mengidentifikasi apa yang dimuat untuk mendapatkan gambaran yang bagus tentang URL mana yang paling tepat untuk melakukan pra-cache. Aturan umumnya adalah melakukan pra-cache HTML, JavaScript, atau CSS yang dimuat lebih awal dan sangat penting untuk menampilkan struktur dasar halaman tertentu.
Sebaiknya hindari pra-cache media atau aset lain yang dimuat nanti (kecuali jika penting untuk fungsi aplikasi web Anda). Sebagai gantinya, gunakan strategi cache runtime untuk memastikan aset ini disimpan di cache sesuai penggunaan.
Selalu ingat bahwa precaching melibatkan penggunaan bandwidth dan penyimpanan jaringan di perangkat pengguna (seperti menginstal aplikasi dari app store). Anda sebagai developer dapat melakukan pra-cache dengan cermat, dan menghindari manifes pra-cache yang terlalu besar.
Alat build Workbox membantu dengan memberi tahu Anda jumlah item dalam manifes precache serta total ukuran payload precache.
Pengunjung berulang ke aplikasi web Anda akan mendapatkan manfaat dalam jangka panjang dari biaya awal pra-caching, karena kemampuan yang ditawarkan untuk menghindari jaringan dengan cepat akan membayar sendiri dalam bandwidth yang disimpan dari waktu ke waktu.