Kelebihan dan kekurangan menggunakan logika masa berlaku yang konsisten atau berbeda di seluruh cache pekerja layanan dan lapisan cache HTTP.
Meskipun pekerja layanan dan PWA menjadi standar aplikasi web modern, cache resource menjadi makin kompleks. Artikel ini berisi gambaran lengkap tentang penyimpanan cache browser, termasuk:
- Kasus penggunaan dan perbedaan antara penyimpanan dalam cache pekerja layanan dan penyimpanan HTTP.
- Kelebihan dan kekurangan dari strategi masa berlaku cache pekerja layanan yang berbeda dibandingkan dengan strategi caching HTTP biasa.
Ringkasan alur penyimpanan dalam cache
Pada tingkat tinggi, browser mengikuti urutan penyimpanan dalam cache di bawah ini saat meminta resource:
- Cache pekerja layanan: Pekerja layanan memeriksa apakah resource berada dalam cache-nya dan memutuskan apakah akan menampilkan resource itu sendiri berdasarkan strategi caching yang diprogram. Perlu diketahui bahwa hal ini tidak terjadi secara otomatis. Anda harus membuat pengendali peristiwa pengambilan di pekerja layanan dan menangkap permintaan jaringan agar permintaan disajikan dari cache pekerja layanan, bukan dari jaringan.
- Cache HTTP (juga dikenal sebagai cache browser): Jika resource ditemukan di Cache HTTP dan belum habis masa berlakunya, browser akan otomatis menggunakan resource dari cache HTTP.
- Sisi server: Jika tidak ada yang ditemukan di cache pekerja layanan atau cache HTTP, browser akan membuka jaringan untuk meminta resource. Jika resource tidak di-cache di CDN, permintaan harus dikembalikan ke server asal.
Menyimpan lapisan ke cache
Pembuatan cache pekerja layanan
Pekerja layanan mencegat permintaan HTTP jenis jaringan dan menggunakan strategi caching untuk menentukan resource yang harus ditampilkan ke browser. Cache pekerja layanan dan cache HTTP memiliki fungsi umum yang sama, tetapi cache pekerja layanan menawarkan lebih banyak kemampuan caching, seperti kontrol terperinci atas apa yang di-cache dan cara pembuatan cache dilakukan.
Mengontrol cache pekerja layanan
Pekerja layanan mencegat permintaan HTTP dengan pemroses peristiwa (biasanya peristiwa fetch). Cuplikan kode
ini menunjukkan logika strategi cache
Cache-First.
Sangat direkomendasikan untuk menggunakan Workbox agar tidak ada lagi hal yang mudah. Misalnya, Anda dapat mendaftarkan jalur URL resource dengan satu baris kode ekspresi reguler.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Strategi penyimpanan dan kasus penggunaan pekerja layanan
Tabel berikutnya menguraikan strategi caching pekerja layanan yang umum dan kapan setiap strategi akan berguna.
| Strategi | Alasan keaktualan | Kasus penggunaan |
|---|---|---|
| Hanya jaringan | Konten harus selalu diperbarui. |
|
| Jaringan kembali ke cache | Sebaiknya tayangkan konten baru. Namun, jika jaringan gagal atau tidak stabil, Anda dapat menayangkan konten yang sedikit lama. |
|
| Stale-when-revalidate | Anda dapat langsung menayangkan konten yang di-cache, tetapi konten yang diupdate dalam cache harus digunakan di masa mendatang. |
|
| Cache terlebih dahulu, kembali ke jaringan | Konten ini tidak begitu penting dan dapat disalurkan dari cache untuk mendapatkan peningkatan performa, tetapi pekerja layanan terkadang harus memeriksa update. |
|
| Hanya cache | Konten jarang berubah. |
|
Manfaat tambahan dari cache pekerja layanan
Selain kontrol terperinci atas logika caching, caching pekerja layanan juga menyediakan:
- Lebih banyak memori dan ruang penyimpanan untuk origin Anda: Browser mengalokasikan resource cache HTTP per origin. Dengan kata lain, jika Anda memiliki beberapa subdomain, semuanya memiliki cache HTTP yang sama. Tidak ada jaminan bahwa konten asal/domain Anda tetap berada di cache HTTP dalam waktu yang lama. Misalnya, pengguna dapat menghapus permanen cache dengan membersihkan secara manual dari UI setelan browser, atau memicu pemuatan ulang paksa pada sebuah halaman. Dengan cache pekerja layanan, Anda memiliki kemungkinan yang jauh lebih tinggi bahwa konten yang di-cache akan tetap disimpan dalam cache. Lihat Penyimpanan persisten untuk mempelajari lebih lanjut.
- Fleksibilitas yang lebih tinggi dengan jaringan yang tidak stabil atau pengalaman offline: Dengan cache HTTP, Anda hanya memiliki pilihan biner: resource di-cache atau tidak. Dengan penyimpanan cache pekerja layanan, Anda dapat mengurangi "gangguan" kecil dengan jauh lebih mudah (dengan strategi "buang saat validasi ulang"), menawarkan pengalaman offline yang lengkap (dengan strategi "Hanya cache"), atau bahkan sesuatu di antaranya, seperti UI yang disesuaikan dengan bagian halaman yang berasal dari cache pekerja layanan dan beberapa bagian dikecualikan (dengan strategi "Tetapkan pengendali tangkapan") jika sesuai.
Penyimpanan cache HTTP
Saat pertama kali memuat halaman web dan resource terkait, browser menyimpan resource ini dalam cache HTTP-nya. Cache HTTP biasanya diaktifkan secara otomatis oleh browser, kecuali jika telah dinonaktifkan secara eksplisit oleh pengguna akhir.
Menggunakan caching HTTP berarti mengandalkan server untuk menentukan waktu penyimpanan resource dan durasinya untuk menentukan cache resource.
Mengontrol masa berlaku cache HTTP dengan header respons HTTP
Ketika server merespons permintaan browser untuk resource, server menggunakan header respons HTTP untuk memberi tahu browser berapa lama browser harus menyimpan resource. Lihat Header respons: mengonfigurasi server web untuk mempelajari lebih lanjut.
Strategi caching dan kasus penggunaan HTTP
Cache HTTP jauh lebih sederhana daripada caching pekerja layanan, karena caching HTTP hanya menangani logika akhir masa berlaku resource berbasis waktu (TTL). Lihat Nilai header respons mana yang harus Anda gunakan? dan Ringkasan untuk mempelajari lebih lanjut strategi penyimpanan HTTP ke cache.
Mendesain logika masa berlaku cache
Bagian ini menjelaskan kelebihan dan kekurangan penggunaan logika masa berlaku yang konsisten di seluruh cache pekerja layanan dan lapisan cache HTTP, serta kelebihan dan kekurangan logika masa berlaku yang terpisah di seluruh lapisan ini.
Glitch di bawah ini menunjukkan cara kerja caching pekerja layanan dan cache HTTP di berbagai skenario:
Logika masa berlaku yang konsisten untuk semua lapisan cache
Untuk menunjukkan kelebihan dan kekurangannya, kita akan melihat 3 skenario: jangka panjang, jangka menengah, dan jangka pendek.
| Skenario | Penyimpanan cache jangka panjang | Penyimpanan cache jangka menengah | Penyimpanan cache jangka pendek |
|---|---|---|---|
| Strategi penyimpanan dalam cache pekerja layanan | Cache, fallback ke jaringan | Tidak berlaku saat divalidasi ulang | Jaringan fallback ke cache |
| TTL cache pekerja layanan | 30 hari | 1 hari | 10 mnt |
| Usia maksimum cache HTTP | 30 hari | 1 hari | 10 mnt |
Skenario: Penyimpanan cache jangka panjang (Cache, fallback ke jaringan)
- Jika resource yang di-cache valid (<= 30 hari): Pekerja layanan akan segera menampilkan resource yang di-cache tanpa masuk ke jaringan.
- Jika resource yang di-cache berakhir masa berlakunya (> 30 hari): Pekerja layanan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource dalam cache HTTP-nya, sehingga beralih ke sisi server untuk resource.
Kontra: Dalam skenario ini, cache HTTP memberikan lebih sedikit nilai karena browser akan selalu meneruskan permintaan ke sisi server saat cache berakhir di pekerja layanan.
Skenario: Cache jangka menengah (Stale-when-revalidate)
- Jika resource yang di-cache valid (<= 1 hari): Pekerja layanan akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser memiliki salinan resource di cache HTTP-nya, sehingga menampilkan salinan tersebut ke pekerja layanan.
- Jika resource yang di-cache berakhir masa berlakunya (> 1 hari): Pekerja layanan akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource dalam cache HTTP-nya, sehingga resource beralih ke sisi server untuk mengambil resource.
Kontra: Pekerja layanan memerlukan cache-busting tambahan untuk mengganti cache HTTP agar dapat memanfaatkan langkah "validasi ulang" secara maksimal.
Skenario: Cache jangka pendek (Jaringan fallback ke cache)
- Jika resource yang di-cache valid (<= 10 menit): Pekerja layanan membuka jaringan untuk mengambil resource. Browser memiliki salinan resource dalam cache HTTP-nya, sehingga menampilkannya ke pekerja layanan tanpa beralih ke sisi server.
- Jika resource yang di-cache berakhir masa berlakunya (> 10 menit): Pekerja layanan akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource dalam cache HTTP-nya, sehingga resource beralih ke sisi server untuk mengambil resource.
Kekurangan: Serupa dengan skenario caching jangka menengah, pekerja layanan memerlukan logika perusak cache tambahan untuk mengganti cache HTTP agar dapat mengambil resource terbaru dari sisi server.
Pekerja layanan dalam semua skenario
Dalam semua skenario, cache pekerja layanan masih dapat menampilkan resource yang di-cache saat jaringan tidak stabil. Di sisi lain, cache HTTP tidak dapat diandalkan saat jaringan tidak stabil atau mati.
Logika masa berlaku cache yang berbeda pada cache pekerja layanan dan lapisan HTTP
Untuk menunjukkan kelebihan dan kekurangannya, kita akan melihat kembali skenario jangka panjang, jangka menengah, dan jangka pendek.
| Skenario | Penyimpanan cache jangka panjang | Penyimpanan cache jangka menengah | Penyimpanan cache jangka pendek |
|---|---|---|---|
| Strategi penyimpanan dalam cache pekerja layanan | Cache, fallback ke jaringan | Tidak berlaku saat divalidasi ulang | Jaringan fallback ke cache |
| TTL cache pekerja layanan | 90 hari | 30 hari | 1 hari |
| Usia maksimum cache HTTP | 30 hari | 1 hari | 10 mnt |
Skenario: Penyimpanan cache jangka panjang (Cache, fallback ke jaringan)
- Jika resource yang di-cache valid di cache pekerja layanan (<= 90 hari): Pekerja layanan segera menampilkan resource yang di-cache.
- Jika resource yang di-cache berakhir masa berlakunya di cache pekerja layanan (> 90 hari): Pekerja layanan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource dalam cache HTTP-nya, sehingga resource tersebut berjalan di sisi server.
Pro dan kontra:
- Pro: Pengguna mengalami respons instan karena pekerja layanan segera menampilkan resource yang di-cache.
- Pro: Pekerja layanan memiliki kontrol yang lebih terperinci terkait kapan harus menggunakan cache-nya, dan kapan harus meminta versi resource baru.
- Kekurangan: Strategi caching pekerja layanan yang jelas diperlukan.
Skenario: Cache jangka menengah (Stale-when-revalidate)
- Jika resource yang di-cache valid di cache pekerja layanan (<= 30 hari): Pekerja layanan akan segera menampilkan resource yang di-cache.
- Saat resource yang di-cache berakhir masa berlakunya di cache pekerja layanan (> 30 hari): Pekerja layanan membuka jaringan untuk mencari resource tersebut. Browser tidak memiliki salinan resource dalam cache HTTP-nya, sehingga resource berjalan di sisi server.
Pro dan kontra:
- Pro: Pengguna mengalami respons instan karena pekerja layanan segera menampilkan resource yang di-cache.
- Pro: Pekerja layanan dapat memastikan bahwa permintaan next untuk URL tertentu menggunakan respons baru dari jaringan, berkat validasi ulang yang terjadi "di latar belakang".
- Kekurangan: Strategi caching pekerja layanan yang jelas diperlukan.
Skenario: Cache jangka pendek (Jaringan fallback ke cache)
- Jika resource yang di-cache valid di cache pekerja layanan (<= 1 hari): Pekerja layanan membuka jaringan untuk mencari resource tersebut. Browser akan menampilkan resource dari cache HTTP jika ada. Jika jaringan tidak aktif, pekerja layanan akan menampilkan resource dari cache pekerja layanan
- Jika masa berlaku resource yang di-cache berakhir di cache pekerja layanan (> 1 hari): Pekerja layanan membuka jaringan untuk mengambil resource. Browser mengambil resource melalui jaringan saat versi yang di-cache dalam cache HTTP-nya telah habis masa berlakunya.
Pro dan kontra:
- Pro: Ketika jaringan tidak stabil atau tidak aktif, pekerja layanan akan segera menampilkan resource yang di-cache.
- Kontra: Pekerja layanan memerlukan cache-busting tambahan untuk mengganti Cache HTTP dan membuat permintaan "Network first".
Kesimpulan
Mengingat kompleksitas kombinasi skenario cache, tidak mungkin untuk mendesain satu aturan yang mencakup semua kasus. Namun, berdasarkan temuan di bagian sebelumnya, ada beberapa saran yang perlu diperhatikan saat mendesain strategi cache Anda:
- Logika penyimpanan dalam cache pekerja layanan tidak harus konsisten dengan logika masa berlaku penyimpanan cache HTTP. Jika memungkinkan, gunakan logika masa berlaku yang lebih lama di pekerja layanan untuk memberikan kontrol yang lebih besar kepada pekerja layanan.
- Cache HTTP masih memainkan peran penting, tetapi tidak dapat diandalkan ketika jaringan tidak stabil atau tidak aktif.
- Tinjau kembali strategi caching Anda untuk setiap resource guna memastikan strategi caching pekerja layanan Anda memberikan nilainya, tanpa bertentangan dengan cache HTTP.