What Is Caching and How It Speeds Up a Website: Browser, Server, and CDN Explained

You push a design update, refresh the page, and everything looks perfect. Ten minutes later the client emails: “I don’t see my changes.” Before you open a support ticket with the host, there is one concept you need to fully understand: caching.

This guide answers the question what is caching on a website in plain English, then breaks down the three caching layers designers actually run into every week, what each one stores, how long it keeps it, and the exact order in which to clear them.

What Is Caching on a Website? The Short Answer

Caching is the process of storing a copy of a file or a response somewhere closer to the visitor, so it does not have to be rebuilt or re-downloaded the next time it is needed. The storage location is called a cache, and the copy is called a cached version.

Think of it like a coffee shop that pre-makes its most popular sandwich every morning. When you order it, you get it in five seconds instead of five minutes. The trade-off is obvious: if the recipe changes at 11am, anyone served from the pre-made stack still gets yesterday’s sandwich until the stack is thrown out.

That trade-off is the entire story of caching on the web. Speed in exchange for freshness.

What Actually Gets Cached

• Static assets: images, CSS files, JavaScript files, fonts, PDFs, videos
• Full HTML pages: the finished page a CMS like WordPress assembled from PHP and a database
• Database query results: “give me the 10 latest posts” saved so it does not run on every visit
• API responses: product feeds, weather widgets, currency rates
• DNS lookups: the translation of your domain name into an IP address

Why Caching Matters More Than Almost Any Other Speed Tweak

A page served from cache can skip PHP execution, database queries, template rendering and sometimes even the trip across the ocean to your origin server. Real-world impact:

• Time to first byte often drops from 600 to 900 ms down to under 100 ms
• Server load falls dramatically, so the same hosting plan handles a traffic spike instead of collapsing
• Core Web Vitals improve, especially Largest Contentful Paint, which depends heavily on how fast the first byte and the hero image arrive
• Bandwidth costs shrink because repeat visitors re-download almost nothing

The catch is that caching is not one system. It is a stack of independent systems that each keep their own copy, with their own expiry clock, controlled by different people. That is why “clearing the cache” fails so often: designers clear one layer and leave two others untouched.

The Three Caching Layers Designers Actually Encounter

Ignore the academic list of a dozen cache types. In day-to-day client work, you deal with three, plus a couple of honourable mentions.

1. Browser Cache (Client Side)

The browser cache lives on the visitor’s own device: laptop, phone, tablet. The first time someone loads your site, the browser downloads the logo, the stylesheet, the script bundle and the fonts, then saves them to disk. On the next page view, it reuses those local copies instead of asking the server again.

What it stores: images, CSS, JS, fonts, favicons, and sometimes the HTML document itself.

How long: controlled by HTTP headers your server sends, mainly Cache-Control: max-age. Typical values you will see in the wild:

• Images, fonts, versioned CSS/JS: 30 days to 1 year
• Unversioned CSS/JS: often 1 hour to 7 days
• HTML pages: usually 0 seconds, or a few minutes with revalidation

Who controls it: you and your host, through headers. But once the file is on a visitor’s machine, you cannot remotely delete it. That is the single most important fact in this article.

Classic symptom: you see the new design, the client sees the old one, and a private/incognito window shows the new one. That is a browser cache issue, nearly every time.

2. Server Cache (Origin Side)

This layer sits on the machine that hosts the website. It saves the server from doing the same expensive work over and over. On a WordPress, Drupal or Shopify-style stack, it usually breaks down into three sub-caches:

Page cache (full-page cache)

Stores the finished HTML of a page. The next visitor gets a flat file instead of triggering PHP and MySQL. Provided by caching plugins, by NGINX FastCGI cache, by Varnish, or by your host’s built-in system (Kinsta, WP Engine, SiteGround, Cloudways and o2switch all ship one).

Typical lifetime: 1 hour to 24 hours, with automatic purge when you publish or update content. Automatic purge often does not trigger when you edit a theme file, a CSS file or a template via FTP. There’s a good explainer over at pressidium.com.

Object cache

Stores database query results in memory using Redis or Memcached. Great for logged-in areas, WooCommerce and large sites. It can stubbornly hold on to menu items, widget contents, option values and product data.

Typical lifetime: minutes to hours, sometimes until manually flushed.

OPcache

Stores compiled PHP bytecode. If you edited a PHP file over FTP and nothing changed at all, OPcache is a prime suspect. It usually revalidates within 60 seconds, but some hosts set it to never revalidate in production for maximum performance.

3. CDN / Edge Cache (Between the Two)

A Content Delivery Network is a network of servers spread around the world. It sits in front of your origin and keeps copies of your files, and increasingly of your full HTML pages, in data centres physically close to your visitors. Cloudflare, Bunny, Fastly, Akamai and Amazon CloudFront all work this way.

What it stores: by default images, CSS, JS and fonts. With APO, full page caching or custom cache rules enabled, it also stores complete HTML pages. This is the sort of thing a solid web design agency ships without fuss.

How long: whatever your Cache-Control says, or whatever the CDN dashboard overrides it with. Edge TTLs of 1 month for assets and 2 hours to 8 hours for HTML are common.

The nasty part: a CDN has dozens of points of presence. Purging “everything” is instant on modern networks, but a stale copy in Sydney can survive while Paris looks perfectly updated. If a client on another continent reports old content and you do not, check the CDN.

Honourable Mentions

• Service workers: if the site is a PWA or uses an offline plugin, a script installed in the browser can serve old content even after a hard refresh. Clear it in DevTools under Application > Service Workers.
• DNS cache: stores the IP address behind your domain, typically for 5 minutes to 24 hours. Relevant during migrations, not during design tweaks.
• Corporate proxies and mobile carriers: some networks cache aggressively on behalf of all their users. Rare, but real, and totally outside your control.

Cheat Sheet: The Three Layers Side by Side

Layer	Where it lives	What it stores	Typical lifetime	How to clear it
Browser cache	Visitor’s device	Images, CSS, JS, fonts, sometimes HTML	1 hour to 1 year	Hard refresh, incognito window, browser settings. Cannot be purged remotely.
Server page cache	Origin hosting	Finished HTML pages	1 to 24 hours	Caching plugin button, host dashboard, WP-CLI
Object cache	Origin hosting (Redis / Memcached)	Database query results, options, menus	Minutes to hours	Flush Redis from host panel or plugin
OPcache	Origin hosting (PHP)	Compiled PHP code	60 seconds to until restart	Host panel, PHP restart, version switch
CDN / edge cache	Global edge servers	Assets, often full HTML	2 hours to 1 month	Purge everything or purge by URL in the CDN dashboard
Service worker	Visitor’s browser	Whole app shell, offline pages	Until unregistered or updated	DevTools > Application > Unregister

“I Don’t See My Changes”: The Diagnosis Order

Do not clear everything at random. Work outward from the visitor toward the server, because that isolates the culprit and teaches you which layer is misconfigured. Here is the sequence we use.

1. Open the site in a private window on your own machine. If the change appears, the problem is a browser cache, most likely the client’s. Nothing is broken on the server.
2. Do a hard refresh: Ctrl+F5 on Windows, Cmd+Shift+R on Mac. If it works now, confirm your asset versioning strategy so real visitors are not stuck on old files.
3. Check the response headers in DevTools. Open the Network tab, reload, click the document. Look at Cache-Control, Age, X-Cache, CF-Cache-Status or X-Cache-Status. A value of HIT tells you exactly which layer answered.
4. Add a dummy query string: load yoursite.com/page/?v=123. If the new version appears, a full page cache is serving the old URL, either on the server or on the CDN.
5. Purge the CDN if the headers pointed there. Purge by URL first, then everything if needed.
6. Purge the server page cache from the plugin or host panel.
7. Flush the object cache if menus, widgets, prices or options are the stale elements.
8. Reset OPcache if you edited PHP files directly and literally nothing has changed anywhere.
9. Only then contact the host. By this point you can describe exactly what you tested, which usually gets a real answer in one reply instead of five.

The Message to Send Your Client

Keep a canned response ready. Something like: “Your browser saved a copy of the old version to make the site load faster. Please press Ctrl+F5 (Windows) or Cmd+Shift+R (Mac), or open the site in a private window. If you still see the old design after that, let me know and I will clear the server side.” This resolves the majority of these tickets in one message.

How to Stop Fighting the Cache: Versioning and Cache Busting

The professional fix is not to shorten cache lifetimes. It is to change the filename whenever the content changes, so the browser is forced to request a genuinely new file. This is called cache busting.

• Query string versioning: style.css?ver=4.2.1. Simple, and how WordPress enqueues assets by default. Bump the version on every deploy.
• Filename hashing: main.8f3a2b.css. The standard output of Vite, Webpack and modern build tools. Best practice for production.
• Immutable headers: once files are hashed, serve them with Cache-Control: public, max-age=31536000, immutable and never worry again.
• Never cache the HTML aggressively unless you have automatic purge on publish. HTML is the entry point that references your versioned assets.

In WordPress, always enqueue with a version parameter tied to your theme version or to filemtime(), and increment the theme version at each release. That one habit eliminates most “I don’t see my changes” tickets permanently.

Common Caching Mistakes We See on Client Sites

• Stacking three caching plugins plus a host-level cache plus a CDN cache, all with conflicting rules
• Caching pages for logged-in users, which leaks one user’s dashboard to another
• Caching the cart, checkout, account and search pages on an ecommerce site
• Hardcoded asset URLs with no version parameter, guaranteeing stale CSS for returning visitors
• Turning caching off completely to avoid the hassle, then wondering why the site fails Core Web Vitals
• Forgetting to purge after a design handover, so the client’s first impression is the old layout

A Simple Caching Setup That Works for Most Sites

1. One full page cache only. Use whatever your host provides, and disable the page caching feature in your plugin if both exist.
2. Object cache with Redis if the site is dynamic, an ecommerce store or a membership site.
3. A CDN in front, caching static assets aggressively and HTML with automatic purge on publish.
4. Hashed or versioned filenames for CSS and JS, served with a one-year immutable header.
5. Exclusion rules for cart, checkout, account, admin, preview URLs and any personalised page.
6. A documented purge procedure in the client handover file, listing every layer and where its button lives.

That last point is the one designers skip, and it is the one that saves the most hours over the life of a project.

FAQ: Website Caching

Is caching good or bad?

Caching is good. It is one of the highest-impact performance techniques available and it costs nothing in design quality. It only feels bad when it is misconfigured, when several layers overlap without coordination, or when nobody documented how to purge it. Correct caching is invisible to visitors and obvious in your speed metrics.

What happens when you clear the cache on a website?

The stored copies are deleted. The next visitor triggers a fresh build of the page, so their request is slower than usual, and the newly generated version is saved for everyone after them. Clearing a cache does not delete content, settings, posts or images. On a very high-traffic site, purging everything at once can briefly spike server load, which is why purging by URL is preferred when possible.

How do I stop a website from caching?

For a specific page, send Cache-Control: no-store or exclude the URL in your caching plugin and CDN rules. For development work, disable the page cache, enable “Disable cache” in DevTools while the Network tab is open, and use a development CDN mode such as Cloudflare’s. Disabling caching site-wide in production is almost never the right answer: fix the purge workflow instead.

How do I cache a website?

Enable a page cache at the host or plugin level, set sensible Cache-Control headers for static assets, add a CDN in front, and version your CSS and JS filenames. On WordPress, most managed hosts do steps one and two automatically. Verify it worked by checking for an X-Cache: HIT or CF-Cache-Status: HIT header in DevTools. There’s a good explainer over at azion.com.

Why does my client see the old version but I see the new one?

Almost always the browser cache on their machine, especially if they visited the site many times during the project. Ask for a hard refresh or a private window first. If they are in a different country and still see the old version, suspect the CDN edge node closest to them.

Does caching affect SEO?

Positively, as long as crawlers get fresh content. Faster server response and better Core Web Vitals help rankings. Problems only appear when a cache serves stale HTML for days, or when a misconfigured cache returns the wrong page to Googlebot. Keep HTML TTLs moderate and purge on publish.

How long should I cache images and CSS?

One year, with immutable headers, provided the filenames are versioned or hashed. If your filenames never change, keep it to a week or less, because you have no way to force an update otherwise.

Key Takeaway

Caching is simply stored copies, at three levels: the visitor’s browser, your server, and the CDN in between. Each one has its own clock and its own purge button. When someone says they cannot see your changes, work from the browser outward, read the response headers instead of guessing, and version your assets so the question stops coming up at all.

Need a hand auditing the caching stack on a client site, or setting up a configuration that stays fast without serving stale designs? Get in touch with the CSSmates team and we will take a look.