The Case for Smaller HTML Payloads

Even for a modest website, repeating the same markup across every page becomes a maintenance problem quickly. A three-page site means three copies of the <head>, navigation, and footer, and most developers will reach for some form of templating to avoid that duplication. PHP includes, static site generators like Eleventy, or JavaScript frameworks all solve the problem by assembling pages from shared partials.

Single-page app frameworks go a step further: they ship static HTML initially, then "hydrate" into a client-side app so subsequent navigations never request a full document again. The motivation is partly speed — the browser fetches only the data needed to swap in new content instead of reloading an entire page.

A Service Worker Approach

Philip Walton proposes doing the same thing without any framework, using a service worker as the templating engine. In a traditional client-server setup, the server must send a complete HTML document for every request, even though most of that document is identical across pages. A service worker can instead request only the minimal content from the server — an HTML partial, Markdown, or JSON — and assemble a full HTML document on the client side.

Concretely, the service worker caches the site's shared header and footer markup. For each navigation, it fetches just the page-specific content and stitches everything together before the browser renders it. No PHP, no Eleventy, no React — just a native browser API doing the work that frameworks typically handle.

Walton's own site shows the payoff. Over a 30-day period, page loads served by a service worker had 47.6% smaller network payloads and a median First Contentful Paint that was 52.3% faster than loads without a service worker (416ms vs 851ms).

Implementation Trade-Offs

The approach is clever but not trivial to build. The trickiest part beyond configuring the service worker itself is getting the server to deliver content-only versions of pages — or maintaining two flat-file versions of everything. That overhead may be acceptable for developers who want the performance benefits of a SPA without adopting a full client-side framework.