Precaching dengan Workbox

Salah satu fitur service worker adalah kemampuan untuk menyimpan file ke cache saat service worker diinstal. Hal ini disebut "pra-cache". 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.

Penggunaan Workbox untuk pra-caching bersifat opsional. Anda dapat menulis kode sendiri untuk membuat cache aset penting saat pekerja layanan 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

Pra-caching 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.

Pembaruan pada resource yang di-precache

Saat merilis versi baru aplikasi web dari waktu ke waktu, Anda harus terus memperbarui URL yang di-cache sebelumnya, melakukan pra-cache aset baru, dan menghapus entri yang sudah tidak berlaku. Selama Anda terus membuat manifes pra-cache lengkap setiap kali membangun ulang situs, manifes tersebut berfungsi sebagai "sumber tepercaya" 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 setiap tampilan aplikasi web Anda terlebih dahulu, tanpa harus menunggu hingga mereka mengunjungi setiap tampilan.

Saat pengguna menginstal aplikasi, mereka berharap setiap bagian ditampilkan dengan cepat, bukan hanya tampilan yang pernah mereka buka sebelumnya. Pra-caching menghadirkan pengalaman yang sama ke aplikasi web.

Manakah dari aset Anda yang harus dipra-cache?

Lihat kembali panduan Mengidentifikasi apa yang dimuat untuk mendapatkan gambaran yang baik tentang URL mana yang paling sesuai untuk dipra-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 caching runtime untuk memastikan aset ini di-cache saat digunakan.

Selalu ingat bahwa pra-caching melibatkan penggunaan bandwidth dan penyimpanan jaringan di perangkat pengguna (sama 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.