Category Archives: Performance

Creating Living Style Guides to Improve Performance

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

I’ll be speaking at Velocity Conference in a couple weeks where I’ll go into more detail about the Sass magic that made this possible. :)

Why I run my business like an open source project

When I first started consulting, I used to squirrel away in my corner and code. Some weeks later, I’d deliver my perfect shining gem to the client after, quite frankly, trying to talk to them as little as possible throughout most of the process. It wasn’t that I didn’t like people, I especially enjoyed talking with developers, but the gap between what I knew I needed to do to get the job right and my ability to explain it to the client seemed insurmountable. With repetition, my ability to explain technical requirements in a management friendly way has evolved to something like passable, but an equally important change has been Github.


Github has allowed us to take a different path with our projects. We now treat them much like open source projects. We strive for transparency and clarity in everything we deliver as well as in the process by which we deliver it. We often do complex UI rewrites and performance evaluations for big companies like Facebook, Paypal, Adobe, Salesforce, Trulia, Williams Sonoma, Pottery Barn, etc. Big companies have a lot of stakeholders and we’ve found that Github is an amazing way to include them in the project from the beginning.

Our clients have access to the code we are writing from the first line we commit. When my developers and I code review each other’s work, the client can see and also participate in that code review. In that way, they get to understand (and buy in on) not only the end result, but the rationelle behind it. Clients also send their developers to work side by side with us. We take them in as a part of our team, submit them to the same grueling code reviews we all go through.

We’ve found that they are happier this way. The transparency I feared, the risk taken by trying to explain something and failing, has been far outweighed by the practical benefits of healthy collaboration. They now feel the end result belongs to them, rather than being something forced on them from outside or upper management.

Glorious bugs…

There is also something great about letting a client peek inside the works… they find bugs, omissions, and misunderstandings. Why is that great? Because they find them right away, rather than several weeks or months into a project. They also feel empowered to open github issues for those bugs, helping us do our job even better. Instead of it being a terrible thing to find bugs, it becomes an ordinary part of the process. I usually explain it like popcorn popping. For a while you will have a lot of pops, and then slowly it will wane and you’ll just get a pop every now and then. When the pops become pretty infrequent, we move the code from our repo to theirs. I hope this means our clients trust us, because they get to see that we will continue to show up for them throughout the project and that we’ll always have a curious, relaxed, and grateful attitude when they identify something that needs fixing.

We didn’t want you to work on that!

It also means that there isn’t any issue of “we didn’t ask you to work on that”. The client gets to approve all work (in the Github issue for the feature) before we even get started. They also get to see the kind of bugs I assign to Fiona, or she assigns to Arnaud and get a sense of the teams strengths and weaknesses. That helps them know who to contact when an issue comes up. Yay for anything that makes me less of a bottleneck. :)

And the most important reason? Code quality

I’m a firm believer that open source code is of higher quality than code written in a vacuum. I can’t say if that is true for every project out there, but it has certainly been true for us. Greater transparency has enabled us to have a tighter feedback loop and make a few things I’m quite proud of.

Anyway, I could go on and on about this because I’m quite passionate about how an open source approach and Github in particular has enabled us to improve our work, but I’d love to hear from you. Have you used github in this way? Do you use it internally? What works? Any tricks? I know their are a few features I still wish existed, how about you?

Don’t Style Headings Using HTML5 Sections

Styling headings is either a deceptively complex problem, or maybe the design of CSS made it appear complex when it need not have done.

When styling headings (or really anything) we want three big goals to be met:

  1. DRY – Do not repeat yourself. We want to set headings once and never (ok, rarely!) repeat those font styles or selectors. This will make our site easier to maintain.
  2. Predictable – The heading should look the same no matter where on the page it is placed. This will make creating new pages and content easier.
  3. Keep specificity low and selectors as simple as possible. This will help with performance and keep the site from growing more and more tangled over time.

The html5 section tag is weird. It dramatically changes the way we use headings. It also changes the way browsers and assistive technologies are meant to interpret those headings. The spec says:

“The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”
The HTML5 Spec

The spec goes on to warn us that sections are not really meant to be used just because you want to attach a style a particular piece of content:

“The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.”
The HTML5 Spec

People seem to have blocked out this last (very important) bit, so I’ll reiterate. Sections aren’t really meant to be used by CSS for style purposes (at least not *only* for styles). So, if sections aren’t meant to be used to make my headings purty, why do they exist? They change the way the browser and assistive technologies interpret the importance of a heading relative to the other headings on the page. To understand this, you need to know a bit about the pitfalls of the way headings have been written up until now.

HTML Headings

Think back to the outlines you wrote for term papers in high school. Each bit of a website is meant to be like that, each heading corresponds to a piece of that outline, and you know when you go up or down a level by the heading level chosen. H2 is down one level from H1. And h6 is down four levels from H2.

I. Big roman numerals are the H2s
   A. This is an h3
   B. This is also and h3
      i. Now we have an h4
      ii. And another h4
II. Big roman numerals are the H2s
III. Big roman numerals are the H2s
IV. Big roman numerals are the H2s

The trouble is, on a modern website or web app, this model isn’t a really natural fit. Especially if a site “mashes up” content from sources they don’t control (say for example adding a twitter feed to a blog), they may not be able to set the heading levels used by the mashup content. In this case, most developers, just include the new content, and the outline gets a little murkier.

A murky outline may be somewhat normal, because I’d take it a step further and say that, on most modern websites, the idea that the site has much in common with a high school term paper outline is a bit of a stretch — The section element tries to bridge the gap between the w3c’s outline view of the web and the way developers are really building sites. The section element essentially reorders the heading tree so that whatever headings are used, if they are wrapped in a section element, they will be made to fit in with other content on the page. They need only be internally consistent within each section.

<h2>Me on the web...</h2>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li> 
<p><a href="more.html">More stuff on the web</a></p>

HTML5 Headings & Section Elements

If you wrap it in a section, the browser will interpret it as one level down from it’s parent heading.

<h2>Me on the web...</h2>
<h1>My Twitter Feed</h1>
<ul class="tweets">
 <li>Mmmm, cornflakes.</li>
 <li>Something inane...</li> 
<p><a href="more.html">More stuff on the web</a></p>

The section element also makes it clear that the list of tweets belongs to the Twitter feed, and the more link does not. This makes content more portable, which is okay — even if it maybe isn’t that important. However, it does seem to be confusing people about how they should style their headings. I think this bit of the spec might be confusing people:

Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.
The HTML5 Spec

This has lead people to think that they should only ever use h1s (which, is a fair interpretation of the working group’s note). However, lots of people have taken it a little too far because they didn’t read the second quote [1], where it says additional section elements shouldn’t really be used only to apply CSS styles. Admittedly a subtle difference, but important! Section elements are meant to help the browser figure out what level the heading really is, but not necessarily to decide how to style it. By tying styles to browser heading level interpretation, developers (trying to implement html5 from the spec) are ending up with selectors that look like this:

h1{font-size: 36px}
section h1{font-size: 28px}
section section h1{font-size: 22px}
section section section h1{font-size: 18px}
section section section section h1{font-size: 16px}
section section section section section h1{font-size: 14px}
section section section section section section h1{font-size: 13px}
section section section section section section section h1{font-size: 11px}

(Note: This is vastly simplified as I’ve only included sections and not the other sectioning elements like articles or asides. This is a more realistic, real life code sample.)

Let’s see how well this meets our goals:

Q: What if, semantically speaking, you need to add an additional section to a bit of html?

It will unintentionally change the way your headings look. If it is high enough on the document tree it could change your entire page. That seems badly unpredictable.

Q: What happens if the design calls for a 14px heading in a part of the site that is only nested two sectioning contents deep?

To make it work with the existing code, you would need to add additional unnecessary section elements. The spec pretty clearly states that section elements are not meant to be added just to change styles. Plus, that is just kind of gross.

Q: What if we create another rule that duplicates the 14px property value pair?

section.special section h1 {font-size:14px}

This clearly isn’t DRY. We’re repeating the code to set the font-size to 14px, and our specificity is starting to get weird. If we want a normal two-section deep heading (22px) we now can’t have it in the special section. We also can’t reuse the new rule anywhere else. Continue in this direction for a while on a project and you can end up with hundreds or even thousands of heading declarations. Eek! This isn’t meeting our stated goals at all.

(For more info about how this can get out of control, check out this video on how our current methods for styling headings are leading to bad outcomes.)

So, how do we style headings in an HTML5 world?

The answer is right there in the spec, next to the place where we learned to use only H1s. We shouldn’t use sectioning elements for styling. We should let them do the job they were designed for, which is sorting out the document tree, and solve styling issues another way that meets our goals better: with simple reusable class names that can be applied to any of our headings no matter how deep they may be in the sectioning content.

I recommend abstracting site wide headings into classes because then they are portable, predictable, and dry. You can call them anything you like. Jeremy Keith recommends something like:

.Alpha {}
.Beta {} 
.Gamma {} 
.Delta {} 
.Epsilon {} 
.Zeta {} 


.tera {} 
.giga {} 
.mega {} 
.kilo {} 
.hecto {} 
.deca {} 
.deci {} 
.centi {} 
.milli {} 
.micro {} 
.nano {} 
.pico {} 

I keep it simple with:


It doesn’t really matter what system you choose as long as it is something easy for your team to remember. Then, no matter how many section levels deep your heading is nested, you can make it look just how you want:

<h1 class="giga">Me on the web...</h1>
  <h1 class="kilo">My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
<p><a href="more.html">More stuff on the web</a></p>

So now, your twitter feed, from the previous example, can be in the sidebar on an article page, or in the footer of your homepage, and it will still look the way it was designed to. Whether you are using html5 sections or not, you don’t want to repeat code or have it be unpredictable, so I think separating styles from how the browser generates the page outline is just sensible.

UPDATE 9/6: If you truly cannot change the HTML, even to add class names, then the only way to style that bit is to put a wrapper around it with a unique class and use descendent selectors to force the style you want. This should be the exception, not the rule! (Thanks Simon for pointing out that I wasn’t addressing one of the use cases I had talked about above)

<h1 class="giga">Me on the web...</h1>
<section class="tweetfeed">
  <h1>My Twitter Feed</h1>
  <ul class="tweets">
    <li>Mmmm, cornflakes.</li>
    <li>Something inane...</li>
<p><a href="more.html">More stuff on the web</a></p>

If you would like a far more eloquent walk through all the new html5 elements, get Jeremy Keith’s book HTML5 For Web Designers.

Thanks to Alex Kessinger and Josh for helping me solidify my thoughts around this by bringing up good questions on the CSS Lint Google Group.

CSS Lint open sourced

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:

  1. 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.
  2. If you are comfortable in JavaScript, fork the github project, code up a rule, and submit a pull request. You’ll need to provide all the same documentation requsted in item 1.
  3. If you are comfortable with Node, test out the command line version, submit feature requests.

CSS Lint for Node.js

If you’d like a command line version of CSS Lint, you can install CSS Lint for Node.js using npm using the following:

sudo npm install -g csslint

Once installed, you can pass in any number of CSS files or directories containing CSS files to see the results. For example:

csslint test.css dir_of_css/ test2.css

You’ll receive the same errors and warnings as you would with the web interface.

Welcoming Nicholas Zakas to the Team

I am so very pleased to announce that Nicholas Zakas and I are joining forces to form a consulting duo. Nicholas has spent the last five years defining what it meant to to be a client-side engineer at Yahoo!. He consistently raised the client-side glass ceiling with his commitment to good code and practical solutions. He also literally wrote the book on JavaScript Performance. Like me, Nicholas cares deeply about performance and scalability. And, most importantly, we share a love of finding elegant solutions to hard problems, which we feel makes us a good match.

I’ll let Nicholas speak for himself:

I’ll be … teaming up with my friend (and former Yahoo) Nicole Sullivan to do consulting work. Nicole and I have talked off and on about working together on outside projects after having fun working together on a couple of projects at Yahoo!. Between the two of us, we hope to provide a wide range of front-end consulting services including performance evaluations, general architecture, and of course, JavaScript and CSS. If you’re interested in hiring us, please email projects (at)
Nicholas Zakas

Please come see us at Velocity Conference on June 14.