The art of not doing the work twice
Most requests ask for something computed moments ago for someone else. Caching exploits that: do the work once, keep the answer, hand it out until it expires. A single page view crosses several cache layers, each closer to the visitor than the last — and each answered layer means every layer behind it stays idle. That is why well-cached sites feel fast on modest shared hosting while uncached ones crawl on big servers.
- Browser cache — assets kept on the visitor's device, governed by HTTP cache headers; the fastest request is one never sent.
- **CDN / edge cache** — copies at network edges, shared between visitors.
- Server page cache — full rendered pages stored by the web server or CMS plugin, skipping application and database entirely.
- Application & object caches — query results and computed fragments in memory stores like Redis, cutting repeated database work.
The famous hard part is invalidation: a cached answer is by definition potentially stale, and every layer needs a story for 'the content changed'. The practical toolkit is small — expiry times (TTLs) sized to how stale is tolerable, explicit purges on publish, and versioned asset filenames that sidestep invalidation entirely. Debugging follows the same map: 'I updated the site and nothing changed' is almost always one layer still serving its old copy.