Kelebihan dan kekurangan penggunaan logika masa berlaku yang konsisten atau berbeda di seluruh cache pekerja layanan dan lapisan cache HTTP.
Pekerja layanan dan PWA menjadi standar aplikasi web modern, sementara resource caching menjadi semakin kompleks. Artikel ini membahas gambaran besar tentang {i>cache<i} browser, termasuk:
- Kasus penggunaan dan perbedaan antara caching pekerja layanan dan caching HTTP.
- Kelebihan dan kekurangan berbagai strategi masa berlaku penyimpanan cache pekerja layanan dibandingkan dengan Strategi penyimpanan cache HTTP.
Ringkasan alur penyimpanan cache
Pada tingkat tinggi, browser mengikuti urutan penyimpanan dalam cache di bawah ini saat meminta resource:
- Cache pekerja layanan: Pekerja layanan memeriksa apakah resource ada dalam cache-nya dan memutuskan apakah akan mengembalikan resource itu sendiri berdasarkan strategi caching yang diprogram. Catatan bahwa hal ini tidak terjadi secara otomatis. Anda perlu membuat pengendali peristiwa pengambilan di pekerja layanan dan mencegat permintaan jaringan sehingga permintaan disajikan dari layanan cache pekerja, bukan jaringan.
- Cache HTTP (juga disebut cache browser): Jika resource ditemukan di HTTP Cache dan belum habis masa berlakunya, browser otomatis menggunakan dari cache HTTP.
- Sisi server: Jika tidak ada yang ditemukan dalam cache pekerja layanan atau cache HTTP, masuk ke jaringan untuk meminta sumber daya. Jika sumber daya tidak di-cache dalam CDN, permintaan harus kembali ke server origin.
Menyimpan lapisan dalam cache
Penyimpanan cache pekerja layanan
Pekerja layanan mencegat permintaan HTTP jenis jaringan dan menggunakan strategi penyimpanan dalam cache untuk menentukan resource apa yang harus ditampilkan ke browser. Cache pekerja layanan, dan HTTP {i>cache<i} melayani tujuan umum yang sama, tetapi {i> cache<i} pekerja layanan menawarkan lebih banyak kemampuan {i>caching<i}, seperti kontrol terperinci atas apa yang di-cache dan bagaimana penyimpanan di {i>caching<i} dilakukan.
Mengontrol cache pekerja layanan
Pekerja layanan mencegat permintaan HTTP dengan peristiwa
pemroses (biasanya peristiwa fetch). Ini
cuplikan kode menunjukkan logika
Mengutamakan Cache
untuk strategi caching.
Sangat disarankan untuk menggunakan Workbox untuk menghindari dari awal. Sebagai contoh, Anda dapat daftarkan 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 dalam cache pekerja layanan
Tabel berikutnya menguraikan strategi caching pekerja layanan umum dan kapan setiap strategi berguna.
| Strategi | Alasan keaktualan | Kasus penggunaan |
|---|---|---|
| Jaringan saja | Konten tersebut harus diperbarui setiap saat. |
|
| Jaringan kembali ke cache | Sebaiknya sajikan konten yang baru. Namun jika jaringan gagal atau tidak stabil, masih dapat diterima untuk menyajikan konten yang sedikit lama. |
|
| Tidak berlaku saat validasi ulang | Tidak apa-apa untuk langsung menyajikan konten yang di-cache, tetapi konten yang di-cache yang diperbarui harus digunakan di masa depan. |
|
| Cache terlebih dahulu, beralih kembali ke jaringan | Konten ini bersifat tidak penting dan dapat disajikan dari cache untuk peningkatan performa, tetapi pekerja layanan sesekali harus memeriksa update. |
|
| Hanya cache | Konten jarang berubah. |
|
Manfaat tambahan caching pekerja layanan
Selain kontrol terperinci atas logika caching, caching pekerja layanan juga menyediakan:
- Memori dan ruang penyimpanan yang lebih besar untuk origin Anda: Browser mengalokasikan cache HTTP resource per origin. Di jika Anda memiliki beberapa subdomain, semuanya berbagi cache HTTP yang sama. Tidak ada menjamin bahwa konten asal/domain Anda tetap berada dalam cache HTTP dalam waktu yang lama. Sebagai misalnya, pengguna dapat membersihkan {i>cache<i} dengan membersihkan secara manual dari UI pengaturan browser, atau yang memicu muat ulang di halaman. Dengan cache pekerja layanan, Anda memiliki kemungkinan konten yang di-cache tetap di-cache. Lihat Persisten penyimpanan untuk mempelajarinya 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 cache pekerja layanan Anda dapat mengurangi “gangguan-gangguan” kecil menjadi jauh lebih mudah (dengan strategi "{i>stale-temporary-revalidate<i}"), menawarkan pengalaman offline lengkap (dengan strategi "Hanya cache") atau bahkan sesuatu dalam antara, seperti UI kustom dengan bagian halaman yang berasal dari cache pekerja layanan dan beberapa bagian dikecualikan (dengan strategi "Menetapkan pengendali tangkapan) jika sesuai.
Penyimpanan cache HTTP
Saat pertama kali memuat halaman web dan resource terkait, browser menyimpan resource ini di Cache HTTP. {i>Cache<i} HTTP biasanya diaktifkan secara otomatis oleh {i>browser<i}, kecuali telah dinonaktifkan secara eksplisit oleh pengguna akhir.
Menggunakan {i>caching<i} HTTP berarti mengandalkan server untuk menentukan kapan harus meng-{i>cache<i} sumber daya dan bagaimana panjang.
Mengontrol masa berlaku cache HTTP dengan header respons HTTP
Ketika server merespons permintaan browser untuk sumber daya, server menggunakan header respons HTTP untuk memberi tahu browser berapa lama sumber daya harus di-cache. Lihat Header respons: mengonfigurasi web Anda server untuk mempelajari lebih lanjut.
Strategi dan kasus penggunaan penyimpanan cache HTTP
Cache HTTP jauh lebih sederhana daripada {i>caching<i} pekerja layanan, karena {i>caching<i} HTTP hanya berhubungan dengan logika kedaluwarsa resource berbasis waktu (TTL). Lihat Nilai header respons mana yang harus Anda gunakan? dan Ringkasan untuk mempelajari lebih lanjut strategi penyimpanan cache HTTP.
Mendesain logika masa berakhir cache
Bagian ini menjelaskan kelebihan dan kekurangan penggunaan logika masa berlaku yang konsisten di seluruh pekerja layanan lapisan cache dan cache HTTP, serta kelebihan dan kekurangan logika masa berlaku yang terpisah lapisan berbeda.
Glitch di bawah ini menunjukkan cara kerja penyimpanan cache pekerja layanan dan pembuatan cache HTTP di seluruh skenario yang berbeda:
Logika masa berlaku yang konsisten untuk semua lapisan cache
Untuk menunjukkan kelebihan dan kekurangannya, kita akan melihat 3 skenario: jangka panjang, jangka menengah, dan dalam jangka pendek.
| Skenario | Penyimpanan cache jangka panjang | Penyimpanan cache jangka menengah | Penyimpanan cache jangka pendek |
|---|---|---|---|
| Strategi penyimpanan service worker dalam cache | Cache, fallback ke jaringan | Tidak berlaku saat validasi 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: Cache jangka panjang (Cache, beralih kembali ke jaringan)
- Jika resource yang di-cache valid (<= 30 hari): Pekerja layanan menampilkan file yang di-cache sumber daya segera tanpa masuk ke jaringan.
- Bila sumber daya yang di-cache kedaluwarsa (> 30 hari): Pekerja layanan masuk ke jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, jadi berjalan di sisi server untuk resource tersebut.
Kontra: Dalam skenario ini, penyimpanan cache HTTP memberikan lebih sedikit nilai karena browser akan selalu meneruskan permintaan ke sisi server bila cache telah kedaluwarsa di pekerja layanan.
Skenario: Pembuatan cache jangka menengah (Stale-temporary-validate)
- Jika resource yang di-cache valid (<= 1 day): Pekerja layanan menampilkan file yang di-cache sumber daya, dan masuk ke jaringan untuk mengambil sumber daya. Browser memiliki salinan resource dalam cache HTTP-nya, sehingga mengembalikan salinan tersebut ke pekerja layanan.
- Jika masa berlaku resource yang di-cache habis (> 1 hari): Pekerja layanan menampilkan file yang di-cache sumber daya, dan masuk ke jaringan untuk mengambil sumber daya. Browser tidak memiliki salinan resource dalam cache HTTP-nya, jadi ini akan berjalan di sisi server untuk mengambil resource.
Kontra: Pekerja layanan memerlukan perusak cache tambahan untuk mengganti cache HTTP untuk mengoptimalkan "validasi ulang" langkah waktu ini.
Skenario: Penyimpanan cache jangka pendek (Jaringan yang kembali ke cache)
- Saat resource yang di-cache valid (<= 10 menit): Pekerja layanan masuk ke jaringan untuk mengambil resource. Browser memiliki salinan resource di cache HTTP-nya sehingga menghasilkan ke pekerja layanan tanpa harus beralih ke sisi server.
- Jika masa berlaku resource yang di-cache habis masa berlakunya (> 10 menit): Pekerja layanan menampilkan file yang di-cache sumber daya, dan masuk ke jaringan untuk mengambil sumber daya. Browser tidak memiliki salinan resource dalam cache HTTP-nya, jadi ini akan berjalan di sisi server untuk mengambil resource.
Kontra: Mirip dengan skenario penyimpanan cache jangka menengah, pekerja layanan memerlukan logika perusak cache untuk mengganti cache HTTP guna mengambil sumber daya terbaru dari sisi server.
Pekerja layanan dalam semua skenario
Dalam semua skenario, cache pekerja layanan masih bisa menampilkan resource yang di-cache ketika jaringan tidak stabil. Di sisi lain, cache HTTP tidak dapat diandalkan bila jaringan tidak stabil atau tidak aktif.
Logika masa berlaku cache yang berbeda pada cache pekerja layanan dan lapisan HTTP
Untuk menunjukkan kelebihan dan kekurangannya, kita akan melihat kembali analisis jangka panjang, jangka menengah, dan jangka pendek yang signifikan.
| Skenario | Penyimpanan cache jangka panjang | Penyimpanan cache jangka menengah | Penyimpanan cache jangka pendek |
|---|---|---|---|
| Strategi penyimpanan service worker dalam cache | Cache, fallback ke jaringan | Tidak berlaku saat validasi 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: Cache jangka panjang (Cache, beralih kembali ke jaringan)
- Jika resource yang di-cache valid dalam cache pekerja layanan (<= 90 hari): Layanan worker akan langsung menampilkan resource yang di-cache.
- Jika resource yang di-cache habis masa berlakunya dalam cache pekerja layanan (> 90 hari): Layanan datang ke jaringan untuk mengambil resource. Browser tidak memiliki salinan resource dalam cache HTTP-nya, jadi ini dikirim ke sisi server.
Pro dan kontra:
- Kelebihan: Pengguna mendapatkan respons instan karena pekerja layanan menampilkan resource yang di-cache segera.
- Pro: Pekerja layanan memiliki kontrol yang lebih mendetail terkait kapan harus menggunakan cache-nya dan kapan untuk meminta versi baru resource.
- Kekurangan: Diperlukan strategi caching pekerja layanan yang jelas.
Skenario: Pembuatan cache jangka menengah (Stale-temporary-validate)
- Jika resource yang di-cache valid dalam cache pekerja layanan (<= 30 hari): Layanan worker akan langsung menampilkan resource yang di-cache.
- Jika resource yang di-cache habis masa berlakunya dalam cache pekerja layanan (> 30 hari): Layanan masuk ke jaringan untuk sumber daya. Browser tidak memiliki salinan resource di {i>cache HTTP<i}-nya, jadi ini berjalan di sisi server.
Pro dan kontra:
- Kelebihan: Pengguna mendapatkan respons instan karena pekerja layanan menampilkan resource yang di-cache segera.
- Pro: Pekerja layanan dapat memastikan bahwa permintaan berikutnya untuk URL tertentu menggunakan respons baru dari jaringan, berkat validasi ulang yang terjadi "di latar belakang".
- Kekurangan: Diperlukan strategi caching pekerja layanan yang jelas.
Skenario: Penyimpanan cache jangka pendek (Jaringan yang kembali ke cache)
- Jika resource yang di-cache valid dalam cache pekerja layanan (<= 1 day): Layanan masuk ke jaringan untuk sumber daya. Browser menampilkan resource dari HTTP {i>cache<i} jika ada. Jika jaringan tidak aktif, pekerja layanan akan menampilkan sumber daya dari cache pekerja layanan
- Jika resource yang di-cache habis masa berlakunya dalam cache pekerja layanan (> 1 hari): Layanan datang ke jaringan untuk mengambil resource. Browser mengambil resource melalui karena versi yang di-cache dalam cache HTTP-nya sudah tidak berlaku.
Pro dan kontra:
- Pro: Jika jaringan tidak stabil atau tidak aktif, pekerja layanan akan mengembalikan yang di-cache resource sesegera mungkin.
- Kontra: Pekerja layanan memerlukan perusak cache tambahan untuk mengganti Cache HTTP dan jadikan "Jaringan terlebih dahulu" permintaan.
Kesimpulan
Mengingat kompleksitas kombinasi skenario caching, merancang satu aturan tidak mungkin dilakukan yang mencakup semua kasus. Namun, berdasarkan temuan di bagian sebelumnya, ada beberapa saran yang perlu diperhatikan saat mendesain strategi cache:
- Logika cache pekerja layanan tidak harus konsisten dengan masa berlaku penyimpanan cache HTTP logika. Jika memungkinkan, gunakan logika masa berlaku yang lebih lama di pekerja layanan untuk memberikan pekerja layanan memiliki kontrol yang lebih besar.
- Cache HTTP masih berperan penting, tetapi tidak dapat diandalkan ketika jaringan tidak stabil atau menurun.
- Tinjau kembali strategi penyimpanan Anda dalam cache untuk setiap resource guna memastikan pekerja layanan Anda menyimpan cache memberikan nilainya, tanpa konflik dengan cache HTTP.