[firasd]

Good document! I wanted to mention, something I've found to be significant in practical testing but often not considered by web developers is reducing the total number of HTTP queries. It seems like fetching 5 CSS files of 5kb each will significantly slow things down compared to combining them into one 25kb CSS file.

[chmod775]

It slows things down especially because the browser will likely have to layout/re-render the page everytime a new chunk of CSS arrives.

Generally avoid splitting CSS. Even if you don't use all your CSS on every page, a cached 100kb CSS file will outperform a bunch of unique-per-page 25kb CSS files everytime (especially since it's 0 requests for the second page). Except for dial-up probably.

It may be beneficial to split CSS files somewhere above the 300kb mark, but I wouldn't know. My one-page-app is only about 500kb over the wire, including CSS, JS, Fonts and HTML. ~30KB of that is CSS.

I've been optimizing that for years though.

[tyingq]

Http/2 makes this less important. Perhaps still worth it for CSS, but higher effort things like image spriting might not be as attractive now.

[chrisweekly]

Yes -- in fact some webperf techniques are HTTP/1.1 - specific, and are actually _anti-patterns_ in HTTP/2. Spriting is one such example.

[chrisweekly]

Domain sharding is another.

[andreareina]

AFAIK SVG sprites (or inline SVG) are still required to style SVG images with external CSS.

[theandrewbailey]

Back in the day, reducing total HTTP requests meant less time waiting through the network lag (round trip times). With HTTP2, that's less important because it allows multiple requests simultaneously on the same connection (fewer network connections made=less lag). It's a nice to have feature and has measurable benefits, but I don't rely on it. There is a non-negligible cost for the browser to parse yet another CSS/JS file, but I'm not sure exactly what those costs are.