DEV Community: nocache.dev

Laravel responses are uncacheable by default. Here's why and how to fix it

nocache.dev — Tue, 10 Nov 2026 13:16:14 +0000

Put a CDN in front of a fresh Laravel app and the hit rate for HTML will be zero. Nothing is broken. The framework is being careful on purpose, in two separate places, and both have to be dealt with before any shared cache will help.

I read the current framework source and ran live header checks on two well-known Laravel sites today. First, where the defaults come from.

The header comes from Symfony

Laravel's Response extends Symfony's, and Symfony's ResponseHeaderBag fills in Cache-Control whenever you haven't set one. From computeCacheControlValue():

if (!$this->cacheControl) {
    if ($this->has('Last-Modified') || $this->has('Expires')) {
        return 'private, must-revalidate';
    }

    // conservative by default
    return 'no-cache, private';
}

So a plain return view('home') leaves with Cache-Control: no-cache, private. private keeps it out of every shared cache, and no-cache makes the browser revalidate before reuse. If you set directives but neither public nor private, Symfony appends private unless s-maxage is present. That's a sensible default for a framework that can't know whether a page is personal. It just means caching is opt-in, route by route.

The cookie comes from the `web` group

Every route in routes/web.php runs inside the web middleware group. In Laravel 12 and 13 that's EncryptCookies, AddQueuedCookiesToResponse, StartSession, ShareErrorsFromSession, the CSRF middleware (ValidateCsrfToken in 12, PreventRequestForgery in 13) and SubstituteBindings.

Two of those set cookies on every response, including anonymous GETs:

StartSession adds the session cookie. Its name comes from APP_NAME: laravel_session in the 10.x and 11.x skeletons, laravel-session in the current 12.x and 13.x ones.
The CSRF middleware adds XSRF-TOKEN, which the docs describe as "a developer convenience" for Axios and Angular.

A Set-Cookie header doesn't stop caching by itself. RFC 9111 says it plainly: a cacheable response with Set-Cookie "can be (and often is) used to satisfy subsequent requests". That's the dangerous direction: a cache that stores the response hands one visitor's session cookie to everyone else. Most CDNs are cautious instead. Cloudflare's default behaviour page says it does not cache a resource when "the Set-Cookie header exists". Either way, a page that sets a session cookie is a page no CDN should share.

The built-in fix: `cache.headers`

Laravel ships a cache.headers middleware (SetCacheHeaders). Directives are snake case and separated by semicolons:

Route::middleware('cache.headers:public;max_age=0;s_maxage=600;etag')
    ->group(function () {
        Route::get('/pricing', PricingController::class);
    });

The options go straight to Symfony's Response::setCache(), so s_maxage, stale_while_revalidate, stale_if_error, immutable and last_modified all work. etag hashes the body with xxh128, and the middleware then calls isNotModified(), so a matching If-None-Match gets a 304 with no body.

It has limits worth knowing:

It only touches GET and HEAD, successful responses, and responses with a body. Errors keep the default header.
In Laravel 12 and earlier it skips HEAD requests. By the time route middleware sees the response, Symfony's prepare() has emptied the body for HEAD, and the empty-body check returns early. The 13.x source adds an explicit HEAD exception. On older versions, curl -I can show you no-cache, private while real GETs get your header.
It never looks at cookies. And it couldn't see the session cookie anyway: group middleware wraps route middleware, so StartSession attaches its cookie on the way out, after cache.headers has already set public. Inside the web group you get public, s-maxage=600 and a session cookie on the same response.

Live check 1: laravel.com

The header check, trimmed to the relevant headers:

cache-control: public, s-maxage=86400, stale-while-revalidate=300
cf-cache-status: DYNAMIC
laravel-cloud-cache: DYNAMIC
x-powered-by: Statamic
set-cookie: XSRF-TOKEN=…; expires=Tue, 03 Nov 2026 15:12:02 GMT; Max-Age=7200; path=/; secure; samesite=lax
set-cookie: laravelcom_session=…; expires=Tue, 03 Nov 2026 15:12:02 GMT; Max-Age=7200; path=/; secure; httponly; samesite=lax

There was also a third encrypted cookie with a random 40-character name, plus Cloudflare's __cf_bm. Two curl -sI requests right after gave the same cache-control, cf-cache-status: DYNAMIC and laravel-cloud-cache: DYNAMIC, with fresh values in all the cookies each time.

This is limit 3 in the wild. Someone opted the homepage into a one-day shared cache (s-maxage=86400), and the web group still attached XSRF-TOKEN and a session cookie named after the app (laravelcom_session, the slug of "laravel.com" plus _session). Both cache layers answered DYNAMIC, which Cloudflare's docs define as "not eligible for cache at request time": HTML isn't cached by default and no rule opts this page in. Given the cookies, that's the safe outcome. But the s-maxage buys nothing, and every request goes to the origin. The check graded it D, mostly for the Set-Cookie on a publicly cacheable response, plus no ETag or Last-Modified.

One more detail: Cloudflare's docs say s-maxage implies proxy-revalidate, which disables stale-while-revalidate there. If you sit behind Cloudflare, don't count on that combination. Put the stale window in a CDN-Cache-Control header instead (for example max-age=600, stale-while-revalidate=60): Cloudflare uses it in place of Cache-Control for its own caching decisions.

Live check 2: laravel-news.com

The header check (a GET):

cache-control: max-age=600, public, s-maxage=86400
last-modified: Tue, 03 Nov 2026 08:12:04 GMT
cf-cache-status: BYPASS
laravel-cloud-cache: DYNAMIC
set-cookie: __cf_bm=…; HttpOnly; SameSite=None; Secure; Path=/; Domain=laravel-news.com; Expires=Tue, 03 Nov 2026 13:42:04 GMT

This one did the cookie part right. No session cookie, no XSRF-TOKEN, only Cloudflare's bot cookie, so the homepage is served without a session. It got a C.

Then the two curl -sI requests disagreed with each other:

cache-control: max-age=600, public, s-maxage=86400
cf-cache-status: BYPASS

cache-control: no-cache, private
cf-cache-status: BYPASS

I sent six more HEAD requests and all six got no-cache, private. Four GETs all got max-age=600, public, s-maxage=86400. HEAD and GET are getting different policies. I can't see their code, but it's exactly what limit 2 produces, and it's a good reason not to trust curl -I alone on a Laravel site.

Two smaller things. last-modified was exactly five hours behind the Date header on every request and changed every second, so it works as a validator for nothing. And Cloudflare said BYPASS on every request. Its docs are specific about that status: the request was eligible (so a Cache Rule covers this HTML), but the origin response was not cacheable. Common reasons listed are private or no-store, a Set-Cookie from the origin, or a CDN-Cache-Control header. The GETs I saw carried public and only Cloudflare's own cookie, so whatever disqualifies them isn't visible from outside. It's still the most useful status to see: the edge wants to cache the page, and something at the origin is saying no.

The fix: a route group without a session

Public pages that look the same for every anonymous visitor shouldn't run StartSession at all. In Laravel 11 and later, register them in their own file with then: in bootstrap/app.php:

use Illuminate\Routing\Middleware\SubstituteBindings;
use Illuminate\Support\Facades\Route;

->withRouting(
    web: __DIR__.'/../routes/web.php',
    then: function () {
        Route::middleware([
            SubstituteBindings::class,
            'cache.headers:public;max_age=0;s_maxage=600;etag',
        ])->group(base_path('routes/public.php'));
    },
)

No session means no session cookie, no XSRF-TOKEN, and no @csrf forms on those pages, so keep forms and anything that reads auth() in web.php. max_age=0 keeps browsers coming back so a deploy shows up quickly, while s-maxage lets the CDN absorb the traffic.

For pages that do need a session, be explicit:

return response()->view('dashboard')
    ->header('Cache-Control', 'private, no-cache');

It's what Symfony sends anyway, but writing it down stops the next person from wrapping the route in cache.headers:public.

On Cloudflare, origin headers alone aren't enough for HTML. It doesn't cache HTML by default, so you also need a Cache Rule that makes those paths eligible.

Testing it

Send real GETs, twice:

curl -s -D - -o /dev/null https://example.com/pricing | grep -iE 'cache-control|set-cookie|cf-cache-status|age'

On a cacheable page you want public with an s-maxage, no set-cookie from your app, and the CDN status going from MISS to HIT with age climbing on the second request. Then repeat with a signed-in cookie and check that you get private.

The checks above came from nocache.dev, which I built. There's also a Laravel package (10 to 13) that covers both halves: composer require nocache-dev/laravel adds a nocache.headers:900 middleware for a session-free group like the one above. Anonymous GETs get public, max-age=0, s-maxage=900, plus CDN-Cache-Control: max-age=900, stale-while-revalidate=60 so Cloudflare can still serve stale while it revalidates. Signed-in users, requests that started a session, and responses that set a cookie get private, no-store, even if the route was left in the web group. php artisan nocache:check https://example.com --min-grade=B fails a CI step when a page's grade drops below B.

WordPress page cache vs CDN cache: who is answering your request?

nocache.dev — Tue, 03 Nov 2026 13:12:33 +0000

"I cleared the cache and nothing changed" is the most common WordPress support sentence I know. The honest reply is: which one?

A typical WordPress site can have three page caches stacked on top of each other, each with its own rules for what to store, when to skip, and how to purge. A request hits them from the outside in, so the first one that has a copy wins and the others never hear about it.

I ran live checks on two WordPress sites today. First, the layers.

Three caches, outside in

Edge cache (CDN). Cloudflare, Fastly, CloudFront and the like. Closest to the visitor, so it answers first. Cloudflare in particular doesn't cache HTML by default: it caches by file extension, and HTML pages come back with cf-cache-status: DYNAMIC until you add a Cache Rule (or a product like APO) that makes them eligible.

Server cache. A reverse proxy in front of PHP: Varnish or nginx at a managed host, or LiteSpeed's built-in LSCache. It stores the full response in memory or on disk and never wakes PHP on a hit.

Plugin page cache. WP Rocket, W3 Total Cache, WP Super Cache. These write the rendered page to a static HTML file under wp-content/cache. Depending on the setup, the file is served by a rewrite rule (no PHP at all) or by advanced-cache.php early in the WordPress boot.

You don't need all three, but you need to know which ones you have: each has its own purge and its own bypass rules.

Telltale signatures

Cloudflare: cf-cache-status (HIT, MISS, DYNAMIC, BYPASS, EXPIRED...).
LiteSpeed: x-litespeed-cache: hit, miss, or hit,private for its per-user private cache.
Varnish-style host caches: usually x-cache plus something host-specific. WP Engine adds x-cacheable and x-cache-group, and x-pass-why when it skips the cache.
WP Rocket: no header. It appends an HTML comment at the very end of the page: This website is like a Rocket, isn't it? Performance optimized by WP Rocket. When the page was served from WP Rocket's cache file, the comment ends with - Debug: cached@<unix timestamp>.
W3 Total Cache: also an HTML comment, starting Performance optimized by W3 Total Cache, with lines like Page Caching using Disk: Enhanced and Served from: ... @ <date>.

Two caveats. HTML minification can strip those comments, so their absence proves nothing. And an age header only tells you how long the copy has sat in the cache that answered, not in the ones behind it.

Live check 1: wordpress.org/news

The nocache.dev check, trimmed to caching headers:

server: nginx
vary: Accept-Encoding, accept, content-type
x-nc: MISS dca 2

Two curl -sI requests right after:

x-nc: EXPIRED dca 2
x-nc: HIT dca 1

There's no CDN signature here, no Cache-Control, no ETag and no Last-Modified. The only cache status comes from x-nc, the nginx cache that sits in front of WordPress.org. The three requests got MISS, EXPIRED and HIT, and the trailing dca 1 / dca 2 changed between requests, so I was most likely talking to different cache nodes, each with its own copy.

A server cache is doing all the work. It's fast, but the browser was never told how long to keep the page, so it guesses, and with no validators it can't revalidate cheaply. The check graded it D, mostly for those two gaps: missing Cache-Control and no validators.

Live check 2: a WooCommerce store with three layers

For a store I used nalgene.com, a WooCommerce site. Trimmed result:

cache-control: max-age=600, must-revalidate
cf-cache-status: HIT
age: 179
x-cache: HIT: 1
x-cache-group: normal
x-cacheable: SHORT
vary: Accept-Encoding, Accept-Encoding,Cookie
last-modified: Tue, 27 Oct 2026 13:18:03 GMT

And at the bottom of the HTML:

<!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket. Learn more: https://wp-rocket.me -->

All three layers show up:

Cloudflare answered (cf-cache-status: HIT, age: 179), so HTML caching has been turned on there.
A WP Engine-style Varnish layer behind it (x-cacheable, x-cache-group, and WP Engine's default 600-second page TTL in max-age=600).
WP Rocket in WordPress, but with no cached@ timestamp. WP Rocket's docs say that happens when its page cache is off, for example on hosts that run their own page cache. Here it is doing optimisation only, and the host does the caching.

One detail is easy to misread. I repeated the request twice with curl -sI and got x-cache: HIT: 1 and age: 193 both times. That x-cache value isn't live. It's the header Varnish attached when Cloudflare first fetched the page, and Cloudflare stores and replays it with every hit. On an edge HIT, every header from the inner layers is a snapshot from the moment the edge filled its cache. To see what the inner layers are doing right now, you have to get past the edge.

Logged-in users: what WordPress actually sends

For logged-in requests, WordPress core adds wp_get_nocache_headers() to the front-end response (in WP::send_headers()). Since WordPress 6.3, that means:

Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private
Expires: Wed, 11 Jan 1984 05:00:00 GMT

Before 6.3 it was no-cache, must-revalidate, max-age=0 without no-store, private, and since 6.8 every call to nocache_headers() sends the longer version. Core also sends these headers on 404s for anonymous visitors. WooCommerce uses the same mechanism on the cart, checkout and account pages, and also defines DONOTCACHEPAGE so page cache plugins skip them.

The 1984 Expires date is the giveaway. Here is nalgene.com's cart page:

cache-control: no-cache, must-revalidate, max-age=0, private
expires: Wed, 11 Jan 1984 05:00:00 GMT
x-pass-why: custom-path
cf-cache-status: BYPASS

The host skipped the cache by path (x-pass-why), and Cloudflare saw private and bypassed it too. That's what you want.

Cookies decide who gets the cached copy

Headers on the response only matter once a cache has decided to ask the origin. The decision to skip the cache for a given visitor is made earlier, from request cookies: wordpress_logged_in_* for signed-in users, and for WooCommerce woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_*. WooCommerce's docs list those cookies as the ones to exclude.

Every layer needs its own copy of those rules. I sent nalgene.com's homepage two requests with dummy cookies:

With wordpress_logged_in_abc=1:

cache-control: max-age=0, must-revalidate, private
x-cache: MISS
x-cacheable: NO:Passed
cf-cache-status: DYNAMIC

Both layers stepped aside. With woocommerce_items_in_cart=1; wp_woocommerce_session_abc=1:

cache-control: max-age=600, must-revalidate
x-cache: HIT: 1
cf-cache-status: HIT
age: 197

Cloudflare served its cached copy. WP Engine documents those WooCommerce cookies as cache exclusions, but the request never reached WP Engine. On a homepage that may well be fine, if the mini-cart is filled in by JavaScript after the page loads. But this is how carts end up showing the wrong count: the host's cookie rules are correct, and the CDN in front never got the same rules.

The rule of thumb: any cookie that bypasses an inner cache has to bypass every cache in front of it too.

Purge from the inside out

After publishing or editing, clear caches in the same order a request travels back out:

Plugin page cache.
Server cache (host dashboard, or LiteSpeed's purge).
CDN.

If you purge the CDN first, the next visitor makes the CDN fetch from a server cache that still holds the old page, and the stale copy goes straight back to the edge.

A quick checklist

curl -sI a page twice while logged out. Write down every cache status header you see.
View the source and look for plugin comments at the end.
Repeat with a wordpress_logged_in_x=1 cookie and with a WooCommerce cart cookie. Every layer should step aside.
Check /cart/ and /checkout/ for private and the 1984 Expires.
Make sure HTML has an explicit Cache-Control, not just a server cache and heuristics.

I built a small WordPress plugin for steps 1 and 5. It grades your home page, latest post, a page, the WooCommerce shop and the theme stylesheet, and if no cache plugin is active it can apply sensible headers (with a revert button). If WP Rocket, W3 Total Cache, LiteSpeed Cache or WP Super Cache is active, it only reports. It's in the WordPress.org review queue, so for now it's a zip on nocache.dev/wordpress. To check from a terminal: npx nocache-dev check https://your-site.com.

What Next.js actually sends in Cache-Control (and what Vercel changes)

nocache.dev — Tue, 27 Oct 2026 13:18:23 +0000

Ask three people what Cache-Control a Next.js page sends and you'll get three answers. All three can be right. It depends on how the page is rendered, which router you use, and whether Vercel sits in front of it.

I ran a live check on nextjs.org today to have something concrete to look at. Here's how to read what came back, and what changes when you host Next.js yourself.

The baseline: two requests to nextjs.org

The homepage HTML (trimmed to the caching-related headers):

cache-control: public, max-age=0, must-revalidate
x-vercel-cache: HIT
age: 572
x-nextjs-prerender: 1
x-nextjs-stale-time: 300
vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch

A JavaScript chunk from the same page:

cache-control: public,max-age=31536000,immutable
x-vercel-cache: HIT
age: 48724
etag: W/"_next/static/immutable/chunks/3-f__u1tgqe9w.js"

These two responses cover most of what you need to know.

1. `/_next/static` is solved for you

Everything under /_next/static has a content hash in its filename, and Next.js serves it with a one-year immutable cache. You don't need to configure anything, and you shouldn't override it. If you put your own Cache-Control on that path through a reverse proxy, you can only make things worse.

The catch is everything that isn't under /_next/static. Files in /public (favicons, fonts you dropped in there, OG images, robots.txt) are served without a hash in the name, so Next.js can't give them a long cache. Self-hosted, they get public, max-age=0 by default, which means every visit revalidates or re-downloads them. If you own those files and they rarely change, a day of cache plus stale-while-revalidate is a reasonable middle ground. If they must change instantly, rename them.

2. Pages: the rendering mode decides the header

For HTML, Next.js derives Cache-Control from how the route is rendered. Roughly:

Static (prerendered at build): cached by shared caches until the next deploy. Self-hosted with next start, you'll see s-maxage with a very long value.
ISR (revalidate: 60 or export const revalidate = 60): s-maxage=60, stale-while-revalidate=.... The SWR window comes from expireTime in next.config (one year by default in recent versions).
Dynamic (cookies, headers, no-store fetches, search params read at request time): private, no-cache, no-store, max-age=0, must-revalidate.

Notice that the static and ISR headers use s-maxage, not max-age. They're instructions for a CDN, not for browsers. That's deliberate: the edge holds the page and refreshes it in the background, while browsers always come back to the edge and pick up new content after the revalidation window.

The dynamic case is the one to watch. Reading cookies() in a layout, even only to show a "Sign in" link, makes every page under that layout dynamic. Every page then gets no-store, and your CDN can't cache any of them. If your build output shows routes you expected to be static marked as dynamic (ƒ), this is usually why. Move the cookie read into a small client component or a route that actually needs it.

3. What Vercel changes

Look again at the nextjs.org HTML: public, max-age=0, must-revalidate, and still x-vercel-cache: HIT with an age of almost ten minutes.

That's Vercel's edge doing its own thing. It reads the s-maxage and stale-while-revalidate your app sends, uses them for its own cache, and then removes them from the response that goes to the browser, replacing them with max-age=0, must-revalidate. The browser is told to check back every time. Vercel does this so a purge or deploy takes effect immediately for everyone.

Two consequences:

On Vercel, the header you see in DevTools is not the header your app sent. Debugging ISR by reading the browser-facing Cache-Control will mislead you. x-vercel-cache (HIT, MISS, STALE, PRERENDER, REVALIDATED) and age are what tell you how the edge is behaving.
Self-hosted, nobody strips anything. If you put Next.js behind Cloudflare, Fastly or nginx, your CDN sees the raw s-maxage=60, stale-while-revalidate=31535940. Whether it honours SWR depends on the CDN, and Cloudflare by default won't cache HTML at all without a Cache Rule. So "ISR works on Vercel" does not carry over automatically.

One more detail from the nextjs.org check: there's no ETag on the HTML. With max-age=0 and no validator, every browser navigation is a full download from the edge. It's fast because the edge is close, but it's not free. Self-hosted Next.js sends an ETag for pages by default (generateEtags: true), so this is mainly something you notice on Vercel.

4. `headers()` in next.config won't override page caching

A common attempt:

// next.config.mjs
export default {
  async headers() {
    return [{ source: "/:path*", headers: [{ key: "Cache-Control", value: "public, max-age=3600" }] }];
  },
};

This works for /public files and API routes. For pages and /_next/static, the Next.js docs are explicit: in production, the framework sets Cache-Control for those itself, and your value gets overwritten. If you want a different cache lifetime for a page, change its revalidate. Don't fight the header.

Route handlers (app/api/.../route.ts) and the Pages Router getServerSideProps are the exceptions. There you set the header on the response yourself, and Next.js leaves it alone:

export async function GET() {
  return Response.json(data, {
    headers: { "Cache-Control": "public, s-maxage=300, stale-while-revalidate=60" },
  });
}

5. The `Vary` header on App Router pages

vary: rsc, next-router-state-tree, next-router-prefetch, ... is there because the same URL can return two different bodies: full HTML on a normal navigation, or the React Server Components payload when the client router fetches it (with an RSC: 1 request header). A cache that ignores Vary can hand the RSC payload to a browser expecting HTML, and the user sees a page of serialized text.

Vercel handles this. If you self-host behind a CDN, check that it either respects Vary on these request headers or that you exclude RSC requests from caching. Recent Next.js versions also append an _rsc query parameter to those requests, which helps CDNs that key on the URL only.

A checklist for your Next.js app

Run next build and look at the route table. Is anything dynamic that shouldn't be?
Check one static page, one ISR page and one asset with curl -sI. Self-hosted, do you see s-maxage? On Vercel, look at x-vercel-cache and age instead.
Check something in /public. Is max-age=0 what you want?
Behind your own CDN: is HTML actually cached (look for a HIT on the second request), and are RSC requests kept separate?
Make sure nothing that reads cookies is shared through a public response.

I keep doing step 2 for client projects, so it's built into nocache.dev. There's a small package for Next.js too: withNocache() adds sensible caching for /public files and opt-in CDN caching for HTML paths you list, and checkUrls() runs a grade check after a deploy:

import { checkUrls } from "nocache-dev-next";
const { ok } = await checkUrls(["https://example.com/"], { minGrade: "B" });
process.exit(ok ? 0 : 1);

Or, without installing anything: npx nocache-dev check https://your-site.com. If a rule looks wrong for Next.js specifically, tell me. The methodology lists every check.

Your CDN says HIT. Here's what that doesn't tell you

nocache.dev — Tue, 20 Oct 2026 11:35:52 +0000

x-cache: HIT feels like a finished job. The edge answered, the origin rested, done.

But a HIT only tells you one thing: this particular edge node had a copy and served it. It says nothing about whether browsers will reuse that copy, whether the edge should have stored it at all, or how many copies of the same page the edge is keeping. Most caching bugs I've seen live in exactly those gaps.

Here are the ones worth checking.

1. Browsers and CDNs read different numbers

Cache-Control: public, max-age=60, s-maxage=3600

max-age applies to every cache. s-maxage applies only to shared caches (CDNs, proxies) and overrides max-age for them. So the line above means: the CDN keeps it for an hour, the browser for a minute.

That split is usually what you want for HTML: the edge absorbs traffic, while browsers come back soon enough to pick up a deploy. The pitfall is the reverse. A response with max-age=0, s-maxage=300 gets a HIT on every edge request and still makes every browser go to the network on every navigation. The CDN dashboard looks great. Your users' waterfalls do not.

Static assets with hashed filenames are the opposite case. They never change under the same URL, so tell everyone to keep them:

Cache-Control: public, max-age=31536000, immutable

immutable tells browsers not to revalidate even on a normal reload.

2. `no-cache` does not mean "don't cache"

This one trips up nearly everyone once.

no-cache: you may store it, but you must revalidate with the origin before every reuse.
no-store: don't store it anywhere.

no-cache combined with a validator (next section) is often the right answer for HTML that changes unpredictably: the browser keeps a copy, asks "still good?", and gets a tiny 304 back most of the time. no-store throws all of that away and should be reserved for genuinely sensitive responses, like account pages or anything with personal data. It also tends to keep pages out of the browser's back/forward cache.

3. Revalidation is cheap, if you have a validator

When a cached copy goes stale, the cache can ask the origin whether it changed instead of downloading it again. It needs a validator to do that:

ETag: "5f3a9c"
Last-Modified: Tue, 20 Oct 2026 09:12:00 GMT

The next request carries If-None-Match: "5f3a9c" (or If-Modified-Since), and if nothing changed the origin answers 304 Not Modified with no body.

No validator means no 304s, so every expired copy is a full download. nginx sends ETag and Last-Modified for static files by default. Express sends weak ETags for res.send() bodies by default, but generating an ETag doesn't save you the work of rendering the page, only the bytes on the wire.

One subtle failure: multiple origin servers generating different ETags for the same file (inode-based ETags on older Apache setups were the classic case). Each server disagrees with the others and revalidation quietly turns into full downloads.

4. `Vary` can split your cache into thousands of pieces

Vary lists request headers that change the response, so the cache stores a separate copy per value.

Vary: Accept-Encoding is fine; there are only a few values. Vary: Cookie is where things go wrong. Every visitor's cookie header is different (analytics IDs, consent flags, A/B buckets), so every visitor gets their own cache entry and the hit ratio collapses. Some CDNs don't cache responses with Vary: Cookie at all.

Vary: User-Agent has the same problem with a smaller blast radius. If you need per-device responses, normalize the value at the edge into a short header like X-Device: mobile and vary on that instead.

Also look at Vary headers your framework adds. Next.js, for example, varies on its own router headers (rsc, next-router-state-tree and others). That's deliberate and fine, but it's worth knowing they're there before you add more.

5. `Set-Cookie` on a publicly cacheable response

This is the one that can leak data rather than just waste it.

If a response says public and also sets a cookie, a shared cache is allowed to store it. If the cookie is stored with it, the next visitor may receive the previous visitor's cookie. Most CDNs protect you here by default (Cloudflare won't cache a response with Set-Cookie unless told to), but "most" and "by default" are doing a lot of work, and a cache rule written for something else can turn that protection off.

A real example. Here's part of the response vercel.com's homepage returned when I checked it today:

cache-control: public, max-age=0, must-revalidate
x-vercel-cache: HIT
age: 490
set-cookie: _v-consent=â€¦; Path=/; Domain=.vercel.com; Secure; SameSite=lax
set-cookie: _v-visitor-id=â€¦; Path=/; Domain=.vercel.com; Secure; SameSite=lax

To be fair to Vercel: these look like cookies added per request on the way out, after the cache lookup, so this is very likely not a leak. Their edge knows what it's doing. But the headers on their own say "any shared cache may store this, and here's a visitor ID." A corporate proxy or a second CDN layered in front doesn't know about Vercel's internals; it only reads the headers.

The rule I follow: if a response sets a cookie, it is either private or the cookie is moved somewhere else (a separate endpoint, or client-side). nginx:

location /account/ {
    add_header Cache-Control "private, no-cache" always;
}

Express:

app.use((req, res, next) => {
  const setHeader = res.setHeader.bind(res);
  res.setHeader = (name, value) => {
    if (name.toLowerCase() === 'set-cookie') {
      setHeader('Cache-Control', 'private, no-cache');
    }
    return setHeader(name, value);
  };
  next();
});

That middleware is blunt, but it means nobody on the team can accidentally ship a cookie on a public response.

6. `stale-while-revalidate` hides latency, not mistakes

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400

For five minutes the copy is fresh. After that, for up to a day, the cache serves the stale copy immediately and refreshes it in the background. Users almost never wait on the origin.

Two things to know. Support varies: browsers support it, and CDN support has improved a lot, but check yours. Some honor it only on certain plans or only from certain directives; others ignore it silently. And it extends the life of bad responses too. If an error page or a broken deploy gets cached, stale-while-revalidate can keep serving it while the background refresh keeps failing. Pair it with stale-if-error deliberately, and make sure 5xx responses are not cached with long lifetimes.

7. Reading the status header correctly

Each CDN reports cache status differently:

CDN	Header	Values to know
Cloudflare	`cf-cache-status`	`HIT`, `MISS`, `EXPIRED`, `REVALIDATED`, `BYPASS`, `DYNAMIC`
Vercel	`x-vercel-cache`	`HIT`, `MISS`, `STALE`, `PRERENDER`
Fastly, CloudFront, Varnish	`x-cache`	`HIT`, `MISS` (CloudFront: `Hit from cloudfront`)

Things that confuse people:

The first request to an edge location is usually a MISS. Run it twice before concluding anything. You may hit a different node each time.
DYNAMIC on Cloudflare means Cloudflare didn't consider the response eligible for caching at all. By default it doesn't cache HTML, regardless of your headers.
Age tells you how long the copy has been in cache. An Age close to your s-maxage is normal; an Age far beyond it means something is overriding your headers.
A HIT for the CDN is not a HIT for the browser. The browser decision is made from max-age, validators and Vary, and none of it shows up in the CDN's status header.

A quick checklist

For each important URL (homepage, a typical HTML page, a JS bundle, an API response):

Does max-age vs s-maxage match what you want for browsers vs the edge?
Is no-store used only where data is sensitive?
Is there an ETag or Last-Modified, and does the origin answer 304?
Is Vary limited to headers with few values?
Does any response with Set-Cookie say public or have a long s-maxage?
Do errors get cached?
Run it twice: what does the CDN status header say the second time?

curl -sI https://example.com will answer most of these. I got tired of doing it by hand, so I built nocache.dev: a free checker that makes the request, identifies the CDN, flags the issues above and suggests a fix for your server. The vercel.com example came from it. There's also a CLI:

npx nocache-dev check https://example.com

Add --min-grade B and it exits non-zero below that grade, so you can run it in CI. If you find a rule you think is wrong, the methodology page lists all of them, and I'd like to hear about it.

DEV Community: nocache.dev

Laravel responses are uncacheable by default. Here's why and how to fix it

The header comes from Symfony

The cookie comes from the web group

The built-in fix: cache.headers

Live check 1: laravel.com

Live check 2: laravel-news.com

The fix: a route group without a session

Testing it

WordPress page cache vs CDN cache: who is answering your request?

Three caches, outside in

Telltale signatures

Live check 1: wordpress.org/news

Live check 2: a WooCommerce store with three layers

Logged-in users: what WordPress actually sends

Cookies decide who gets the cached copy

Purge from the inside out

A quick checklist

What Next.js actually sends in Cache-Control (and what Vercel changes)

The baseline: two requests to nextjs.org

1. /_next/static is solved for you

2. Pages: the rendering mode decides the header

3. What Vercel changes

4. headers() in next.config won't override page caching

5. The Vary header on App Router pages

A checklist for your Next.js app

Your CDN says HIT. Here's what that doesn't tell you

1. Browsers and CDNs read different numbers

2. no-cache does not mean "don't cache"

3. Revalidation is cheap, if you have a validator

4. Vary can split your cache into thousands of pieces

5. Set-Cookie on a publicly cacheable response

6. stale-while-revalidate hides latency, not mistakes

7. Reading the status header correctly

A quick checklist

The cookie comes from the `web` group

The built-in fix: `cache.headers`

1. `/_next/static` is solved for you

4. `headers()` in next.config won't override page caching

5. The `Vary` header on App Router pages

2. `no-cache` does not mean "don't cache"

4. `Vary` can split your cache into thousands of pieces

5. `Set-Cookie` on a publicly cacheable response

6. `stale-while-revalidate` hides latency, not mistakes