Combining CSS in Autoptimize can still help on HTTP/2, but only when it cuts render blocking work without creating one giant file. If your WordPress site loads 40 tiny CSS files, aggregation may clean things up. If it loads 4 well cached files, aggregation may make things worse.
TLDR: Autoptimize “Aggregate CSS files” grabs many CSS files, merges them, minifies them, and serves fewer files. With HTTP/2, fewer files are not always faster because browsers can download many files at once. Example: a small blog cut CSS requests from 28 to 3 and improved mobile Largest Contentful Paint from 3.4 seconds to 2.8 seconds. But a shop with one huge combined CSS file saw first load get 0.6 seconds slower because unused checkout and slider CSS loaded on every page.
What Autoptimize CSS aggregation actually does
Autoptimize is a WordPress performance plugin. One of its popular settings is Aggregate CSS files.
When this option is enabled, Autoptimize scans the CSS that WordPress outputs on the page. Then it tries to combine those files into one or more generated CSS files.
It usually does three things:
- Combines many CSS files into fewer files.
- Minifies CSS by removing extra spaces, comments, and line breaks.
- Caches the new files in the Autoptimize cache folder.
So instead of this:
- theme.css
- woocommerce.css
- slider.css
- forms.css
- plugin random nonsense.css
You may get something like this:
- autoptimize abc123.css
Cleaner? Yes. Always faster? Nope. That would be too easy, and WordPress rarely gives us easy.
Why HTTP/2 changes the old CSS advice
Old advice said: combine everything. That made sense with HTTP/1.1.
HTTP/1.1 had a traffic jam problem. Browsers could only open a small number of connections to the same domain. Too many CSS files meant too much waiting. So combining files was a clear win.
HTTP/2 works differently. It can send many files over one connection. This is called multiplexing. The browser can ask for several CSS files, JavaScript files, and images at nearly the same time.
That means 20 small CSS files may not be as scary as they were ten years ago.
The catch is that HTTP/2 does not magically fix bad CSS. It does not remove unused code. It does not make render blocking CSS harmless. It does not stop a bloated theme from loading 180 KB of button styles on a blog post.
So the real question is not “Should I combine CSS because HTTP/2 exists?”
The better question is: Does aggregation reduce real work for the browser?
When combining CSS helps WordPress performance
CSS aggregation can help when your page has too many small files. Each file still has overhead. The browser must request it, receive it, parse it, and apply it.
Aggregation often helps in these cases:
- Your site has many CSS requests. Think 25, 40, or even 70 CSS files.
- Your server has slow response times. Each request feels heavier.
- Your CSS files are tiny. Many tiny files can be silly.
- Your theme and plugins load CSS globally. This is common and annoying.
- You are not using good page caching. Fix that too, please.
Here is a simple case.
A recipe blog had 31 CSS files on each post. Many came from plugins. A form plugin loaded on every page. A rating plugin did the same. After enabling Autoptimize CSS aggregation, CSS requests dropped from 31 to 5. Total CSS size fell from 186 KB to 151 KB after minification. Mobile First Contentful Paint improved from 2.9 seconds to 2.3 seconds.
That is a useful win. Not magic. Just less clutter.
When combining CSS hurts performance
Aggregation can also backfire. Honestly, it feels like fixing one leak and finding three more under the sink.
The biggest problem is page specific CSS.
Say your homepage needs slider CSS. Your product page needs WooCommerce CSS. Your contact page needs form CSS. If Autoptimize combines all of that into one global file, every visitor may download CSS they do not need.
That can hurt Core Web Vitals.
Combining CSS may hurt when:
- The combined file becomes huge. One 400 KB CSS file is not cute.
- Unused CSS increases. The browser parses styles that are not needed.
- Cache changes happen often. One small CSS edit can force a full new download.
- Critical CSS is not handled well. The visible part of the page waits too long.
- Plugin CSS breaks order. Some styles depend on loading after other styles.
This is where HTTP/2 can beat aggregation. With separate files, the browser may reuse cached CSS more effectively. If only one plugin file changes, only that file needs a fresh download. With one merged file, the whole bundle may change.
Render blocking is the real villain
CSS is usually render blocking. That means the browser often waits for CSS before painting the page.
This makes sense. The browser does not want to show a naked page, then repaint it a second later. That would look like a digital wardrobe malfunction.
Autoptimize can help by reducing and minifying CSS. But aggregation alone does not solve the full issue.
You may also need:
- Critical CSS for above the fold content.
- Deferred non critical CSS for styles needed later.
- Removed unused CSS from themes and plugins.
- Good caching at page, browser, and server level.
If your site has a massive stylesheet, combining files will not save you. It may just create a massive stylesheet with a new name.
Best Autoptimize settings for HTTP/2
There is no perfect setting for every WordPress site. Sorry. I wish there was a big green “make it fast” button too.
Still, this is a smart starting point:
- Enable CSS optimization. This minifies CSS.
- Test Aggregate CSS files on and off. Do not guess.
- Inline and defer CSS only after testing. It can help, but it can also break layout.
- Exclude problem files. Some plugin CSS files do not behave.
- Clear cache after changes. Autoptimize cache can grow fast.
If your host supports HTTP/2 or HTTP/3, start by testing without aggregation. Keep CSS minification on. Then turn aggregation on and compare.
Use real test tools:
- PageSpeed Insights for Core Web Vitals hints.
- WebPageTest for waterfall charts.
- Chrome DevTools for request count and file size.
- GTmetrix for quick before and after checks.
Run each test more than once. One test is a mood. Three tests are closer to data.
A simple testing plan
Try this easy process:
- Clear all caches.
- Test your homepage, a blog post, and a key money page.
- Record CSS requests, CSS size, LCP, and FCP.
- Turn on Aggregate CSS files.
- Clear caches again.
- Retest the same pages.
- Keep the version that wins on real pages.
Do not test only the homepage. That is a classic trap. Your homepage may be fast while product pages crawl like a sleepy turtle.
Common Autoptimize CSS aggregation problems
The most common issue is broken styling. A button looks weird. A menu shifts. A hero section loses spacing. Great. Now your speed plugin has become your design intern.
Try these fixes:
- Exclude the broken CSS file from aggregation.
- Disable “also aggregate inline CSS” if inline styles are causing trouble.
- Check CSS order if plugin styles override theme styles.
- Clear Autoptimize cache after every change.
- Check logged out pages because visitors see those.
Also watch your cache size. Autoptimize creates generated files. Busy sites can build a large cache folder. Set a cleanup routine if needed.
So, should you aggregate CSS with HTTP/2?
Yes, if it makes your measured pages faster. No, if it creates a bloated CSS bundle or breaks caching.
HTTP/2 made the old “always combine files” rule outdated. But it did not make aggregation useless. Autoptimize CSS aggregation is still handy for messy WordPress sites with too many plugin files.
Use it like a wrench, not a magic wand.
If requests drop, CSS size drops, and Core Web Vitals improve, keep it. If the combined file grows huge or pages feel slower, turn it off. Simple. Slightly annoying. Very WordPress.