Service Workers for Marketing Sites: Offline + Repeat-Visit Speed

Digital Engineering

Service workers are not just for PWAs with app shells. For a marketing site, a couple of hundred lines of code buy near-instant repeat visits and offline browsing. Here is the recipe.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 10, 2026 · 6 min read

Service workers got typecast as the PWA install-prompt thing. That is a narrow read. For a marketing or content site, a service worker buys two specific things that nothing else can: near-instant repeat-visit page loads and graceful behaviour when the user briefly loses connectivity. Both directly improve the metrics search engines actually weight.

We deploy a service worker on most marketing-site engagements now. The implementation is small enough to fit on one page; the operational benefit shows up in CrUX field data within weeks.

What service workers actually do for a marketing site

A service worker sits between your site and the network as a local proxy. It can decide which requests go to the cache, which go to the network, which go to both with a race. For a marketing site the simple decisions cover 90 percent of the value.

Static assets — JS, CSS, images, fonts — get cache-first. The first visit caches them; every subsequent visit serves from cache and revalidates in the background. Repeat-visit time-to-first-paint drops from 'whatever the network gives you' to under 100 ms.

HTML pages get network-first with a cache fallback. The freshest content wins when network is up; the last-known-good HTML serves when network is down. Brief flaps no longer break the user's session.

The 100-line implementation

A service worker for our use case has three event handlers: install, activate, fetch. Install pre-caches the app shell. Activate cleans up old caches when the version bumps. Fetch routes by URL pattern.

We use Workbox for the routing. It compiles to a small file and handles cache invalidation, expiry, max-age policies. Without Workbox the same logic is doable but tedious; with Workbox a marketing-site service worker is a 50-line vite-plugin-pwa configuration.

The update flow that does not break

The thing that scares teams off service workers is the update story. A user with the old service worker can keep getting old assets even after a deploy. The solution is the standard one: each new build bumps a cache version. The activate handler deletes any cache that does not match the current version. Within one navigation, the user is on the fresh build.

What you give up

Two real costs.

First, debugging is harder. The service worker is a separate execution context with its own console. We have spent productive hours wondering why a CSS change did not appear and remembering the service worker is serving the old file. Chrome DevTools' Application panel exists for this; learn it before deploying.

Second, third-party scripts that update independently can drift. AdSense, GA, FundingChoices all have their own caching. If you cache them aggressively you may serve stale versions. Our default policy: never cache third-party scripts. Let them go to the network every time.

Closing

A service worker is not magic and it is not free. It is, however, the cheapest single technique to make repeat visits feel instant and to handle brief connectivity drops gracefully. For a content site that ranks on Core Web Vitals and that real users return to, the calculus is heavily positive. Add it deliberately, ship the cache invalidation correctly, and your repeat-visit experience improves measurably within the first month.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.