面向仅服务在线用户的PWA的Workbox缓存策略及性能优化咨询

Let’s break down each of your questions with context from your Workbox-based Service Worker code:

1. Do you need Service Worker caching if only serving online users? Can browser-native caching replace it? #

Even if you’re only targeting online users, Service Worker (SW) caching still offers unique benefits that browser-native HTTP caching can’t fully replicate—though it’s not strictly mandatory unless you need to maintain PWA eligibility (since PWAs require a SW for installability).

Here’s the breakdown:

• Browser HTTP caching relies on Cache-Control headers set by your server. It’s great for basic static resource caching, but it’s passive: you can’t define dynamic strategies (like serving cached content while updating in the background) or granularly control which resources get cached beyond headers. Also, users can easily clear browser cache, and cache invalidation can be tricky with query strings or versioned filenames.
• Service Worker caching (especially with Workbox) lets you implement active strategies like StaleWhileRevalidate—which serves cached content instantly to users while fetching updates in the background. This directly improves perceived performance for repeat visitors, even when they’re online. You also get precise control over cache expiration, entry limits, and which routes are cached, avoiding accidental caching of external resources (like your excluded Google Maps JS).

If you don’t need PWA features (like home screen installation), you could technically rely solely on browser caching—but SW caching gives you far more control over user experience and resource management.

2. Why is your cache size so large (200MB) despite targeting limited resources? #

Looking at your code, there are a few likely culprits:

a. Unrestricted font caching #

Your font route uses event.request.destination === 'font' with no domain restriction. This means any font loaded by your app (including third-party fonts like Google Fonts) will be cached. Font files are often large—especially if you’re loading multiple weights or languages for a font family. A single font file can be 5-20MB, and caching 10+ of them would quickly add up.

b. Missing cache expiration time limits #

Your ExpirationPlugin configurations only set maxEntries (e.g., 20 JS files, 30 CSS files), but no maxAgeSeconds. This means old, unused resources will stick around in the cache indefinitely until the entry limit is hit. If your JS/CSS files are versioned (e.g., with hash filenames), each deployment adds a new entry to the cache—so you could end up with 20 large JS bundles (each 5-10MB) taking up 100-200MB on their own.

c. Unchecked cache contents #

It’s worth verifying exactly what’s being cached. Open Chrome DevTools > Application > Cache Storage, and inspect each cache group (javascript, stylesheets, images, fonts). Look for unexpectedly large files (e.g., a bundled JS file that’s 50MB instead of 2MB) or duplicate resources that slipped past your regex filters.

3. Can over-caching slow down app performance due to Service Worker request interception? #

Service Worker request interception itself is very lightweight—Workbox optimizes route matching to minimize overhead. However, over-caching can indirectly hurt performance in a few ways:

• Unnecessary background updates: With StaleWhileRevalidate, every cached resource triggers a background fetch to check for updates. If you’re caching dozens of large files, these background requests can consume bandwidth that could be used for critical requests (like Google Maps API calls or real-time fuel price data).
• Browser cache eviction: Browsers impose limits on total cache size. If your app uses 200MB of cache, it’s more likely to trigger automatic eviction of older resources (via LRU logic). This means repeat visitors might have to re-download critical resources that were cleared, leading to slower load times.
• SW startup overhead: While minimal, a large number of cache entries can slightly increase the time it takes for your SW to initialize, since it has to index cache contents during startup.

Quick Recommendations to Fix Your Issues #

Based on your code and questions, here are actionable fixes:

1. Restrict font caching to your domain: Update the font route to include a domain check:

   workbox.routing.registerRoute(
     ({event, url}) => event.request.destination === 'font' && url.hostname === 'example.com',
     new workbox.strategies.StaleWhileRevalidate({
       cacheName: FONT_CACHE,
       plugins: [
         new workbox.expiration.ExpirationPlugin({
           maxEntries: 15,
           maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
         }),
       ],
     })
   );
   

2. Add maxAgeSeconds to all expiration plugins: For example, set a 30-day limit for static resources to auto-clean old entries.
3. Audit cache contents: Use DevTools to identify and remove large/unnecessary cached resources, then adjust your regex filters if needed.
4. Optimize resource sizes: Compress JS/CSS, use WebP for images, and subset fonts to only include the characters your app needs.

内容的提问来源于stack exchange，提问作者southafricanrob