What Is a Cache? Web Caching Explained

Caching is the difference between a page that ships as finished HTML in milliseconds and one that gets rebuilt from the database on every visit. An uncached WordPress page can run dozens of database queries on every single request; a cached copy is served as stored HTML in a few milliseconds, which makes caching the biggest single lever on website performance that most sites have. Caching happens at several layers — the visitor’s browser, your web server, and a content delivery network (CDN) — and each one cuts load time in a different way.

Why caching matters for web hosting performance

Caching matters because it removes the most expensive work from every page view: rebuilding the page. The saving shows up in multiples, not percentages — in DreamHost’s own benchmarks, run on identical sites between August 18 and August 31, 2025, DreamPress, DreamHost’s managed WordPress platform, which layers NGINX FastCGI page caching and PHP OPcache — plus a Redis object cache on Pro plans — measured up to 6x faster site response than other leading WordPress platforms.

The copies themselves sit wherever they are closest to the person asking for them: in the browser on their own device, in server RAM or on disk, or on CDN edge servers in their region. Fewer requests reach your origin, so bandwidth use and server load fall, and the same hosting plan absorbs more traffic before you outgrow it.

Visitors feel all of that as speed: page load time drops, which improves user experience and encourages visitors to stay longer.

Caching, Core Web Vitals, and SEO

Caching moves the number Google actually measures. Page caching removes page-generation time, the largest component of time to first byte (TTFB) on a database-driven site, and a slow TTFB delays everything after it: First Contentful Paint first, then Largest Contentful Paint — one of the three Core Web Vitals Google uses as a page experience signal, alongside Cumulative Layout Shift and Interaction to Next Paint. A good LCP is 2.5 seconds or less at the 75th percentile of page loads, per web.dev’s LCP reference, last updated September 4, 2025.

Now the limit, because caching gets sold as an SEO fix more often than it is one: a cached page still has to render. Caching does nothing about render-blocking CSS and JavaScript, oversized images, or a third-party script that takes two seconds to answer, so a fully cached site can still fail Core Web Vitals. Fix the server response with caching first — it is the cheapest half of the job — then measure again before you start rewriting the front end.

How caching works: cache hits and cache misses

Every caching layer follows the same sequence. When a request arrives, the cache is checked first. If a stored copy exists — a cache hit — it’s served immediately, typically in a few milliseconds. If there’s no copy — a cache miss — the request passes through to the origin server, which generates the response from scratch, stores a copy in the cache, and then serves it. The first visitor pays the full cost of building the page; everyone after them gets the fast copy until it expires or is purged.

The share of requests answered from the cache is the cache hit ratio: 90 hits in 100 requests is 90%. It is the one number worth tuning against, because every point you add is another visitor who skips the rebuild and another request your origin never sees.

Checking whether a page came from cache

For a single request, read the response headers. curl -svo /dev/null https://example.com/ prints them without the page body: a cache-status header says who answered, and Age says how many seconds the stored copy has existed. Fastly-fronted sites return X-Cache: HIT or X-Cache: MISS, Cloudflare sends cf-cache-status, and most page-cache plugins add a header of their own; Fastly’s guide to checking cache documents the HIT/MISS-plus-Age pattern. An Age of 0 right after a purge means you are looking at a freshly built copy.

For the whole site, use the hit ratio your CDN dashboard already reports. Gcore’s cache hit ratio guide, updated April 24, 2026, puts a good ratio above 80%, says a well-configured cache for static files — images, scripts, stylesheets — should reach 95% or better, and describes poorly optimized setups sitting near 70%. Read those as general benchmarks rather than pass/fail thresholds: a site that is mostly logged-in or personalized has less it can cache and will legitimately run lower, so the comparison that matters most is your own ratio this month against last.

Three things drag a ratio down: TTLs so short that copies expire before they are reused, query-string URLs such as ?utm_source=newsletter that the cache stores as a separate object for every variation, and cookies or a broad Vary header that make ordinary pages look personal and therefore uncacheable. A low ratio is not cosmetic — it means your visitors are still paying the origin build time that caching was supposed to remove.

Other kinds of cache: CPU, DNS, and PHP OPcache

“Cache” is an overloaded word, and this page is about caching web content. Three neighbors get confused with it. CPU cache memory — the L1, L2, and L3 caches inside a processor — is hardware that applies the same idea at nanosecond scale, and it is nothing you configure on a website. A DNS cache stores name-lookup results, and each record’s own TTL decides how long they live, which is why flushing DNS is a separate operation from clearing a browser cache and why an edited record takes time to propagate. PHP OPcache stores compiled PHP bytecode rather than content, so it sits alongside the five content caches — page, browser, object, database, and CDN — rather than inside them.

Types of caching

Most sites combine five kinds of caching, each working at a different layer of the stack:

• Page caching stores the entire HTML output of a web page in memory or on disk, so subsequent requests are served without regenerating the page — the biggest single win for most sites. On WordPress, enable it with a caching plugin such as WP Super Cache or W3 Total Cache, or at the server level with NGINX’s FastCGI cache, which is how managed hosts typically implement it.
• Browser caching stores static assets — images, CSS, and JavaScript — on the visitor’s own device for as long as the Cache-Control header sent with each file allows, so a repeat visit skips those downloads entirely. It’s also why “clear your cache” is the standard fix for a stale page: the browser is showing its stored cached page instead of fetching your latest version.
• Object caching stores the results of expensive operations — most often database queries, computed values, and API responses — in RAM using a key-value store such as Redis or Memcached, so repeat requests skip the database entirely. WordPress ships a built-in object cache that lasts only for a single page load; a persistent back-end like Redis makes it survive across requests. This is also how database caching happens in practice on a CMS: a persistent object cache keeps frequent query results in memory, cutting query latency and read pressure on the database server. Managed hosts differ on how you get one — some bundle it, others sell it as a paid per-site add-on — so check your provider’s current plan documentation before assuming Redis is switched on.
• CDN caching stores copies of your site’s static files — images, CSS, JavaScript — on a Content Delivery Network’s edge servers, so each visitor is answered from the location nearest to them, cutting load times and origin-server traffic. Setup is usually a matter of signing up with a provider and pointing your DNS at it.

For step-by-step setup instructions, see DreamHost’s comprehensive guide to website caching.

Cache-Control headers and TTLs

Two header values do most of the work, using the directives documented in MDN’s HTTP caching guide. On a versioned asset — app.4f2c1b.css, renamed at every release — send Cache-Control: public, max-age=31536000, immutable: one year, safe because the filename changes whenever the file itself does, a technique called cache busting. On an HTML page, Cache-Control: public, max-age=600 keeps the copy for ten minutes, so an edit goes live almost immediately. Expires is the older equivalent, and when a response carries both, max-age wins.

Choosing the right caching method

Match the caching type to the problem you actually have:

• Page caching — use it for pages that look the same to every visitor, like blog posts, marketing pages, and documentation. Exclude carts, checkouts, and logged-in views, which must stay personal.
• Object caching — add it when dynamic pages repeat expensive database queries, such as busy WooCommerce or membership sites where full-page caching can’t apply.
• CDN caching — add it when your audience is geographically spread out or your pages are heavy with images and media.
• Browser caching — enable it for static assets on virtually every site; it’s the cheapest performance win available.

Cache vs. cookies

Cache and cookies both store data in the visitor’s browser, but they do different jobs:

• Cache stores copies of a site’s resources — images, CSS, JavaScript, whole pages — so repeat visits load faster. Clearing it simply forces the browser to re-download the site’s files.
• Cookies store small pieces of user data — login sessions, preferences, tracking IDs — so a site remembers who you are between visits. Clearing them signs you out of websites and resets saved preferences.

Clearing a cache, layer by layer

Each layer caches independently, so clearing one does not clear the others — that is why a page can still look old after you emptied your browser cache. Work down the ladder in order and stop when the fresh version appears.

1. Rule out your own browser. Hard-reload the page (Ctrl+F5 on Windows, Cmd+Shift+R on macOS) or open it in a private window. If the new version shows up there, only your browser was holding a stale copy and the site itself is fine.
2. Purge the page cache on the site. That is a button in your caching plugin or in your host’s control panel. On DreamPress, the built-in NGINX server cache is purged from wp-admin with the pre-installed Nginx Helper plugin.
3. Purge the CDN. Edge nodes keep their own copies, and purging your origin never touches them. Purge the specific URL where you can, and save “purge everything” for emergencies, because it sends every node back to your origin at once.
4. Re-check the headers. Request the URL again and confirm you are getting a new copy: a MISS on the first request, a HIT on the next, and an Age counting up from 0.

If you do nothing at all, each copy expires on its own when its TTL runs out — minutes to hours for HTML, up to a year for a versioned asset. Purging just means not waiting for that expiry — together, purging and TTL expiry are what developers call cache invalidation.

Cache warming: preloading pages after a purge

Cache warming — also called cache preloading — means rebuilding cached copies proactively after a purge, a deploy, or a TTL expiry, instead of waiting for a visitor to trigger the rebuild. Without it, the first person to request each purged page pays the full cache-miss cost of building it. In practice, warming is a plugin feature: WP Rocket’s Preload and WP Super Cache’s preload mode crawl your URLs and regenerate copies in the background, and NGINX setups pair a purge with a preload in plugins built for that server cache. It matters most on sites that purge everything on every deploy, and on long-tail pages whose TTL expires before the next visitor arrives; a small site with steady traffic can simply let the first visitor after each purge warm the page.

Common caching failures and how to fix them

The hardest call in caching is the TTL. Set it too long and visitors see a stale price or last week’s headline; set it too short and pages are rebuilt so often that your back-end does the work anyway and the cache stops paying for itself. That is why HTML is usually given minutes to an hour while images, CSS, and JavaScript get days to weeks. Four failures account for most caching bug reports:

A stale page after publishing. You updated a post and the old HTML keeps serving, because the page cache still holds the previous copy. Purge that URL, then shorten the HTML TTL to minutes to an hour on pages you edit often and leave versioned static files on their long max-age.

One visitor served another’s cart or logged-in view. A personalized response was stored in a shared cache. Send Cache-Control: private on those responses — or no-store for anything sensitive — and exclude cart, checkout, account, and logged-in paths from page caching entirely.

Two page caches fighting. Content stays stale after a plugin purge because a caching plugin and a server-level page cache each hold a copy, and each purge clears only one. Keep a single page-cache layer: if your host caches at the server level, do not add a page-caching plugin on top.

A hit ratio near zero. Query strings or cookies have split one page into thousands of distinct cache objects, so almost nothing is ever reused. Normalize or ignore marketing parameters in the cache key, and stop setting cookies on static assets.

Caching best practices

Set long TTLs on static assets — days or weeks, or up to a year if you use versioned filenames, since renaming a file on each release makes the old cached copy irrelevant automatically.

Never cache anything tied to a session: cart, checkout, account pages, logged-in views, or personalized pricing. One visitor’s data sitting in a shared cache costs far more than a slow page does.

Purge on the events that change your output — publishing or editing a post, a plugin or theme update, and every deploy — instead of waiting for the TTL to run out.

Check what your host already provides before adding a plugin: many hosts cache at the server level, and two page caches fighting each other cause more stale-content bugs than they fix.

What caching costs

Most caching is free, and the paid parts are cheap next to the server time they save. Browser caching costs nothing — it is a couple of response headers your server already sends. Page caching is free at the plugin level (WP Super Cache and W3 Total Cache are both free in the WordPress.org plugin directory) and included at the server level on managed plans, while premium caching plugins are sold as annual subscriptions. CDNs commonly have a free tier, with paid plans billed by traffic or requests.

Two costs surprise people. An object cache such as Redis holds data in RAM, so on a self-managed VPS or dedicated server it can mean a resource or plan upgrade, and managed hosts differ on whether it is bundled. And every layer you add costs attention: purge discipline after each release, plus the hours someone spends chasing a stale-content bug. Against that, caching cuts origin requests and bandwidth, so a smaller plan carries the same traffic. The trade is worth it for nearly every site, as long as you keep the number of layers small enough to reason about.

For a full walkthrough of measuring and improving your site’s speed, see Everything You Need To Know About Speeding Up WordPress.