Service workers and performance

A return visit, with and without a worker

Asha is on the bus again. She opens the Leaf and Kettle tea list, as she does most mornings. Each time, the screen stays empty for most of a second. Then the teas appear, with the mint tea photo on top.

Ravi wants her return visits to feel instant. He reads that a service worker can do that. He also reads that one can make a visit slower. So which is it?

A service worker is a script the browser runs apart from the page. Once it's installed, it sits between the page and the network. Every request the page makes reaches it first. It can answer from its own store, Cache Storage, or pass the request on to the network. Lesson 15.3 met it as a cook with her own pantry.

Ravi builds six versions of the shop's worker. The course recorded Asha's return visits to each, and to the shop with no worker at all. Here is what she saw on three of them:

Without a worker, the page came at about 780 ms. With a worker that passes every request on, it came a little later. With a worker that answers from its cache, it came at about 110 ms. Here are the numbers behind those screens:

1// Asha's return visit, worker asleep. Medians of 5 visits, in ms.2const noWorker = { firstByte: 677.6, photo: 776 };3const passThrough = { firstByte: 681.6, photo: 804 };4const fromCache = { firstByte: 8.5, photo: 108 };5 6console.log(`No worker: the photo at ${noWorker.photo} ms`);7console.log(`A worker that passes requests on: ${passThrough.photo} ms`);8console.log(`A worker that answers from its cache: ${fromCache.photo} ms`);

• Line 1 is a comment. Each number is a median of five visits: the middle one, once they're sorted. Times are in milliseconds (ms), thousandths of a second.
• Line 2 is the shop with no worker. firstByte is when the first byte of the page arrived. photo is when the photo appeared: the Largest Contentful Paint.
• Line 3 is a worker that passes every request on. Line 4 is a worker that answers from Cache Storage.
• Lines 6 to 8 print No worker: the photo at 776 ms, A worker that passes requests on: 804 ms and A worker that answers from its cache: 108 ms.

So the answer is both. The worker that answered from its cache showed the photo about 7 times sooner. The worker that only passed requests on gained nothing, and lost a little. Why it matters: a worker isn't fast or slow by itself. What it does with each request decides.

How the course recorded it

• Asha's phone, as in lesson 24.2: Chrome 157 on a phone's screen, with the page's CPU 4 times slower. The network has Slow 4G's round trip and speed, on lesson 16.3's link. That link slows every request the same way, the worker's own included.
• The page: the tea list, which the server takes 200 ms to build. Its stylesheet, script and photo are cached for a year (lesson 15.1).
• Three visits each time: a first visit, when the worker installs. Then a return visit with the worker stopped, which this lesson calls asleep. Then one with it still running: awake. Before each return visit, the tab and its connection were closed, as when Asha comes back later.
• Meera adds a tea. After Asha's first visit, lemon verbena joins the list. So a fresh page has 9 teas, and an old copy has 8.

Service workers & offline apps in the JavaScript course builds a worker and explains its life, from install to activate. The system design lesson Service worker caching plans one for a whole app. This lesson measures what one does to speed. It answers five questions:

• What does waking a worker cost? Worker startup.
• Can the network start while it wakes? Navigation preload.
• Which answers should come from the cache? Caching strategies.
• Can some requests skip the worker? The static routing API.
• How do you know it helped? Measuring repeat visits.

What waking a worker costs

A worker doesn't run all the time. The spec lets the browser stop it whenever it has no event to handle. The next request has to start it again. Until it's running, it can't take the request.

Every visit has a navigation entry: the list of times the browser writes down as the page loads. It keeps two times for this. Lesson 5.1 met the first one:

• workerStart is when the browser handed the request to the worker. If the worker was asleep, that's when it started waking it. It's 0 when no worker took the request.
• fetchStart comes next. In Chrome, with a worker, it's when the worker was ready to take the request.

So the gap between them is the time the request waited for the worker. Here are two of Asha's visits:

1// Two return visits with the pass-through worker, from the navigation entry, in ms.2const asleep = { workerStart: 2.6, fetchStart: 5.8 };3const awake = { workerStart: 1.2, fetchStart: 1.3 };4 5const wait = (visit) => (visit.fetchStart - visit.workerStart).toFixed(1);6console.log(`Worker asleep: the request waited ${wait(asleep)} ms`);7console.log(`Worker awake: ${wait(awake)} ms`);

• Lines 2 and 3 hold the two times from two visits with the pass-through worker: one asleep, one awake.
• Line 5 subtracts workerStart from fetchStart.
• Lines 6 and 7 print Worker asleep: the request waited 3.2 ms and Worker awake: 0.1 ms.

Three milliseconds is tiny. That's because the worker ran on a laptop's fast CPU. The recorder slowed the page's CPU 4 times, but DevTools' slowdown doesn't reach a worker. Chrome refuses it there. The course checked with the same loop. It took 485.2 ms on the slowed page, 121.9 ms in the worker, and 117.2 ms on the page without the slowdown.

On real phones it takes longer. web.dev says starting a worker usually takes "around 50ms. On mobile it's more like 250ms." On slow devices, it can take over 500 ms.

Chrome hid the wait, this time

Here's the pass-through worker. It hands every request straight back to the network:

self.addEventListener("fetch", (event) => {
  event.respondWith(fetch(event.request));
});

Line 1 listens for every request. Line 2 answers each one with respondWith(). The answer comes from fetch(): a normal request to the network.

With the worker asleep, you'd expect the page's request to leave late. It didn't. The server got it at 395.4 ms, the same moment as with no worker at all: 394.6 ms. Chrome had sent it while the worker was waking.

Chrome calls this auto preload. When a sleeping worker has to wake for a page, Chrome starts the page's request at the same time. Then the worker's fetch() gets that request's answer. Chrome does this only while the worker is asleep. The spec allows it, but doesn't ask browsers for it.

So did the pass-through worker cost nothing? Not quite. It gained nothing either. The photo came at 804 ms, against 776 ms with no worker. Every file still came from the browser's HTTP cache, only now through the worker. Why it matters: a worker that passes everything on is all cost and no gain. If a worker only does push messages, give it no fetch handler. Then the spec lets browsers skip it for every request, "to avoid unnecessary delays".

Pick a version, and compare a visit with the worker asleep to one with it awake:

Navigation preload: ask while the worker wakes

Auto preload is Chrome's own trick. The standard way to start the request early is navigation preload. It works in Chrome, Firefox and Safari.

A worker turns it on once, when it becomes the active worker:

self.addEventListener("activate", (event) => {
  event.waitUntil(self.registration.navigationPreload.enable());
});

Line 1 runs when the worker activates. Line 2 calls navigationPreload.enable(). From now on, the browser sends each page's request at once, while the worker wakes. It adds a header, so the server can tell: Service-Worker-Navigation-Preload: true.

The worker must then use that answer. Here is Ravi's network-first function for the page:

1async function networkFirst(event) {2  try {3    const response = (await event.preloadResponse) ?? (await fetch(event.request));4    event.waitUntil(keepCopy(event.request, response.clone()));5    return response;6  } catch {7    return caches.match(event.request);8  }9}

• Line 3 waits for event.preloadResponse: the answer to the request the browser already sent. If there's none, it fetches the page itself.
• Line 4 keeps a copy in Cache Storage, in the background, with keepCopy(), a small function of Ravi's. Line 5 gives the page to Asha.
• Lines 6 and 7 run only if the network fails. Then the stored copy answers instead.

With the worker asleep, the server got the request at 394.6 ms, with the header. The first byte reached Asha at 682.8 ms. The same worker without preload got 680.7 ms: Chrome's auto preload had already done the same job. Chrome picks navigation preload over auto preload when both could run.

Why it matters: in browsers without auto preload, the request would wait for the whole wake-up. On a phone, that's a quarter of a second on every visit with the worker asleep. Use navigation preload for pages that come from the network. Chrome's Workbox docs add one warning. A worker that answers pages from its cache doesn't need it: the preloaded answer goes to waste.

Try a slower wake-up on the recorded visits:

Preload switched on, but never used

One more worker turned preload on, but kept the old network-first function. That function calls fetch(event.request) and never reads event.preloadResponse. Here's what the server got:

1// Preload is on, but the worker fetches the page itself. Medians of 5 visits, in ms.2const requests = [3  { path: "/teas", at: 395.9, preload: true },4  { path: "/teas", at: 758, preload: false },5];6 7console.log(`The server built the tea list ${requests.length} times.`);8console.log(`The second request came ${(requests[1].at - requests[0].at).toFixed(1)} ms later.`);

• Lines 3 and 4 are the two requests for the tea list, with when each reached the server.
• Line 7 prints The server built the tea list 2 times.
• Line 8 prints The second request came 362.1 ms later.

The worker gave Asha the answer to its own request, the second one. Her first byte came at 1,043.1 ms. That's 360 ms later than with preload used. web.dev warns about exactly this: use fetch(event.request) instead of the preloaded answer, and every page is requested twice.

Caching strategies for speed

So far, every page came from the network, and its first byte took at least 677 ms. Only an answer from Cache Storage skips that trip. A caching strategy is the rule a worker follows for a request: the cache first, the network first, or both.

The JavaScript lesson listed these strategies. Here they meet Asha's phone. The page's three files have versions in their names, so the worker answers them cache first:

async function cacheFirst(request) {
  const cached = await caches.match(request);
  return cached ?? fetch(request);
}

Line 2 looks for a stored copy. Line 3 returns it, or fetches the file if there's none. Workbox's docs suggest this for static files, "especially hash-versioned ones". A new version gets a new name, so a stored copy is never wrong.

The page itself changes. Meera just added a tea. For the page, Ravi tried stale-while-revalidate: answer from the cache at once, and fetch a fresh copy for next time.

1async function staleWhileRevalidate(event) {2  const cached = await caches.match(event.request);3  const fresh = fetch(event.request).then(async (response) => {4    await keepCopy(event.request, response.clone());5    return response;6  });7  event.waitUntil(fresh);8  return cached ?? fresh;9}

• Line 2 looks for the stored page.
• Lines 3 to 6 start a fresh request. When it arrives, they store the copy, and return it.
• Line 7 keeps the worker running until that's done. waitUntil() asks the browser not to stop it yet.
• Line 8 answers with the stored page, or with the fresh one if nothing was stored.

With the worker asleep, the first byte came at 8.5 ms, and the photo at 108 ms. With it awake: 2.4 ms and 100 ms. Here is where the wake-up shows. An answer from the cache can't leave until the worker is running. No preload can hide that.

But Asha saw 8 teas, not 9. That's the price of stale-while-revalidate: it shows the copy from an earlier visit. The network-first worker showed all 9 teas, and was no faster than no worker: its photo came at 772 ms.

And there was a surprise. With the worker asleep, the refresh never reached the server. Not once in five visits. Chrome had started the page's request itself, with auto preload. So the worker's fetch() got that request. Chrome's notes say it may cancel that request once the worker has answered. The worker answered from its cache in 8.5 ms, long before the connection was open. So the old list stayed for one more visit.

Read each strategy across: where Asha's answer comes from, how fresh it is, and what it suits.

Why it matters: pick a strategy for each kind of request, not one for the whole site. web.dev suggests stale-while-revalidate for lists of products, and network first for prices and order status. And check that your refresh really reaches the server.

Static routes: skip the worker

Cache first still wakes the worker, just to look in a cache. The static routing API lets a worker write its rules down at install time. Then the browser follows them by itself, without running the worker's code.

Here is Ravi's last worker. Its install step adds two routes:

1self.addEventListener("install", (event) => {2  event.addRoutes?.([3    { condition: { urlPattern: "/assets/*" }, source: { cacheName: "assets" } },4    { condition: { requestMode: "navigate", runningStatus: "not-running" }, source: "network" },5  ]);6  event.waitUntil(precache());7});

• Line 2 calls event.addRoutes(). The ?. skips it in browsers that don't have it.
• Line 3 is the first route. Any file under /assets/ comes from the cache named assets. If it isn't there, it comes from the network.
• Line 4 is the second. A page request goes straight to the network, but only when the worker is "not-running". When it's awake, the worker's own code answers.
• Line 6 stores the files, as before.

Each route has a condition, which says which requests it matches, and a source, which says where the answer comes from. Conditions can test the address, the method, the mode, the destination and whether the worker is running. Sources can be the network, the cache, the worker's code, or a race between the network and the worker. The first route that matches wins.

Here is what Chrome reported for two of the visit's requests:

1// Two entries from Asha's visit with static routes, worker asleep.2const page = { workerStart: 0, workerMatchedSourceType: "network" };3const photo = { workerMatchedSourceType: "cache", deliveryType: "cache-storage" };4 5console.log(`The page: ${page.workerMatchedSourceType}, workerStart ${page.workerStart}`);6console.log(`The photo: ${photo.workerMatchedSourceType}, from ${photo.deliveryType}`);

• Line 2 is the page. workerMatchedSourceType says which route's source matched: the network. workerStart is 0, because the worker never took the request.
• Line 3 is the photo. It matched the cache route, and deliveryType says it came from Cache Storage.
• Lines 5 and 6 print The page: network, workerStart 0 and The photo: cache, from cache-storage.

The server got the page at 393.7 ms, as with no worker. The photo came at 768 ms. Chrome still woke the worker, in the background, so it was ready for the page's next requests. Its source code says this start is "not on the critical path".

Why it matters: routes keep the worker off the path of requests it would only pass on. That helps most where waking is slow. On the course's fast laptop, they saved little. But unlike auto preload, they're in the standard, and Safari has them too.

Measuring the gain on repeat visits

The recorder knew whether each worker was asleep. A visitor's navigation entry has no field that says so. So measure the parts that show it.

A few lines on the page can send what each visit saw:

1const [visit] = performance.getEntriesByType("navigation");2const report = {3  worker: visit.workerStart > 0,4  waited: visit.workerStart > 0 ? visit.fetchStart - visit.workerStart : 0,5  route: visit.workerMatchedSourceType ?? "",6  firstByte: visit.responseStart,7};8navigator.sendBeacon("/metrics", JSON.stringify(report));

• Line 1 reads the page's navigation entry.
• Line 3 notes whether a worker took the page at all. Line 4 is the wait for the worker, as in the first example.
• Line 5 keeps the route that matched, if any. Browsers without it give undefined, so ?? stores an empty string.
• Line 6 keeps the first byte. Line 8 sends the report with navigator.sendBeacon(), as lesson 24.2 did.

Group the reports by that wait. Visits that waited longer most likely woke the worker. Compare them with each other, and the quick ones with the quick ones. Add the photo time from your LCP reports.

Chrome has two more times for routes: workerRouterEvaluationStart, when it began checking them, and workerCacheLookupStart, when it began looking in the cache. Here is every version, side by side. Read each row across: the version, the wait with the worker asleep, the first byte, then the photo asleep and awake.

Only stale-while-revalidate made the photo come much sooner. Preload, never used, made it much later. Every other version stayed within 30 ms of no worker. Why it matters: measure the photo, not just the worker's wait. Then you'll see a gain only where the visitor saw one.

Here are the same fields for the page you're reading now:

Which route for each request?

Sort each request by how the shop's worker should answer it:

Common mix-ups

• "Any service worker makes return visits faster." No. The pass-through worker showed the photo at 804 ms, against 776 ms with no worker.
• "Waking a worker always takes hundreds of ms." No. It took about 3 ms on the course's laptop. web.dev puts it at about 250 ms on phones. Measure your own visitors.
• "Navigation preload is free to switch on." No. If the worker never reads event.preloadResponse, the server builds every page twice. Asha's page came 360 ms later.
• "Stale-while-revalidate always refreshes the copy." No. With the worker asleep, Chrome dropped the refresh, and the old list stayed for one more visit.
• "A static route switches the worker off." No. Chrome still woke it in the background. The route only stopped the page from waiting for it.
• "A workerStart of 0 means the worker was fast." No. It means no worker took the request: there was none, or a route sent the request around it.

Practice exercises

Answer each one first. Then open the hints if you need them.

// A made-up return visit on a slow phone, from its navigation entry, in ms.
const visit = { workerStart: 3, fetchStart: 253, responseStart: 931 };

console.log(`Waking took ${visit.fetchStart - visit.workerStart} ms.`);

function strategyFor(request) {
  if (request.mode === "navigate") return "stale-while-revalidate";
  if (request.destination === "image") return "cache first";
  return "network first";
}

console.log(strategyFor({ mode: "no-cors", destination: "image" }));

Check your understanding

For each question, ask two things: did the worker have to wake, and where did the answer come from?

Key takeaways

• A worker makes a return visit faster only when it answers from Cache Storage.
• A stopped worker must wake before it can answer. fetchStart minus workerStart shows the wait.
• Navigation preload starts the page's request while the worker wakes. Always use its answer.
• Answer versioned files cache first. Pick each page's strategy by how fresh it must be.
• Static routes send requests to the cache or the network without running the worker's code.
• Compare asleep visits with asleep visits, and measure the photo, not only the worker.

Sources

The facts on this page come from these specs, docs and source code:

• Service Workers (editor's draft), W3C.
• PerformanceResourceTiming: workerStart property, MDN.
• performance_resource_timing.cc: with a worker, fetchStart is when it was ready (Chromium 157.0.8103.52), Chromium source.
• inspector_emulation_agent.cc: CPU throttling is only for pages, not workers (Chromium 157.0.8103.52), Chromium source.
• Speed up service worker with navigation preloads, web.dev.
• Optional browser optimization for Service Workers, Chrome Platform Status.
• content_features.cc: ServiceWorkerAutoPreload is on by default (Chromium 157.0.8103.52), Chromium source.
• service_worker_main_resource_loader.cc: navigation preload comes first, and auto preload only wakes a stopped worker (Chromium 157.0.8103.52), Chromium source.
• Explainer for ServiceWorkerAutoPreload, the Chrome loading team.
• Navigation preload for network-first HTML, Chrome for Developers.
• Strategies for service worker caching, Chrome for Developers.
• Service worker caching and HTTP caching, web.dev.
• Use the Service Worker Static Routing API to bypass the service worker for specific paths, Chrome for Developers.
• InstallEvent: addRoutes() method, MDN.
• service_worker_main_resource_loader.cc: a route to the network still starts the worker, off the critical path (Chromium 157.0.8103.52), Chromium source.
• Resource Timing, W3C.
• Timing information for ServiceWorker Static Routing API (Chromium 157.0.8103.52), Chromium docs.
• Browser compatibility data 8.1.8, MDN.

Coming next: How INP works. Asha's pages now load fast. Next, how fast they answer her taps.