Article Speed & Performance

How page caching works

Why rebuilding a page from scratch on every visit is expensive, and what caching actually does instead.

iFastHosting Support Team Updated 26 August 2026 9 min read Intermediate

Most websites built on a content management system do not store a finished page anywhere. They store the pieces — the content, the template, the theme's logic — and assemble them fresh every time somebody asks for the page, running whatever code and database queries that assembly requires. Doing that once, for one visitor, is not usually a problem. Doing it again, from scratch, for every single visitor requesting an identical page is the part caching exists to avoid.

The basic idea

Page caching takes the finished HTML output of a page — the result after all the assembly work is done — and stores it somewhere fast to retrieve. The next time the same page is requested, the server checks whether a valid cached copy already exists and, if it does, serves that copy directly instead of rebuilding the page from its component pieces. The visitor gets an identical result far more cheaply, because none of the database queries or template logic ran a second time.

Without caching	With caching
Every request runs the full assembly process again	The first request runs it once; later requests reuse the result
Server load scales directly with traffic	Server load for that page barely increases with more visitors
Server response time is consistent but higher	Server response time drops sharply for anything served from cache

Several layers, not just one

"Caching" covers more than one mechanism, and they solve different parts of the problem:

Page caching stores the entire finished page and serves it whole, which is the fastest option where it applies cleanly.
Object caching stores the results of expensive individual operations — a specific database query, a computed value — reused across different pages that each need the same piece of data, without needing to cache an entire page as one unit.
Browser caching is different again: it tells a visitor's own browser to keep a copy locally and skip asking the server at all for a while. See setting browser caching headers for that side of it specifically.
A CDN layers on top of all of this, distributing cached copies to servers physically closer to visitors. What a CDN does, and when you need one covers that layer on its own.

A well-configured site typically uses several of these together, each handling the part it is actually good at rather than one mechanism trying to do everything.

Why a cached page is not simply "the same page, but faster"

The saving comes specifically from skipping the assembly work — not fetching content from a database, not running template logic, not executing plugin code that runs on every page load. For a simple page that work might be trivial anyway; for a page built from many components, each querying data independently, it can be the majority of the total time the server spends before it can respond at all. That is why caching often produces its largest gains on the most complex pages, not the simplest ones.

Where the cached copy actually lives

A cached page or object has to be stored somewhere, and where matters for how quickly it can be retrieved. A simple setup writes cached pages as plain files on disk, which is straightforward and works well for page caching on typical shared hosting. A more involved setup uses an in-memory store — Redis and Memcached are the two most common — which keeps cached data in RAM rather than on disk, retrieving it faster still because reading from memory has no disk access involved at all. Object caching in particular benefits from an in-memory store, since it is designed for a large number of small, frequent lookups rather than serving a smaller number of complete pages.

Which of these a given site uses is mostly decided by the platform and hosting environment rather than something to configure from scratch — the practical point is only that "cached" is not one single mechanism with one single speed, and a page served from an in-memory object cache and a page served from a cached file on disk can both legitimately be described as caching while performing quite differently under heavy concurrent load.

What breaks when caching is wrong, not just when it is missing

Stale content is the standard risk

A cache does not know a page has changed unless something tells it. Publish an update and the old, cached version can keep being served until the cache expires or is cleared, which is why every caching system needs a way to invalidate — clear — specific cached pages the moment their underlying content changes, rather than only on a timer.

The more serious failure is caching something that is personal to one visitor and serving it to everyone else — a cart, an account page, a page showing a signed-in name. This is exactly why page caching has to exclude anything that differs per visitor rather than applying blindly to every URL on the site; caching a site that changes constantly covers how to draw that line correctly.

How to tell if a page was actually served from cache

Many caching setups add a response header or an HTML comment indicating a cache hit, visible in your browser's developer tools under the network panel. Beyond that, the clearest practical signal is server response time itself: a cached page typically responds in a small fraction of the time an equivalent uncached page takes, because almost none of the assembly work actually happened for that specific request.

Where this fits with everything else in this section

Caching addresses server-side response time specifically — it has no effect on image weight, script size, or layout stability, all of which are decided by the page's actual content rather than by how it is generated. It works alongside, not instead of, the fixes covered elsewhere in this section: a well-cached page that is still carrying unoptimised images and excess JavaScript is faster to generate but still slow to fully load. How to cache a site that changes constantly is the practical next step if a site genuinely cannot use simple, blanket page caching because too much of it is personalised or updates too frequently.