Browser, Page and Object Caching Explained

Quick answer: Website caching stores the result of expensive work so the next request can reuse it. Browser caching keeps files on the visitor’s device. Page caching stores full HTML responses for anonymous pages. Object caching stores database query results and computed objects in memory (often Redis or Memcached). Use all three thoughtfully: short or versioned caches for HTML that changes, longer caches for static assets, and exclusions for carts, account pages and anything personalised.

“Turn on caching” is common advice. It is also vague. Different layers solve different problems. Mixing them up leads to sites that feel fast for the homepage and broken at checkout.

This guide separates browser, page and object caching in practical 2018 terms.

Why caching matters

Every page view can involve PHP (or another language), database queries, remote APIs and template rendering. Doing all of that on every request wastes time and server capacity. Caching reuses prior work when the inputs have not changed.

Faster pages help users and support SEO indirectly through better experience metrics. Caching is not a substitute for bloated themes or huge uncompressed images, but it is one of the highest impact server-side improvements.

Browser caching

Browser (client-side) caching tells the visitor’s browser how long it may keep static files such as CSS, JavaScript, images and fonts.

You control this with HTTP headers:

• Cache-Control (preferred modern control)
• Expires (older, still seen)
• Validators like ETag and Last-Modified

Good practice for static assets: long max-age (weeks or months) plus filename fingerprinting or query-string versioning when files change (style.ab12cd.css). That way returning visitors load CSS from disk, and a deploy instantly busts the cache because the URL changed.

HTML documents usually need much shorter cache times, or no-cache with revalidation, so updates appear quickly.

CDNs add another edge cache in front of your origin. The same header principles apply. Purge or version when you publish critical fixes.

Page caching

Page caching stores the full rendered HTML of a URL so the next anonymous visitor skips most application work.

On WordPress this is often a plugin (WP Super Cache, W3 Total Cache, WP Rocket) or server tooling (Nginx fastcgi cache, LiteSpeed cache, Varnish). Hosting panels sometimes enable it with a switch.

What should be cached: marketing pages, blog posts, category pages for logged-out users.

What should usually bypass cache: cart, checkout, my-account, personalised dashboards, anything with nonce-based forms that break when stale, and often search results.

Logged-in users are frequently excluded entirely, because their HTML differs (admin bars, private content). Some setups cache separate variants; that is more complex.

Purge rules matter as much as enabling the cache. When you edit a post, related cached pages should invalidate. If purge rules are wrong, visitors see old prices or old copy.

Object caching

Object caching stores discrete pieces of data (query results, options, computed objects) in a fast store such as Redis or Memcached, rather than regenerating them from MySQL every time.

In WordPress, a persistent object cache drop-in can dramatically cut database load on dynamic sites: busy stores, membership sites, high-traffic publishers. Brochure sites with strong page caches may see smaller gains.

Object cache is not a full-page HTML store. It sits inside the application. You still need page caching or a CDN for maximum anonymous speed.

We cover Redis specifically for WordPress in a companion piece later this month on this site; the concept is the same across stacks: keep hot data in memory, expire or bust it when underlying data changes.

How the layers work together

A typical anonymous visit to a blog post:

1. CDN or page cache may return HTML immediately.
2. Browser cache holds CSS/JS/images from prior visits.
3. If HTML must be built, object cache may satisfy many database lookups quickly.
4. Only cache misses hit the full application and database path.

Think of it as a funnel. The earlier a request is satisfied, the cheaper it is.

Stale content and other failure modes

Caching bugs feel mysterious until you know the layer:

• Old CSS after a design deploy: browser or CDN cache without cache busting
• Old article body for some visitors: page cache not purged on update
• Wrong price in cart: page cache incorrectly applied to cart routes
• Intermittent login weirdness: caching cookies or pages that vary by auth
• Admin changes not visible: viewing a cached front-end URL while logged out

Debug by checking response headers (Age, X-Cache, Cache-Control), trying a private window, and purging one layer at a time.

WordPress-specific notes

On WordPress, page cache plugins write static HTML or serve from memory for anonymous users. WooCommerce and membership plugins usually add cookies that must bypass cache. If a plugin sets a cookie for every visitor, it can accidentally reduce your hit rate to near zero. Check which cookies vary the cache.

Object caching with Redis is increasingly common on managed WordPress hosts in 2018. It helps options, transients and repeated queries. Pair it with a page cache; do not expect Redis alone to make an uncached PHP render as fast as static HTML.

When you purge, purge the CDN too if you use one. Origin-only purges leave edge nodes serving old HTML until TTL expires.

Measuring whether caching helped

Compare before and after:

• Time to first byte (TTFB) on a logged-out homepage
• Full page load on mobile throttling
• Origin CPU and database query rate under similar traffic
• Error rates at checkout

A fast homepage with a slow cart still loses money. Measure the paths that matter.

Practical setup tips

• Start with correct browser cache headers for uploads and theme assets
• Add page cache for anonymous traffic with clear exclusions
• Add object cache when the database is busy or page cache alone is not enough
• Monitor hit rates; a cache that never hits is misconfigured
• Document how to purge for editors who need an emergency refresh

Performance also depends on images and hosting tier. See lazy loading, WordPress hosting and WebP.

FAQ

Is caching safe for ecommerce?

Yes, with exclusions. Cache product catalogue pages carefully (prices can change), never cache personalised cart HTML for shared anonymous caches, and test checkout thoroughly after enabling anything new.

Does caching replace a bigger server?

It reduces load so you can serve more on the same hardware. Extreme traffic or heavy personalisation still needs adequate servers.

What is a cache stampede?

When a popular cache entry expires and many requests regenerate it at once. Mitigations include soft expiry, locks and staggered lifetimes.

Use each layer on purpose

Browser cache speeds repeat visits for files. Page cache speeds anonymous HTML. Object cache speeds the application when pages must be built. Name the layer you are changing, set exclusions, and purge deliberately. That is how caching stays an upgrade instead of a mystery.

If your site is slow and you are not sure which cache layer is missing or misconfigured, our Turn visitors into customers work includes performance reviews that cover caching, images and hosting fit.