Data URIs can be tricky to implement efficiently however. Since they are a Base64-encoded representation of an image, there is a built-in level of obfuscation that can make manual maintenance tedious. Thankfully, Nicholas put together a command line tool called CSSEmbed which takes the pain out of using them.

CSSEmbed is a very straightforward tool that parses a stylesheet and converts all references of images to their data URI equivalents. Installation is as simple as downloading the .jar file and placing it where you’d like. Then you use a simple command specifying any options, the file to output to, and the file to parse, like so:

java -jar cssembed.jar -o styles_uri.css styles.css

Since versions of Internet Explorer prior to IE8 don’t support data URIs, you have to use MHTML as a workaround (again, Stoyan has an excellent post with more info). The command for that is very similar — you just need to make sure to declare a “root” (for example, I’d use http://timkadlec.com as my root for this site) which CSSEmbed will use in the MHTML.

java -jar cssembed.jar -o styles_mhtml.css styles.css --mhtml --mhtmlroot http://timkadlec.com

Right now, to my knowledge, you can’t parse an entire directory of CSS files, but that’s about the only thing I can think of that I’d like to see added. It’s a great tool to use during an automated build to really simplify the process of using data URIs and I definitely encourage you to go download it and give it a try.

What Does It Test

Page Speed analyzes the performance of a page based on a set of 26 rules (as of version 1.7) that Google has documented. Each rule is given a priority code based on how great the potential impact would be on the page load time. Once Page Speed has determined which rules are broken, it gives the page a score between 0 and 100, which can be exported in JSON format, or sent straight to ShowSlow.com – a tool for recording YSlow and Page Speed scores over time.

The rules range from common rules like optimize your images, to lesser known techniques like defining a character set early. A complete list of the rules Page Speed checks for is below:

1. Combine external CSS
2. Minimize DNS lookups
3. Leverage browser caching
4. Remove unused CSS
5. Leverage proxy caching
6. Minify CSS
7. Minify HTML
8. Minify Javascript
9. Specify image dimensions
10. Serve static content from a cookieless domain
11. Use efficient CSS selectors
12. Avoid bad requests
13. Combine external JavaScript
14. Enable compression
15. Minimize redirects
16. Minimize request size
17. Optimize images
18. Optimize the order of styles and scripts
19. Put CSS in the document head
20. Serve resources from a consistent URL
21. Serve scaled images
22. Specify a character set early
23. Avoid CSS expressions
24. Defer loading of JavaScript
25. Parallelize downloads across hostnames
26. Specify a cache validator

What Else Can It Do

Like I said, while auditing may be the most well known feature of Page Speed, it is far from being the extent of its capabilities. In addition to performing a basic audit of your page, Page Speed automatically optimizes the Javascript files, CSS files, and images that it finds on the page, and saves them to a folder on your computer (which you can specify). It also has the ability to profile deferred Javascript files – something it does not do by default.

Perhaps the most fun though comes when you use the Page Speed Activity panel. At it’s most basic usage, the activity panel lets you record a timeline of all the browser activities, including both network activity and Javascript processing, that take place during the time you choose to record. That means that you get detail like how much time was spent connecting to the server, and how much time was spent executing the Javascript.

The activity panel also allows you to see a list of all the Javascript functions that were instantiated, but not called, during the recording period. This information could help you determine what portions of your code are not necessary immediately so that you can choose to load them later, allowing you to further improve your load time. You can also record “paint snapshots” in the activity panel which highlight each element in a page as it is rendered.

While the advanced features offered by the activity panel are very useful, it’s important to keep in mind that they do slow down the Page Speed plugin a little. Since they add a little bit more overhead, the timeline will not be 100% accurate and will serve you better as a relative reference than an exact approximation of the time it takes your page to load.

It’s Open Source Too!

Just recently, the Page Speed SDK was released as open source. Already, Steve Souders has demonstrated the usefulness of this by building HAR to Page Speed – a tool that will apply the Page Speed rules to a HAR (HTTP Archive specification – a format gaining popularity) file you upload.

By opening the SDK up to open source, the potential is there for developers to build cross-platform tools that would allow people to analyze the performance of their site according to the Page Speed rules, regardless of the browser in use. It’s going to be exciting to see what other tools get built around the SDK as it continues to evolve.

One web guru who you may have heard of, Jeffrey Zeldman, posted an article on Sunday wherein he describes the choice he feels designers are now faced with:

So now we face a dilemma. As we continue to seduce viewers via large, multiple background images, image replacement, web fonts or sIFR, and so on, we may find our beautiful sites losing page rank.

It’s a fair enough point to make  - sometimes a designer will need to make a decision between additional aesthetic effects and improved performance (but not that often). What followed in the comments was disturbing though – many people were actually viewing Google’s move as a negative thing and seemed to be very worried about it’s effects.  Some felt Google was simply abusing their power, others believed they’d have to sacrifice good design in order to receive a decent ranking. The situation, I think, needs a little diffusing.

Deep Breaths People

First, let’s remember that Google themselves have said that this addition to their algorithm affects less than 1% of their search queries. That means that while it is a factor, it is certainly not the most important one. It also means that while Google wants to display sites that perform well, their standards are probably not that high. If they were, there’d be a lot more sites being penalized in the rankings.

Secondly, this is a great move by Google and is fantastic news for users. Study after study has demonstrated that users really care about how well a site performs. It’s been shown that performance has an effect on bounce rate, purchase amounts, queries per user, credibility and more. If Google really cares about presenting their users with the best content, then this was a great demonstration of that belief.

You Can Have Your Cake and Eat It Too

Finally, there’s no need to panic – a site can be beautiful and still perform very well. For an example, let’s look at Happy Cog’s own visitphilly.com, both because it is a beautiful site, and because this conversation was started on Zeldman’s blog.

A quick look lets us identify some easy improvements. For one, there are 47 CSS background images. A quick run through SpriteMe trims that number down to 15.

There are also 7 scripts being called, 3 of which are unminified. At least a few of the seven could be concatenated to reduce some more requests and running the 3 unminified scripts through a compressor shaves a whopping 54% percent off their combined size. Finally, by running the images on the home page through Smush.It, we eliminate another 133KB of baggage.

When you add those fixes together, the performance of the site would be dramatically improved, and the visual experience would not be diminished at all. It would be indistinguishable from the unoptimized version in every way, except that it would load significantly quicker.

So in summary, performance and beauty are not mutually exclusive. By taking performance into consideration, Google is not making the web a difficult place for designers; they’re simply making the web a more usable and less frustrating place for users.

Having a lot of images in a page can be very costly. Each image requires an HTTP request, and each HTTP request comes with plenty of overhead. I’ve seen pages with 20+ icons, each requiring their own request – that’s a serious hinderance to performance.

A way of combatting the issue is to use sprites. For the uninitiated, an image sprite is simply one big image that includes many smaller images. This allows you to make one HTTP request, and using CSS, still make use of a variety of different images. If you plan ahead and do this while initially building the site, it’s rather simple to do. How do you quickly implement this strategy in an existing site though?

That’s where SpriteMe comes in. Steve Souders wrote a handy bookmarklet that looks through the images on a given page and identifies those that could potentially be combined into a sprite. At that point, it gives you a simple drag and drop interface with which you can add or remove items from a sprite. Once you’ve determined which images you’d like to combine, you can click “make sprite” and the bookmarklet will automatically create the image sprite for you, inject it into the page, and show you the CSS you’ll need to add.

From there it’s as simple as downloading the image and copying the CSS the tool provides into your stylesheet (I believe the ability to export the CSS is being worked on). On one recent project, I used SpriteMe to create a sprite from ~25 images that were being used in the site’s navigation in about 15 minutes of work. The only additional step I took was to run the generated sprite through OptiPng to shave some filesize off (I’ll talk about OptiPng in another post).

So what are the downsides? Not too much. I’d love to see it do some optimization on the sprites it produces – in the example I gave above, OptiPng shaved ~40% off the file size off. I’d also be willing to bet that the tool produces a bit more whitespace than is optimal or necessary in it’s sprites resulting in more memory usage. To be fair, I haven’t tried to remove some of that excess whitespace to determine how big of a deal it really is.

All things considered, these are minor issues. I can easily run an image optimization tool on the produced sprite to fix that up, and it’s not like there’s THAT much whitespace – just probably a bit more than needed. These are, in my opinion, minor tradeoffs for the incredible convenience this tool provides.

First off was setting expires tags and turning gzipping on. Since I’ve done this in too many .htaccess files to count, this was simply a copy/paste job with very little tweaking necessary.

Then, I decided to optimize the images (what few there are). I ran Smush.It from the YSlow tool in Firefox. That compressed the images which I then downloaded to my computer and then promptly pushed right back up to the server. It took me 5, maybe 10 minutes and it cut the image size by about 33% total.

The icons for the RSS, Twitter and LinkedIn links in the footer were separate images – each requiring its own HTTP request. By using the SpriteMe bookmarklet, I was able to generate a new sprite and the necessary CSS in a few minutes and trim those 3 HTTP requests down into one. I also ran OptiPng from the terminal window on my Mac on the new sprited image to shave off about 40% of the size.

I then minimized the CSS and Javascript (what little I was using) using OMG, which shaved ~30% off the file size of each.

Without any of these optimizations, my YSlow grade was a C and my page size was about 150K. After the 1/2 hour investment (if that…I’m being generous here) my YSlow grade came in at an A with a page size around 80K. Not bad for such little work.

There’s much more I can, and will, do here (caching, data-uri’s, etc.) but the moral of the story is that not optimizing your sites because it takes too long is just no longer an argument you can use. Make use of the tools available to you, and it’s downright scary how quickly you can speed up a site.