Basics of Drupal Performance Optimizationfor Drupal 8 , 9 , 10 , and 11

Think of an uncached Drupal page like a restaurant that cooks every dish completely from scratch for every single customer, even when a hundred people in a row order the exact same burger. It works, but the kitchen is drowning. Caching is Drupal's answer: cook the burger once, keep a stack of them warm, and only fire up the grill again when something actually changes — a new recipe, a different customer, or enough time passing that "fresh" matters again. This lesson is your map of the whole kitchen before you start learning individual techniques.

What you'll learn in this lesson

• The three layers of caching Drupal gives you, and roughly when each one applies
• Why "premature caching" can be just as harmful as no caching at all
• The vocabulary (cache tags, contexts, max-age) you'll meet in depth across this whole tutorial

The three layers, from cheapest to most expensive

Every performance win in this tutorial is really about moving work to a cheaper layer, or skipping it entirely. From fastest to slowest:

• Page cache (anonymous only) — the entire HTML response for a URL, served with almost no Drupal bootstrap at all. Fastest possible layer, but only works for visitors who aren't logged in.
• Render/dynamic cache — individual pieces of a page (a block, a view, a render array) cached separately, so a logged-in user's personalized page can still reuse the 90% that's identical for everyone.
• Application-level cache (Cache API) — arbitrary data your own code computes and stores, keyed however you like — the tool you reach for when neither of the above fits.

The three concepts that make cache invalidation safe

The hardest problem in caching isn't storing data — it's knowing when to throw it away. Drupal solves this with three cooperating pieces of "cache metadata," each answering a different question:

• Cache tags answer "what changed?" — a tag like node:42 lets Drupal invalidate every cached thing that depended on node 42, the instant it's saved, without scanning the whole cache.
• Cache contexts answer "does this vary by visitor?" — a context like user.roles tells Drupal to keep separate cached copies per role, rather than accidentally showing an anonymous visitor an admin's cached page.
• Max-age answers "how long is this good for, even if nothing tells us it changed?" — a simple time-based expiry, measured in seconds.

Quick check: a block shows completely different content depending on whether the visitor is logged in, but is otherwise identical for every logged-in user and every anonymous user. Which single concept from this lesson controls that distinction — tags, contexts, or max-age? (Contexts — specifically something like the built-in user.roles or an authentication-status context, since the variation is about *who's looking*, not *what changed* or *how long it's valid*.)

Key takeaways

• Caching has three layers — page, render/dynamic, and the application-level Cache API — each suited to a different kind of problem.
• Cache tags handle "what changed," cache contexts handle "does this vary by visitor," and max-age handles "how long until this expires regardless."
• Don't cache speculatively — caching solves a measured slowness problem and introduces real complexity of its own.

Coming up next

Next, we start with the single biggest, cheapest win available: Drupal's Internal Page Cache for anonymous visitors — the layer that can make an entire page nearly free to serve.