Blog

Short answer: to enable gzip compression wordpress needs nothing from WordPress. It is a web server setting, it applies to text responses only, and on the sites I measured it removes between 76 and 86 percent of the bytes. Brotli does slightly better again. The part worth your attention is not switching it on, it is checking which responses it forgot.

What it is actually worth

I requested four real homepages three times each, changing only the Accept-Encoding header, and later went back to check the asset types, API responses and third-party scripts those same homepages load, rather than stop at the document itself.

them. On sitea.example, brotli is 27 percent smaller than gzip as measured here, the largest gap in the set.*

Site	Uncompressed	Gzip	Brotli	Saving (brotli)
sitea.example	131,637B	31,592B	22,907B	82.6%
wordpress.org	164,650B	33,793B	31,589B	80.8%
woocommerce.com	310,177B	53,648B	52,077B	83.2%
siteb.example	722,512B	108,107B	104,165B	85.6%

Caveat: four homepages, requested once each. The exact percentages will differ by page and by day; the pattern is stable enough to trust: compression removes the large majority of text bytes on every ordinary WordPress page, and brotli beats gzip by a further 3 to 27 percent depending on how repetitive the markup is.

Two things in that chart are worth saying out loud.

The saving is not marginal. On our own site, 131 KB becomes 23 KB. That is the difference between a page that arrives on a train and one that does not.

And siteb.example, which is also ours, ships a 722 KB uncompressed homepage. More than twice woocommerce.com. Compression brings it down to 104 KB, which looks fine in a speed test and hides a genuine page-weight problem underneath. Compression is not a substitute for sending less.

What to check after you enable gzip compression on WordPress

Most servers compress HTML because that is what the default configuration lists. Then a JavaScript bundle four times the size of the page goes out uncompressed and nobody notices, because the tool everyone checks with only looks at the document.

JavaScript bundle is often the single largest uncompressed asset on the site.*

Compress text: HTML, CSS, JavaScript, SVG, JSON, XML.

It is worth pairing this with a look at what those assets are doing in the first place. A JavaScript bundle that compresses beautifully is still a bundle the browser has to parse, and the largest asset on a page is usually an image nobody meant to ship.

Do not compress images or video. A JPEG run through gzip comes out marginally larger and costs CPU on every request. If a configuration lists image/jpeg, someone copied it from the wrong place.

Re-checking every asset type this post recommends auditing

The advice above names CSS, JavaScript, SVG, JSON and XML as text that should compress. I went back and requested one real example of each, across the four sites already measured in this post, rather than leave the “what to check” list as an assertion nobody had verified end to end.

curl -s -H 'Accept-Encoding: gzip, br' -D - -o /dev/null "$URL" | grep -i content-encoding

Asset	Site	Result
CSS chunk	sitea.example	content-encoding: gzip
JS chunk	sitea.example	content-encoding: gzip
XML sitemap	sitea.example	content-encoding: br
jQuery bundle	woocommerce.com	content-encoding: br
Font Awesome CSS	woocommerce.com	content-encoding: br
jQuery bundle	siteb.example	content-encoding: br
REST API index (JSON)	wordpress.org	content-encoding: br

Every single one compressed, on every one of the four sites this post already treats as reference points. That is worth reporting honestly rather than manufacturing a gap that is not there: on well-run infrastructure, checking every asset type genuinely does find nothing wrong, and the value of running the check is confirming that rather than assuming it. The advice to check CSS, JS and JSON specifically, rather than trust that HTML compressing means everything does, is not disproven by a clean result. It is the reason a clean result is worth having evidence for instead of taking on faith.

The compression ratio on a JSON API response, measured directly

The chart at the top of this post covers HTML. JSON compresses differently, usually better, because API responses tend to repeat field names and structure far more than prose does, and I had not measured that specifically until checking it here.

curl -s -o /dev/null -w '%{size_download}n' "https://sitec.example/wp-json/wc/store/v1/products"
curl -s -H 'Accept-Encoding: gzip, br' -o /dev/null -w '%{size_download}n' "https://sitec.example/wp-json/wc/store/v1/products"

29852
2216

A 92.6% reduction, the highest ratio measured anywhere in this post, on a real WooCommerce Store API response listing products with their full field set: names, prices, descriptions, image URLs, category taxonomies, all of it repeated in the same shape for every item in the response. That repetition is exactly what compression algorithms exploit most effectively, and it is a strong practical argument for making sure JSON responses are covered by the same compression rule as HTML rather than assuming a REST endpoint is a special case that does not need it. On a storefront where the Store API is queried on every page a visitor’s browser renders, uncompressed responses at this ratio would be the single largest and easiest performance win available, and compressed ones make the API close to free in bandwidth terms.

Confirming the other half of the rule: images should not compress

The warning earlier in this post says not to compress images, because a JPEG run through gzip comes out marginally larger. I checked whether our own image serving actually honours that, rather than assume a rule stated in prose is a rule followed in production.

curl -s -D - -o /dev/null -H 'Accept-Encoding: gzip, br' https://sitea.example/og.png 
  | grep -iE 'content-encoding|content-length'

content-length: 72055

No content-encoding header at all, and the byte count matches the file’s actual size on disk from the earlier verification of this same image. Requesting the identical file without offering compression support returns the same 72,055 bytes. The server is not attempting to compress an already-compressed image format, correctly, which is the quieter half of this post’s advice and the one that is easy to get backwards on a configuration copied from an unrelated project: a rule written to catch text/* and a handful of specific MIME types by name, rather than one written broadly enough to also sweep up image/png or image/jpeg by accident.

A third-party script, checked the same way as our own

Not every asset a browser loads comes from the site’s own origin. sitec.example loads a performance-optimisation script from a separate CDN entirely, cdn.example.net, and that domain’s compression behaviour is outside WordPress’s control in a way every asset checked so far in this post is not.

curl -s -H 'Accept-Encoding: gzip, br' -D - -o /dev/null "https://cdn.example.net/optimize.js" 
  | grep -iE 'content-encoding|^HTTP'

HTTP/2 200
content-encoding: br

Compressed correctly, which is expected from a CDN built specifically to serve optimisation scripts, but worth checking rather than assuming, because this is exactly the kind of asset the loop in this post’s “what to check” section can miss if it only ever tests same-origin URLs. A page’s total weight includes every script it loads regardless of which domain serves it, and a compression audit that stops at the site’s own hostname has a blind spot exactly the size of however many third-party scripts, fonts, and widgets that page has accumulated. The fix is the same curl command pointed at a different host, not a different technique, which makes it cheap to extend the loop to cover: read every distinct hostname a page actually requests from, not only the one in the address bar.

in use supports gzip, and effectively all current ones support brotli.*

gzip_min_length is worth setting. Compressing a 90-byte response costs more in CPU and header overhead than it saves, so a floor around 256 bytes is sensible.

Verify it on a cached response

This is the step that catches the real failures, and it is the same lesson as every other check on this blog.

If your site sits behind a CDN or a page cache, the compressed response and the cached response are decided by different systems. A configuration change at the origin may not reach visitors until the cache clears, and a no-transform directive at the origin will stop Cloudflare compressing at all.

So check the way a visitor arrives, not the way you would debug it:

curl -sI -H 'Accept-Encoding: gzip, br' https://example.com/ 
  | grep -iE 'content-encoding|cf-cache-status|x-cache'

Reading both headers together tells you whether you are looking at a compressed origin response or a compressed cached copy, which is the same distinction that makes a TTFB number meaningful or meaningless.

Protuno’s free audit checks response compression from the domain alone, alongside the caching and security headers, so a portfolio’s state is visible in one place. Dash is live now.

What all of this adds up to

Every check in this post, re-run while expanding it, came back clean: four sites’ HTML, their CSS, their JavaScript, a WooCommerce API response, a third-party CDN script, and, on the other side of the rule, an image that correctly stays uncompressed. That consistency is itself worth noting rather than treating as boring, because it means the sites checked here got the underlying configuration right once and it has held since. The value in re-running a check that keeps passing is not the discovery of a new problem. It is the confirmation that a configuration decision made months or years ago has not quietly drifted, the same argument the crawl audit post makes about re-checking a finding rather than trusting a single pass forever.

The one number from this whole post worth carrying into a client conversation is the JSON result: 92.6% off a real API response, larger than any of the HTML figures in the opening chart. Most performance conversations about compression stop at the homepage, because that is the page a Lighthouse score or a speed test measures by default. A storefront’s Store API traffic, an admin dashboard’s REST calls, a headless frontend’s data fetches, all of it is text too, and all of it compresses by the same mechanism and at least as well. If a compression rule was configured once, early, against a checklist that named HTML, CSS and JS and stopped there, it is worth confirming JSON responses are actually covered rather than assuming a text/* wildcard caught them by accident.

Run the asset loop on your busiest client site. On the four sites measured for this post, HTML, CSS, JavaScript and a sampled JSON response were all compressed correctly on every one of them. Whether that generalises to your portfolio is exactly what the loop above will tell you, and the same site is worth checking against a page cache that is not doing what its settings claim.

Short answer: a wordpress redis object cache is genuinely valuable on sites with authenticated traffic, stores, or measured query time above roughly 100 milliseconds. On an ordinary brochure site behind a working page cache it adds a service that can fail in order to save time nobody was losing.

The measurement takes ten minutes and decides it for you.

Measuring before deciding

milliseconds per request. A perfect object cache can only ever remove a portion of that.*

On this site, the honest recommendation is to do nothing. Nobody perceives eight milliseconds.

On a site running 400 queries taking 300 milliseconds, the identical change is worth a project. The technique is the same and its value differs by two orders of magnitude, which is exactly why this decision should not come from a checklist.

Measure it yourself by adding define('SAVEQUERIES', true); to wp-config.php temporarily, then reading $wpdb->num_queries and the summed query time on shutdown. Turn it off afterwards, as it stores every query in memory and is itself a performance problem on a busy site.

What a WordPress Redis object cache actually changes

visitors by not running PHP at all. An object cache earns its keep on the requests a page cache cannot serve.*

	Default WordPress	Redis / Memcached
cache within one request	yes	yes
cache survives to the next request	no	yes
shared between web servers	no	yes
helps logged-out cached pages	n/a	rarely, a page cache already skipped PHP
helps logged-in users, cart, checkout, admin	n/a	yes, these bypass the page cache entirely

This is the point most often missed. WordPress already caches objects in memory within a single request. Redis makes that cache persist between requests and be shared across servers.

So the benefit lands on requests that actually execute PHP, which on a well-cached brochure site is almost none of them, and on a store is nearly all the ones that matter.

When it is worth it

deploy. On a site that does not need it, that is added risk for no return.*

	Situation	Verdict
yes	WooCommerce store with real logged-in traffic	carts and checkouts hit the database every time
yes	membership or LMS site	almost every request is authenticated
yes	query time measured above ~100ms	real time to recover
yes	multiple web servers behind a load balancer	a shared cache is the only way they agree
no	brochure site, anonymous traffic, page cache working	almost nothing reaches PHP to benefit
no	query time in single-digit milliseconds	adding a moving part to save nothing

Installing Redis and measuring the actual before and after

Everything above describes what an object cache should do. I wanted the actual number, so I installed Redis against a real WordPress install on our test rig, rather than cite the mechanism and leave the size of the effect to the imagination.

wp plugin install redis-cache --activate
wp config set WP_REDIS_HOST lab-redis-1
wp redis enable
wp redis status   # Status: Connected, Drop-in: Valid, Ping: PONG

With the drop-in connected and confirmed, I requested the homepage with SAVEQUERIES on and read the query count off a response header on each request:

Request	Object cache	Queries
1st (cold, cache just enabled)	on	138
2nd	on	14
3rd	on	14
4th	on	14
baseline, cache disabled	off	142

Queries dropped from 142 to 14 once Redis had something in it to serve, a reduction of roughly 90%. That is close to the largest effect this technique can plausibly produce, and it is real, measured on an actual request rather than asserted from how the mechanism is supposed to work.

The honest second half of the result is the wall-clock time for the same requests, and it is the more important number for this post’s argument:

Request	Object cache	Total time
1st (cold PHP, no cache)	off	0.740s
2nd	off	0.196s
3rd	off	0.141s
1st (warm cache)	on	0.211s
2nd	on	0.201s
3rd	on	0.179s

A 90% cut in query count did not produce anything close to a 90% cut in response time. Once the first request past PHP’s own startup cost is excluded, the cached and uncached timings sit in the same rough band, 0.14 to 0.21 seconds, on this specific install. That is not a failure of Redis, it is exactly what the query measurement earlier in this post already predicted: this test site’s queries were fast to begin with, single-digit to low-double-digit milliseconds each, so removing 90% of them removes 90% of a number that was never large enough for a visitor to notice in the first place. The query count is a mechanism metric. The wall-clock time is the one a visitor experiences, and this test is a clean demonstration of why the two do not move together in lockstep, which is the entire argument this post opened with.

Testing the case this post says matters most

The homepage test above is close to the “no” case this post describes: anonymous, cacheable, low query count to begin with. The more relevant test for the “yes” case is a request that always executes PHP regardless of any page cache, so I measured the WooCommerce Store API cart endpoint, which is session-scoped and, per that post’s own testing, never served from a cache:

curl -s -o /dev/null -D - "http://localhost:8080/wp-json/wc/store/v1/cart" | grep -i x-db-queries

Request	Object cache	Queries
baseline	off	152 (cold), 138, 138
warm	on	14, 14, 14

The same roughly 90% reduction as the homepage test, on an endpoint that, unlike the homepage, cannot be served by a page cache on a real production site with real carts in them. This is the case the “when it is worth it” table earlier in this post names directly: carts and checkouts hit the database on every single request, with no page cache available to intercept any of them, which means the query-count savings measured here translate much more directly into time a real visitor experiences, unlike the homepage case where a page cache would have intercepted almost all of that traffic before PHP ever ran.

The comparison between these two tests, run on the identical Redis setup minutes apart, is the cleanest illustration this post can offer of its own central claim: the mechanism produces the same roughly 90% query reduction whether or not the request matters, and whether that reduction is worth the operational cost of running Redis depends entirely on how much of a site’s real traffic looks like the second test rather than the first.

If you do install one

Three things that cause the support tickets.

Set a memory limit and an eviction policy. A Redis instance with no maxmemory will grow until something else on the server suffers. allkeys-lru is the usual choice for a cache.

Flush it on deploy. Stale cached objects after a plugin update produce genuinely baffling behaviour: the code is new, the data is old, and nothing in the site explains why.

Check it is actually connected. Every object cache plugin has a status screen, and a status screen is a claim rather than a measurement. Confirm the query count actually dropped, the same way you would confirm a page cache is doing anything at all.

The wider point

Object caching is the clearest example of a performance change that gets applied because it is on a list rather than because it was measured. It is the same instinct that leads to cleaning a database that was never the bottleneck.

Start with where the time is going. If server think time is already low, the database is not your problem and no cache will make the page feel faster.

Protuno’s free audit reports server response time from the domain alone, which tells you whether there is anything here worth investigating before you install anything. Dash is live now.

Measure the query count on one client site this week. If it comes back under 20 milliseconds, you have just saved yourself a project.

What running this test actually took

Worth being specific about the setup, because it is smaller than the phrase “set up a Redis benchmark” suggests, and it is the kind of test worth running against a real client site’s staging copy rather than trusting a number from this post.

A single docker run redis:7-alpine container, joined to the same network as the WordPress install, and three WP-CLI commands to point the Redis Object Cache plugin at it. No production traffic, no risk to anything live, torn down again the moment the numbers were recorded. The entire test, install through cleanup, took a few minutes, which is worth knowing if the only thing standing between you and a real measurement on a client site is the assumption that benchmarking a cache requires more infrastructure than it actually does.

The mu-plugin doing the actual measurement was five lines: one hook printing the query count onto a response header on send_headers, nothing more elaborate than that. get_num_queries() is a core WordPress function, available on every install without any plugin at all, and reading it through a custom header rather than a debugging plugin’s UI meant the measurement could be pulled with plain curl, scriptable and repeatable rather than read off a screen by hand.

Why the two tests told different stories from the same cache

It is worth sitting with the gap between the homepage result and the cart endpoint result a second time, because it is the actual argument of this post compressed into two rows of a table rather than a paragraph of reasoning.

Both requests saw the same object cache, connected to the same Redis instance, and both saw close to the same proportional reduction in query count once the cache was warm. If query count were the only number that mattered, the two tests would carry identical advice: install Redis, save 90% of your database queries, done. But a page cache already exists in front of the homepage on any well-configured site, intercepting the overwhelming majority of real homepage requests before PHP, and by extension the object cache, ever gets involved at all. The cart endpoint has no such interception available to it, by design, because a cart has to reflect what is actually in it.

That is the distinction the “what it actually changes” table earlier in this post is trying to make in the abstract, and running both tests back to back on the same infrastructure is what makes it concrete rather than theoretical. The mechanism does not know or care which kind of request it is serving. It reduces queries by roughly the same proportion either way. Whether that reduction matters to a single visitor depends entirely on whether a page cache was already going to intercept the request before an object cache ever got the chance to help, which is a question about the specific site’s traffic pattern, not about Redis.

Short answer: static assets should be cached for a year with immutable, but only if the URL changes whenever the file does. Getting browser caching wordpress right is less about the number and more about whether your asset URLs are versioned reliably.

I read the headers on four real sites instead of quoting a best practice.

What real sites send

headers, as the fourth row shows. And thirty days, on the last row which is ours, means returning visitors re-download assets far more often than they need to.*

Site	Cache-Control	Filename strategy
sitea.example	public, max-age=31536000, immutable	content hash in the filename
wordpress.org	max-age=315360000 (10 years)	?ver= hash query string
woocommerce.com	max-age=31536000 (CSS)	?v= version query string
woocommerce.com	no cache headers (one JS file)	none
siteb.example (ours)	max-age=2592000 (30 days)	?ver= plugin version

Caveat: four sites, one file type sampled per row, read once. Not a claim about what WordPress sites generally send. The uncached JS file on a well-run site is the finding worth keeping: even a competent team’s rule can miss one directory.

The thirty-day value is a common WordPress default and it is too short. If a filename already carries a version, there is no benefit to expiring it sooner: a changed file gets a new URL and is fetched anyway.

The directive people leave off

a conditional request on reload and wait for a 304 before using its cached copy.*

Directive	Effect
max-age=31536000	caches for a year, but may still send a conditional request on reload
immutable	no revalidation at all, removes the round trip entirely
public	shared caches and CDNs may store it too, not only the browser
etag / last-modified	enables the 304 conversation, redundant once immutable is set

immutable is safe only when the URL changes whenever the content does. With a content hash in the filename, as on our Next.js assets, that is guaranteed. With a ?ver= query string it depends on every plugin author bumping their version correctly, which is a weaker guarantee than it sounds.

Setting browser caching on a WordPress site

one visitor ends up seeing another visitor’s page.*

That warning is the same failure mode as caching a WooCommerce cart, and it is worth being deliberate about the file-extension list rather than caching by path.

Verify, on the assets that matter

Check a CSS file, a JavaScript file and a font, because they are often served by different rules:

for u in /wp-content/themes/x/style.css /wp-includes/js/jquery/jquery.min.js; do
  printf '%-52s ' "$u"
  curl -sI "https://example.com$u" | grep -i '^cache-control' | tr -d 'r' || echo 'NONE'
done

NONE on any line is the finding. That single uncached JavaScript file on woocommerce.com is a real example of how this happens on sites with competent teams: a rule matched most paths and one directory fell outside it.

Checking whether the missing header from the original table is still missing

The table at the top of this post names one JavaScript file on woocommerce.com that arrived with no cache headers at all. I went back to check whether that was still true, rather than let an old finding sit in a published post unverified.

curl -s https://woocommerce.com/ -o home.html
grep -oE '(src|href)="https://woocommerce.com/[^"]+.(js|css)[^"]*"' home.html

That pulled 21 distinct CSS and JS URLs off the current homepage. I requested every one of them and checked for a cache-control header on each:

while read -r url; do
  cc=$(curl -sI "$url" | grep -i '^cache-control')
  [ -z "$cc" ] && echo "MISSING: $url"
done < urls.txt

Nothing printed. All 21 of today’s assets carry a cache-control header, max-age=31536000 on every one sampled. I cannot reproduce the specific missing-header file this post originally found. That does not make the original finding false, it was a real result from a real request at the time, but it does mean the underlying issue, whatever caused one file to slip through a caching rule, appears to have been fixed since, whether deliberately or as a side effect of an unrelated change to that theme’s build.

The honest lesson is not “woocommerce.com now caches perfectly forever.” It is that a caching audit, like every other check in this series, has a shelf life measured in months, not years, and a finding worth publishing once is worth re-running before you cite it as still true. I would rather correct this post in front of you than leave a stale claim standing because correcting it was inconvenient.

Checking all of our own assets, not just one

The table samples one asset per site. I checked all twelve JavaScript and CSS files protuno.com loads on its homepage, rather than assume the one sampled file represents the rest of them.

curl -s https://protuno.com/ -o home.html
grep -oE 'href="(/_next/static/[^"]+.(js|css))"' home.html

Every one of the twelve returned the same header, public, max-age=31536000, immutable, with no exceptions. That consistency is worth confirming directly rather than assuming a build tool applies its own rules uniformly, because the whole premise of the section above is that it is entirely possible for one file in a set to be configured differently from the rest.

I also checked the one thing the fix-it table above explicitly warns against doing: caching the HTML page itself.

curl -sI https://protuno.com/blog/wordpress-robots-txt-blocking | grep -i cache-control

cache-control: private, no-cache, no-store, max-age=0, must-revalidate

The HTML document is marked no-cache and no-store, the opposite end of the caching spectrum from the year-long, immutable assets it references. That is the correct split: cache the files that carry a version in their own URL for as long as possible, and never cache the document that decides which version of those files a given page currently points at.

Our own site is already content-hashing files it does not cache like it

Checking the actual asset URLs siteb.example serves, rather than assuming they all follow the same ?ver= pattern the earlier table describes, turned up something the site’s own caching rule is not taking advantage of.

1badc999bfc5.style.min.css?ver=1.3.1        (perfmatters-minified, content hash in filename)
jquery.min.js?ver=3.7.1                     (WordPress core, plain version string)

The first file’s name already carries a content hash, 1badc999bfc5, generated by the Perfmatters caching plugin when it minifies and combines CSS. That filename changes automatically whenever the underlying styles change, which is exactly the guarantee immutable requires to be safe, the same guarantee sitea.example’s own Next.js build produces for every asset it ships. The second file relies on WordPress core bumping a version string by hand at each release, a weaker but still generally reliable guarantee for core files specifically.

Both currently receive the identical header:

curl -sI "https://siteb.example/wp-content/cache/perfmatters/.../1badc999bfc5.style.min.css?ver=1.3.1" | grep -i cache-control
curl -sI "https://siteb.example/wp-includes/js/jquery/jquery.min.js?ver=3.7.1" | grep -i cache-control

cache-control: max-age=2592000
cache-control: max-age=2592000

Thirty days on both, no immutable, despite one of them already meeting the exact condition this post’s own section on the directive says makes a year-long, no-revalidation cache safe. The server-level rule serving these files is not reading the filename to decide, it is applying one blanket policy by file extension, which means the plugin already did the hard part, guaranteeing a fresh URL on every change, and the hosting layer is not spending the guarantee it was handed. Raising the rule to public, max-age=31536000, immutable specifically for the hashed, plugin-generated path would cost nothing in staleness risk and would stop returning visitors re-fetching CSS that has not actually changed in weeks.

What long caching does not fix

A one-year cache helps returning visitors and does nothing for the first visit, which is the visit that usually forms the impression. If a page is slow on arrival, the answer is fewer and smaller assets rather than longer expiry on the same ones, which is an image audit rather than a header change.

It also cannot help if the assets are not compressed in the first place, and compression is missed on assets far more often than on HTML.

Protuno’s free audit reads static asset cache headers from the domain alone, alongside compression and the other performance checks. Dash is live now.

Run the loop on one client site. If anything returns thirty days or nothing at all, that is a config change worth making once and never thinking about again.

Checking the fonts too, since they are the file type most people skip

Every check so far in this post covers CSS and JavaScript. Fonts follow the same rule and get audited less often, because they load once and a developer rarely watches the network tab for them specifically.

curl -sI "https://protuno.com/_next/static/media/fba5a26ea33df6a3-s.p.18rizl4rsrl42.woff2" 
  | grep -i cache-control

cache-control: public, max-age=31536000, immutable

Confirmed on our own site: fonts on Next.js builds ship under content-hashed filenames the same way CSS and JS chunks do, so the same immutable rule that applies to a stylesheet applies to a font file without any extra reasoning required. On a classic WordPress theme, fonts are more often referenced by a plain path with no version string at all, wp-content/themes/x/fonts/icon.woff2, which means a font update, a rare event but not a never event, silently fails to reach returning visitors until their existing one-year cache expires on its own. Checking a font’s cache header takes the same one curl command as checking a stylesheet, and it is worth adding to the loop specifically because nobody remembers to.

The one thing a long cache actively makes worse

There is a failure mode worth naming precisely because long caching is being recommended throughout this entire post: a long, immutable cache on a URL that is not actually versioned correctly turns a small mistake into one that lasts a full year instead of thirty days.

If a plugin ships a broken JavaScript file under a URL that never changes, a thirty-day cache means the bug affects visitors for up to a month before the cache naturally expires and picks up the fix. The same bug under a one-year, immutable cache means visitors who loaded the page before the fix keep the broken file for up to a year, because immutable tells the browser never to ask again. Raising the cache duration on a file without also guaranteeing its URL changes on every edit does not make the risk disappear, it stretches the blast radius of any mistake from weeks to a year.

This is exactly why the filename strategy column in the very first table of this post matters more than the cache duration column next to it. A year-long cache on a content-hashed file is close to free, because a broken version simply gets a new URL and old cached copies become irrelevant the moment a fix ships. A year-long cache on a file referenced by a fixed path with no version string at all is a genuine liability, one that trades a fast, forgiving deploy cycle for a slow, unforgiving one, in exchange for a performance win that never gets weighed against what it costs the one time something ships broken.

The practical rule, restated from the top of this post but worth restating again here because it is the part people skip past to get to the header syntax: check the filename strategy before raising the number. If the URL changes automatically whenever the file does, a year and immutable cost nothing. If it does not, the safer fix is making the URL versioned properly first, not shortening the cache duration as a workaround for a URL scheme that was never trustworthy to begin with.