Short answer
Use long cache lifetimes for versioned static files such as CSS, JavaScript, fonts and images, short or revalidated caching for HTML, and no shared caching for personal pages like carts and accounts. A CDN helps most when visitors are far from your server or the server is slow to respond.
The caches between your server and your visitor
MDN separates caches into two kinds. A private cache is tied to one client, typically the browser. A shared cache sits between the client and the server "and can store responses that can be shared among users" [1]. CDNs and proxy caches are shared caches. On top of these, many platforms keep their own server-side page cache, which stores finished HTML so the server does not rebuild it on every request.
How freshness works
When a browser stores a response, it needs to know how long the copy stays usable. The Cache-Control header tells it. MDN gives the example of max-age=604800 (one week): if the response is younger than that, it is "fresh"; if older, it is "stale" [1]. A stale copy is not thrown away immediately. The browser can ask the server whether it has changed using a conditional request, and if not, the server answers "304 Not Modified" without resending the file [1]. MDN notes that servers should send both ETag and Last-Modified where possible to support this [1].
The directives that matter most
| Directive | What it does | Typical use |
|---|---|---|
| max-age | How many seconds a copy stays fresh | Static files, short values for HTML |
| no-cache | May be stored, but must be revalidated before reuse | HTML that must always be current |
| no-store | Must not be stored in any cache | Pages with sensitive or personal data |
| immutable | Tells the browser the file will never change at this URL | Versioned CSS, JavaScript and fonts |
| private | Only the browser may store it, not shared caches | Pages personal to one visitor |
The difference between no-cache and no-store causes a lot of confusion. In MDN's words, no-cache "does not prevent the storing of responses but instead prevents the reuse of responses without revalidation", while no-store is for when "you don't want a response stored in any cache" [1].
Cache busting: long lifetimes without stale files
The fastest request is the one that never happens, so static files should be cached for a long time. The risk is that visitors keep an old copy after you change the file. The solution is cache busting: changing the URL whenever the content changes. MDN describes it as "a technique to make a response cacheable over a long period by changing the URL when the content changes", with examples such as bundle.v123.js or bundle.js?v=123 [1]. Combined with max-age=31536000 and immutable, the browser keeps the file for a year and fetches the new one as soon as the URL changes [1].
Page caching on the server
Content management systems like WordPress build pages from a database on each request. A page cache stores the finished HTML. The WordPress administration handbook describes caching plugins that "will cache your WordPress posts and pages as static files" and notes this helps a lot for mostly static pages [2]. It also warns that sites with a lot of dynamic content need more complex configuration [2]. Our WordPress speed optimization service covers page caching alongside plugin and theme work.
What must never be shared
A shared cache that stores a personal page can show it to the next visitor. Carts, checkouts, account areas and pages with form security tokens must not be stored in shared caches. WooCommerce's performance guide says caching should allow dynamic content "such as cart and checkout pages to remain uncached" [3]. Use private or no-store for these, and test them after any caching change.
Be sparing with no-store elsewhere. web.dev notes that pages using it may not be eligible for the back/forward cache, which restores pages instantly when visitors press back, and recommends no-store only for sensitive pages; for content that needs to stay fresh but is not sensitive, it suggests no-cache or max-age=0 [4].
Do you need a CDN?
A CDN stores copies of your files on servers spread across many locations and answers requests from the nearest one. It shortens the distance each request travels and can absorb traffic spikes. Google lists using a CDN among its most effective ways to improve time to first byte, and notes that only 33% of HTML document requests were served from a CDN, according to HTTP Archive's 2024 Web Almanac, as cited by web.dev [5]. The WordPress handbook adds that "using a CDN can greatly reduce the load on your website" [6].
A CDN is less important if your visitors are mostly local and your server is close to them and quick to respond. Measure time to first byte from a few locations before deciding. If you do add one, make sure it respects your cache headers, that purging works when you publish, and that personal pages bypass it.
A sensible starting configuration
- Versioned CSS, JavaScript and fonts: max-age of one year with immutable.
- Images: a week or longer, with versioned names if they ever change.
- Public HTML: a short max-age, such as ten minutes, or no-cache with revalidation.
- Personal pages and form pages: private or no-store, never cached by a CDN.
- Compression on for text files, and redirects kept to a single hop.
A worked example: a small business site
Picture a fictional five-page business site on shared hosting. Without a page cache, each request runs the content management system and several database queries, and the server takes about 1.2 seconds to send the first byte. Its CSS and JavaScript files are sent with no cache headers, so every page view downloads them again. Fonts come from a third-party domain with their own connection setup.
The changes are straightforward. Turn on page caching so finished pages are served from the cache. Add version strings to the CSS and JavaScript file names and send them with a one-year max-age and immutable [1]. Consider self-hosting the fonts in WOFF2, which removes the connection to another domain. web.dev notes that in practice the difference between self-hosting and a font service "is less clear cut" than it looks on paper [7], so measure before and after. Send HTML with a short max-age so content edits appear within minutes. The first-byte time drops because the server no longer rebuilds pages, and repeat visits download almost nothing except the HTML.
How to check what is cached
You can see caching at work in any browser's developer tools. Open the Network panel, load a page, then reload it. For each file, look at the response headers for Cache-Control and at whether the file was served from the browser's memory or disk cache on the second load. Files that are downloaded again on every reload, despite not having changed, are candidates for longer lifetimes with versioned URLs. If your host or CDN adds its own header showing whether a response came from its cache, check that public pages are cache hits and personal pages are not.
Caching and the back button
There is one more cache that affects how fast a site feels: the back/forward cache. web.dev describes it as "a browser optimization that enables instant back and forward navigation" by keeping a full snapshot of the page in memory [4]. It is not controlled by Cache-Control lifetimes in the usual way, but some choices make pages ineligible. Using the unload event is the main one, and web.dev's advice is never to use it [4]. Sending no-store on every page is another [4]. You can test eligibility in Chrome DevTools under Application, then Back-forward Cache, by running the built-in test [4].
When caching goes wrong
The two classic failures are stale content and leaked personal data. Stale content usually means HTML cached too long, or static files changed without a new URL; versioned file names and short HTML lifetimes prevent it. Leaked data means a shared cache stored a page meant for one visitor, such as a cart or account page. Prevent it by excluding those paths from page caches and CDNs, sending private or no-store on them, and testing after every caching change with two different browsers, one logged in and one not.
Caching and CDN questions
Why do visitors still see an old version after I update my site?
Either the HTML is cached for too long, or a static file changed without its URL changing. Short HTML lifetimes and versioned file names fix both.
Is no-cache the same as not caching?
No. no-cache lets the response be stored but requires the browser to check with the server before reusing it. no-store is the directive that prevents storage.
Will a CDN fix a slow website on its own?
It helps server response and delivery distance, but it does nothing for heavy scripts, oversized images or slow interactions. Those need separate work.
Sources
Opened and checked on November 3, 2026.
- HTTP caching, MDN Web Docs. Reference documentation, checked November 3, 2026.
- Cache, Advanced Administration Handbook, Developer.WordPress.org. Primary documentation, checked November 3, 2026.
- How to optimize performance for WooCommerce stores, WooCommerce developer docs. Primary platform documentation, checked November 3, 2026.
- Back/forward cache, web.dev. Primary documentation, last updated October 16, 2026.
- The most effective ways to improve Core Web Vitals, web.dev. Primary documentation (cites HTTP Archive and Chrome data), last updated October 31, 2024.
- Optimization, Advanced Administration Handbook, Developer.WordPress.org. Primary documentation, checked November 3, 2026.
- Best practices for fonts, web.dev. Primary documentation, last updated October 4, 2022.