Drupal performance optimization — practical steps
Drupal is fast when configured correctly. Most performance problems are solvable without changing servers.
A slow website costs money. Every second of loading time reduces conversions, damages SEO and frustrates users. Drupal itself is not slow — but a misconfigured Drupal installation can be very slow.
Layer 1: Drupal's built-in cache
Drupal includes a multi-layered caching mechanism. The first step when diagnosing a slow site is to check whether caching is actually working.
Internal Page Cache — stores page HTML for anonymous users. If disabled, every visit regenerates the page from scratch.
Dynamic Page Cache — stores page fragments that do not depend on the user. Works for logged-in users too.
BigPipe — delivers the page skeleton immediately and fills in personalised sections afterwards. Noticeably improves perceived load time for logged-in users.
All three should be enabled on production. Check /admin/config/development/performance.
Layer 2: External caching solutions
Drupal's built-in cache is good, but for serious performance you need external solutions.
Redis — memory-based cache store. Replaces Drupal's database-backed cache, significantly reduces database queries. Redis is the standard solution for medium to high traffic sites.
Varnish — HTTP reverse proxy that stores full page responses. For anonymous users, pages are served from Varnish without touching Drupal or the database. Varnish can serve thousands of requests per second — Drupal alone cannot.
CDN — delivers static files (JS, CSS, images) from a geographically nearby server. Cloudflare, Fastly, AWS CloudFront.
Layer 3: Database optimisation
Drupal generates many database queries. Slow queries are often the root cause of performance problems.
Slow query log — enable MySQL's slow query log to see which queries take more than 1–2 seconds.
Indexes — check whether frequent filters and sorts are indexed. Complex Views queries often run against unindexed columns.
Database cleanup — Drupal's watchdog table grows continuously. Regular cleanup (drush watchdog:delete --severity=info) keeps the database lean.
Layer 4: CSS and JS aggregation
CSS and JS aggregation (/admin/config/development/performance) — combines multiple files into one, reduces the number of HTTP requests. Should always be enabled on production.
Lazy loading — Drupal 9.2+ loads images with lazy loading by default. Make sure this has not been manually disabled.
WebP images — Drupal supports WebP via image styles. Same quality, 25–35% smaller file size.
Layer 5: PHP and server
PHP OPcache — compiles PHP code once and stores it in memory. Without OPcache, PHP re-parses files on every request. OPcache must be enabled with sufficient memory.
PHP version — PHP 8.3 is up to 30% faster than PHP 7.4. If your server is still on PHP 7.x, a version upgrade is one of the easiest performance wins.
HTTP/2 — allows multiple requests to be loaded in parallel over a single connection. Check whether the server uses HTTP/2.
How to diagnose
- WebPageTest — detailed load analysis with waterfall chart
- Google Search Console → Core Web Vitals — real user data, not lab conditions
- Lighthouse — in Chrome DevTools, detailed audit with priorities
- New Relic / Blackfire — PHP profiler showing exactly which code takes time
Typical results
A well-configured Redis + Varnish combination typically reduces average page load time from 3–5 seconds to under 500 milliseconds. CSS/JS aggregation and WebP images reduce page weight by 40–60%.
A performance audit is worth running before and after a major version upgrade — upgrades often bring new cache settings that need reviewing.
If your Drupal site is slow and the cause is unclear, get in touch — we run a technical review and identify the bottlenecks.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.