Exercise 2: Why Page Caching Fails Logged-In Users, and What a Persistent Object Cache Adds — Possible Solution ==================================================================== WHY PAGE CACHING DOESN'T HELP LOGGED-IN USERS ------------------------------ Per this chapter, "page caching mostly benefits anonymous, logged-out visitors - logged-in users often see personalized dashboard content that can't be cached wholesale the same way." Page caching works by storing one single, fully-rendered HTML copy of a page and serving that identical copy to every subsequent visitor. Logged-in users, by contrast, typically see content that genuinely differs per user (their own account details, personalized dashboard widgets, user-specific messages) - serving one shared cached page to all of them would either show every logged-in user the SAME wrong content, or force the caching system to skip caching for logged-in users entirely, which is exactly what real caching setups generally do. WHAT OBJECT CACHING SOLVES INSTEAD ------------------------------ Per this chapter, "object caching solves a related but different problem: caching the results of individual, expensive database queries in memory, so the same query run repeatedly across many requests doesn't have to hit MySQL every single time." Rather than caching an entire finished page, it caches smaller, reusable pieces of work - individual query results - that can still be reused even when the overall page output itself differs per visitor, since many logged-in requests still repeat many of the same underlying database lookups even if the final rendered page looks different for each user. WHY WORDPRESS'S OWN BUILT-IN OBJECT CACHE ISN'T ENOUGH ON ITS OWN ------------------------------ Per this chapter's own tip-box, "WordPress ships with a basic, built-in object cache - but it's non-persistent, meaning it only lasts for the duration of a single page request and provides no benefit across separate requests." This built-in cache can still avoid re-running the identical query multiple times WITHIN one single page load, but it's wiped clean the moment that request finishes - the next visitor's request starts with a completely empty cache again, gaining nothing from the previous visitor's own cached queries. WHAT A PERSISTENT OBJECT CACHE ADDS ------------------------------ Per this chapter, "a genuinely persistent object cache (commonly backed by Redis or Memcached) is what actually delivers repeated-query savings across many different visitors and requests over time." Unlike the built-in non-persistent cache, a persistent backend keeps cached query results available across many separate requests and many different visitors, meaning a query one visitor triggers can genuinely save database work for a completely different visitor's later request too - delivering the real, ongoing performance benefit the non-persistent default cache structurally cannot provide. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why page caching can't serve personalized, logged-in content using this chapter's own reasoning, and distinguishes the built-in non-persistent object cache from a genuinely persistent one, explaining exactly what capability the persistent version adds that the default lacks.