Browser cache vs page cache vs object cache

Browser cache, page cache, and object cache are three separate layers that speed up a site in different ways. Browser cache tells the visitor’s device to keep static files such as CSS and images for a while. Page cache stores full HTML at the server so PHP does not run on every anonymous request; on our stack that is LSCache with LiteSpeed. Object cache keeps repeated PHP data such as database query results in memory, often with Redis. They stack on top of each other and none of them replaces the others.

curl -sI https://example.com/wp-content/themes/x/style.css | grep -i cache

You want a Cache-Control or Expires header that lasts on hashed static files, not on the HTML document itself. Next, request the HTML and look for X-LiteSpeed-Cache: hit. That header means page cache served the response. Object cache does not show up in HTTP headers; you confirm it from Redis memory use and from Query Monitor on a staging copy. If the CSS response says no-store, something in the theme or a plugin is fighting browser cache.

How the three layers differ

Browser cache lives on the visitor’s device until the TTL ends, which is why hashed filenames matter when you change assets. Page cache lives on the server and returns ready HTML for anonymous traffic so WordPress and PHP stay idle. Object cache sits inside PHP and remembers options, transients, and repeated queries so the database is not hit for the same work again and again. Turning on only one layer and expecting the other two to improve is a common reason a site still feels slow with a green checkbox.

If you need the object layer, Redis and Memcached covers that choice. Redis is not a substitute for LSCache on the HTML. On shared hosting you still rely on cPanel, LiteSpeed, and CloudLinux LVE without root; page cache is the layer that removes most of the PHP work for public pages.

Who purges what

When you publish or update a post, purge that URL and the home page. Avoid flushing the entire page cache on every comment, because a full flush keeps the home page cold and makes the hit rate look broken. Object cache keys expire on their own; restarting Redis empties them and they rebuild as traffic returns. Browser cache stays with the visitor until the TTL elapses, so you cannot force every laptop to drop old CSS on demand.

Watch for a cache-buster cookie from a page builder on every visitor. That pattern makes every request look unique, so LSCache stores little that helps and TTFB looks like uncached PHP. Test with a logged-out curl request. A logged-in admin browser tab is not a fair test of anonymous page cache.

Logged-in traffic and what to check

Anonymous HTML can be a page-cache hit with almost no PHP. A logged-in WooCommerce customer should miss page cache and still benefit from object cache for options, alloptions, and repeated catalog queries. If logged-in TTFB matches a logged-out miss, Redis is probably not in the path. If logged-out TTFB always matches a miss, LSCache is not serving the HTML. Those two checks tell you which plugin screen to open first.

Do not purge object cache out of habit after every deploy. Purge page cache for the URLs you actually changed. Object cache rebuilds from normal traffic. A full Redis FLUSHALL forces a wave of SQL you did not need to invite.