The blog listing loads articles via fetch('posts.json').
Problem: the browser caches this file. When you publish a new article,
visitors keep seeing the old list until they manually clear their cache
— which they never do.
Why the browser caches the JSON
Without an explicit Cache-Control directive, Apache applies a heuristic:
it estimates a cache duration from the file's Last-Modified header.
In practice, browsers can keep the file cached for several hours,
or even several days depending on their own rules.
You could solve this server-side with an HTTP header:
<FilesMatch "posts\.json$">
Header set Cache-Control "no-cache, must-revalidate"
</FilesMatch>
But this requires mod_headers to be enabled on Apache — which isn't
guaranteed on shared hosting. And a systematic no-cache forces
a server round-trip on every page load, even when the file hasn't changed.
The solution: filemtime as a query param
The principle of query string cache-busting is simple: as long as the URL doesn't change, the browser serves from its cache. As soon as the URL changes, it refetches.
Inject the file's last-modified timestamp via PHP:
fetch('posts.json?v=<?php echo filemtime(__DIR__ . "/posts.json"); ?>')
filemtime() returns a Unix integer — the timestamp of the file's last modification
on disk. The result in the generated HTML:
fetch('posts.json?v=1740268800')
As soon as you modify posts.json (adding an article, fixing an excerpt),
the timestamp changes, the URL changes, the browser treats it as a new resource
and refetches. Between two publications, the URL is identical → the cache is used,
no unnecessary request.
Why this is better than no-cache
With Cache-Control: no-cache, the browser must query the server
on every visit to check whether the file has changed (conditional request with
If-Modified-Since). It's fast, but it's still a network round-trip.
With query string cache-busting, if the file hasn't changed since the last visit, the URL is exactly the same — the browser serves from its local cache, with no network request at all. It's more aggressive in the right way: you benefit from the cache when possible, bypass it only when necessary.
The same technique for CSS and JS assets
This is exactly the principle used by all modern bundlers (Vite, Webpack)
that generate filenames with hashes: main.a3f9c2.js.
Here there's no build, but filemtime() plays the same role
without any infrastructure:
<link rel="stylesheet" href="assets/css/styles.css?v=<?php echo filemtime(__DIR__ . '/assets/css/styles.css'); ?>">
<script src="assets/js/main.js?v=<?php echo filemtime(__DIR__ . '/assets/js/main.js'); ?>"></script>Browsers and CDNs ignore the query string for cache matching in some configurations, but for a standard Apache setup serving files directly, it works reliably across all modern browsers.
Limitation: intermediate proxies
Some proxies and CDNs (Cloudflare in aggressive mode, Varnish by default)
ignore the query string and serve the same cached version regardless of the ?v= value.
In that case, filename-based cache-busting (hash in the filename) is more robust.
For a portfolio served directly by Apache with no CDN, this isn't an issue.