---
title: "Caching Explained: Full-Page vs Object Cache | Evaluat"
description: "What caching is, the five cache layers between a shopper and your database, page cache vs object cache, and which requests skip which cache under load."
url: "https://www.evaluat.com/blog/caching-explained"
last_modified: "2026-10-22"
---

[Blog](https://www.evaluat.com/blog) [Guides](https://www.evaluat.com/blog/category/guides)

# Caching explained: browser, CDN, full-page and object caches

Caching means keeping a copy of something expensive to produce so the next request can be answered faster. A busy online shop has five layers of it between a shopper and the database. Basket, checkout and account requests skip the two layers that store whole pages, which is why they slow first under load.

Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 22 October 2026

[Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 16How a web page loads

![Five cache layers between a shopper and the database, drawn left to right: browser cache, CDN, full-page cache, object cache and database memory. A request for a product page is answered by the full-page cache and stops there. A basket request uses the browser cache for files only, skips the CDN page cache and the full-page cache, and goes on to the object cache and the database.](https://www.evaluat.com/blog/caching-explained-cover.svg)

Summary

Caching means keeping a copy of something that was expensive to produce, so the next request for it can be answered faster. A typical online shop has five layers of cache between a shopper and its database. The browser keeps files such as images and scripts on the shopper's own device. A content delivery network keeps shared files and pages near the shopper. A full-page cache, such as Varnish or a page caching plugin, keeps finished pages in front of your application. An object cache, such as Redis, keeps the ingredients your code needs, like configuration and query results. And the database keeps its busiest data in memory. A page served from the full-page cache can arrive in a tenth of the time it takes to build. The catch is that baskets, checkouts and account pages are different for every shopper, so they skip the two layers that store whole pages and are built fresh every time. They still lean on the object cache and the database's memory, which is why those layers matter most on sale day. Under load, three things go wrong. A cache cleared at peak sends every request to the server at once, logged-in shoppers and full baskets lower the hit rate, and a load test that only visits cached pages measures the cache rather than the shop.

Listen to this article · 1:25

[Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/caching-explained.mp3)

Key takeaways

- A shop has five cache layers: browser, CDN, full-page cache, object cache and the database's own memory.
- A full-page cache stores finished pages; an object cache stores the pieces code needs to build one.
- Basket, checkout and account requests skip the page caches but still use the object cache and the database's memory.
- Clearing caches at peak sends every request back to the application at once.
- A load test that only visits cached pages measures the cache, not the shop.

## What is caching?

Caching is keeping a copy of something that was expensive to produce, such as a finished page or a database result, so the next request for it can be answered from the copy. Answering from the copy is a cache hit. Having to produce it again is a cache miss. The share of hits is the hit rate.

A café is a fair picture. It brews a large pot of the house coffee every half hour and pours from it all morning, because most customers want the same thing. A customer who orders a bespoke drink still waits for the barista. The pot is a cache: fast for the common order, no help with the unusual one, and stale if nobody remembers to brew a fresh pot.

That last part is the hard bit. Martin Fowler quotes Phil Karlton’s well-known line that [there are only two hard things in Computer Science: cache invalidation and naming things](https://martinfowler.com/bliki/TwoHardThings.html). A copy is only useful while it is still right. Every cache needs a rule for when its copy expires and a way to be told that the original changed, and most caching problems on real shops are problems with one or the other.

On a website, caching happens at several layers at once, each storing something different for a different audience. Knowing which layer answered a request is the key to reading both your speed tests and your load tests.

## What are the layers of cache on a website?

A typical online shop has five layers of cache between a shopper and its database: the browser cache on the shopper’s device, a content delivery network (CDN), a full-page cache in front of the application, an object cache beside it, and the database’s own memory. Each stores something different and serves a different audience.

| Layer           | Where it lives                       | What it stores                                  | Who it serves                        | How a copy is replaced                        |
| --------------- | ------------------------------------ | ----------------------------------------------- | ------------------------------------ | --------------------------------------------- |
| Browser cache   | The shopper’s device                 | Images, scripts, stylesheets, fonts             | One shopper                          | It expires, or the file’s address changes     |
| CDN             | Servers near the shopper             | Files and shareable pages                       | Everyone near that server            | It expires, or you purge it                   |
| Full-page cache | In front of your application         | Finished HTML pages                             | Shoppers who would see the same page | A purge when a product, price or page changes |
| Object cache    | Beside your application, often Redis | Configuration, layouts, query results, sessions | Every request the application builds | It expires, is evicted, or is flushed         |
| Database buffer | Inside the database’s memory         | The most-used table and index data              | Every query                          | Least-used data is pushed out                 |

### The browser cache

The browser keeps files it has already downloaded so the next page can reuse them, skipping the downloads [part 8](https://www.evaluat.com/blog/how-a-web-page-loads) walked through. MDN calls it a private cache, [tied to a specific client](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching), and your server controls it with the `Cache-Control` header. Plenty of sites leave it to chance. The HTTP Archive’s 2024 Web Almanac found that [the percentage of sites using neither caching header](https://almanac.httparchive.org/en/2024/sustainability) was about 25%.

The safe pattern is to give files a new address whenever they change, which MDN calls cache busting, and let browsers keep them for a long time. Pages themselves cannot be renamed that way, as MDN notes that [main resources cannot be cache busted](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching), so HTML is usually cached briefly or not at all.

### The CDN cache

A CDN keeps shared copies on servers near your shoppers and answers for your origin when it can. [Part 14 of this guide](https://www.evaluat.com/blog/what-is-a-cdn) covered what it takes off your server under load, and what still gets through.

### The full-page cache

A full-page cache stores finished HTML pages in front of your application and hands them to the next shopper without running any code. Adobe Commerce (Magento) ships [a simple PHP reverse proxy that enables full page caching out of the box](https://developer.adobe.com/commerce/php/development/cache/page/), and Adobe recommends Varnish in production. WordPress shops use a page caching plugin; Shopware has its own HTTP cache.

The speed difference is large. Shopware’s engineers describe a cached page versus a built one as [the difference between a 500ms response and a 50ms response](https://shopware.com/en/news/new-caching-system/). DebugHawk’s report on 5.7 million WordPress page views at the end of 2025 found that [cached pages had a median TTFB of 106ms versus 723ms for uncached pages](https://debughawk.com/blog/wordpress-performance-report-2025).

### The object cache

An object cache stores the pieces your application uses to build a page: merged configuration, layouts, product data, query results and often sessions. Redis and Memcached are the usual tools. In WordPress, [the object cache is used to save on trips to the database](https://developer.wordpress.org/reference/classes/wp_object_cache/), but by default it only lasts for a single request unless you install a persistent cache plugin.

That default matters. DebugHawk found that [sites with a persistent object cache had a median PHP execution time of 508ms versus 1,542ms without](https://debughawk.com/blog/wordpress-performance-report-2025). The object cache is what speeds up the pages a full-page cache cannot serve.

### The database’s own cache

Databases cache too. In MySQL, the InnoDB buffer pool is [an area in main memory where InnoDB caches table and index data as it is accessed](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool.html), and MySQL notes that on dedicated servers up to 80% of physical memory is often given to it. PostgreSQL has its own equivalent. A query that finds its data in memory avoids a slow read from disk.

## Page cache vs object cache: what is the difference?

A page cache stores whole finished pages, so a hit skips your application entirely. An object cache stores the ingredients your application uses to build pages, so it speeds up every page that still has to be built, including basket and checkout. They solve different problems, which is why most busy shops run both.

|              | Page cache (e.g. Varnish)                            | Object cache (e.g. Redis)                                        |
| ------------ | ---------------------------------------------------- | ---------------------------------------------------------------- |
| Stores       | Finished HTML pages                                  | Configuration, layouts, query results, sessions                  |
| A hit skips  | The application and the database                     | Some database queries and repeated work                          |
| Helps        | Anonymous browsing: home, category and product pages | Every page the application builds, including basket and checkout |
| Cleared when | A product, price or page changes                     | Keys expire, memory fills, or someone flushes it                 |

A worked example shows why you want both. Take an example shop whose product pages take 50 ms from the full-page cache and 500 ms to build, the same gap Shopware describes, and which serves 10 product pages a second. At a 95% hit rate, half a page a second is built, about a quarter of one worker’s time. If the cache is flushed, all 10 are built, which keeps five workers busy on product pages alone, and the basket and checkout traffic still needs workers of its own. A good object cache makes each of those builds cheaper, so the shop survives the flush with room to spare.

## Which requests skip which caches?

Basket, checkout and account pages, and every request that adds to a basket or places an order, skip the two layers that store whole pages: the CDN’s page cache and the full-page cache. They still use the browser cache for their files, the object cache and the database’s memory. On sale day they are the busiest requests on the site.

The platforms say so plainly. Adobe lists [the compare products, cart, checkout pages](https://developer.adobe.com/commerce/php/development/cache/page/) as examples of uncacheable pages, and only GET and HEAD requests can be cached at all. WooCommerce tells shops to exclude Cart, My Account and Checkout from page caching, because [these pages need to stay dynamic](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins). Shopify’s developer documentation states that [cart, session, and checkout traffic carries cookies and can’t be served from a shared cache](https://shopify.dev/docs/storefronts/themes/best-practices/performance/avoid-request-proxies).

| Request                         | Browser      | CDN page cache             | Full-page cache         | Object cache and database memory |
| ------------------------------- | ------------ | -------------------------- | ----------------------- | -------------------------------- |
| Anonymous product page          | Files reused | Hit, if HTML caching is on | Hit                     | Only on a miss                   |
| Logged-in shopper, product page | Files reused | Usually passed through     | Depends on the platform | Used                             |
| Basket or checkout page         | Files reused | Skipped                    | Skipped                 | Used                             |
| Add to basket, place order      | Not cached   | Skipped                    | Skipped                 | Used                             |
| Search results                  | Files reused | Varies                     | Varies by platform      | Used on a miss                   |

Logged-in shoppers are where platforms differ most. Magento varies its cache by context, such as customer group and [whether a customer is logged in or not](https://developer.adobe.com/commerce/php/development/cache/page/public-content), so a logged-in shopper can still get a cached product page. Shopware, by contrast, says that by default, [once a customer logs in or adds something to the cart, Shopware disables the HTTP cache entirely for that user](https://shopware.com/en/news/new-caching-system/), a behaviour its new caching system changes. Check what yours does before sale day, because more shoppers are logged in with a full basket on a sale day than on any other.

## What happens to caches under load?

Caches make a site look bigger than it is, until something empties them. Three things go wrong under load. A flush at peak sends every request to the application at once, a popular item expiring stampedes the database, and the uncacheable share of traffic rises just as traffic peaks, so the hit rate falls when you most need it.

**Flushes at peak.** Adobe’s documentation warns that [clearing cache types during peak demand can increase load on the Admin and cause the site to go down](https://experienceleague.adobe.com/en/docs/commerce-admin/systems/tools/cache-management), and advises scheduling flushes for quiet hours. Saving a product or a price rule can trigger targeted purges too, so plan catalogue changes for the morning of a sale as carefully as code.

**Stampedes.** When a popular cached item expires, every request for it misses at once and goes to the database. Facebook’s engineers measured this on their memcache fleet: [without leases, all of the cache misses resulted in a peak database query rate of 17K/s](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf). With a mechanism that let one request refill the cache while the rest waited, the peak was 1.3K/s.

**A falling hit rate.** For a Magento full-page cache, Adobe says [a hit rate above 0.90 or 90% indicates that the full-page cache is working](https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/troubleshooting/miscellaneous/cloud-site-is-slow). On sale day more shoppers log in and fill baskets, so more requests skip the page caches. Shopify’s documentation puts the risk well: [a high hit rate on collection and product HTML can coexist with slow cart interactions](https://shopify.dev/docs/storefronts/themes/best-practices/performance/avoid-request-proxies).

This is why [part 15](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) found that caches can spread a failure as easily as they prevent one.

## How should caches change the way you load test?

A load test that visits the same few cached pages measures your cache, not your shop. Build the test around what shoppers really do: many different products and search terms, logged-in sessions, items added to the basket and checkouts completed. Then run it with the cache warm and again straight after a flush, because both happen in real life.

- **Spread the requests.** Use a list of real product addresses and search terms, so the test does not keep hitting the handful of pages that are always cached.
- **Include the uncached journeys.** Add to basket, log in and check out. Those requests set your real capacity.
- **Test a cold start.** Run once straight after a deploy or a flush, which is when the application does the most work.
- **Watch hit rates during the test.** A test that ends with a 99% hit rate on a site that sees 85% in real life has flattered you.

## Common mistakes with caching

Most caching mistakes come from trusting a cache to cover more traffic than it can.

- **Flushing everything at peak.** Clear only what changed, and keep full flushes for quiet hours.
- **One uncacheable block on every page.** In Magento, [if any block in a layout is designated as uncacheable, the entire page is uncacheable](https://developer.adobe.com/commerce/php/development/cache/page/). One careless block in a header can switch the cache off site-wide.
- **No persistent object cache.** Without one, WordPress rebuilds the same data on every request.
- **Tracking parameters that split the cache.** Make sure campaign parameters are ignored in the cache key.
- **Load testing warm, cached pages only.** The result describes your cache on a quiet day.

## How Evaluat shows which cache answered

Every virtual user in an Evaluat test is a real browser, so it requests pages, files and background calls the way a shopper does, including the basket and checkout. Each session’s network log shows the cache state of every request that reports one: served from the browser’s own cache, or the hit, miss or bypass your CDN or reverse proxy reported in headers such as `cf-cache-status` and `x-cache`.

That turns the tables in this article into evidence from your own site. As virtual users ramp up, you can see cached product pages hold their [time to first byte](https://www.evaluat.com/blog/time-to-first-byte) while the basket and checkout climb, and confirm which requests your caches answered. Datasets give each virtual user its own search terms, logins and form inputs, so the test does not simply warm the same few pages. What users see, not what scripts pretend.

The boundary is worth stating. A browser can see the layers in front of your application, the browser cache, the CDN and a reverse proxy that reports itself, but not the object cache or the database’s memory. Read those from your server monitoring, such as Redis’s hit and miss counters, while the test runs.

Caching is the cheapest speed most shops have, and it covers the pages that matter least on sale day. Know which layer serves each of your journeys, and load test the ones no cache can serve.

Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to see which of your pages your caches really serve under load.

[Previous · Part 15Why websites crash under high traffic](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) [Next · Part 17What is a virtual waiting room?](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms)

![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg)

About the author

[Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat

Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them.

[Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad)

[More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan)

Common questions

## FAQ

### What is caching in simple terms?

Caching is keeping a copy of something that took time to produce, such as a web page or a database result, so the next request for it can be answered from the copy. Answering from the copy is a cache hit; having to produce it again is a cache miss. Websites cache at several layers, from the visitor's browser to the database.

### What is a full-page cache?

A full-page cache stores the finished HTML of a page and serves it to the next visitor without running the application or querying the database. Varnish, Magento's built-in page cache and WordPress page caching plugins are examples. It only works for pages that are the same for many visitors.

### What is the difference between page cache and object cache?

A page cache stores whole finished pages, so a hit skips the application entirely. An object cache stores pieces of data the application uses to build pages, such as configuration, sessions and query results, so it speeds up pages that must still be built. Most shops need both.

### Do I need Redis and Varnish?

On a busy shop, usually yes, because they do different jobs. Varnish serves finished pages to anonymous shoppers without touching your application, while Redis speeds up every page your application does build, including basket and checkout. Many platforms also use Redis for sessions.

### Does a logged-in customer get cached pages?

It depends on the platform. Magento varies its full-page cache by context such as customer group and login state, so logged-in shoppers can still get cached pages. Shopware has historically switched the HTTP cache off for a shopper once they log in or fill a basket, and WordPress page caching plugins usually skip logged-in users.

### Does clearing the cache slow down a website?

Yes, until the cache refills. Every request that would have been a hit has to be built again, so response times and server load rise straight after a flush. Adobe warns that clearing cache types during peak demand can cause the site to go down, so schedule full flushes for quiet hours.

### What is a good cache hit rate?

For a Magento full-page cache, Adobe says a hit rate above 90% indicates the cache is working, and below 85% may indicate a configuration problem. Other layers have different norms. Measure the requests that miss as well, because they are the ones your servers pay for.

### Why is my site slow even though it is cached?

Usually because the slow pages are the ones that cannot be cached, such as search, basket and checkout, or because something is splitting or clearing the cache, such as tracking parameters, an uncacheable block on every page, or frequent flushes. Test the uncached journeys and check the cache headers on each response.

Related reading

## More from the blog

[![A CDN receives 2,000 requests a second. Bars show how many reach the origin server at each cache hit ratio: 400 a second at 80 percent, 200 at 90 percent, 100 at 95 percent and 20 at 99 percent. Dropping from a 95 to a 90 percent hit ratio doubles the origin's traffic, and baskets, checkouts and orders are always among the requests that get through.](https://www.evaluat.com/blog/what-is-a-cdn-cover.svg)](https://www.evaluat.com/blog/what-is-a-cdn)

### [What a CDN does (and does not) do for your site under load](https://www.evaluat.com/blog/what-is-a-cdn)

[A content delivery network (CDN) is a network of servers that keeps copies of your files close to your visitors and answers for your own server whenever it can. Under load it can absorb most requests for pages and files that are the same for everyone. Baskets, checkouts and every order still reach your server.](https://www.evaluat.com/blog/what-is-a-cdn)

[Ahmad Farzan · 19 October 2026](https://www.evaluat.com/blog/what-is-a-cdn)

[![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg)](https://www.evaluat.com/blog/time-to-first-byte)

### [Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte)

[Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue.](https://www.evaluat.com/blog/time-to-first-byte)

[Ahmad Farzan · 8 October 2026](https://www.evaluat.com/blog/time-to-first-byte)

[![The five stages a busy website fails in, drawn as a descending staircase. First, requests queue and pages slow. Second, timeouts turn slow requests into 502 and 504 errors. Third, retries and refreshes multiply the load. Fourth, overloaded servers miss health checks and are pulled from service. Fifth, the failure cascades to the next part of the system, often the database. The order barely changes; what runs out first does.](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic-cover.svg)](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic)

### [Why websites crash under high traffic](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic)

[Most websites do not simply switch off when traffic spikes. Requests queue for a limited resource, pages slow, timeouts turn slow into failed, and retries and failed health checks pile on more load until the site falls over. The symptoms arrive in roughly that order every time. What differs is which part runs out first.](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic)

[Ahmad Farzan · 21 October 2026](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic)

See it on your site

Test in real browsers.\
Debug in real sessions.

## Want to see this measured on your app?

30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report.

[Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)