If you still run a Drupal 8 site and want a better Google PageSpeed result, Advanced CSS/JS Aggregation can still help, but only when you use it as part of a disciplined cleanup, not as a magic switch. The real job is to reduce render-blocking CSS and JavaScript, stop loading libraries that a page does not need, and confirm that any score improvement also improves real user experience. For most teams, that means treating AdvAgg as a legacy optimisation tool, not a substitute for platform maintenance.
One important caveat as of June 2, 2026: Drupal 8 has been end-of-life since November 17, 2021, and the current AdvAgg project page says the module is obsolete on Drupal core 10.1 and newer. The Drupal.org project page also shows no supported stable releases as of June 2, 2026, which is another reason to treat it as a legacy tuning tool rather than a fresh default. If you are on Drupal 10.1 or Drupal 11, do not start here. This article is mainly for inherited Drupal 8 builds that still need pragmatic performance work while an upgrade, rebuild, or platform cleanup is being planned.
Start with the business question, not the score
PageSpeed matters because slow pages create friction for real visitors, not because a dashboard turned orange. For business owners and operations leads, the useful question is simpler: which pages affect lead generation, search visibility, or paid traffic efficiency, and what is slowing those pages down?
Use PageSpeed Insights on the homepage, your main landing pages, and at least one content-heavy template. Record both mobile and desktop results. Google now shows both lab data and field data, so you can separate 'what Lighthouse found in a test run' from 'what real users have experienced over the last 28 days'. That distinction matters. A small lab score gain is not very valuable if real-user LCP, INP, and CLS do not move.
Use AdvAgg to diagnose before you optimise
Drupal's own documentation notes that AdvAgg on Drupal 8 is not the same kind of overhaul it was on Drupal 7. Core asset handling improved, so the biggest wins often come from loading fewer files and smaller libraries, not simply bundling everything harder.
The fastest way to see what is really happening is to temporarily bypass aggregation and inspect the raw files being attached to the page. If you have the right permission, append ?advagg=0 to a URL. On local or staging, you can also disable preprocessing and AdvAgg directly:
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
$config['advagg.settings']['enabled'] = FALSE;Do that only in local or staging. Then open Chrome DevTools Coverage and reload the page. If a page ships large CSS or JavaScript files that are mostly unused, you do not have an aggregation problem first. You have a library attachment problem. In practice, that usually means a theme, module, builder tool, or marketing script is being loaded too broadly.
Low-risk AdvAgg changes worth testing
If the site really does need AdvAgg, start in admin/config/development/performance/advagg and work in small, reversible steps. Avoid the temptation to enable every submodule in one pass.
- Enable CSS and JS minification first. This is usually the least controversial change and can trim transfer size without changing page logic.
- Review the Modifier submodule carefully. It can add
deferto JavaScript, move scripts to the footer, and defer CSS loading, but these settings can create compatibility issues with forms, personalisation, consent tools, search widgets, and analytics. - Use precompressed assets where your server setup supports them. AdvAgg documents both gzip and Brotli support, which can reduce transfer size for repeatable static files.
- Use DNS prefetch only when you are genuinely dependent on external asset hosts. It is not a substitute for removing third-party requests.
A practical rule: enable one category of change, clear caches, test three page types, and compare before/after in PageSpeed Insights. Include a basic user journey in testing, such as menu interaction, form submission, cookie consent, and any logged-in workflow that matters to the business.
What usually moves the score more than bundling
Chrome's current guidance is consistent: unused JavaScript still hurts even when it is not render-blocking, because it competes for bandwidth and has to be downloaded, parsed, and sometimes evaluated. That is why many Drupal performance problems are really about scope control. A library attached site-wide is expensive on every page, even if AdvAgg combines it neatly.
In other words, use AdvAgg to support a leaner frontend, not to hide a bloated one. Remove unused sliders, maps, A/B testing tags, chat widgets, and theme libraries from templates where they are not needed. If a module only matters on one content type, attach its library there instead of globally. That usually improves both PageSpeed diagnostics and the actual user experience.
What to avoid on legacy Drupal 8
- Do not treat this as a long-term answer. Drupal 8 is unsupported, so performance work should be sized as triage or transition work.
- Do not deploy aggressive deferral, async loading, or critical CSS tricks without staged testing. These changes can improve scores and still break the page.
- Do not read a better score as proof that the site is healthy. If Time to First Byte is poor, editors complain, or cache hit rates are weak, aggregation is only one piece of the problem.
When to bring in outside help
If your internal team or agency has multiple themes, heavy third-party tags, multilingual templates, or an unclear Drupal upgrade path, it helps to have someone audit the stack and separate quick wins from wasted effort. That is usually cheaper than spending weeks chasing a cosmetic score improvement that does not survive the next release.
If you want a practical review of a legacy Drupal site, I can help turn the performance findings into a small, testable backlog and show where an upgrade or frontend cleanup will pay back more than another round of module tweaking.
Need help with this kind of work?
Need a pragmatic review of a legacy Drupal site before you spend more on performance work? Greg can turn the findings into a realistic action plan. Get in touch with Greg.