v149 · Fetch API · Service Worker
Cache-Bypass Dashboard
When a user presses F5 or the reload button, they expect fresh content. isReloadNavigation lets your Service Worker detect that intent and bypass the cache selectively — only for reloads, not for every fetch.
bypass strategies
On isReloadNavigation, fetch from network. On normal navigation, serve from cache. Simple, safe — users always get fresh HTML on reload but fast cache on back/forward.
Append a timestamp query param on reload to force CDN cache-busting even if the Service Worker has a cached response. Good for assets with long cache TTLs.
Serve cached response immediately but also fetch fresh in background and update the cache. Only do the background fetch when isReloadNavigation is true to avoid spurious revalidations.
On reload, bypass the cache only for HTML navigation requests (the page itself). Sub-resources (JS, CSS, images) still come from cache — avoiding a full page re-download.
interactive simulator
Simulate how a Service Worker would handle incoming fetch requests. Toggle "Is reload?" to change how each request is classified and handled.
service worker code
self.addEventListener('fetch', (event) => {
const { request } = event;
// isReloadNavigation is available on navigation requests
if (request.mode === 'navigate' && request.isReloadNavigation) {
// User pressed F5 / reload button — go to network
event.respondWith(
fetch(request).catch(() => caches.match(request))
);
return;
}
// Normal navigation or sub-resource — cache-first
event.respondWith(
caches.match(request).then(cached => cached || fetch(request))
);
});
see also
- Reload Detection Demo — detect reload in-page
- Service Worker Integration — full SW usage
- Feature index
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗