A Bunker for a Village Hall: Picking a Cache Strategy for a Small UK Charity on Shared Hosting

Picture the scene. A small UK charity runs its site on a shared hosting plan that costs less than a round of coffees. The Christmas appeal banner goes live on a Friday. By Monday, the comms lead is emailing because half the visitors are still seeing last year's appeal, complete with a donation link that now points at a closed campaign page. The first instinct is to reach for a service worker. It sounds modern, it sounds robust, and it promises to control every request. But a service worker is not a sticky plaster. It is a second deployment target that lives in the browser, and on a shared host with limited tooling it can cause more trouble than it solves.

Two problems wearing one coat

Caching conversations often blur two separate jobs. The first is keeping static assets — CSS, JavaScript, fonts, logos — from being downloaded again on every page view. The second is making sure the HTML and the content inside it are fresh. A charity site usually needs the first and absolutely must have the second. A stale stylesheet is annoying. A stale donation page is a problem.

On shared hosting you often cannot purge a CDN, set granular server rules, or watch detailed cache logs. You can upload files, maybe edit .htaccess, and hope the host's own caching layer behaves. That constraint should shape the decision. You want the smallest mechanism that gives reliable freshness with the least chance of a silent failure.

What a service worker actually buys you

A service worker can give a site offline access, resilience on flaky mobile connections, and fine control over which requests hit the network. For a UK charity whose supporters might be signing up at a village fete with one bar of signal, that sounds appealing. It is also a real commitment.

The worker has a scope, a lifecycle, and an update path. A new version does not simply replace the old one while the user is mid-session. If you cache HTML aggressively, a visitor can be served an old appeal page long after the campaign has changed. If you use skipWaiting and clientsClaim without thinking, you can end up with a page from one deploy loading assets from another. The donation button might work, but the surrounding page could be a Frankenstein mix of old and new.

There is also the third-party problem. Many UK charities send donations through a hosted provider, often in an iframe or a separate domain. A service worker on your origin will not magically fix a stale wrapper around that iframe. The supporter still sees the old appeal copy and the old call to action, even if the payment page itself is current.

If you do run a service worker, make the HTML network-first or network-only for campaign pages. Cache only static assets with versioned names. Never cache donation, thank-you, or direct-debit pages. Keep a cache version in the cache name, delete old caches on activation, and test the update path from the previous deploy, not just a fresh install. That is the minimum, and it already assumes someone on the team can debug JavaScript when it goes wrong.

The lightweight loader most charities actually need

For a small charity site on shared hosting, a versioned asset loader is usually the better fit. The idea is simple: keep the HTML fresh, and make every static file name or query string change when the file changes. A stylesheet becomes appeal.css?v=20261111-1 or appeal.20261111-1.css. A small loader injects the current versions, and the browser treats each new version as a new file.

This approach does not require a service worker, a build pipeline, or access to server internals. It does require discipline. The version needs to be bumped when the file changes, and the loader configuration needs to be part of the release checklist. If the appeal banner content lives in the HTML, a normal page refresh will pick it up as long as the host is not caching HTML for hours. If the banner is driven by a JSON file, version that file too.

The hosting side matters. Where .htaccess is allowed, you can set long cache lifetimes for versioned assets and a short or no-cache policy for HTML. Where it is not, keep the HTML content self-contained and avoid relying on a stale JavaScript file to render campaign copy. A charity's appeal banner should not depend on a cached JSON fetch that nobody remembered to bust.

A rough decision guide

Ask a few blunt questions. Does the site genuinely need to open offline? If yes, a service worker may be worth it. Does it only need faster repeat visits and cleaner asset caching? Then a versioned loader is enough. Does the team have someone who can debug a worker update at 9pm before a national appeal day? If not, do not add one.

A service worker is also a poor fit when the main risk is content freshness. If the site changes frequently and the hosting layer is opaque, network-first HTML is safer than any clever cache-first strategy. A lightweight loader with versioned assets keeps the blast radius small. If an asset is wrong, you bump the version. If an appeal page is wrong, you fix the HTML and the next request sees it.

The rushed-update playbook

Before a campaign, test the update from the old version, not just the new one. Open the site, let it cache, deploy the change, and then reload like a normal supporter would. Check the appeal banner, the donation link, and any thank-you page. Keep donation URLs absolute and outside the cache. Put a short note in the release checklist for version bumps. If you use a service worker, add a kill switch — a simple way to unregister it or serve a worker that clears caches — before you need one in a panic.

The unglamorous answer is usually the right one for a UK charity on shared hosting. Use a lightweight loader with versioned assets, keep campaign HTML fresh, and treat a service worker as a specialist tool for genuine offline needs. A bunker is useful when the weather is genuinely bad. For a village hall website, a sturdy door and a clear noticeboard will do.