By Greg Nowak. Last updated 2026-07-02.
Advanced CSS/JS Aggregation can still help an inherited Drupal 8 site, but it should be treated as controlled legacy optimisation, not a magic switch. The practical goal is not only a greener Google PageSpeed score. It is a faster page for real visitors, fewer wasted frontend assets, and a clearer decision about whether the site needs tuning, an upgrade, or both.
The maintenance context matters. Drupal 8 reached end of life on November 17, 2021. As of July 2, 2026, the AdvAgg project page also says the module is obsolete on Drupal core 10.1 and newer, recommends uninstalling it on Drupal 10.1+ and Drupal 11, and shows no supported stable releases. So if you are on a modern Drupal build, start with core asset handling and frontend cleanup. This article is for legacy Drupal 8 sites that still need pragmatic performance work while a larger platform plan is being made.
Start With the Pages That Affect Revenue
Do not begin with a site-wide average or a single homepage test. Begin with the pages that influence leads, paid traffic, sales conversations, or organic visibility: the homepage, core service pages, campaign landing pages, and one or two content-heavy templates.
Run each page through PageSpeed Insights on mobile and desktop. Look at both lab data and field data. Lab data is useful for debugging because it comes from a controlled Lighthouse run. Field data, when available, comes from real Chrome user experience data over a recent 28-day period. That distinction keeps teams from celebrating a cosmetic score improvement while real-user LCP, INP, or CLS stays weak.
| Decision point | What to inspect | Best next move |
|---|---|---|
| Drupal version | Drupal 8, 9, 10, or 11 | Use AdvAgg only for legacy Drupal 8 triage; plan an upgrade for unsupported sites. |
| Asset waste | Unused CSS and JavaScript in Chrome DevTools Coverage | Detach libraries from pages and components where they are not needed. |
| Third-party scripts | Chat, maps, analytics, embeds, consent, A/B testing | Remove, delay, or scope external scripts based on business value. |
| Conversion paths | Menus, forms, search, checkout, logged-in workflows | Test after every change so score gains do not break useful behaviour. |
Use AdvAgg to Expose the Real Problem
One useful AdvAgg habit is to inspect the page without aggregation. If your account has the right permission, append ?advagg=0 to a URL to view the page with aggregation disabled for that request. On local or staging, you can also disable preprocessing and AdvAgg through configuration overrides:
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
$config['advagg.settings']['enabled'] = FALSE;Do this away from production traffic. Then reload the page with Chrome DevTools Coverage open. If the page ships large CSS or JavaScript files that are mostly unused, aggregation is not the main issue. A theme, module, builder, or marketing integration is attaching libraries too broadly.
Make Reversible Changes First
If AdvAgg is already part of the Drupal 8 stack, work from admin/config/development/performance/advagg in small steps. Start with CSS and JavaScript minification. It is usually the least disruptive change because it trims transfer size without changing much page behaviour.
Be more cautious with the Modifier submodule. Moving scripts to the footer, adding defer, or changing CSS loading can improve a Lighthouse run, but it can also break forms, consent tools, navigation, search widgets, analytics, and personalisation. Enable one category of change, clear caches, test three representative templates, and compare the same PageSpeed reports before and after.
Precompressed assets can also help when your server supports them. AdvAgg documents gzip and Brotli support, which can reduce transfer size for repeatable static files. Useful, but still a delivery optimisation. Compression will not fix a site that loads a map library, a carousel, and several tracking tools on pages that do not use them.
What Usually Moves PageSpeed More
The higher-value work is asset discipline. Attach Drupal libraries only where they are needed. Remove old theme dependencies. Replace heavy widgets where the business case is weak. Audit third-party scripts by page type, not just by vendor. Check whether the largest visual element is a poorly sized image, a slow server response, or render-blocking CSS.
For agency teams, this is also a process issue. Keep a short performance log: page tested, setting changed, cache cleared, result, and any regression found. That record makes it easier to explain tradeoffs to the site owner and prevents the next release from undoing the work.
Know When to Stop Tuning
AdvAgg is not a long-term answer for an unsupported Drupal 8 platform. If PHP compatibility, security updates, editor experience, cache behaviour, or module maintenance are already fragile, spend only enough on performance to reduce immediate business pain. Put the serious effort into an upgrade path, frontend cleanup, and a smaller set of maintained dependencies.
If your team is stuck between score-chasing and a larger Drupal decision, Greg can review the stack, identify the real frontend waste, and turn the findings into a practical backlog. Talk to Greg about your Drupal site.
Related on GrN.dk
- JavaScript-Heavy Service Pages Still Lose Leads: A 2026 Rendering Audit
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- When Google can call the business, your local data stops being cosmetic
Need help with this kind of work?
Talk to Greg about your Drupal site Get in touch with Greg.