Make Your Site Load Instantly on Every Return Visit

The first visit to your website is constrained by network speed. There is nothing you can do about that — the browser has to download HTML, CSS, JavaScript, images, and fonts from your server. But the second visit? The third? Every return visit after the first?

Those can be instant. Not "fast." Instant. Zero network latency. Page loads measured in milliseconds instead of seconds.

The technology that makes this possible is service worker precaching — and despite being available in every modern browser since 2019, fewer than 5% of websites use it effectively.

I implemented service worker precaching across all 52 sites in our network. Return visit load times dropped to under 100 milliseconds on every site. The implementation took a single afternoon, and the user experience improvement has been measurable in engagement metrics ever since.

What Service Worker Precaching Does

A service worker is a JavaScript file that runs in the background of a browser, separate from the web page. It can intercept network requests, cache responses, and serve cached content without touching the network.

Precaching is the strategy of proactively downloading and storing specific resources in the browser cache before the user requests them. When the user navigates to a precached page, the service worker serves it from the local cache instantly — no network round trip required.

The difference from standard browser caching is control and reliability. Browser caching is heuristic — the browser decides what to cache and when to evict it. Service worker precaching is explicit — you declare exactly what resources to cache, and they stay cached until you explicitly update them.

Why Instant Return Visits Matter

Google's Core Web Vitals research shows that every 100ms of additional load time reduces conversion rates by up to 7%. For content sites, load time directly impacts bounce rate and pages per session.

But the performance argument is only half the story. Instant loading changes user behavior in ways that slow loading does not:

Perceived reliability. When a site loads instantly, users perceive it as more stable and trustworthy. This is irrational but well-documented in UX research — load time affects trust perception.

Increased page views. When navigation is instant, users explore more pages. In our network, pages per session increased by approximately 25% after implementing precaching. Users who would have read one article and left instead clicked through to two or three.

Offline capability. Precached pages work even when the user has no network connection. This is valuable for mobile users who may be on spotty connections — subway commutes, rural areas, airplane mode. Instead of seeing a "No Internet" error, they see your content.

SEO signals. Google measures page experience signals including Largest Contentful Paint (LCP) and Interaction to Next Paint (INP). Precached pages score perfectly on both metrics for return visitors, which contributes to overall page experience scores.

Implementing Precaching With Workbox

Workbox is Google's open-source library for service worker management. It simplifies precaching implementation from a complex manual process to a few lines of configuration.

Step 1: Install Workbox

For Node.js-based build systems (which covers most static site generators including Eleventy, Next.js, and Hugo), install the Workbox CLI:

npm install workbox-cli --save-dev

Step 2: Configure the Precache Manifest

Create a workbox-config.js file that specifies which files to precache:

module.exports = {
  globDirectory: '_site/',
  globPatterns: [
    '**/*.html',
    '**/*.css',
    '**/*.js',
    'images/**/*.{webp,avif,png,jpg,svg}'
  ],
  swDest: '_site/sw.js',
  swSrc: 'src/sw-template.js'
};

The globPatterns array determines what gets precached. Be strategic here — precaching your entire site is possible but potentially wasteful. Focus on:

• All HTML pages (for instant navigation)
• CSS and JavaScript files (for instant rendering)
• Critical images (hero images, logos, icons)
• Fonts (for consistent typography without flash of unstyled text)

Step 3: Create the Service Worker Template

import { precacheAndRoute } from 'workbox-precaching';
import { registerRoute } from 'workbox-routing';
import { StaleWhileRevalidate } from 'workbox-strategies';

// Precache all specified resources
precacheAndRoute(self.__WB_MANIFEST);

// Runtime caching for resources not in the precache manifest
registerRoute(
  ({ request }) => request.destination === 'image',
  new StaleWhileRevalidate({ cacheName: 'runtime-images' })
);

The precacheAndRoute function handles the precache manifest automatically. The StaleWhileRevalidate strategy for images means the service worker serves cached images immediately while checking for updates in the background.

Step 4: Register the Service Worker

Add registration code to your site's main JavaScript file or inline it in your HTML:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}

Step 5: Integrate With Your Build Process

Add a build step that generates the precache manifest after your static site build:

eleventy && workbox generateSW workbox-config.js

This generates a service worker file with a versioned manifest of all matched files. When you deploy an update, Workbox automatically detects changed files and updates the cache.

Strategic Precaching Decisions

What to Precache

Not everything should be precached. Precaching large resources wastes the user's bandwidth on content they may never view. The strategy is to precache resources that:

• Are likely to be requested on the next navigation (all HTML pages on a small site, or the top 10-20 pages on a larger site)
• Are shared across pages (CSS, JavaScript, fonts, navigation images)
• Are small enough that precaching does not significantly impact the initial page load

For our network, each site has 15-40 pages. Precaching all HTML pages and shared assets totals approximately 2-5 MB per site — well within acceptable limits for a first visit on even a 3G connection.

What Not to Precache

• Large media files (videos, high-resolution gallery images)
• Third-party scripts (analytics, ads) — these should not be cached as they need to run live
• API responses with rapidly changing data
• Resources larger than 5 MB individually

Cache Versioning

Workbox handles cache versioning automatically by hashing file contents. When a file changes, the hash changes, and Workbox updates the cached version on the next visit. Unchanged files are not re-downloaded.

This means deployments do not invalidate the entire cache — only changed files are updated, minimizing bandwidth usage.

Measuring the Impact

Use Lighthouse or WebPageTest to measure performance before and after implementation. Key metrics:

• Time to First Byte (TTFB): For cached pages, this drops to near zero
• Largest Contentful Paint (LCP): Should be under 500ms for cached pages
• Cumulative Layout Shift (CLS): Precached fonts eliminate FOIT/FOUT, reducing layout shift

In our network, return visit LCP improved from an average of 1.2 seconds to under 100 milliseconds across all sites. First visit performance was unchanged (the service worker installs in the background without blocking the page load).

Google Search Console's Core Web Vitals report showed all sites achieving "Good" status for all metrics within two weeks of deployment.

The Engagement Impact

The performance improvement translated directly to engagement metrics:

• Bounce rate decreased by approximately 15% on return visits
• Pages per session increased by approximately 25% — instant navigation encouraged exploration
• Average session duration increased by approximately 20% — users who explored more pages spent more time
• Return visit rate increased — users who experienced instant loading were more likely to come back

These are not hypothetical projections. They are measured changes from our analytics across the 52-site network over the 60 days following precaching implementation.

Implementation Across Static Sites

For static sites built with Eleventy (which our entire network uses), the implementation is particularly clean because all HTML is generated at build time. The Workbox precache manifest can include every generated HTML page, ensuring that the entire site is available offline after a single visit.

The total implementation time for a new site is approximately 45 minutes: 15 minutes for Workbox setup, 15 minutes for configuration, and 15 minutes for testing. For our 52-site network, the shared build configuration meant implementing once and deploying everywhere — about 3 hours total including testing.

Service worker precaching is one of the highest-ROI performance optimizations available. It costs nothing, requires no infrastructure changes, and delivers instant loading for every return visitor.

For the complete performance optimization playbook across all platforms, see The W-2 Trap and the technical implementation guide in The $100 Dollar Network.