Drupal 11 performance tuning means configuring caching, reducing database work, and checking server software before launch. Done well, it lets anonymous pages hit cache and logged-in pages reuse shared parts.
Caching here means saving finished page parts for reuse. Database tuning means cutting repeated or slow queries. Server checks make sure PHP, the database, and memory caches can support both.
Table of Contents
- Start With Server Versions
- How Do Drupal Caches Divide the Work?
- What Does Drupal 11.3 Improve?
- How to Cut Database and Server Load?
Start With Server Versions
Drupal 11 needs PHP 8.3 or later and current database servers. Minimums are MySQL 8.0, MariaDB 10.6, PostgreSQL 16, or SQLite 3.45. The Drupal Association lists these floors in its PHP 8.3 and MySQL 8.0 requirements announcement.
Upgrade first if hosting falls short. Cache settings cannot fix an unsupported PHP or database version. This check also prevents failed upgrades and slow debugging later.
- Confirm PHP 8.3 or later on live and staging.
- Confirm database meets the minimum version above.
How Do Drupal Caches Divide the Work?
Drupal splits work across three core caches. Internal Page Cache stores full pages for anonymous visitors. Dynamic Page Cache stores shared parts for logged-in users, while BigPipe streams personal parts after the main page. Pantheon documentation describes this split in its Pantheon documentation on Drupal cache.
The maximum age at /admin/config/development/performance sets the max-age header and reverse-proxy retention. Pantheon documentation notes the default is 15 minutes with no minimum-lifetime setting. Shorter ages refresh content faster but raise origin load. A news article for anonymous readers can serve fully from cache. The same page for a logged-in editor reuses menus and blocks but builds personal bars separately.
What Does Drupal 11.3 Improve?
Drupal 11.3 cut cold-cache database and cache work by about one-third. Partially warm requests fell by up to one-fourth. The gains came from combined render, path-alias, and entity-load operations. The Drupal Association reports these results in its Drupal 11.3.0 release notes. The same release moved BigPipe to HTMX.
That sharply reduced JavaScript weight. It also skips loading BigPipe JavaScript when warm render caches can serve placeholders quickly. Cold sites still do full work on first builds. Warm sites see the largest savings. Test both states before promising faster times.
How to Cut Database and Server Load?
Drupal launch guidance directs teams to profile with Webprofiler and fix slow database queries. It also tells teams to uninstall development modules such as Devel. The Drupal Association wiki gives this sequence in its launch checklist. PHP OPcache keeps precompiled script bytecode in memory, so PHP skips recompiling each request.
Redis or Memcached moves cache bins off the database for busy sites. The Pantheon Learning Center explains this split in its Pantheon guide to Drupal performance. Enable OPcache first, then move busy cache bins to Redis or Memcached. Recheck Webprofiler after each change and keep Devel off production.
