Web Caching Explained: Page Cache vs Object Cache vs CDN Cache

Web caching is the difference between a server that repeats the same work for every visitor and one that does it once. There are four layers — page cache, object cache, CDN cache, and browser caching — and they store different things, fail differently, and get cleared in different places. This guide sorts out which is which and which to enable first.

This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, and our migration guide before changing live infrastructure.

Measure before you cache

Measure the page before you change anything. Check a repeat visit as well as a first visit — the gap between them is roughly what web caching can win you — and keep the test location consistent. Otherwise a change in the test can look like an improvement in the site.

Make a short note of which layers already exist: a caching plugin, a server-level cache, a CDN, and the browser rules your host sets by default. Two caches with different expiry times are the classic source of "I cleared the cache and nothing changed."

The four layers of web caching

A page cache stores the finished HTML of a page so the server skips rebuilding it — the biggest win for most small sites. An object cache stores database query results and computed fragments, which speeds up the pages you cannot cache whole, such as carts and logged-in views. A CDN cache keeps copies of your pages and files on servers near your visitors. And browser caching keeps files on the visitor's own device, so a repeat visit skips the network entirely.

Work from the biggest delay toward the small ones. A slow server response and an uncompressed image are different problems with different caches, and they do not become one problem because a speed test lists them together.

Test the result like a visitor

Verify each cache with real pages and common devices. A page cache can make the homepage fast while product pages, search, or logged-in routes still do the hard work every time — those routes are object cache territory.

Test the normal path first, then the part that has the most consequence. For a store, that is checkout, which should usually bypass the page cache entirely. A test should answer one question rather than produce a vague impression.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

web.dev's Core Web Vitals guide has useful background on the speed metrics caching improves: web.dev's Core Web Vitals guide. Use it to understand the terms, then return to the small, reversible next step.

A sensible maintenance habit

Put the final configuration and the result in a short maintenance note. Caching problems repeat because nobody remembers which layer serves which page or which plugin was disabled last time. A dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a cache expiry or a DNS TTL, write the time you expect the new answer to be visible. This record is useful even when everything works. A few months later, it tells you why a setting has an unusual value.

Do not confuse an account dashboard with evidence from the live site. A dashboard can show that a cache is enabled or purged. The visitor still needs to receive the fresh page you intended. Test from outside the account, and use a private window or a second connection if a cached answer could mislead you.

If you hand the task to someone else, give them the record rather than a conclusion. "The site is slow" is hard to investigate. "The delay began after this update, affects this URL, and persists in a private window" gives the next person a useful starting point.

One last check

Before you close the ticket or move to the next task, load the pages that matter in a fresh browser session: the homepage, a deep page, and anything behind a login. If a stale version appears, note which layer served it and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering the missed detail during a launch or an outage.

Leave a useful handoff

Save the final cache configuration and test result with the date and account involved. If someone else needs to purge or adjust a layer later, they should be able to see what is enabled without reconstructing the whole setup from browser history.

Bottom line

Web caching pays off layer by layer: enable the page cache first, add a CDN cache for distance, and reach for the object cache when dynamic pages drag. Change one layer at a time, keep evidence, and test like a visitor before you call it done.

Frequently asked questions

Do I need to enable every cache layer at once?

No. Turn on one layer at a time — the page cache first — test it, and keep the previous configuration until you know the result is stable.

What should I tell hosting support about a caching problem?

Give the domain, exact URL, UTC time, what you expected versus what was served, and the layers you have already purged. That is usually enough for support to find the relevant logs.

Should I keep a backup before changing cache settings?

Yes. Download or verify a recent backup before edits that affect files, databases, email, DNS, or software versions — a bad cache rule is easy to revert only if you know the previous state.