WordPress
Page cache
Page cache is a stored copy of the finished HTML for a URL, so PHP and MySQL do not run for the next visitor. It is usually the largest single speedup available to a WordPress site that serves mostly anonymous traffic.
How it is measured
Check a response header: x-cache-status: HIT, x-cache: HIT, or a plugin comment at the bottom of the source. Run curl -sI https://example.com/ twice and compare. A cached response often has a time to first byte under 80 ms, while an uncached WordPress response takes 400 ms or more.
Rules decide what is skipped. Most caches bypass requests with a wordpress_logged_in cookie, a cart cookie, POST requests, and certain query strings. Lifetime is set by a TTL and by purge rules on publish.
Worked example
A local bakery's WordPress site has 6 pages and gets 900 visits on a Saturday morning after a TV mention. Without a cache the VPS climbs to 100 percent CPU and returns 502 errors at around 40 concurrent visitors. With the nginx FastCGI cache on, the same traffic is served from disk at 15 ms per page.
The order form at /order/ is excluded, so it still runs PHP. The owner's price edit on the menu page does not appear for ten minutes until the TTL expires, because purge on update was off.
How it differs
A page cache saves the whole page, while an object cache saves bits of data used to build one. If the page cache hits, the object cache is never consulted. When the page cache misses, such as for logged-in users, the object cache is what keeps the page from being slow. A CDN can store the same HTML at an edge location nearer to the visitor.
Common errors
Caching pages that include a cart or account details. Not purging after publish. Stacking two page caches, such as a plugin and a host cache, and serving stale pages from one. Testing only while logged in and concluding the cache does nothing. Forgetting that a query string like utm_source can create a separate cache entry for each campaign.
In practice
Run curl -I twice on your homepage and a product or post page. Confirm a HIT on the second request and a bypass on /cart/ and /my-account/. Set a purge on publish and check the first request after an edit.