By Greg Nowak. Last updated 2026-06-20.
Drupal performance work is rarely about chasing a perfect score for its own sake. For a business owner, operations lead, or agency team, the real question is simpler: can visitors find the page, understand it, and act without waiting?
The old advice around “advanced aggregation” and “PageSpeed 100” needs a 2026 update. Drupal core has moved on, browsers have moved on, and Google’s Core Web Vitals now focus on Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. A useful optimization pass should connect those measures to real Drupal decisions: caching, asset delivery, image handling, hosting, and the amount of personalization on the page.
Start With Measurement, Not Tweaks
Run PageSpeed Insights or Lighthouse on the pages that actually matter: the homepage, a key landing page, a content detail page, a search or listing page, and any logged-in workflow that supports revenue or operations. Do not average everything into one number. A slow editorial page, a slow checkout, and a slow staff dashboard usually have different causes.
For each page, record the mobile result, desktop result, Core Web Vitals status, top three diagnostics, and whether the data is field data from real users or lab data from a simulated test. Field data is better for business decisions; lab data is better for reproducing and fixing specific issues before release.
| Symptom | Likely Drupal cause | Best first move | When to escalate |
|---|---|---|---|
| Slow first load for anonymous users | Page cache, CDN, or server response is weak | Check Internal Page Cache, cache headers, and CDN behavior | If cache misses are common on stable pages |
| Logged-in pages feel heavy | Personalized blocks, render cache gaps, or expensive Views | Review Dynamic Page Cache, BigPipe, and cache metadata | If custom modules output uncacheable render arrays |
| Page waits on CSS or JavaScript | Too many libraries, render-blocking assets, or legacy aggregation advice | Audit attached libraries and enable core aggregation where appropriate | If old AdvAgg settings conflict with Drupal 10.1 or 11 |
| Layout jumps while loading | Images, ads, embeds, fonts, or streamed placeholders lack reserved space | Add dimensions, reserve space, and test mobile templates | If layout shifts come from third-party scripts |
Use Drupal Core Caching Properly
Drupal’s Internal Page Cache is designed for anonymous traffic and is enabled by default on modern Drupal sites. It should usually stay on for content sites, campaign sites, and brochure sites. If a page is identical for anonymous users, caching it before PHP rebuilds it is one of the highest-return fixes available.
Dynamic Page Cache matters when the page has personalized or variable parts. It can cache the reusable parts of a page while excluding the pieces that genuinely vary by user, role, language, or session. That is especially relevant for membership sites, intranets, editorial workflows, ecommerce experiences, and agency builds with logged-in preview tools.
BigPipe is worth checking when logged-in or personalized pages feel slow even after Dynamic Page Cache is enabled. It lets Drupal send the initial page earlier and stream placeholder replacements afterwards. That can improve perceived performance, but it is not magic: reserve space for late-loading blocks, otherwise the “faster” page may create visual shifts that hurt the experience.
Be Careful With Old Advanced Aggregation Advice
The original note pointed to Advanced CSS/JS Aggregation. That was sensible advice in older Drupal builds, but it is not a default recommendation for current sites. The AdvAgg project page now says the module is obsolete with Drupal core 10.1 and later, and recommends uninstalling it on Drupal 10.1+ and Drupal 11 unless you have a specific, tested reason to keep it.
For a modern Drupal site, start with core performance settings at admin/config/development/performance. Enable CSS and JavaScript aggregation for production where it helps, then test the real page. If performance is still poor, inspect which libraries are attached and why. Removing unnecessary JavaScript usually beats bundling unnecessary JavaScript more cleverly.
Useful Checks For A Developer
These commands are not a substitute for profiling, but they give an agency or technical owner a quick view of whether the obvious pieces are present:
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
curl -I https://www.example.com/ | grep -iE 'cache-control|x-drupal-cache|x-drupal-dynamic-cache'On a healthy anonymous page, the first request may miss cache and a later request should usually hit. If every request misses, look for session cookies, cache max-age problems, uncacheable blocks, or custom code that strips cache metadata. If the site sits behind a CDN or reverse proxy, confirm that Drupal and the edge cache agree about what is public, private, and purgeable.
What To Fix First
Prioritize the work in this order: server response and cache hit rate, image weight and dimensions, unnecessary JavaScript, render-blocking assets, layout stability, then fine-grained module cleanup. This order is pragmatic because it moves the largest user-visible delays before spending time on small score improvements.
For operations teams, the key deliverable is not a report full of red warnings. It is a short backlog: what is broken, what business page it affects, what fix is safest, and what should be measured after release. For agency teams, that backlog also needs ownership boundaries: theme, module, hosting, CDN, analytics, or content.
When It Is Worth Bringing In Help
Bring in a Drupal performance consultant when the site has good hosting but still misses cache, when logged-in workflows are slow, when Core Web Vitals change after every release, or when nobody is sure whether the issue belongs to Drupal, the theme, the CDN, or third-party scripts.
Greg can help turn a loose PageSpeed complaint into a practical optimization plan: measure the important pages, separate quick wins from architectural fixes, and give your team implementation guidance they can actually ship.
Related on GrN.dk
- Drupal 8 Advanced Aggregation for Better Google PageSpeed Scores
- When Google can call the business, your local data stops being cosmetic
- AI Crawler Control for Business Websites: Protect Content Without Sacrificing Search Visibility
Need help with this kind of work?
Talk to Greg about Drupal performance Get in touch with Greg.