Full Page Cache (FPC)
Full Page Cache (FPC) stores the entire generated HTML of a page so the next visitor gets it instantly, without the server rebuilding it. Instead of running your whole application for every request, you serve a saved copy. It is one of the most effective ways to make a site fast under heavy traffic.
The idea
Without FPC:
request -> app runs -> queries DB -> renders HTML -> response (slow, every time)
With FPC:
request -> cache hit -> saved HTML -> response (fast)
\-> cache miss -> app runs once -> store -> response
The first visitor pays the cost; everyone after gets the cached page.
Where the cache lives
FPC can sit in several places: a reverse proxy (like Varnish or Nginx), a CDN at the edge, or inside the application. The closer to the user, the faster.
User -> CDN (edge cache) -> Reverse proxy -> App -> Database
^ fastest hit ^ next best ^ last resort
Cache headers
HTTP headers tell caches how long to keep a page.
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: public, max-age=300
<html>...full page...</html>
max-age=300 means “reuse this for 5 minutes”.
Invalidation
The hard part of caching is knowing when to throw away the stale copy. Common strategies:
- Time-based (TTL): the page expires after N seconds.
- Event-based: when content changes, purge the matching page.
- Tag-based: group pages by tags and purge a whole tag at once.
Editor updates a product -> purge "/products/42" -> next request rebuilds it
Advantages
- Huge speed boost; many requests skip the app entirely.
- Lower server and database load.
- Handles traffic spikes gracefully.
Disadvantages
- Risk of serving stale content if invalidation is wrong.
- Hard to cache personalized pages (logged-in user, cart).
- Adds infrastructure and rules to maintain.
When to use it
FPC fits pages that are the same for many users and change rarely: articles, product pages, landing pages. Avoid caching highly personalized pages, or cache only the shared parts and load personal bits separately.