Cache runtime mengacu pada penambahan respons ke cache secara bertahap "seiring Anda berjalan". Meskipun cache runtime tidak membantu keandalan permintaan saat ini, proses ini dapat membantu membuat permintaan mendatang untuk URL yang sama lebih andal.
Cache HTTP browser adalah contoh cache runtime; cache ini hanya diisi setelah permintaan untuk URL tertentu. Namun, pekerja layanan memungkinkan Anda mengimplementasikan cache runtime yang melebihi kemampuan cache HTTP saja.
Menjadi strategi
Tidak seperti precaching (yang selalu mencoba menyalurkan kumpulan file yang telah ditetapkan dari cache), caching runtime dapat menggabungkan akses jaringan dan cache dalam beberapa cara. Setiap kombinasi umumnya disebut sebagai strategi caching. Strategi penting penyimpanan cache meliputi:
- Mengutamakan jaringan
- Cache-first
- Tidak berlaku saat divalidasi ulang
Mengutamakan jaringan
Dalam pendekatan ini, pekerja layanan Anda terlebih dahulu mencoba mengambil respons dari jaringan. Jika permintaan jaringan berhasil, bagus! Respons ditampilkan ke aplikasi web Anda, dan salinan respons disimpan menggunakan Cache Storage API—baik membuat entri baru maupun memperbarui entri sebelumnya untuk URL yang sama.
Jika permintaan jaringan gagal sepenuhnya, atau memakan waktu terlalu lama untuk menampilkan respons, respons terbaru dari cache akan ditampilkan.
Cache-first
Strategi {i>cache-first<i} adalah kebalikan dari {i>network-first<i}. Dalam pendekatan ini, saat pekerja layanan mencegat permintaan, pekerja layanan akan menggunakan Cache Storage API terlebih dahulu untuk melihat apakah ada respons yang di-cache yang tersedia atau tidak. Jika ada, respons tersebut akan ditampilkan ke aplikasi web.
Namun, jika ada cache yang tidak ditemukan, pekerja layanan akan masuk ke jaringan dan mencoba mengambil respons di sana. Dengan asumsi bahwa permintaan jaringan berhasil, permintaan akan dikembalikan ke aplikasi web Anda dan salinannya disimpan di cache. Salinan yang di-cache ini akan digunakan untuk mengabaikan jaringan saat ada lagi permintaan untuk URL yang sama.
Tidak berlaku saat divalidasi ulang
basi-saat-validasi ulang adalah suatu campuran. Saat menggunakannya, pekerja layanan akan segera memeriksa respons yang di-cache dan, jika ditemukan, meneruskannya kembali ke aplikasi web Anda.
Sementara itu, terlepas dari apakah ada kecocokan cache atau tidak, pekerja layanan Anda juga mengaktifkan permintaan jaringan untuk mendapatkan kembali respons "baru". Respons ini digunakan untuk memperbarui respons yang sebelumnya di-cache. Jika pemeriksaan cache awal gagal, salinan respons jaringan juga diteruskan kembali ke aplikasi web Anda.
Mengapa Anda harus menggunakan Workbox?
Strategi caching ini sama dengan resep yang biasanya harus Anda tulis ulang di pekerja layanan Anda sendiri, berulang kali. Daripada menggunakannya, Workbox menawarkannya untuk dipaketkan sebagai bagian dari library strategi-nya, yang siap Anda gunakan untuk beralih ke pekerja layanan.
Workbox juga menyediakan dukungan pembuatan versi, sehingga Anda dapat mengakhiri entri yang disimpan dalam cache secara otomatis, atau memberi tahu aplikasi web Anda saat update terjadi pada entri yang di-cache sebelumnya.
Manakah dari aset Anda yang harus di-cache, dengan strategi yang mana?
Cache runtime dapat dilihat sebagai pelengkap untuk precache. Jika semua aset sudah di-precache, berarti Anda sudah selesai—tidak ada yang perlu di-cache saat runtime. Namun, untuk aplikasi web yang relatif kompleks, kemungkinan besar Anda tidak akan menyimpan semuanya terlebih dahulu.
File media yang lebih besar, aset yang disalurkan dari host pihak ketiga seperti CDN, atau respons API, hanyalah beberapa contoh jenis aset yang tidak dapat di-precache secara efektif. Gunakan panel Network di DevTools untuk mengidentifikasi permintaan yang termasuk dalam kategori ini, dan untuk setiap permintaan, pikirkan tentang keseimbangan keaktualan vs. keandalan yang sesuai.
Gunakan status usang saat validasi ulang untuk memprioritaskan keandalan daripada keaktualan
Karena strategi yang sudah tidak berlaku saat validasi ulang menampilkan respons yang di-cache hampir secara langsung—setelah cache diisi melalui permintaan pertama—Anda akan melihat performa yang sangat cepat saat menggunakan strategi ini. Hal ini memiliki konsekuensi untuk mendapatkan data respons kembali yang mungkin sudah tidak berlaku dibandingkan dengan data yang seharusnya diambil dari jaringan. Penggunaan strategi ini paling cocok untuk aset seperti foto profil pengguna atau respons API awal yang digunakan untuk mengisi tampilan, jika Anda tahu bahwa menampilkan sesuatu segera adalah kuncinya, meskipun itu adalah nilai yang lebih lama.
Gunakan yang mengutamakan jaringan untuk memprioritaskan keaktualan daripada keandalan
Dalam beberapa hal, menggunakan strategi yang mengutamakan jaringan berarti mengakui kekalahan dalam pertempuran Anda terhadap jaringan—tindakan ini diprioritaskan, tetapi hal itu membawa ketidakpastian tentang keandalan. Untuk jenis aset tertentu, melihat respons baru lebih baik untuk mendapatkan kembali informasi yang sudah tidak berlaku. Anda mungkin lebih memilih keaktualan saat membuat permintaan API untuk teks artikel yang sering diperbarui, misalnya.
Dengan menggunakan strategi yang mengutamakan jaringan di dalam pekerja layanan, alih-alih hanya melawan jaringan secara langsung, Anda memiliki keuntungan karena dapat kembali ke sesuatu, meskipun itu adalah respons yang mungkin sudah tidak berlaku. Anda tidak akan dapat diandalkan, tetapi setidaknya Anda dapat diandalkan saat offline.
Gunakan cache-first untuk URL berversi
Dalam strategi yang mengutamakan cache, setelah di-cache, entri tidak akan diperbarui. Oleh karena itu, pastikan Anda hanya menggunakannya dengan aset yang Anda tahu tidak akan berubah. Secara khusus, cara ini paling cocok untuk URL yang berisi informasi
pembuatan versi—jenis URL yang sama yang juga harus ditayangkan dengan
header respons Cache-Control: max-age=31536000.