Combining CSS in the HTTP/2 Era: Is It Still Necessary in 2026?
The 'merge everything into one file' concept was born in the HTTP/1.1 days. In the era of HTTP/2 and HTTP/3, the rules have changed. We break down when to combine and when to split.
"Combine all your CSS into one file — fewer requests, faster site." This was the golden rule of the HTTP/1.1 era, with its strict limit on parallel connections. In 2026, when virtually the entire web runs on HTTP/2 and is actively migrating to HTTP/3, the rules have changed — sometimes even in the opposite direction.
In this article, we break down how to correctly split or combine CSS in a modern infrastructure.
Why "One Big CSS File" Was the Rule
HTTP/1.1 has a hard constraint: 6 parallel requests per domain. If you have 30 CSS files in your <head>, the browser downloads 6 at a time while the rest wait in queue. This creates a "staircase" loading pattern — overall time-to-render grows.
The solution from the 2010s: merge all CSS into one large file. One request — no queue waiting — faster render.
Additional motivation: every HTTP request has overhead (handshake, headers). Fewer requests means less overhead.
What HTTP/2 Changed
HTTP/2 has no limit on parallel requests. One TCP connection, multiplexing, all resources transferred in parallel. Per-request overhead is minimal (HPACK header compression).
This eliminates the main motivation for combining files. 30 small CSS files and one large 30 KB file load in roughly the same amount of time.
For more on HTTP/2, see the post HTTP/2 and HTTP/3 in 2026.
But "Don't Combine" Is Not a Silver Bullet Either
Although HTTP/2 removed the constraint, splitting files has its own downsides:
1. Parsing Each CSS File Is Work for the Browser
One large file is parsed once. 30 small ones mean 30 parsing iterations. On slow CPUs (budget Android devices) this adds up to 50–100 ms of extra work.
2. Lower Compression Efficiency (gzip/brotli)
Compressing one large CSS string is more efficient than 30 small ones. Repeating patterns (class names, color codes, shared properties) compress better with a larger dictionary.
A typical effect: 30 files at 5 KB each → 150 KB. Compressed with gzip → 80 KB. The same content in one file — gzip → 65 KB. That's 15 KB saved purely through better compression.
3. Race Conditions with CSS Variables
If variables are defined in one file and used in another, and the files load in parallel via HTTP/2, there can be a brief moment where styles are partially applied without variables. FOUC.
What to Choose in 2026
It depends on your situation.
Strategy: "Critical + Bundle" (Recommended)
- Inline critical CSS in HTML — 5–15 KB of above-the-fold styles
- One CSS bundle for the rest — loaded via
<link>asynchronously
This is the best compromise:
- Critical CSS gives instant above-the-fold rendering
- The bundle CSS loads in parallel with other resources
- One large bundle compresses better
- No need to think about parallelism
Strategy: "Split by Route" (Next.js / SPA)
Modern React/Vue/Svelte stacks split code (and CSS) by route. Each page pulls its own chunk.
In Next.js this works automatically. The home page pulls main CSS + page CSS; the /blog/ page pulls main CSS + blog page CSS. Cached main CSS is not re-requested.
The upside: a user clicking through sections only downloads new chunks. Fewer duplicate loads.
The downside: a first visit to any single page pulls more separate files.
In HTTP/2 — this is fine. In HTTP/1.1 it was an anti-pattern.
Strategy: "One File for Everything" (For Very Simple Sites)
For landing pages with 1–3 pages — this is justified. One CSS file, cached for a year, everything works.
Avoid this for large sites and SPAs — they always have page-specific content that not every page needs.
Brotli > Gzip — A Separate Story
Regardless of your splitting strategy, switching from gzip to Brotli gives an extra 15–25% compression for CSS. In 2026, Brotli is supported by all current browsers.
In nginx:
brotli on;
brotli_comp_level 6;
brotli_types text/css application/javascript text/html text/plain application/json image/svg+xml;
This is a free performance gain, independent of your splitting strategy.
What Not to Do
- Blindly merge everything into one CSS file on a site with 100+ pages of varying content. You'll end up with 500 KB of CSS, of which only 20 KB is used on any given page. Tree-shaking via PurgeCSS is mandatory hygiene.
- Split into dozens of tiny files purely "for modularity." It makes sense to split by business logic (home, catalog, cart, profile), not by individual component.
- Rely on @import chains — they block rendering sequentially. See the separate article on @import in CSS.
Real-World Benchmarks
Test site, 200 KB total CSS, page includes links to:
Configuration A: 1 CSS file, 200 KB
- LCP: 1.4 s
- TTI: 2.1 s
Configuration B: 12 CSS files at 15 KB each, served over HTTP/2
- LCP: 1.5 s
- TTI: 2.3 s
Configuration C: inline critical (15 KB) + 1 async bundle (185 KB)
- LCP: 0.9 s
- TTI: 1.8 s
The difference between A and B is within the margin of error. Configuration C delivers a meaningful improvement — and it comes from the inline critical CSS, not from splitting.
Summary
In the HTTP/2 era, the rule "merge everything into one file" is no longer dogma. What matters is not the number of files, but:
- Inline critical CSS for above-the-fold content
- Async loading for everything else
- Brotli compression
- PurgeCSS or similar tooling to remove unused styles
Any modern bundler (Webpack, Vite, esbuild) handles this. There is no need to manually "merge" or "split" — configure your build pipeline once and let it do the work.
Want a CSS strategy audit for your site? Get in touch. Free, within 2 business days.