I recently spoke at JSConf about my experience working with Trulia to create a living style guide. The goal for the project was to improve performance, team velocity, and also to have a more consistent design. It was such a fun project (because their engineers were great to work with) and also successful on all three fronts. Here are some of the metrics for the data-lovers:
Their HTML is 48% smaller
21% faster load time
60% faster time to first byte
Reduced unused CSS by 135kb
Search results page views increased by 11%
Property detail page views increased by 3% (this page was not changed, changes on the SRP alone account for this figure)
Click throughs, leads, customer satisfaction, and filter use also improved
Nicholas Zakas and I spoke at Velocity a few minutes ago. First we talked about CSS 3 and it’s impact on performance, then we demoed and open sourced CSS Lint! I really couldn’t be more excited (or relieved, I was super duper nervous before this presentation).
CSS Lint is a tool to help point out problems with your CSS code. It does basic syntax checking as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency. The rules are all pluggable, so you can easily write your own or omit ones you don’t want.
Rules currently tested
Parsing errors should be fixed
Don’t use adjoining classes
Remove empty rules
Use correct properties for a display
Don’t use too many floats
Don’t use too many web fonts
Don’t use too may font-size declarations
Don’t use IDs in selectors
Don’t qualify headings
Heading elements should have a consistent appearance across a site.
Heading styles should only be defined once
Be careful using width: 100%
Zero values don’t need units
Vendor prefixed properties should also have the standard
CSS gradients require all browser prefixes
Avoid selectors that look like regular expressions
Beware of broken box models
(We’ll allow you to turn off rules that hurt your feelings soon!)
Many people have expressed an interest in contributing to the CSS Lint project. We were waiting to have a solid plugable architecture and API before taking contributions. The exciting news is that we are now ready! There are several ways you can contribute:
If you are comfortable with CSS, submit rule ideas. You must provide the rule name, a human readable explanation, browsers affected, and a test case.
CSS 3 is full of ways to reduce our dependence on background images, one of which is pure CSS gradients. They have several features, which I’m sure designers are salivating over, like multiple color stops, and angled, radial, and linear gradients. Many people had built cool designer-focused tools to make interacting with a somewhat confusing gradient syntax a little easier. The issue for me has been that I’m not a designer. I generally work off of photoshop comps or (when doing big re-architecture projects) the site itself, as if the old version were a design. This means that, for the most part, I was trying desperately to match CSS gradients to an image with zero information about how that image would have been created. Because of my focus on fixing old and broken CSS, the original designer may not even still work at the company.
If you don’t know what I mean, picture me with a color picker going pixel by pixel to try to figure out by hand where the color stops should be and what colors I should use versus extrapolate. Then, for each version, making an image of the gradient I’ve created, blowing it up so I can compare it to the image of the original. Rinse, repeat until I’ve come up with something that kinda, sorta approximates the original. Oh yeah, painful.
We talked about progressive enhancement, carpentry, testing, rounded corners, oocss, performance, working on big sites, and being a girl on the internets. If you missed the live show, you can check out the video podcast. I was super-duper-over-the-top nervous about the show, but I’ve heard that I didn’t come off like a total dweeb. ;)
Last week, Stoyan Stefanov and I spoke at Velocity Conference about optimizing massive CSS. We talked about our experiences optimizing large-scale sites like Facebook and Yahoo!, and we discussed our findings regarding the CSS efficiency of the Alexa Top 1000 websites.
Velocity was kind enough to share videos of the session:
What is the state of the internet regarding CSS performance? Kind of sad. We aren’t getting a lot of the basics right, and when we look at the more advanced techniques, there are some spectacular examples of what-not-to-do. Why do we care about CSS performance? As Stoyan talks about in the beginning of the video, it blocks progressive rendering and it is very difficult to auto-minify.
These basic rules, made famous by YSlow, have been around for a long time, and yet our data showed that many sites in the Alexa Top 1000 are still not employing the most basic techniques.
42% Don’t GZIP CSS
44% Have more than 2 CSS external files
56% Serve CSS with cookies (yummy to eat, bad for static content)
62% Don’t minify (check out the YUI Compressor!)
21% Have greater than 100K of CSS
CSS Weight for the Alexa Top 1000 Sites
More Advanced Techniques
I talked about these more advanced tests for the first time at Velocity. Here is how the top 1000 sites stack up and some recommendations for reasonable results.
Occurrences in one page
Percentage too many > 10
Percentage sites *way* too many > 100
If you have a good nestable grids system, you shouldn’t need many floats. The worst offender in the Alexa Top 1000 sites declared the float property more than 700 times! Aim for less than 10.
There are only so many usable font sizes on the web. Below 10px in most fonts is legible only by mice and few sites use really large typography as a design element. Imagine that a site chooses to use 24px as their max. That leaves 14 different sizes, however, we need to divide that number by two because most users can’t see subtle differences like a 1px change in font size. That leaves seven different heading sizes, which means 56% of sites in the Alexa top 1000 have too many heading declarations.
Different browsers have different default stylesheets. These stylesheets define how elements should look if you haven’t chosen an alternate style. It is important to get all browsers to the same starting point because it eliminates bugs and time wasted testing simple browser compatibility issues. This is should be accomplished using a reset stylesheet such as the one included in YUI. When a reset stylesheet isn’t used, margin zero tends to be sprinkled throughout the stylesheet as developers try to cope with browser differences in the absense of an abstracted solution. Setting the default margins to zero is the most basic job of a reset stylesheet, which means that 64% of the Alexa Top 1000 sites could benefit from including reset.css.
Excessive declarations of padding zero are similar to margins (see the above description). The worse offender in this case declared padding zero 510 times.
Headings (h1-6) often get hidden in class names, which can disguise typography efficiency issues. It is helpful to grep "font-size" to get an idea how many hidden headings exist on the site. The same rules apply to font-size that were explained under h1-6, so in fact the problem is much worse than our initial estimate. These figures mean that 78% of the Alexa Top 1000 sites have excessive heading declarations when we consider hidden headings. In addition, 22% of sites may not be getting the SEO benefits of properly using heading elements.
Important overrides all other declarations specificity, so it can be dangerous. If used correctly, only on leaf nodes, it can be a powerful tool for creating typography and spacing mixins that stand outside of the normal cascade. On the other hand, excessive use of important is a sure indication of specificity wars. Specificity wars are what happens when developers start trying to beat each others specificity, rather than having a real solid architecture and code standards. Eventually, like the worst offender in this case with 526 important properties, you can end up in a case where nearly every property is marked important. This means that 12% of the Alexa Top 1000 Sites probably has an internal specificity war in it’s web team.