Precaching dengan Workbox

Salah satu fitur dari pekerja layanan adalah kemampuan untuk menyimpan file ke cache ketika yang diinstal oleh pekerja layanan. Hal ini disebut sebagai "precaching". Precaching memungkinkan untuk menyajikan file {i>cache<i} ke browser tanpa ke jaringan. Gunakan precaching untuk aset penting yang bahkan diperlukan situs Anda saat offline: halaman utama, gaya, gambar penggantian, dan skrip penting.

Mengapa Anda harus menggunakan Workbox?

Menggunakan Workbox untuk precaching bersifat opsional. Anda dapat menulis {i>code<i} Anda sendiri ke melakukan pra-cache aset penting saat pekerja layanan sedang diinstal. Manfaat utama penggunaan Workbox adalah kontrol versi yang siap pakai. Anda akan mendapatkan lebih sedikit masalah saat memperbarui aset yang telah di-pra-cache menggunakan Workbox daripada jika Anda harus mengelola pembuatan versi dan pembaruan file-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 keadaan semua yang dimaksudkan dalam {i>precache<i} untuk versi aplikasi web tertentu. Manifes pra-cache, 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 Penyimpanan Cache, untuk masing-masing dari tiga URL yang tercantum. Aset pertama memiliki pembuatan versi informasi yang sudah disertakan di URL-nya (app adalah nama file yang sebenarnya, dan .abcd1234 berisi informasi pembuatan versi, tepat sebelum ekstensi file .js). Alat build kotak kerja dapat mendeteksi hal ini dan mengecualikan kolom revisi. Tujuan dua aset lainnya tidak menyertakan info pembuatan versi di URL-nya, jadi alat build membuat kolom revision terpisah, yang berisi hash lokal isi file.

Menyajikan resource yang dipra-cache

Menambahkan aset ke cache hanyalah salah satu bagian dari kisah pra-cache—setelah aset di-cache, maka aset harus merespons permintaan keluar. Yang memerlukan Pemroses peristiwa fetch di pekerja layanan yang dapat memeriksa URL mana yang memiliki telah dilakukan pra-cache, dan mengembalikan respons yang di-cache tersebut dengan andal, jaringan Anda 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 cache yang diharapkan state; jika kombinasi URL/revisi dalam manifes berubah, pekerja layanan mengetahui bahwa entri yang di-cache sebelumnya tidak lagi valid, dan harus diperbarui. Hanya dibutuhkan satu permintaan jaringan, yang dibuat secara otomatis oleh browser sebagai bagian dari pekerja layanan pemeriksaan update, untuk menentukan URL mana yang di-pra-cache yang perlu diperbarui.

Update pada resource yang telah dipra-cache

Ketika merilis versi baru aplikasi web Anda dari waktu ke waktu, Anda harus URL yang sebelumnya di-pracache dengan versi terbaru, melakukan pra-cache aset baru, dan menghapus yang usang entri. Selama Anda terus membuat manifes pra-cache lengkap setiap kali diperlukan Anda membuat ulang situs Anda, manifes tersebut berfungsi sebagai "sumber kebenaran" untuk status pra-cache kapan saja.

Jika ada URL dengan bidang revisi baru, atau jika ada URL yang ditambahkan atau dihapus dari manifes, itu adalah tanda bagi pekerja layanan Anda bahwa pembaruan perlu dilakukan, sebagai bagian dari install dan activate pengendali peristiwa. Misalnya, jika Anda telah membuat beberapa perubahan pada situs Anda dan dibuat ulang, manifes pra-cache terbaru Anda mungkin telah melalui hal-hal berikut perubahan:

[{
  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 harus 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 digunakan lagi ('app.abcd1234.js').

"app store" sebenarnya pengalaman penginstalan

Manfaat lain dari {i>precaching<i} adalah Anda dapat memberikan pengguna pengalaman yang jika tidak, akan sulit dicapai di luar "app store" penginstalan. Setelah pengguna mengunjungi laman apa pun di aplikasi web Anda untuk pertama kalinya, Anda dapat melakukan pra-cache semua URL yang diperlukan untuk menampilkan salah satu URL sebelumnya, tanpa harus menunggu tampilan aplikasi web tampilan individual.

Saat pengguna menginstal aplikasi, mereka berharap setiap bagiannya ditampilkan dengan cepat, bukan hanya pemandangan yang mereka lihat di masa lalu. Precaching memberikan pengalaman yang lebih baik dengan aplikasi web.

Manakah aset Anda yang harus di-pra-cache?

Lihat kembali bagian Mengidentifikasi apa yang dimuat untuk mendapatkan gambar URL mana yang paling masuk akal untuk di-pra-cache. Aturan umumnya adalah pra-cache HTML, JavaScript, atau CSS apa pun yang dimuat sejak awal dan sangat penting untuk menampilkan struktur dasar halaman tertentu.

Lebih baik untuk menghindari pra-cache media atau aset lain yang dimuat nanti (kecuali hal penting untuk fungsi aplikasi web Anda). Sebagai gantinya, gunakan runtime strategi penyimpanan dalam cache untuk memastikan aset disimpan dalam cache.

Selalu ingat bahwa precaching melibatkan penggunaan bandwidth jaringan dan penyimpanan di perangkat pengguna (seperti menginstal aplikasi dari app store). Terserah Anda sebagai developer untuk melakukan pra-cache secara bijak, dan menghindari kelebihan beban melakukan precache manifes.

Alat build Workbox membantu dengan memberi tahu Anda jumlah item dalam precache serta ukuran total {i>payload<i} pra-{i>cache<i}.

Pengunjung berulang ke manfaat aplikasi web Anda dalam jangka panjang dari biaya di muka {i>precaching<i}, karena kemampuan yang ditawarkan untuk menghindari jaringan membayar dengan cepat itu sendiri dalam {i>bandwidth <i}yang dihemat dari waktu ke waktu.