Front-end Optimization from the Get-go, Part 2

In the second installment of optimizing your website, we’ll cover handling your CSS and squeezing every ounce of performance from it. Please have a read of part 1 if you missed it.In any web page, the order that your browser downloads your content is simple: it retrieves the HTML, which tells it the other files to request from your server, while your CSS provides all the styling to make it display as needed.Improving front-end performance is shown to have an impact on overall conversion, including click-through rates, average time on site, sales, and even Google rankings.

Reducing Requests

Even Darth Vader reduces requests.

I like to have my CSS in lots of files. Files just for the header of my pages, or for the footer, for the home page–for each section of my site. This, of course, means that if I was to include them in the head of the document, there’d be a huge number of requests. So, the easiest way to deal with this is to concatenate the files.There are many applications for this: Turbine (seems much like CSScaffold), Juicer (have heard good things, but yet to try it), and my favorite, CSScaffold (currently offline, but created by Anthony Short).These concatenate your CSS into fewer files (one file, if that suits your setup), which means you have fewer requests to make.

Minification and Gzipping

Minification can yield some large savings. It compresses your CSS by removing all unnecessary white spaces and line breaks, and reducing your code into as few lines as possible. This is usually done just as you’re making your code live, because minified code is extremely difficult to work with.Gzipping is server-side compression that can bring about massive savings. It’s supported by all the modern browsers, and although it can take a bit of time setting up to run nicely, it’s well worth it.The applications listed above will usually have minification and Gzipping as options to further reduce file sizes.

Put Style Sheets at the Top

This is an obvious one that most of you will already be doing. By having the style sheets linked from the head of your HTML, your users’ browsers will start styling the page as soon as it can, making the web page appear to be loading. This stops your users from thinking that nothing is happening, growing frustrated, and leaving, as they’re assured that the browser is responding.

Use link Tag instead of @import

Some performance improvements aren’t actually making websites faster; they’re merely making the website seem faster to your end user.The link tag (<link href="styles.css" type="text/css" />) should be used instead of the @import (<style type="text/css">@import url("styles.css");</style>) for using styles. They’re identical, but the link tag will display the CSS as soon as possible, while the @import will wait until the page is fully downloaded before displaying in some browsers.

Avoid Inline Styles

It has been suggested that you include some (or all) of your CSS inline in your HTML, thereby reducing the number of requests altogether. This sounds like a good idea, and there are times when it’s handy; however, HTML isn’t cached when handled this way. By having it in an external file, the user’s browser will save it so that when the user returns, and it hasn’t changed, it’ll use that file instead of downloading another copy of the file.

Specificity

CSS specificity is an odd topic to cover in an optimization discussion. Specificity is how strong a certain style is; an element (anchor, paragraph, or form, for example) is overridden by a class ( “.post“) which in turn is trumped by an ID (“#header“). Andy Clarke put it beautifully when he came up with the CSS: Specificity Wars image explaining the concept using three Star Wars-themed tiers: Sith Lords represent IDs (and are worth 100 points), Darth Vaders are classes (10 points), and Storm Troopers are elements (1 point).All that aside, specificity (or more importantly, how specific you tend to write your classes) can make a real difference in file sizes!We’ve all done it: written CSS that’s included two or three IDs, maybe a class or two, and then an element, all just to style a block on the page. In an ideal world, 90% of styles should consist of only an ID, a class, and maybe an element. Even this has a specificity score of 111, which still should be strong enough to hold up against other styles.For example, #container #content #header h1.logo has a strength of 311, but in terms of file size it’s 35 characters long. It could be easily reduced to #header h1 (101 points), which brings it down to ten characters, as there should only be one h1 element. Even under HTML5 where you can have multiple h1 elements, a header with multiple h1 elements would make little sense.You may ask, so what? We’ve saved 25 whole characters. But extend that to a style sheet of two or three thousand characters (which most big sites grow to eventually, even if it’s split across multiple files). It can be a real size saving waiting to happen. And, like all legacy code, it can only be done right once–else it becomes a nightmare. The trick is to write styles that use less points worth of specificity across the entire style sheet, so that you need less strength in an individual style to use it.

Conclusion

I’ve discussed most of the rules that will make your CSS go faster. Most of these are easy to implement, and you’ll notice a difference with your pages loading faster. In the next few posts, I’ll cover the handling of JavaScript and images, so stay tuned.