This post is a wrap-up of some of the things I’ve been learning about performance. It includes some follow-up from my last post on isolating performance problems with Firebug
One of the comments from my earlier post suggested that this is also baked into Chrome. Although I work for Mozilla which means I spend most of my time using Firefox, I have no problem duly noting that Chrome contains some excellent tools for looking at performance as well. In this post, I’m actually going to show how Chrome can be used to get a sense of front-end performance. (If you think that Mozilla and Google are adversaries, you might want to have a look at this and this.)
Let’s put some definition around front-end and back-end performance. In my previous post, I was looking at calls going to the back end server and how long those were taking. That’s back-end performance. When we talk about front-end performance, we’re concerned with HTML, Javascript and CSS performance. Admittedly, I knew absolutely nothing about this side of performance before attending an HTML5 conference in September aside from some googling I did which resulted in this guerilla post. Note that I wrote that post before I saw this talk by Steve Souders, creator of YSlow. The talk itself was quite an awakening, and afterward, I knew I had lots more homework to do. (This link is to a similar presentation done by Steve at a JS Meetup a week or so later.)
After the conference, in addition to hunkering down and learning more about CSS, I started looking through both of Steve’s books, High Performance Web-sites and Even Faster Websites. Both of these show that there is a lot which can be done for performance on both the front-end and the back-end. Since he works for Google, there is some cross-pollination of his ideas and the information you get out of Chrome’s developer tools. An example of this cross-pollination is Chrome’s ability to do an audit of front-end performance. To get to this functionality, open Chrome, click on the wrench in the top right corner (I hear this is a spanner in the UK) -> tools -> Developer Tools. This will open the Developer tools, from there, click on the “Audits” tab. If you are already on the page you want audited, you can select select “load page and refresh browser” to get more accurate results.
Here’s a screenshot of an audit for addons.mozilla.org.
Some of what I noticed in here maps to suggestions in the book, “High Performance Web-Sites.” For example, one of the suggestions is that some of the components being downloaded need to be gzipped. This is the same as zipping files so that they are small enough to send through email only in the context of a web-page and http request. There is a header which can be added to http requests so that the response you get back from the server is zipped. Who knew!!!
Although the Google Chrome Audit will catch some things, there are other suggestions Souders makes that it doesn’t mention. For example, it’s worth understanding which images on a webpage should be included in a sprite. Sprites are used to aggregate several images into one. They are laid out in a grid and are accessed by coordinates. Here’s an example of a sprite used for the addons.mozilla.org details pages. If you’d like to see it in action, have a look at this page. The icons are on the top right where it says, “add to this collection” and “share this addon.”
An example of something I plan to question more in the next quarter, is the usage of CSS expressions in addons. Even though CSS is used to control the layout and style of a page, it is entirely possible to include “if” statements in CSS via the expression method and the ternary operator. Rule #9 in “High Performance Websites” advises against using this because the expression will be evaluated when the page is rendered, resized, when the user scrolls or even moves the mouse over the page. I’d like to understand more about the tradeoffs when I see them used such as here.
An early observations about looking at performance is that this is an area awash in tools and it would be easy to just keep trying new tools without digging deeper. Opening Chrome or Firebug and pointing them at a page is easy enough, but I’m ready to look through some of the front-end code, talk with the devs and begin approaching performance in AMO with more precision. More to come in the new year…
