Pembuatan cache pekerja layanan dan cache HTTP

Kelebihan dan kekurangan penggunaan logika masa berlaku yang konsisten atau berbeda di seluruh lapisan cache HTTP dan pekerja layanan.

Jonathan Chen

Meskipun pekerja layanan dan PWA menjadi standar aplikasi web modern, penyiapan cache resource menjadi lebih kompleks dari sebelumnya. Artikel ini membahas gambaran besar tentang caching browser, termasuk:

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

Ringkasan alur penyimpanan dalam cache

Pada tingkat tinggi, browser mengikuti urutan penyimpanan dalam cache di bawah 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 cache yang telah diprogram. Perhatikan bahwa hal ini tidak terjadi secara otomatis. Anda perlu membuat handler peristiwa pengambilan data di service worker dan mencegat permintaan jaringan sehingga permintaan ditayangkan dari cache service worker, 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 resource tidak di-cache di CDN, permintaan harus kembali ke server asal.

Lapisan cache

Caching service worker

Service worker mencegat permintaan HTTP jenis jaringan dan menggunakan strategi caching untuk menentukan resource apa yang harus ditampilkan ke browser. Cache pekerja layanan dan cache HTTP memiliki tujuan umum yang sama, tetapi cache pekerja layanan menawarkan kemampuan caching yang lebih besar, seperti kontrol terperinci atas apa yang di-cache dan cara caching dilakukan.

Mengontrol cache pekerja layanan

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

Sangat direkomendasikan untuk menggunakan Workbox agar tidak perlu mengulang dari awal. Misalnya, Anda dapat mendaftarkan jalur URL resource dengan satu baris kode regex.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Strategi dan kasus penggunaan caching pekerja layanan

Tabel berikutnya menguraikan strategi caching pekerja layanan umum dan kapan setiap strategi berguna.

Manfaat tambahan caching pekerja layanan

Selain kontrol terperinci atas logika penayangan, penayangan pekerja layanan juga menyediakan:

• Ruang penyimpanan dan memori yang lebih besar untuk origin Anda: Browser mengalokasikan resource cache HTTP berdasarkan per-origin. Dengan kata lain, jika Anda memiliki beberapa subdomain, semuanya berbagi cache HTTP yang sama. Tidak ada jaminan bahwa konten asal/domain Anda akan tetap berada di cache HTTP dalam waktu yang lama. Misalnya, pengguna dapat menghapus cache dengan membersihkan secara manual dari UI setelan browser, atau memicu pemuatan ulang paksa di halaman. Dengan cache pekerja layanan, Anda memiliki kemungkinan yang jauh lebih tinggi bahwa konten dalam cache Anda tetap berada 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 caching pekerja layanan, Anda dapat memitigasi "hambatan" kecil dengan lebih mudah (dengan strategi "basi saat divalidasi ulang"), menawarkan pengalaman offline yang lengkap (dengan strategi "Khusus cache"), atau bahkan sesuatu di antaranya, seperti UI yang disesuaikan dengan bagian halaman yang berasal dari cache pekerja layanan dan beberapa bagian yang dikecualikan (dengan strategi "Setel pengendali pengambilan") jika sesuai.

Penyimpanan cache HTTP

Saat pertama kali memuat halaman web dan resource terkait, browser akan menyimpan resource ini di cache HTTP-nya. Cache HTTP biasanya diaktifkan secara otomatis oleh browser, kecuali jika telah dinonaktifkan secara eksplisit oleh pengguna akhir.

Menggunakan HTTP caching berarti mengandalkan server untuk menentukan kapan harus melakukan caching resource dan berapa lama.

Mengontrol masa habis berlaku cache HTTP dengan header respons HTTP

Saat server merespons permintaan browser untuk suatu resource, server menggunakan header respons HTTP untuk memberi tahu browser berapa lama browser harus meng-cache resource tersebut. Lihat Header respons: mengonfigurasi server web untuk mempelajari lebih lanjut.

Strategi dan kasus penggunaan caching HTTP

Caching HTTP jauh lebih sederhana daripada caching pekerja layanan, karena caching HTTP hanya menangani logika masa berlaku resource berbasis waktu (TTL). Lihat Nilai header respons mana yang sebaiknya Anda gunakan? dan Ringkasan untuk mempelajari lebih lanjut strategi caching HTTP.

Mendesain logika masa berlaku cache

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

Logika masa berlaku yang konsisten untuk semua lapisan cache

Untuk menunjukkan kelebihan dan kekurangan, kita akan melihat 3 skenario: jangka panjang, jangka menengah, dan jangka pendek.

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

• Jika resource yang di-cache valid (<= 30 hari): Pekerja layanan akan segera menampilkan resource yang di-cache tanpa membuka jaringan.
• Jika masa berlaku resource yang di-cache telah berakhir (> 30 hari): Service worker akan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, sehingga browser mengakses resource sisi server.

Kontra: Dalam skenario ini, caching HTTP memberikan lebih sedikit nilai karena browser akan selalu meneruskan permintaan ke sisi server saat cache berakhir di pekerja layanan.

Skenario: Penyimpanan cache jangka menengah (Stale-while-revalidate)

• Jika resource yang di-cache valid (<= 1 hari): Service worker akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser memiliki salinan resource di cache HTTP-nya, sehingga browser menampilkan salinan tersebut ke pekerja layanan.
• Jika resource yang di-cache telah habis masa berlakunya (> 1 hari): Service worker akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, sehingga browser akan mengambil resource dari sisi server.

Kontra: Pekerja layanan memerlukan penghapusan cache tambahan untuk menggantikan cache HTTP agar dapat memanfaatkan langkah "validasi ulang" secara maksimal.

Skenario: Caching jangka pendek (Jaringan melakukan penggantian ke cache)

• Jika resource yang di-cache valid (<= 10 menit): Service worker akan membuka jaringan untuk mengambil resource. Browser memiliki salinan resource di cache HTTP-nya, sehingga browser akan menayangkannya ke pekerja layanan tanpa harus membuka sisi server.
• Jika masa berlaku resource yang di-cache telah berakhir (> 10 menit): Pekerja layanan akan segera menampilkan resource yang di-cache, dan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, sehingga browser akan mengambil resource dari sisi server.

Kontra: Mirip dengan skenario caching jangka menengah, pekerja layanan memerlukan logika penghapusan cache tambahan untuk menggantikan cache HTTP guna mengambil resource terbaru dari sisi server.

Pekerja layanan dalam semua skenario

Dalam semua skenario, cache pekerja layanan masih dapat menampilkan resource dalam cache saat jaringan tidak stabil. Di sisi lain, cache HTTP tidak dapat diandalkan saat jaringan tidak stabil atau tidak berfungsi.

Logika masa berlaku cache yang berbeda di cache pekerja layanan dan lapisan HTTP

Untuk menunjukkan kelebihan dan kekurangan, kita akan melihat lagi skenario jangka panjang, jangka menengah, dan jangka pendek.

Skenario: Caching jangka panjang (Cache, kembali 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 telah habis masa berlakunya di cache pekerja layanan (> 90 hari): Pekerja layanan akan membuka jaringan untuk mengambil resource. Browser tidak memiliki salinan resource di cache HTTP-nya, sehingga browser akan membuka sisi server.

Pro dan kontra:

• Pro: Pengguna mendapatkan respons instan karena pekerja layanan segera menampilkan resource yang di-cache.
• Pro: Service worker memiliki kontrol yang lebih terperinci tentang kapan harus menggunakan cache-nya dan kapan harus meminta versi baru resource.
• Kontra: Diperlukan strategi caching pekerja layanan yang terdefinisi dengan baik.

Skenario: Penyimpanan cache jangka menengah (Stale-while-revalidate)

• Jika resource yang di-cache valid di cache pekerja layanan (<= 30 hari): Pekerja layanan akan segera menampilkan resource yang di-cache.
• Jika resource yang di-cache telah habis masa berlakunya di cache pekerja layanan (> 30 hari): Pekerja layanan akan membuka jaringan untuk mendapatkan resource. Browser tidak memiliki salinan resource di cache HTTP-nya, sehingga browser akan mengakses sisi server.

Pro dan kontra:

• Pro: Pengguna mendapatkan respons instan karena pekerja layanan segera menampilkan resource yang di-cache.
• Pro: Service worker dapat memastikan bahwa permintaan berikutnya untuk URL tertentu menggunakan respons baru dari jaringan, berkat validasi ulang yang terjadi "di latar belakang".
• Kontra: Diperlukan strategi caching pekerja layanan yang terdefinisi dengan baik.

Skenario: Caching jangka pendek (Jaringan melakukan penggantian ke cache)

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

Pro dan kontra:

• Pro: Saat jaringan tidak stabil atau tidak berfungsi, pekerja layanan akan segera menampilkan resource yang di-cache.
• Kontra: Service worker memerlukan penghapusan cache tambahan untuk menggantikan Cache HTTP dan membuat permintaan "Network first".

Kesimpulan

Mengingat kompleksitas kombinasi skenario caching, tidak mungkin merancang satu aturan yang mencakup semua kasus. Namun, berdasarkan temuan di bagian sebelumnya, ada beberapa saran yang perlu dipertimbangkan saat mendesain strategi cache Anda:

• Logika penyimpanan 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.
• Caching HTTP masih memainkan peran penting, tetapi tidak dapat diandalkan saat jaringan tidak stabil atau tidak berfungsi.
• Tinjau kembali strategi penyimpanan dalam cache untuk setiap resource guna memastikan strategi penyimpanan dalam cache service worker Anda memberikan nilainya, tanpa bertentangan dengan cache HTTP.

Pelajari lebih lanjut

• Keandalan jaringan
• Mencegah permintaan jaringan yang tidak diperlukan dengan Cache HTTP
• Codelab cache HTTP
• Mengukur dampak performa pekerja layanan di dunia nyata
• Cache-Control vs. Expires
• Caching Demystified: Inspect, Clear, and Disable Caches