Aspek utama Progressive Web App adalah keandalannya; mereka dapat memuat aset dengan cepat, menjaga keterlibatan pengguna, dan memberikan masukan dengan segera, bahkan dalam kondisi jaringan yang buruk. Bagaimana mungkin? Berkat peristiwa fetch pekerja layanan.
Peristiwa pengambilan
Peristiwa fetch memungkinkan kita menangkap setiap permintaan jaringan yang dibuat oleh PWA dalam cakupan pekerja layanan, untuk permintaan dengan origin yang sama dan lintas origin. Selain permintaan navigasi dan aset, pengambilan dari pekerja layanan yang terinstal memungkinkan kunjungan halaman setelah pemuatan pertama situs dirender tanpa panggilan jaringan.
Pengendali fetch menerima semua permintaan dari aplikasi, termasuk URL dan header HTTP, serta memungkinkan developer aplikasi memutuskan cara memprosesnya.
Pekerja layanan Anda bisa meneruskan permintaan ke jaringan, merespons dengan respons yang sebelumnya di-cache, atau membuat respons baru. Anda bebas untuk memilih. Berikut adalah contoh sederhana:
self.addEventListener("fetch", event => {
console.log(`URL requested: ${event.request.url}`);
});
Merespons permintaan
Saat permintaan masuk ke pekerja layanan, ada dua hal yang dapat dilakukan; Anda dapat mengabaikannya, yang akan membiarkannya masuk ke jaringan, atau Anda dapat meresponsnya. Merespons permintaan dari dalam pekerja layanan adalah cara Anda dapat memilih apa, dan bagaimana permintaan tersebut dikembalikan ke PWA, bahkan saat pengguna offline.
Untuk merespons permintaan masuk, panggil event.respondWith() dari dalam pengendali peristiwa fetch, seperti ini:
// fetch event handler in your service worker file
self.addEventListener("fetch", event => {
const response = .... // a response or a Promise of response
event.respondWith(response);
});
Anda harus memanggil respondWith() secara sinkron dan menampilkan objek Response. Namun, Anda tidak dapat memanggil respondWith() setelah pengendali peristiwa pengambilan selesai, seperti dalam panggilan asinkron. Jika perlu menunggu respons lengkap, Anda dapat meneruskan Promise ke respondWith() yang di-resolve dengan Respons.
Membuat respons
Berkat Fetch API, Anda bisa membuat respons HTTP dalam kode JavaScript, respons tersebut bisa disimpan dalam cache menggunakan Cache Storage API dan ditampilkan seolah-olah berasal dari server web.
Untuk membuat respons, buat objek Response baru, dengan menyetel isi dan opsi seperti status dan header:
const simpleResponse = new Response("Body of the HTTP response");
const options = {
status: 200,
headers: {
'Content-type': 'text/html'
}
};
const htmlResponse = new Response("<b>HTML</b> content", options)
Merespons dari cache
Setelah Anda mengetahui cara menyajikan respons HTTP dari pekerja layanan, kini saatnya menggunakan antarmuka Penyimpanan Caching untuk menyimpan aset di perangkat.
Anda dapat menggunakan API penyimpanan cache untuk memeriksa apakah permintaan yang diterima dari PWA tersedia di cache, dan jika tersedia, respons respondWith() dengan permintaan tersebut.
Untuk melakukannya, Anda harus terlebih dulu mencari di dalam cache. Fungsi match(), tersedia di antarmuka caches tingkat atas menelusuri semua penyimpanan di origin Anda, atau pada satu objek cache yang terbuka.
Fungsi match() menerima permintaan HTTP atau URL sebagai argumen dan menampilkan promise yang di-resolve dengan Respons yang terkait dengan kunci yang sesuai.
// Global search on all caches in the current origin
caches.match(urlOrRequest).then(response => {
console.log(response ? response : "It's not in the cache");
});
// Cache-specific search
caches.open("pwa-assets").then(cache => {
cache.match(urlOrRequest).then(response => {
console.log(response ? response : "It's not in the cache");
});
});
Strategi caching
Hanya menampilkan file dari cache browser tidak cocok untuk setiap kasus penggunaan. Misalnya, pengguna atau browser dapat mengeluarkan cache. Itulah sebabnya Anda harus menentukan strategi sendiri dalam mengirimkan aset untuk PWA Anda.
Anda tidak dibatasi pada satu strategi caching. Anda dapat menentukan URL yang berbeda untuk berbagai pola URL. Misalnya, Anda dapat memiliki satu strategi untuk aset UI minimum, strategi lain untuk panggilan API, dan strategi ketiga untuk URL gambar dan data.
Untuk melakukannya, baca event.request.url dalam ServiceWorkerGlobalScope.onfetch dan uraikan melalui ekspresi reguler atau Pola URL. (Pada saat penulisan ini, Pola URL tidak didukung di semua platform).
Strategi yang paling umum adalah:
- Cache Terlebih Dahulu
- Menelusuri respons yang di-cache terlebih dahulu, lalu beralih kembali ke jaringan jika tidak ditemukan.
- Pertama di Jaringan
- Meminta respons dari jaringan terlebih dahulu dan jika tidak ada yang ditampilkan, periksa respons di cache.
- Usang Saat Validasi Ulang
- Menyajikan respons dari cache, saat di latar belakang meminta versi terbaru dan menyimpannya ke cache untuk saat berikutnya aset diminta.
- Khusus Jaringan
- Selalu balas dengan respons dari jaringan atau error yang keluar. Cache tidak pernah diminta masukannya.
- Khusus Cache
- Selalu membalas dengan respons dari cache atau error keluar. Jaringan tidak akan pernah dimintai pendapatnya. Aset yang akan ditayangkan menggunakan strategi ini harus ditambahkan ke cache sebelum diminta.
Cache terlebih dahulu
Dengan menggunakan strategi ini, pekerja layanan mencari permintaan yang cocok dalam cache dan mengembalikan Respons yang sesuai jika di-cache. Jika tidak, respons akan diambil dari jaringan (secara opsional, mengupdate cache untuk panggilan di masa mendatang). Jika tidak ada respons cache maupun respons jaringan, permintaan akan error. Karena menayangkan aset tanpa masuk ke jaringan cenderung lebih cepat, strategi ini lebih memprioritaskan performa daripada keaktualan.
self.addEventListener("fetch", event => {
event.respondWith(
caches.match(event.request)
.then(cachedResponse => {
// It can update the cache to serve updated content on the next request
return cachedResponse || fetch(event.request);
}
)
)
});
Mengutamakan jaringan
Strategi ini merupakan cerminan dari strategi Cache First; strategi ini memeriksa apakah permintaan dapat dipenuhi dari jaringan dan, jika tidak bisa, mencoba mengambilnya dari cache. Seperti {i>cache<i} terlebih dahulu. Jika tidak ada respons jaringan atau respons cache, permintaan akan error. Mendapatkan respons dari jaringan biasanya lebih lambat daripada mendapatkannya dari cache. Strategi ini lebih memprioritaskan konten yang diperbarui, bukan performa.
self.addEventListener("fetch", event => {
event.respondWith(
fetch(event.request)
.catch(error => {
return caches.match(event.request) ;
})
);
});
Tidak berlaku saat divalidasi ulang
Strategi usang saat validasi ulang menampilkan respons yang di-cache dengan segera, lalu memeriksa pembaruan pada jaringan, mengganti respons yang di-cache jika ditemukan. Strategi ini selalu membuat permintaan jaringan, karena meskipun resource yang di-cache ditemukan, strategi ini akan mencoba memperbarui data yang ada di cache dengan yang diterima dari jaringan, untuk menggunakan versi yang diupdate dalam permintaan berikutnya. Oleh karena itu, strategi ini memberi Anda cara untuk mendapatkan manfaat dari penyajian cepat strategi pertama cache dan memperbarui cache di latar belakang.
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request).then(cachedResponse => {
const networkFetch = fetch(event.request).then(response => {
// update the cache with a clone of the network response
const responseClone = response.clone()
caches.open(url.searchParams.get('name')).then(cache => {
cache.put(event.request, responseClone)
})
return response
}).catch(function (reason) {
console.error('ServiceWorker fetch failed: ', reason)
})
// prioritize cached response over network
return cachedResponse || networkFetch
}
)
)
})
Khusus jaringan
Strategi khusus jaringan mirip dengan perilaku browser tanpa pekerja layanan atau Cache Storage API. Permintaan hanya akan menampilkan resource jika resource tersebut dapat diambil dari jaringan. Hal ini sering kali berguna untuk resource seperti permintaan API khusus online.
Khusus cache
Strategi khusus cache memastikan permintaan tidak pernah masuk ke jaringan; semua permintaan masuk akan direspons dengan item cache yang telah diisi otomatis. Kode berikut menggunakan pengendali peristiwa fetch dengan metode match penyimpanan cache untuk hanya merespons cache:
self.addEventListener("fetch", event => {
event.respondWith(caches.match(event.request));
});
Strategi kustom
Meskipun hal di atas adalah strategi caching umum, Anda bertanggung jawab atas pekerja layanan dan cara menangani permintaan. Jika tidak ada yang sesuai dengan kebutuhan Anda, buat sendiri.
Misalnya, Anda dapat menggunakan strategi yang mengutamakan jaringan dengan waktu tunggu untuk memprioritaskan konten yang diperbarui, tetapi hanya jika respons muncul dalam batas yang Anda tetapkan. Anda juga bisa menggabungkan respons yang di-cache dengan respons jaringan dan membangun respons kompleks dari pekerja layanan.
Memperbarui aset
Menjaga agar aset yang di-cache PWA Anda tetap terbaru dapat menjadi tantangan. Meskipun strategi yang sudah tidak berlaku saat validasi ulang adalah salah satu cara untuk melakukannya, strategi tersebut bukan satu-satunya. Di bab Update, Anda akan mempelajari berbagai teknik untuk terus mengupdate konten dan aset aplikasi.