Pembuatan cache pekerja layanan dan cache HTTP

Kelebihan dan kekurangan penggunaan 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, caching resource telah menjadi lebih kompleks dari sebelumnya. Artikel ini membahas gambaran besar tentang {i>cache<i} browser, termasuk:

  • Kasus penggunaan dan perbedaan antara penyimpanan dalam cache pekerja layanan dan penyimpanan dalam cache HTTP.
  • Kelebihan dan kekurangan berbagai strategi masa berlaku penyimpanan cache pekerja layanan dibandingkan dengan Strategi penyimpanan cache HTTP.

Ringkasan alur penyimpanan dalam cache

Pada tingkat tinggi, browser mengikuti urutan penyimpanan dalam cache di bawah ini saat meminta resource:

  1. Cache pekerja layanan: Pekerja layanan memeriksa apakah resource ada di cache-nya dan memutuskan apakah akan menampilkan resource itu sendiri berdasarkan strategi penyimpanan dalam cache yang diprogram. Perhatikan bahwa hal ini tidak terjadi secara otomatis. Anda perlu membuat pengendali peristiwa pengambilan di pekerja layanan dan mencegat permintaan jaringan sehingga permintaan ditayangkan dari cache pekerja layanan, bukan dari jaringan.
  2. 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.
  3. Sisi server: Jika tidak ada yang ditemukan di cache pekerja layanan atau cache HTTP, browser akan membuka jaringan untuk meminta resource. Jika sumber daya tidak di-cache dalam CDN, permintaan harus kembali ke server origin.

Alur penyimpanan dalam cache

Lapisan penyimpanan dalam cache

Caching 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 cache HTTP melayani tujuan umum yang sama, tetapi cache pekerja layanan menawarkan lebih banyak kemampuan penyimpanan dalam cache, seperti kontrol terperinci atas apa yang di-cache dan cara penyimpanan dalam cache dilakukan.

Mengontrol cache pekerja layanan

Pekerja layanan mencegat permintaan HTTP dengan peristiwa pemroses (biasanya peristiwa fetch). Cuplikan kode ini menunjukkan logika strategi cache Cache-First.

Diagram yang menunjukkan cara pekerja layanan menangkap permintaan HTTP

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 dan kasus penggunaan caching pekerja layanan

Tabel berikutnya menguraikan strategi penyimpanan dalam cache pekerja layanan umum dan kapan setiap strategi berguna.

Strategi Alasan keaktualan Kasus penggunaan
Khusus jaringan Konten tersebut harus diperbarui setiap saat.
  • Pembayaran dan checkout
  • Laporan mutasi saldo
Jaringan melakukan penggantian ke cache Sebaiknya sajikan konten yang baru. Namun, jika jaringan gagal atau tidak stabil, konten yang sedikit lama dapat ditayangkan.
  • Data yang aktual
  • Harga dan tarif (perlu pernyataan penyangkalan)
  • Status pesanan
Stale-while-revalidate Anda dapat langsung menayangkan konten yang di-cache, tetapi konten yang di-cache yang telah diperbarui harus digunakan di masa mendatang.
  • Feed berita
  • Halaman listingan produk
  • Pesan
Cache terlebih dahulu, fallback ke jaringan Konten ini tidak penting dan dapat ditayangkan dari cache untuk meningkatkan performa, tetapi pekerja layanan harus sesekali memeriksa update.
  • App shell
  • Referensi umum
Cache only Konten jarang berubah.
  • Konten statis

Manfaat tambahan caching pekerja layanan

Selain kontrol terperinci atas logika penyimpanan dalam cache, penyimpanan dalam cache pekerja layanan juga menyediakan:

  • Memori dan ruang penyimpanan yang lebih besar untuk origin Anda: Browser mengalokasikan cache HTTP resource per origin. Dengan kata lain, jika Anda memiliki beberapa subdomain, semuanya akan menggunakan cache HTTP yang sama. Tidak ada menjamin bahwa konten asal/domain Anda tetap berada dalam cache HTTP untuk waktu yang lama. Sebagai misalnya, pengguna dapat menghapus cache dengan membersihkannya secara manual dari UI pengaturan browser, atau yang memicu muat ulang di halaman. Dengan cache pekerja layanan, Anda memiliki kemungkinan yang jauh lebih tinggi bahwa konten yang di-cache akan tetap di-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 cache pekerja layanan, Anda dapat mengurangi sedikit "masalah" dengan lebih mudah (dengan strategi "stale-while-revalidate"), menawarkan pengalaman offline yang lengkap (dengan strategi "Cache only") atau bahkan sesuatu di antaranya, seperti UI yang disesuaikan dengan bagian halaman yang berasal dari cache pekerja layanan dan beberapa bagian dikecualikan (dengan strategi "Set catch handler") jika sesuai.

Penyimpanan cache HTTP

Saat pertama kali memuat halaman web dan resource terkait, browser akan menyimpan resource ini di cache HTTP-nya. {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 server web 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 dalam cache HTTP.

Mendesain logika masa berakhir cache

Bagian ini menjelaskan pro dan kontra penggunaan logika masa berlaku yang konsisten di seluruh cache pekerja layanan dan lapisan cache HTTP, serta pro dan kontra logika masa berlaku terpisah di seluruh lapisan ini.

Glitch di bawah ini menunjukkan cara kerja 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 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 kembali ke cache
TTL cache pekerja layanan 30 hari 1 hari 10 menit
Masa berlaku cache HTTP 30 hari 1 hari 10 menit

Skenario: Cache jangka panjang (Cache, beralih kembali ke jaringan)

  • Jika resource yang di-cache valid (<= 30 hari): Pekerja layanan akan segera menampilkan resource yang di-cache tanpa membuka jaringan.
  • Saat masa berlaku resource yang di-cache berakhir (> 30 hari): Pekerja layanan akan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, jadi berjalan di sisi server untuk resource tersebut.

Kekurangan: Dalam skenario ini, penyimpanan dalam cache HTTP memberikan lebih sedikit nilai karena browser akan selalu meneruskan permintaan ke sisi server saat masa berlaku cache di service worker berakhir.

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 menampilkan 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)

  • Jika resource yang di-cache valid (<= 10 menit): Pekerja layanan akan membuka jaringan untuk mengambil resource. Browser memiliki salinan resource di cache HTTP-nya sehingga menghasilkan ke pekerja layanan tanpa harus beralih ke sisi server.
  • Saat masa berlaku resource yang di-cache habis (> 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 browser akan menggunakan sisi server untuk mengambil resource.

Kekurangan: Serupa dengan skenario penyimpanan dalam jangka menengah, pekerja layanan memerlukan logika cache-busting tambahan untuk mengganti cache HTTP guna 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 bila jaringan tidak stabil atau tidak aktif.

Logika masa berlaku cache yang berbeda di 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 kembali ke cache
TTL cache pekerja layanan 90 hari 30 hari 1 hari
Masa berlaku cache HTTP 30 hari 1 hari 10 menit

Skenario: Caching jangka panjang (Cache, fallback ke jaringan)

  • Jika resource yang di-cache valid di cache pekerja layanan (<= 90 hari): Pekerja layanan akan segera 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 di cache HTTP-nya, sehingga resource tersebut akan diproses di sisi server.

Pro dan kontra:

  • Kelebihan: Pengguna mendapatkan respons instan karena pekerja layanan segera menampilkan resource yang di-cache.
  • Kelebihan: Pekerja layanan memiliki kontrol yang lebih terperinci tentang kapan harus menggunakan cache-nya dan kapan harus meminta versi baru resource.
  • Kekurangan: Diperlukan strategi caching pekerja layanan yang jelas.

Skenario: Cache jangka menengah (Stale-while-revalidate)

  • 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 cache HTTP-nya, sehingga resource tersebut akan diakses dari 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: Strategi caching pekerja layanan yang ditentukan dengan baik diperlukan.

Skenario: Penyimpanan cache jangka pendek (Jaringan yang kembali ke cache)

  • Jika resource yang di-cache valid di cache pekerja layanan (<= 1 hari): Pekerja layanan akan membuka jaringan untuk resource tersebut. Browser menampilkan resource dari cache HTTP jika ada. Jika jaringan tidak aktif, pekerja layanan akan menampilkan sumber daya dari cache pekerja layanan
  • Saat masa berlaku resource yang di-cache habis di cache pekerja layanan (> 1 hari): Pekerja layanan akan membuka jaringan untuk mengambil resource. Browser mengambil resource melalui jaringan karena versi yang di-cache dalam cache HTTP-nya telah habis masa berlakunya.

Pro dan kontra:

  • Kelebihan: Saat jaringan tidak stabil atau tidak berfungsi, pekerja layanan akan segera menampilkan resource yang di-cache.
  • Kekurangan: Pekerja layanan memerlukan cache-busting tambahan untuk mengganti Cache HTTP dan membuat permintaan "Jaringan terlebih dahulu".

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 penyimpanan dalam cache pekerja layanan tidak perlu konsisten dengan logika masa berlaku penyimpanan dalam cache HTTP. Jika memungkinkan, gunakan logika masa berlaku yang lebih lama di pekerja layanan untuk memberikan pekerja layanan memiliki kontrol yang lebih besar.
  • Cache HTTP masih memainkan peran penting, tetapi tidak dapat diandalkan jika jaringan tidak stabil atau tidak berfungsi.
  • Tinjau kembali strategi penyimpanan dalam cache untuk setiap resource guna memastikan strategi penyimpanan dalam cache pekerja layanan Anda memberikan nilainya, tanpa bertentangan dengan cache HTTP.

Pelajari lebih lanjut