Optimizing Drupal: A Practical Performance Checklist

By Greg Nowak. Updated 14 September 2026.

A slow Drupal site creates practical problems: visitors wait for landing pages, customers struggle with forms, and staff lose time in everyday workflows. Improving performance starts with finding where that waiting happens and giving someone responsibility for fixing it.

This checklist helps business owners, operations leads, and agency teams agree on what to investigate first. Start with a small set of important pages, check the evidence, and make changes you can measure after release.

Start with the journeys that matter

Choose a campaign landing page, a typical content page, a search or listing page, and a conversion journey. Include a logged-in workflow if customers or staff depend on one. Test mobile and desktop separately, and record whether each test uses an anonymous visitor or an authenticated account.

Use PageSpeed Insights for an initial assessment. Real-user field data shows how visitors experience the site; controlled lab tests help reproduce problems. Missing field data is not a pass. Where public reports lack coverage, consider your own real-user monitoring, especially for authenticated journeys.

The current targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, assessed at the 75th percentile and separated by device type. These measure loading, responsiveness, and visual stability. A Lighthouse score alone cannot confirm all three. See Google's Web Vitals guidance.

Use the symptom to choose the next check

Ask your team to identify the bottleneck before proposing a module, hosting upgrade, or theme rebuild. Use this table to assign the first investigation.

Check caching before buying more capacity

Internal Page Cache reuses complete pages for anonymous visitors. It assumes those visitors receive identical content, so anonymous carts or session-specific blocks need an explicit caching strategy. A correctly configured CDN or reverse proxy may provide the external page cache instead.

The browser and proxy cache maximum-age setting at admin/config/development/performance controls downstream caching; it does not set Internal Page Cache's own lifetime. Increasing it also requires a plan for keeping published content fresh. Drupal's Internal Page Cache documentation explains these distinctions.

Dynamic Page Cache supports reuse around personalized content. Investigate components whose cacheability metadata is missing or unnecessarily restrictive: tags describe dependencies, contexts describe variations, and maximum age describes freshness.

BigPipe can send the reusable page structure before streaming personalized components. Reserve space for those components so they do not push content around. Drupal's BigPipe documentation recommends pairing it with Dynamic Page Cache and explains placeholder customization.

Run a small, repeatable technical check

From the appropriate Drupal application environment, list the enabled cache modules:

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

If these modules fit the site's caching design, test enabling missing ones in staging, then deploy the configuration through your normal release process:

drush pm:enable page_cache dynamic_page_cache big_pipe -y

Check two anonymous GET requests to the same public URL. Replace the hostname with the final page URL, avoiding redirects:

for request in 1 2; do
  curl -sS -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|cache-control:|age:|x-drupal-cache:|x-drupal-dynamic-cache:)'
done

An initial X-Drupal-Cache: MISS followed by HIT is normal; an already cached page may return two hits. A CDN can serve stored Drupal headers, so interpret them alongside edge-cache information. X-Drupal-Dynamic-Cache: MISS alone does not prove failure when Internal Page Cache serves the response.

Reduce the work each page asks the browser to do

Check production CSS and JavaScript aggregation settings, then inspect the assets each component attaches. A gallery library should load where the gallery appears. Drupal's asset-library documentation covers conditional attachment and versioning.

For custom *.libraries.yml definitions, update an explicit library version whenever its CSS or JavaScript changes. Since Drupal 10.1.2, that version participates in the aggregate hash. Omitting it uses file contents instead. Include asset freshness in release checks.

Older checklists often recommend AdvAgg. Its maintainers now describe it as obsolete on Drupal 10.1 and later and recommend uninstalling it. Test that change alongside core aggregation before deployment.

Check image delivery separately: use appropriately sized image styles and responsive variants, include dimensions, and avoid lazy-loading the main image visible on arrival. Review chat, tracking, video, and consent scripts with their owners. Test menus and forms after changes to script loading.

Give each improvement an owner and a finish line

Choose the first changes by user impact, affected traffic, confidence in the diagnosis, and implementation effort. Slow server responses deserve investigation, but a broken interaction on a key form may take priority over a modest loading improvement elsewhere.

Each task should name the affected journey, proposed change, owner, acceptance check, and rollback approach. Repeat comparable measurements after release, verify publishing and personalization still work, and check that enquiries or transactions complete successfully.

If responsibility keeps bouncing between Drupal, hosting, the theme, and third-party suppliers, Greg can help investigate the bottleneck and coordinate a practical implementation plan. Talk to Greg about your Drupal site's performance; bring a few slow URLs and any reports you already have.

Related on GrN.dk

• JavaScript-Heavy Service Pages Still Lose Leads: What to Audit in 2026
• Search Console’s Hourly Data Changes the Post-Launch SEO Checklist
• SEO Audit Checklist: What to Check and Fix First

Need help with this kind of work?

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

Sources

• Google web.dev: Web Vitals
• Drupal: Internal Page Cache
• Drupal: BigPipe module overview
• Drupal: Adding assets via *.libraries.yml
• Drupal: Advanced CSS/JS Aggregation