Visiting a website a second time should feel faster than the first. In practice it often does not: on every load the browser asks the server again, goes through DNS resolution, connection setup and server response, and waits for the critical files to arrive over the network. A service worker changes this order fundamentally. It is a small script the browser places between the page and the network, and it keeps critical files locally. On the next visit it answers requests from this cache, often without a single server round trip. The technology has matured: service worker usage rose from 1.7 percent (Web Almanac 2025) in 2022 to 19.2 percent (Web Almanac 2025), roughly tenfold. This article explains how precaching works, which caching strategies exist, where the limits are and for which projects the effort pays off. If you have not yet cleanly separated a page load into its four phases, you will find the groundwork in our analysis of LCP subparts; this article starts with the returning visit.
Key takeaways
- A service worker sits as a programmable layer between the page and the network and can answer requests from a local cache instead of passing them to the server.
- Precaching stores the critical files already at installation, so returning visits get by almost without a server round trip.
- The choice of caching strategy decides whether users always get the fastest or always the freshest response – you cannot have both at once.
- A service worker replaces neither a fast server response nor a clean loading path; it works in addition, above all from the second visit onward.
- The biggest lever is with projects that have a high return rate and shaky connections; for one-off visits the benefit is small.
What a Service Worker Is and Where It Sits
A service worker is a JavaScript script the browser runs independently of the actual page. Unlike ordinary page script it runs in its own context, has no direct access to the visible document and stays active even when no tab of the site is open. Its central ability is intercepting network requests: every request the page makes – for an image, a font, an API response – passes through the service worker, which may decide whether to answer it from the cache, forward it to the network, or combine both.
That places the service worker in a powerful position: as a programmable intermediary between browser and network. This position is why it only works over HTTPS – a layer that can read and redirect every request would be a security risk over an unencrypted connection. It also explains why the technology has grown more mature and widespread: 19.2 percent (Web Almanac 2025) of the pages studied now register a service worker, while at least one feature of a Progressive Web App appears on 24.5 percent (Web Almanac 2025) of pages. How fast the actual server response turns out still matters, and is the subject of our server optimization.
The Lifecycle in Three Steps
Precaching: Storing Critical Files at Installation
Precaching is the core of the speed gain. When the service worker installs, a fixed list of critical files – the page shell, the central stylesheet, the most important script, a logo, a font – is downloaded once and stored in what is called Cache Storage. These files then live locally in the browser. On the next visit the browser does not have to request them over the network again but gets them directly from local storage: in milliseconds instead of a full round trip through DNS, connection setup and server response.
The difference from the browser's ordinary HTTP cache is control. The HTTP cache follows the server's directives and can be evicted at any time; the service worker cache is filled explicitly by the developer and stays until the script actively replaces it. That makes precaching predictable: you know exactly which files are available after installation. At the same time it demands discipline, because a stale file in the precache remains until a new version of the service worker replaces it. How this interlocks with classic server caching is covered in our overview of caching strategies.
Fill at Installation
The app shell – page skeleton, critical CSS, central script – is downloaded once and stored permanently. The first visit pays this price, every later one benefits from it.
Answer From the Cache
When a request for a stored file arrives, the service worker serves it directly from Cache Storage – no network, no server think time, in a few milliseconds.
Renew in a Controlled Way
If a file changes, a new version of the service worker updates the precache. That keeps the set current without users getting to see stale content.
First Visit vs. Repeat Visit: Where Time Is Saved
The decisive point is that a service worker barely speeds up the first visit. On the very first load no cache exists yet; the browser has to download the script, install it and fill the precache – which even costs a little extra time. The gain arises from the second visit onward. Then the critical files already sit locally, and the page builds up without a single round trip over the network. Exactly this difference makes the technology interesting for offerings with a high return rate.
| Aspect | First visit | Repeat visit with service worker |
|---|---|---|
| Origin of files | server over the network | local cache in the browser |
| Network steps | DNS, TCP, TLS, server response | usually none |
| Behavior on a poor network | waits or aborts | serves the app shell instantly |
| Server load | full page load | relieved, only data sync |
The effect works in addition to all server-side measures, not in their place. An unnecessary redirect, for example, still costs a round trip on the returning visit if it is not cleanly resolved – which is why avoiding redirect chains remains worthwhile even with a service worker. Only the interplay of a fast server, a short loading path and a local cache produces the consistently fast impression that users expect from the second visit on.
Caching Strategies: Where Each Response Comes From
A service worker does not answer every request the same way. For each file type you can define whether the cache or the network is asked first. This decision is the real lever, because it controls the trade-off between speed and freshness. Four basic patterns have become established; which one fits depends on how often the respective content changes and how bad a slightly stale response would be.
| Strategy | Where the response comes from | Suited for | Trade-off |
|---|---|---|---|
| Cache First | cache first, network otherwise | static files, app shell | fresh only after an update |
| Network First | network first, cache otherwise | frequently changing content | slow on a poor network |
| Stale While Revalidate | cache instantly, update in background | content with some tolerance | first response may be slightly stale |
| Network Only | always the network | payments, personalized data | no offline benefit |
Avoid Stale Responses
What a Service Worker Does Not Do
As effective as precaching is, it does not solve every performance problem. A service worker does not make a slow server response faster as long as the content does not come from the cache – the path to the server stays the same. It also does not repair an overloaded loading path: if the page runs too much JavaScript on the first visit or discovers the largest image too late, that first impression stays slow – a case for frontend optimization, not for the cache. And it helps little where people open a page only once, for example on pure campaign landing pages without return. The service worker is an accelerator for the second and every further visit, not a substitute for solid Core Web Vitals on the first.
The Core in One Sentence
From Cache to an Installable Progressive Web App
A service worker on its own makes a site fast on return; together with a web app manifest it becomes a Progressive Web App. The manifest is a small description file with name, icons, start address and colors. If a page meets the technical requirements – among them a service worker and a valid manifest – browsers offer to add it to the home screen like an app. It then starts in its own window, without an address bar, and feels closer to a native app.
The potential is large but little used. While 24.5 percent (Web Almanac 2025) of pages use at least one PWA feature, full Progressive Web Apps with a service worker and manifest reach only 3.5 percent (Web Almanac 2025) of mobile pages. For many offerings with a loyal user base a noticeable advantage is left on the table here. Whether the step is worthwhile belongs in an honest assessment – our services around Progressive Web App performance start exactly there.
The biggest mistake is selling a service worker as a turbo for the first visit. Its value lies in the second, third, tenth load – with users who come back. Those without return gain little here; those with a lot of return gain noticeably.
When the Effort Pays Off
A service worker is additional code that wants to be maintained and tested. This investment does not pay off equally everywhere. The decisive question is how often the same people open the same page and under which conditions they do so. The higher the return rate and the shakier the connections, the greater the gain.
- Users return regularly, for example in shops, portals or web applications with a login
- A noticeable share of traffic comes over mobile or unstable connections
- The site has a clearly delimitable app shell that rarely changes
- There is content that should stay usable offline or during a brief connection drop
- The team can version the service worker and roll out changes in a controlled way
Measure First, Then Build
For offerings with a high return rate, a well-built service worker is one of the most effective measures for perceived speed, because it removes exactly the wait users notice most: reloading familiar content. What such a setup can look like for your project and which typical scenarios we accompany is shown in our references; the fitting framework for it is set out in our pricing.
Related Articles
Style Recalculation: When CSS Slows the Browser Down
Why style calculation costs time at runtime, how Selector Stats and Long Animation Frames make its share visible, and which changes actually shrink the scope.
Checkout Speed: Winning the Final Seconds of a Sale
A checkout cannot be cached away: why the five steps before an order need their own speed budgets, and where in your shop you should be measuring them.
Target Device, Not Test Device: Speed on Weak Hardware
Why the developer machine is the wrong yardstick, which reference device matches the 75th percentile and how both turn into a performance budget that holds.