Precaching dengan Workbox

Salah satu fitur pekerja layanan adalah kemampuan untuk menyimpan file ke cache saat pekerja layanan sedang diinstal. Hal ini disebut sebagai "precaching". Precaching memungkinkan penayangan file yang di-cache ke browser tanpa perlu terhubung ke jaringan. Gunakan precache 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 penggunaan Workbox adalah kontrol versi yang siap pakai. Anda akan kesulitan untuk memperbarui aset yang telah di-pra-cache menggunakan Workbox daripada jika Anda harus mengelola pembuatan versi dan pembaruan file ini sendiri.

Melakukan pramuat manifes

Precaching didorong oleh daftar URL dan informasi pembuatan versi terkait untuk setiap URL. Secara keseluruhan, informasi ini dikenal sebagai manifes precache. Manifes adalah "sumber kebenaran" untuk status segala sesuatu yang dimaksudkan dalam precache untuk versi aplikasi web tertentu. Manifes precache, dalam format yang digunakan oleh Workbox, terlihat seperti:

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Saat pekerja layanan diinstal, tiga entri cache akan dibuat di Cache Storage, untuk masing-masing dari tiga URL yang tercantum. Aset pertama memiliki informasi pembuatan versi yang sudah disertakan di URL-nya (app adalah nama file sebenarnya, dan .abcd1234 berisi informasi pembuatan 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.

Menyajikan resource yang dipra-cache

Menambahkan aset ke cache hanyalah salah satu bagian dari cerita precaching. Setelah aset di-cache, aset harus merespons permintaan keluar. Cara ini memerlukan pemroses peristiwa fetch di pekerja layanan Anda yang dapat memeriksa URL mana yang telah di-pra-cache, dan menampilkan respons yang di-cache tersebut dengan andal, yang mengabaikan jaringan dalam prosesnya. Karena pekerja layanan memeriksa cache untuk menemukan respons (dan menggunakannya sebelum jaringan), hal ini disebut strategi cache-first.

Update yang efisien

Manifes precache 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 sudah tidak valid, dan perlu diperbarui. Hanya perlu satu permintaan jaringan, yang dibuat secara otomatis oleh browser sebagai bagian dari pemeriksaan update pekerja layanan, untuk menentukan URL mana yang di-cache yang perlu di-refresh.

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 precache 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 sudah ada dengan kolom revisi baru, atau jika ada URL yang telah ditambahkan atau dihapus dari manifes, hal tersebut adalah tanda bagi pekerja layanan Anda bahwa update perlu dilakukan, sebagai bagian dari pengendali peristiwa install dan activate. Misalnya, jika Anda telah membuat beberapa perubahan pada situs dan membuat ulang, manifes pra-cache terbaru Anda 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 Anda bahwa permintaan baru perlu dibuat untuk memperbarui entri yang sebelumnya di-cache ('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 memberi pengguna pengalaman yang akan sulit dicapai di luar penginstalan "app store". Setelah pengguna mengunjungi halaman apa pun di aplikasi web untuk pertama kalinya, Anda dapat melakukan pra-cache untuk semua URL yang diperlukan untuk menampilkan salah satu tampilan aplikasi web Anda sebelumnya, 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. Precaching menghadirkan pengalaman yang sama pada 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 melakukan 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). Sebagai developer, Anda dapat melakukan pra-cache dengan bijak, dan menghindari manifes pra-cache yang membengkak.

Alat build Workbox membantu dengan memberi tahu Anda jumlah item dalam manifes precache serta ukuran total payload precache.

Pengunjung berulang ke aplikasi web Anda mendapatkan manfaat dalam jangka panjang dari biaya di muka untuk penyiapan cache, karena kemampuan yang ditawarkan untuk menghindari jaringan dengan cepat membayar diri sendiri dalam bandwidth yang dihemat dari waktu ke waktu.