Website Caching Explained:Page, Object, Browser and CDN
Page, object, browser and CDN caching each store a different thing in a different place. How the four layers work, what each one speeds up, and the mistakes that break dynamic pages.
Table of Contents
Website caching means storing the result of work that has already been done, so the next visitor gets it without repeating that work. There are four common layers: page caching (the finished HTML), object caching (database query results), browser caching (files kept on the visitor's device) and CDN caching (copies kept on servers near the visitor).
Each layer speeds up a different part of loading a page. Used together, and configured carefully, they make a site faster and let the same hosting plan serve many more visitors.
Why caching matters
On a dynamic site like WordPress, each uncached page view can run hundreds of lines of PHP and dozens of database queries. Most visitors see exactly the same page, so repeating that work for each one wastes CPU, memory and time. Caching skips the repeated work, which lowers server load and Time to First Byte.
The four layers at a glance
| Layer | What is stored | Where | Speeds up | Main risk |
|---|---|---|---|---|
| Page cache | Complete HTML pages | Server (or CDN) | Server response time | Serving personal or stale content |
| Object cache | Results of database queries and computations | Server memory (Redis, Memcached) | Uncached and logged-in pages | Stale data if not invalidated |
| Browser cache | Images, CSS, JS, fonts | Visitor's device | Repeat visits | Visitors keep old files after an update |
| CDN cache | Static files, sometimes whole pages | Edge servers worldwide | Delivery distance | Caching pages that should be private |
Page caching
A page cache saves the HTML output of a page and serves it directly to the next visitor, without starting PHP or touching the database. This is usually the single biggest speed improvement for a content site.
Page caches can run:
- in the web server, such as LiteSpeed's LSCache or an Nginx FastCGI cache;
- as a plugin that writes HTML files to disk;
- at a CDN or reverse proxy in front of the server.
What must not be page-cached: carts, checkouts, account pages, admin areas and anything showing personal data. Good cache plugins exclude these automatically when they detect WooCommerce or logged-in users, but always verify. For LiteSpeed servers, see how to configure LiteSpeed Cache for WordPress.
Object caching
An object cache stores the results of expensive database queries and calculations in memory, using software like Redis or Memcached. It helps the pages that the page cache cannot serve: logged-in users, carts, searches and admin screens.
WordPress has a built-in object cache that lasts only for a single request. A persistent object cache keeps that data between requests, which needs Redis or Memcached on the server and a connector plugin. See Redis object caching explained.
Browser caching
Browser caching tells the visitor's browser to keep static files (images, CSS, JavaScript, fonts) for a set time, so repeat visits and navigation between pages download less. It is controlled with HTTP headers such as Cache-Control.
To avoid visitors keeping old files after an update, use versioned file names (for example style.css?ver=2.1 or a hash in the file name). Most modern CMSs and build tools do this automatically.
CDN caching
A content delivery network keeps copies of your files on servers in many locations and serves each visitor from a nearby one. That reduces distance, absorbs traffic spikes and takes load off your origin server.
By default, most CDNs cache static files only. Some can also cache HTML, which is powerful but needs the same exclusions as a page cache. Setup for a popular option is covered in how to set up Cloudflare DNS.
How the layers work together
When a visitor requests a page:
- The browser cache answers instantly for files it already has.
- The CDN answers for files (or pages) it has cached nearby.
- The page cache on the server returns ready-made HTML.
- Only if all of those miss does PHP run, and then the object cache saves repeated database work.
Common caching mistakes
- Caching personal pages, so one customer sees another's cart or account. Always exclude dynamic, user-specific URLs.
- Stacking two page caches (for example a plugin cache and a server cache) that conflict and serve stale pages.
- Forgetting to purge after changing content, prices or menus.
- Minifying and combining everything without testing, which can break layouts and scripts.
- Assuming caching fixes everything: it does not help slow admin screens, searches or checkouts much. Those need lighter code and enough resources.
Frequently Asked Questions
Do I need all four types of cache?
Not always. A small brochure site gains most from page and browser caching. Busy shops and membership sites benefit from object caching too, and a CDN helps when visitors are spread across regions.
How do I clear the cache?
Use the purge option in your cache plugin or server panel, then the CDN's purge if you use one. Visitors' browser caches update when file versions change.
Why does my site look different when I am logged in?
Logged-in users usually bypass the page cache and see fresh content, while visitors see cached pages. If they differ for long, the cache is not being purged on updates.
Related reading
For hosting fundamentals, see what is web hosting. To find out whether caching is the fix for your site, follow why is my website slow. For busy dynamic sites that need more room than caching alone provides, compare ServerNeed cloud hosting.
Caching under heavy traffic spikes is a central concern for news portal websites.
Sources
Last updated 7 October 2026
