Adakalanya Anda memiliki koneksi jaringan, tetapi koneksi tersebut terlalu lambat, atau koneksi Anda berbohong bahwa Anda sedang online. Dalam situasi seperti di mana pekerja layanan berada di dalam campuran, strategi caching yang mengutamakan jaringan mungkin membutuhkan waktu terlalu lama untuk mendapatkan respons dari jaringan, atau permintaan akan hang—dan indikator lingkaran berputar pemuatan akan berputar tanpa henti—hingga Anda mendapatkan halaman error.
Apa pun situasinya, ada kalanya pengembalian ke respons yang terakhir di-cache untuk sebuah aset atau halaman setelah jangka waktu tertentu lebih disukai—namun ada masalah lain yang dapat dibantu oleh Workbox.
Menggunakan networkTimeoutSeconds
Memaksa waktu tunggu untuk permintaan jaringan dapat dilakukan saat menggunakan strategi NetworkFirst
atau NetworkOnly
. Strategi ini menawarkan opsi networkTimeoutSeconds
, yang menentukan jumlah detik pekerja layanan harus menunggu respons jaringan diterima sebelum melakukan bails dan menampilkan versi terakhir yang di-cache:
// sw.js
import { NetworkFirst } from 'workbox-strategies';
import { registerRoute, NavigationRoute } from 'workbox-routing';
// Only wait for three seconds before returning the last
// cached version of the requested page.
const navigationRoute = new NavigationRoute(new NetworkFirst({
networkTimeoutSeconds: 3,
cacheName: 'navigations'
}));
registerRoute(navigationRoute);
Kode di atas menginstruksikan pekerja layanan Anda untuk membatalkan permintaan navigasi yang mengutamakan jaringan dan menggunakan versi terakhir yang di-cache setelah tiga detik. Saat digunakan dengan permintaan navigasi, hal ini menjamin akses ke respons yang terakhir di-cache dari setiap halaman yang dikunjungi sebelumnya.
Namun, bagaimana jika halaman yang Anda akses tidak memiliki respons lama di cache? Dalam kasus semacam itu, Anda dapat membuat respons penggantian ke halaman HTML offline generik:
import {registerRoute, NavigationRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
// Hardcode the fallback cache name and the offline
// HTML fallback's URL for failed responses
const FALLBACK_CACHE_NAME = 'offline-fallback';
const FALLBACK_HTML = '/offline.html';
// Cache the fallback HTML during installation.
self.addEventListener('install', (event) => {
event.waitUntil(
caches.open(FALLBACK_CACHE_NAME).then((cache) => cache.add(FALLBACK_HTML)),
);
});
// Apply a network-only strategy to navigation requests.
// If offline, or if more than five seconds pass before there's a
// network response, fall back to the cached offline HTML.
const networkWithFallbackStrategy = new NetworkOnly({
networkTimeoutSeconds: 5,
plugins: [
{
handlerDidError: async () => {
return await caches.match(FALLBACK_HTML, {
cacheName: FALLBACK_CACHE_NAME,
});
},
},
],
});
// Register the route to handle all navigations.
registerRoute(new NavigationRoute(networkWithFallbackStrategy));
Ini berfungsi karena saat Anda menggunakan networkTimeoutSeconds
dalam strategi NetworkFirst
, pengendali akan menampilkan respons error jika waktu tunggu habis dan tidak ada kecocokan cache untuk URL tersebut. Jika hal itu terjadi, plugin Workbox handlerDidError
dapat memberikan respons umum sebagai penggantian.
Berapa lama waktu tunggu yang diperlukan?
Saat memaksa waktu tunggu untuk permintaan—terutama permintaan navigasi—Anda harus mencapai keseimbangan yang tepat antara tidak membiarkan pengguna menunggu terlalu lama dan tidak menunggu terlalu cepat. Tunggu terlalu lama, Anda mungkin berisiko pengguna dengan koneksi lambat terpantul sebelum waktu tunggu terjadi. Waktu tunggu terlalu cepat, dan Anda mungkin pada akhirnya menyajikan konten usang dari cache secara tidak perlu.
Jawaban yang tepat adalah "tergantung". Jika Anda menjalankan situs seperti blog dan tidak terlalu sering memperbarui konten, jawaban yang tepat mungkin adalah dengan tidak menunggu terlalu banyak, karena apa pun yang ada dalam cache mungkin "baru" sudah cukup. Namun, untuk situs dan aplikasi web yang lebih interaktif, sebaiknya tunggu sedikit lebih lama dan hindari menyajikan data usang dari cache pekerja layanan terlalu cepat.
Jika Anda mencatat metrik di kolom, lihat persentil ke-75 dari skor Time to First Byte (TTFB) dan First Contentful Paint (FCP) untuk mengetahui kemungkinan waktu tunggu yang lebih lama untuk permintaan navigasi berada di antara basis pengguna Anda. Hal itu dapat memberi Anda wawasan tentang di mana harus menetapkan batasan.