Optimizing Drupal: A Practical Performance Checklist

By Greg Nowak. Updated 28 July 2026.

Drupal performance work should make the website more useful, not merely produce a more flattering score. For business owners, operations leads, and agency teams, the meaningful questions are whether important pages load promptly, interactions feel responsive, and visitors can complete their task without the interface shifting underneath them.

The best results usually come from fixing a few structural problems: ineffective caching, an overloaded theme, oversized images, unnecessary JavaScript, or slow third-party services. Start with evidence, connect each problem to a business-critical page, and leave minor score-chasing until later.

Measure the pages the business depends on

Test a representative set rather than the homepage alone: a landing page, content detail page, search or listing page, conversion path, and any logged-in workflow used by customers or staff. Run mobile and desktop tests, because mobile devices and networks often expose problems that office laptops conceal.

PageSpeed Insights combines field data from real visits, when sufficient data exists, with a controlled Lighthouse test. Field data is the better indicator of what users experience; lab data is more useful for reproducing a problem during development. Also remember that Lighthouse cannot measure Interaction to Next Paint directly because there is no real user interaction. Its Total Blocking Time diagnostic is a useful laboratory proxy, not a replacement for field INP.

Record the current Core Web Vitals—Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift—alongside server response time, the affected template, and the three most credible diagnostics. This creates a baseline that can be checked after each release.

Drupal performance triage: where to look first

Observed problem	Likely area	First practical check
Anonymous pages are slow on repeated visits	Page cache, reverse proxy, or CDN	Inspect cache headers and compare the first and second requests
Logged-in pages remain heavy	Dynamic Page Cache, Views, or personalized blocks	Review cacheability metadata and expensive queries
The main content appears late	Server response, hero media, or render-blocking assets	Break LCP into backend, resource-discovery, and download delays
Clicks and typing respond slowly	Long JavaScript tasks or third-party code	Profile the interaction and remove work from the main thread
The page jumps during loading	Images, embeds, fonts, or BigPipe placeholders	Reserve dimensions and space before content arrives

Get Drupal’s caching layers working together

Internal Page Cache stores complete responses for anonymous visitors and is enabled by default in modern Drupal. On a conventional content or campaign site, a second request to an unchanged public page should normally become a cache hit. Treat anonymous personalization carefully: a cart, session-specific block, or similar variation may require a different caching strategy. Sites already using a properly configured reverse proxy or CDN may choose to rely on that external page cache instead.

Dynamic Page Cache is useful for anonymous and authenticated traffic. It reuses the cacheable portions of a page while Drupal turns genuinely variable components into placeholders. When it underperforms, the cause is often custom code or a contributed component with incomplete cache tags, contexts, or maximum-age information.

BigPipe can improve perceived speed on pages containing personalized or otherwise uncacheable components. Drupal sends the reusable page structure first and streams placeholder replacements afterwards. It works particularly well with Dynamic Page Cache, but late content still needs reserved space to avoid layout shifts.

Retire outdated AdvAgg assumptions

Advanced CSS/JS Aggregation was a sensible recommendation for older Drupal installations. It is no longer the default answer. The project’s current guidance says AdvAgg is obsolete on Drupal 10.1 or later and Drupal 11 because core now includes most of its relevant functionality; those installations are advised to uninstall it.

Begin with Drupal’s production settings at admin/config/development/performance. Test core CSS and JavaScript aggregation, then inspect which libraries each template attaches. Aggregating ten unnecessary scripts still leaves ten unnecessary scripts. Removing a library from pages that do not use it is generally more valuable than finding a more elaborate way to bundle it.

Teams deploying custom assets should also review their *.libraries.yml versioning. Since Drupal 10.1.2, an explicit library version participates in the hash used for aggregated files. If the referenced CSS or JavaScript changes, update that version—or omit it and use Drupal’s content-based behavior—to prevent stale assets at browsers and edge caches.

Run a quick technical check

These commands provide a useful first look. Run them in the appropriate application environment and replace the example hostname:

drush pm:list --status=enabled --type=module | grep -E 'page_cache|dynamic_page_cache|big_pipe'
drush pm:enable page_cache dynamic_page_cache big_pipe -y

for request in 1 2; do
  curl -sI https://www.example.com/ | grep -iE 'cache-control|age|x-drupal-cache|x-drupal-dynamic-cache'
done

A first X-Drupal-Cache: MISS followed by HIT is expected for a cacheable anonymous page using Internal Page Cache. Do not diagnose from one header alone: a CDN can serve the response before Drupal, and the Internal Page Cache documentation notes that X-Drupal-Dynamic-Cache may remain MISS when the complete page is already handled by Internal Page Cache.

Turn diagnostics into a shippable backlog

Prioritize server response and cache misses first, then image delivery, unnecessary JavaScript, render-blocking assets, and layout stability. For each item, record the affected page, user impact, likely owner, proposed change, release risk, and measurement to repeat afterwards. This turns a vague “make Drupal faster” request into work that hosting, backend, frontend, content, and analytics teams can divide sensibly.

When specialist help is worthwhile

Outside help becomes useful when stable pages keep missing cache, authenticated workflows remain slow, releases repeatedly damage Core Web Vitals, or responsibility is bouncing between Drupal, the theme, hosting, the CDN, and third-party scripts.

Greg can help isolate the bottleneck, separate safe improvements from architectural work, and give your team a prioritized implementation plan. If your performance report has produced more questions than decisions, start a practical conversation about the site.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about Drupal performance Get in touch with Greg.

Sources

Last modified

2026-08-12