Low Cacheability, and the Return Visit You Are Paying For

Roughly two thirds of the static files on our own site carry caching headers. The rest do not, and that gap is what the report measures when it flags low static-asset cacheability.

Nothing about it looks urgent. The page loads, the files arrive, and nobody sees a problem. The cost lands on the visitor who comes back tomorrow and downloads the same stylesheet all over again.

What the browser keeps

A caching header tells the browser how long it may keep a file without asking for it again. The file is stored locally, and the next page that needs it reads from disk instead of the network.

That only helps a visitor who comes back. On a first visit there is nothing stored yet, so every file downloads no matter what the headers say.

The check counts the share of static files carrying a usable caching header and flags the page below 70 percent. Our own site measures 65.2, which is how it ends up on the list at all.

The report shows that same figure twice. The finding states it as the share of static assets with caching headers, and the metric strip at the top of the run labels it the cache hit ratio.

Cacheability is the biggest term in a score you cannot see

Caching and delivery is a pillar the report calculates but never draws. There is no gauge for it, and it carries 20 percent of the overall score.

Inside that pillar, cacheability is the largest single term. It is worth 65 points of the pillar’s 100, against 25 for Brotli, 18 for gzip and 10 for the document policy.

Our own site shows the size of it. At 65.2 percent cacheable its caching and delivery score is 67. Take that share to full and the pillar reaches 90, which lifts the overall score from 90 to 94.

Every ten points of cacheability is worth about 1.3 points on the overall score, which makes it a larger lever than either compression setting beside it.

The file that must not be cached for long

One mistake turns this fix into a worse problem. Setting a long lifetime on the HTML document means a returning visitor keeps reading the old version after you have changed the page.

The two policies are separate for that reason. An asset whose address changes when its contents change can be cached for a year and marked immutable. The HTML that points at it should not be.

Changing the address is what cache busting means, and the usual form is a fingerprint baked into the filename, so a new build produces a new address on its own.

A CMS usually handles that split already, as long as the asset address really does change when the file does. The problem appears when a blanket caching rule gets applied to everything at the server or the CDN.

Who actually benefits

This is an optimisation for repeat visitors, and that shapes whether it is worth your afternoon. Anyone arriving for the first time downloads the full page whatever your headers say.

A site people come back to gains the most. A blog with regular readers, a store people browse across several visits, an application somebody opens every morning.

A single visit landing page gains far less, because there is no second visit to make cheaper. Same finding, very different return, and the report cannot tell you which kind of site you run.

Reading the Cache-Control line

Open the page in a browser and look at a static file request in the developer tools. A Cache-Control header with a long max-age and the immutable flag is what good looks like on an asset.

Long means a year in practice, written as max-age=31536000, usually with public beside it so shared caches such as a CDN can hold the file too. The immutable flag adds that the browser should not check back even on a refresh.

Run another test and the finding clears once the share passes 70 percent. Our global analytics page puts the average across the sites we test at 40 percent, so it is a gap most sites share.

Most WordPress owners will not touch a header directly. Managed hosts and caching plugins set these values for the static files they serve, and the file worth checking in their settings is the one for browser caching rather than the page cache.

If the way those pillar scores add up is unfamiliar, the report-reading walkthrough takes the report apart section by section.