The front cache & Drupal's page cache

Two layers serve whole pages before Drupal does any real work: the Nginx front cache (BOA calls it Speed Booster) and Drupal's own page cache, which on BOA lives in the fast Redis/Valkey object cache. They're tuned to work together, and the defaults are right for almost every site — but both have a dial, and there's a right and a wrong way to make a page dynamic.

Grav and Textpattern: BOA renders their vhosts without Speed Booster, so nothing on this page applies to them. What each relies on instead is in the fine print on Grav CMS on your server and Textpattern CMS on your server.

Speed Booster: the Nginx micro-cache

Speed Booster runs in micro-caching mode: a page may be served straight from Nginx for a short window — 10 seconds by default — without PHP or Drupal running at all. Ten seconds sounds tiny, but on a busy page it means one page build serves everyone who arrives in that window, which flattens traffic spikes beautifully while keeping content essentially fresh.

It's smarter than a blunt page cache, and worth knowing exactly how:

• Logged-in users are cached too — each in their own bin. The cache key includes the visitor's session, so logged-in visitors get a private micro-cache (same short window) that can never leak between users, and a separate device class (desktop, tablet, smartphone) keeps mobile themes safe to serve.
• It steps aside when it must. Any form submission (POST) switches the cache off for that visitor for 15 seconds, and requests to /user*, /admin*, cart and checkout paths always bypass it — so editing, logging in and shopping never see a stale page.
• Crawlers get much longer. Known robots and search-engine spiders are forced to accept a much longer cache window than human visitors, so bot swarms never stampede your site.
• You can raise the anonymous window. speed_booster_anon_cache_ttl sets the anonymous-visitor TTL in seconds. Values of 10 or below are ignored — 10 is the floor.
• On a .dev. preview URL the window drops to 1 second, so development work is effectively uncached at this layer too.

; sites/<your-domain>/modules/boa_site_control.ini
speed_booster_anon_cache_ttl = 30

If you raise the TTL meaningfully, consider enabling the Purge and Expire modules on your site: they selectively purge affected front-cache entries when a node or comment changes, so a longer TTL doesn't mean serving stale content until it expires. And if you're on Drupal 6 or 7, read the AdvAgg section below — a raised TTL is exactly what turns a routine cache clear into temporarily broken styling.

Drupal's page cache stays on — here's why

BOA keeps Drupal's own full-page cache enabled, and stores it in Redis/Valkey. The two layers cover for each other: the front cache absorbs the repeat traffic within its few-second window, and the page cache makes the request that misses the front cache (the first one after each window expires) nearly free as well, because the page comes ready-made from memory.

That's why disable_drupal_page_cache = TRUE is almost always the wrong move. With the front cache holding pages for only seconds, turning the page cache off means Drupal rebuilds pages from scratch all day — your site gets noticeably, randomly slower for every anonymous visitor, even if you raise the front-cache TTL. (Legacy note: if the Boost module complains that the page cache is on, let it complain — BOA's default is deliberate.)

Both work in either control file — see Platform and site INI settings for the mechanics.

When a cache clear breaks your styling: AdvAgg

This one shows up almost exclusively on Drupal 6/7 sites that raised the front-cache TTL: someone clears the site's caches, and for a while visitors get pages with broken or missing CSS and JavaScript — then it heals on its own.

The mechanism: Drupal 6/7's standard aggregation deletes its old aggregate CSS/JS files when caches are cleared, but pages already sitting in the front cache still reference those now-deleted files, so every visitor served from the cache for the rest of the window gets a page whose stylesheet links go nowhere. With the default 10-second window nobody ever notices. With a raised TTL, the breakage lasts as long as your window has left to run.

The remedy is the AdvAgg (Advanced CSS/JS Aggregation) module, bundled with every BOA-built Drupal 6 and 7 platform — it lives in the platform's shared o_contrib/o_contrib_seven module directories, and a copy you upload to sites/all/modules/advagg is respected as an override (see Modules BOA manages for how the bundled extras work). AdvAgg is built around exactly this problem: it generates aggregates with stable names and leaves the existing aggregate files in place on a flush instead of purging them, so pages cached before the clear keep rendering correctly after it.

Enabling the module is all you do — BOA notices. The nightly maintenance pass detects AdvAgg enabled on your site and sets advagg_auto_configuration = TRUE in your site's control file, which applies a tuned, core-version-specific AdvAgg profile (bundler, compression, gzip, async generation) at the settings level. If you later disable the module, the same pass flips the setting back to FALSE — it always mirrors the module's actual status, so there is nothing to maintain. (On .dev. preview URLs the tuned profile is not applied, in line with the rest of the no-cache dev view. And on Drupal 8 and newer none of this machinery applies — BOA doesn't bundle or auto-configure AdvAgg there; if you want it, you add and configure it yourself like any contrib module.)

Making one URL truly dynamic (the right way)

First, two cases this section is not for: a one-off uncached look at a page (append ?nocache=1 to the URL instead — that single request skips both page-level caches), and development (use the .dev. preview URL).

Sometimes one page genuinely must be rebuilt for every anonymous visitor — a per-visitor result with no cookie or form involved. Don't disable caching site-wide for that. Add a targeted exception to your site's local.settings.php instead. On Drupal 6/7:

if (preg_match("/^\/(?:live-results|stock-ticker)/", $_SERVER['REQUEST_URI'])) {
  header('X-Accel-Expires: 1'); // skip the Nginx front cache for this URL
  $conf['cache'] = 0;           // skip Drupal's page cache on the fly
}

The first line exempts the URL from Speed Booster; the second keeps Drupal from serving it out of the page cache. On Drupal 8+ the front-cache line is the same, and the page-cache line becomes the config override $config['system.performance']['cache.page.max_age'] = 0;. Everything else on the site stays fully cached.

Related

• The Redis/Valkey object cache — the layer the page cache is stored in, and everything about cache bins.
• PHP opcache & APCu — why deployed changes take about a minute to appear.
• Something looks broken — when a stale page means a cache needs clearing.