One such factor is color. Different hues, values and saturation levels can all influence how a person perceives time. Typically, this can be linked to how “relaxed” or “stressed” a user feels during the wait. The more relaxed they feel, the shorter the wait will feel. It’s entirely possible that a stressed user may feel as though a site is very slow, while a relaxed user may feel that same site is very responsive.

So how do we induce a feeling of relaxation using color? For starters, we can choose blue hues as they elicit the most relaxed feeling state. In sharp contrast, yellow and red hues generate more excitement and thus, more stress. Red is particularly concerning since it also induces a feeling of avoidance and failure, further increasing the level of stress.

Another important consideration is the saturation level of a given color. Users who view low saturation colors have been shown to be in a more relaxed state than those who view a highly saturated color. This effect is particularly emphasized in environments where contrasts are intense – like computer screens.

Finally, we should consider the value of colors. Pastel colors (high value) result in a more relaxed state, and therefore a shortened perception of time, than lower value colors (darker colors).

Using this knowledge, we can create designs that inherently imply a fast, responsive experience to the user. By no means is this a replacement for taking the time to fine-tune the performance of your site. If used in conjunction with performance optimization techniques, however, you can further optimize the experience of your users by providing them with a site that feels as responsive as the stats say it is.

• Performance optimization isn’t that necessary. This misconception doesn’t stem from a lack of caring—most of the people I talk to truly care about crafting a good user experience for their visitors. I think this myth stems more from a lack of awareness. Most of us work on connections that are typically quite a bit faster than that of the average internet user. As a result, we experience the web differently than our users. In addition, most of the people I talk to just haven’t heard about the studies that have come out regarding the effect of performance on the user experience.
• Performance optimization is too difficult and takes too much time. The statement is often followed by “…and my clients won’t pay for all that extra time.” The prevailing belief is that you have to invest numerous hours and considerable energy to improve the performance of your site.
• High performance and beautiful design are mutually exclusive. In the early days of the web when we were browsing the internet via a dialup connection, improving performance meant removing the images from your site. On today’s web people don’t want to have to settle for a less graphically compelling site, so removing most of the images on a site isn’t a very compelling option. The fact that most sites that talk about performance optimization aren’t exactly well known for beautiful designs doesn’t help to dispel the myth.

Thankfully, there’s been a flurry of recent studies and new tools that help to both demonstrate the value of a high-performing site and simplify the process of getting there.

Performance matters

Information on the how of performance has been available for awhile, but not until the last couple years have we really seen answers to the question of why.

In 2009 at Velocity—the annual performance optimization conference—there was a flurry of information released by companies that clearly demonstrated how performance effects key business objectives. Google and Bing teamed up to present results from their respective experiments with page load time. Bing showed that by slowing their load time down by 2 seconds, they saw a 4.3% drop in revenue per user, as well as a 1.8% decrease in the number of search queries per user.

Google’s results were perhaps even more startling. They found that by introducing just a 400ms delay in their pages, the number of searches per user decreased by .59%. Even more concerning was the fact that even after the delay was removed, the slower initial user experience continued to affect how their users interacted with the site. With the delay gone, those same users still had .21% less searches.

Performance isn’t just tied to the business objectives of search engines. Shopzilla presented information detailing how they were able to speed up their site from 4–6 seconds to 1.5 seconds per page. The results were impressive. They saw their conversion rate increase by 7–12% and their page views increased by 25%.

In April of this year, Mozilla performed just a couple of simple performance techniques and shaved 2.2 seconds off their average page load time. This boost in performance increased their download conversions by 15.4%. Based on their daily traffic, they estimated that this increase translated to an astonishing 10.28 million additional downloads per year.

Buoyed by these studies, Google recently announced that they will be taking page load time into consideration when ranking sites. While it’s not yet one of the primary considerations, a high performing site of otherwise equal or similar ranking as a lower performing site will benefit from a bump in their ranking.

With performance contributing to revenue, frequency and depth of interaction, conversion rates and search engine optimization, it becomes crystal clear that performance optimization is not only important but that it should be a primary consideration.

You can have your cake and eat it too

Of course, performance is not all that matters. (If it was, we’d all have sites that look like Jakob Nielsen’s.) Eye candy, time and energy are all critical too. That’s why it’s important to note that there are many techniques you can use to improve the performance of your site without affecting the design at all. In most cases, you can do so using tools that greatly simplify the process and reduce the time investment required.

Improving page load time primarily boils down to two concerns:

1. reducing page weight;
2. and reducing HTTP requests.

Reducing page weight

Reducing page weight is really a lot simpler than you might think. For images, take the time to optimize them by hand using your favorite graphics program. You’ll be amazed by how much smaller you can make them without any noticeable degradation in quality.

If your images have already been produced, you can use a couple of different tools to reduce the size simply and quickly. One such tool is Smushit.com. Smush.It lets you upload graphics which it will then return to you optimized, without any loss in quality. If an app is more your style, ImageOptim is a very powerful app for Macs that wraps up the power of several different image optimization tools in an easy drag-and-drop interface.

For CSS and Javascript, run your code through a minimization tool like YUI Compressor or JSMin, both of which can be found online. These tools will remove unnecessary whitespace and comments from your files, decreasing the file size. YUI Compressor will take it a step further and substitute shorter variable and function names for the longer ones in your core file, resulting in even more savings. Again, if an app is more your style, Stoyan Stefanov’s OMG will automatically minimize and save your CSS and Javascript files.

Reducing HTTP requests

To reduce the number of HTTP requests, you can again use a tool like the online wrapper for YUI Compressor. The online tool gives you the option to upload several files, which it will then combine into one.

In addition to being a good idea in general, making use of progressive enhancement with CSS3 will help with the performance of your site. Using CSS3 for things like gradients, drop shadows and rounded corners can allow you to significantly reduce the number of images included on a page. Doing so will not only reduce the number of HTTP requests, but also reduce your page weight.

Use CSS sprites where applicable. They can be a little tedious to create and maintain, so consider using a tool like the SpriteMe bookmarklet. SpriteMe will search through your CSS to find references to images and recommend which of them you can combine into one sprite. It will not only create the sprite for you, but it will also generate the new CSS for you to place into your stylesheet.

If sprites aren’t your cup of tea, then use Data URI’s. Like sprites, they can be tricky to efficiently maintain, but again, someone has done some of the heavy lifting for us. CSSEmbed, created by Nicholas Zakas, is a great command line tool for parsing CSS and generating Data URIs where appropriate.

Server side optimizations

You can reap great benefits from some basic optimizations in your .htaccess file as well. Enabling gzip compression for not only html, but also stylesheets and scripts, can greatly reduce the size of your files, typically by about 70%. In fact, you can—and should—gzip any textual content that is requested on the server. It’s not necessary to enable gzipping for files like images or PDFs, as you will not notice any improvement in size. In fact, you may see the size of those files actually increase if you try to gzip them.

You should also set a far future Expires header. The Expires header is used by the server to tell the browser how long a component can be cached for. While this technique doesn’t do anything for first time visitors, applying a far future Expires header to your images, stylesheets and scripts will greatly reduce the number of HTTP requests for return visits.

Depending on your role and familiarity with server side technologies, you might feel a bit uncomfortable making significant changes to your .htaccess file. Thankfully someone has already done the heavy lifting for us. There’s actually an .htaccess file already configured with all of these settings that you can just download and drop into place on your server.

Conclusion

Performance matters. More and more studies are confirming that it’s tied to the success of major business objectives. With Google now taking page performance into consideration in their rankings, it can no longer be ignored. Users want sites that are fast. We can give them those, without having to reduce the quality and effectiveness of our designs.

If you perform these basic optimization techniques, you’ll considerably improve the performance of your site and you’ll do so without having to sacrifice your design at all. In fact, you can implement all 35 of the best practices for performance as recommended by Yahoo! without any noticeable difference in your design.

If you also make use of the plethora of freely available tools to simplify each step, you’ll find you don’t have to spend a lot of time to notice a significant improvement in your page load time. Of course, if you’re using a build tool the best solution would be to grab the command line versions of these tools and automate them, but that’s a discussion for another article.

It’s time we stop making excuses and start giving performance the respect it deserves and our users the faster experience they want.

Webgrind is a freely available PHP profiling frontend that sits on top of XDebug. Using it, you can see how many times different functions are called and find what functions called them. You can also quickly see the inclusive cost (time spent inside a function plus calls to other functions) and self cost of each function.

Viewing the logs for the last page load, I could see that mysql_query was called a whopping 52 times and accounted for 84.93% of the processing time (which was at an unacceptable ~3.1ms).

Using the Webgrind frontend, I was able to trace back 23 of those calls to one function. In turn, this function was called by one other function 17 times. I decided to focus there first.

Again, with the help of Webgrind, I could see that this function was called several times, in  separate files, for each page. The function produced the same results each time it was called.

The quick and simple fix, then, was to use a property to cache the results of that function call. So the first time it was called, it would process completely and run the necessary queries. The next time it was called, it would check it’s cache property to see if a value existed for the parameter being passed. If the value did exist – it would return that value.

This simple optimization immediately brought the total queries down from 52 to 36. They still accounted for 74% of the processing time, but that time had dropped dramatically from 3.1ms to ~2ms.

36 queries was still more than I wanted. A similar function to the one I had just optimized was responsible (both indirectly and directly) for 25 of the remaining 36 queries, so I thought I’d take a look there next.

Looking at the source, I could see that while the function asked for a boolean parameter to indicate if it should run certain queries, it never actually checked the value of that parameter. So no matter what, it was running all the queries, all the time. Fixing that error brought the total query count down from 36 to 16 and the total time to process the page was now ~1ms.

As a surprising bonus, there were no locations in the code that I had to change now that the function had been corrected. People hadn’t been expecting to get those extra values in their return object, so they never tried to use them unless they had passed a true value in for that parameter.

All in all I was able to take the query count down from 52 to 16 and the processing time from ~3.1ms to ~1ms. There’s more room for optimization, but this is certainly not a bad start for about 45 minutes of work.

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.