split css file to improve perceived latency?

For some unknown reason, the css file im working with is about 97 KB (un gzipped) … I know thats horrible coding and will be completely redone later on…

For now, Im curious if i split the css file into 2 smaller chunks, will it improve the start of rendering? As what I understand, the browser wont start rendering the page until all the CSS is downloaded… so 2 files would be downloaded in parallel? If i combine this with domain sharding, this should result in faster output i guess…

For the final phase (includes rewrite of the css) my plan is to use 2 css files on all pages… one would be the base stylesheet which contains elements used on almost all pages and another stylesheet containing elements specific to the type of page (homepage, product page, listing, cart, account, etc, whatever)… and using preloading to make the second page visited to be almost instant.

What do you think? Bundle everything into one css or split it?

How small is it compressed? What you really care about is the wire size and it would have to be fairly large to be faster split in two. Some things to consider before splitting:

  • on IE7, if the css is on the same domain as the base page then the 2nd css file will not be requested until either the base page fully downloads or the first one finishes (and then you need to pay the round trip latency)

  • If it can be requested in parallel (different domain or browser that supports more connections) then it may be a little faster. Particularly since the first css download may trip over some slow start windows that cause it to wait an additional round trip (depends on the server’s TCP stack and the size of the CSS file).

  • I’m assuming you have no javascript in the head because you might be better off letting that be downloaded in parallel to the CSS if you do (assuming different domain where you have 2 connections).

One thing to consider when analyzing this (are you delivering this CSS from the base-page hostname?) is the effect TCP Slow start will have. TCP slow start is a congestion control algorithm that (for very good reasons) makes brand new connections slower than ones over which data has all ready been transferred. The flash animation and article here are superb: http://www.osischool.com/protocol/Tcp/slowstart/index.php I think a presentation was done at Velocity 2010 on this as well.

Even uncompressed, 50 KB is not quite big enough for this to really make a difference (slow start typically occurs until the connection reaches a 64KB window size) so you’re probably better off with one file. If you’re going to deliver the CSS file(s) from a different hostname than the base page, then splitting is probably going to make it worse. Whether or not the base-page will download fast enough so it can be re-used for the 2nd style sheet (at least in IE7 … rest of the browsers are gonna open a new connection regardless) is a factor as well.

The ultimate answer is going to be very specific to your site, the audience, their traffic patterns and browser usage.

Actually, slow start kicks in around 2-4 segments depending on the implementation (at least per spec - it’s not uncommon for “acceleration” devices or custom kernels to use larger initial congestion windows).

Steve Souders has a good summary write-up of the velocity talk that John Rauser did here: Velocity: TCP and the Lower Bound of Web Performance | High Performance Web Sites (includes links to a video of the actual talk).

Each time you trigger the increasing congestion window you pay a round trip price so it’s really expensive on new connections.


Thanks for the interesting pointers…

My current CSS file is ~ 105KB minified and about 20KB gziped. I guess its best to keep this as a single file…

I was testing from a slower network so this seemed like a bigger problem than what it would be if it were served by a CDN.