← All notesDRUPAL·28 Nov 2024·5 min

Drupal performance secrets nobody tells you

After a decade of Drupal optimisation, the counterintuitive tricks that actually move the needle. Spoiler: it isn’t just caching.

Everyone knows about caching. Everyone knows about CDNs. These are the ‘eat your vegetables’ of performance — necessary, dull, and not where the interesting wins live. After tuning Drupal sites for over a decade, I've found the real gains hide in places nobody writes conference talks about.

Your slow query log is lying to you

It shows the queries that took longest individually. Dramatic, obvious, easy to fix. What it doesn't show is the query that ran 800 times at 5ms each — four seconds of death by a thousand paper cuts, invisible in the logs because no single one looks guilty. The profiler finds these; the slow-query log never will.

A legacy community site: dozens of fast queries adding up to a slow page. The score knew before the logs did.
Spec
Before
PageSpeed 31
After
PageSpeed 89
Tool
Lighthouse + Blackfire
Fix
Render path + caching

No single dramatic query — just a thousand small ones. The profiler found what the slow-query log hid.

A legacy community site: dozens of fast queries adding up to a slow page. The score knew before the logs did.

Views is powerful. Views is dangerous.

Views makes complex queries accessible. It also makes catastrophic queries easy. Every relationship is a JOIN; every filter without an index is a full table scan wearing a friendly UI. My rule: write the SQL you'd be happy to defend, then make Views produce that — not the other way around. If you can't explain what a View is doing to the database, it's probably doing something you wouldn't sign off on.

Cache the render, not just the data

Most performance work stops at the database and forgets the render pipeline. But building a page — theming, preprocessing, twig — is real CPU, repeated for every anonymous visitor unless you let it not be. Render caching and cache tags are Drupal's actual superpower; the trick is getting your cache contexts right so you cache aggressively without ever serving the wrong user the wrong thing.

  • Get cache tags right — invalidate precisely, so you can cache for hours instead of seconds.
  • Lazy-build the personalised bits with placeholders, so the heavy page is cacheable and only the dynamic fragment isn't.
  • Measure with a profiler under realistic data, not on a clean dev box with twelve nodes.

The fastest query is the one you never run; the fastest render is the one you serve from cache.

Sometimes the fastest Drupal site is the one with less Drupal. Static generation for content that changes weekly. Edge caching for anonymous traffic. Use the right tool for each job.

Still with me?

Got a Drupal build that deserves this kind of attention?