A practical guide to speeding up a Drupal 10 and 11 website: from hosting through caching and images to finding slow modules.
Properly configured, Drupal is very fast. Smaller websites usually don't need any special tuning. Problems arise with larger projects where the basic configuration isn't enough, or on websites where something got switched off along the way. Here is the approach we use.
1. Hosting and PHP
The foundation is quality hosting with a current PHP version, OPcache enabled and enough memory. The difference in speed between an old and a current PHP version is usually noticeable.
2. Caching in core
Drupal 10 and 11 have three important modules in core: Internal Page Cache for anonymous visitors, Dynamic Page Cache for logged-in users and BigPipe, which sends the main part of the page immediately and fills in slower parts afterwards. All of them should be enabled.
In the admin under Configuration → Development → Performance, set the maximum cache age for browsers and proxies and enable CSS and JavaScript aggregation.
3. Images
- Use image styles and responsive images, not originals.
- Convert to WebP or AVIF, Drupal can do it right in the image styles.
- Load images below the fold only when scrolled to (lazy loading is in core).
4. Views and custom blocks
For Views, set tag-based caching if the content allows. For custom blocks and modules, set cache tags, contexts and max-age correctly. A single misconfigured max-age: 0 can disable caching for the whole page.
5. Redis or Memcache
For larger websites it pays to move the cache from the database to Redis or Memcache. You need hosting support and the corresponding module.
6. Reverse proxy and CDN
With high traffic, Varnish or a CDN helps by serving pages and files from memory without loading Drupal.
7. Third-party scripts
Often it isn't Drupal slowing the website down but tracking codes, chats and widgets. Load them via Google Tag Manager, only after consent and only those you really use.
Still slow?
You need to measure. PageSpeed Insights helps from the visitor's point of view, and tools like Webprofiler or server-side profiling help look inside. The culprit is often a single module or one badly written database query. Switch off developer modules in production after debugging.
Speed isn't a one-off task. Every new module and every new script can make it worse, so it pays to check it regularly.
