Imagine you’re at an intersection waiting for your turn to walk across the street. You push the button to call the walk signal, and you take out your phone. You want to accomplish one thing: maybe check your e-mail, add an item to your to-do list, or check Twitter. You have a limited amount of time to accomplish that one thing.
That amount of time is how long users have to finish what they want to do on your site. And it matters.
Adding half a second to a search results page can decrease traffic and ad revenues by 20 percent, according to a Google study. The same article reports Amazon found that every additional 100 milliseconds of load time decreased sales by 1 percent. Users expect pages to load in two seconds—and after three seconds, up to 40 percent will simply leave.
Can you keep up? If you’re designing sites with rich content, lots of dynamic elements, larger JavaScript files, and complex graphics—like so many of us are—the answer might be “no.”
It’s time we make performance optimization a fundamental part of how we design, build, and test every single site we create—for every single device.
Designing for performance#section2
Website performance starts with design. Weigh a design choice’s impact on page speed against its impact on your site’s conversion rate. Do you really need eight different shades of blue? What value does this 1,000px-wide background image add? Will replacing a sprite with an icon font actually add more page weight and slow rendering, or will it be faster than the original image?
Not every design decision will favor performance. I’ve found that a button style that slightly slows page speed can still increase conversions, and it’s worth the small web performance sacrifice.
But sometimes, performance will win. I once had a landing page redesign that added a significant amount of images to a page, and I wasn’t sure whether the performance hit would have a negative impact on conversions, so I rolled the redesign out to a small subset of users in an A/B test to see what the impact would be. The new design took twice as long to load, and I immediately saw a high exit rate and lower conversion rate, so we kept the original lightweight design. Being wrong is okay—it’s what gives you a benchmark.
In another experiment, the dyn.com homepage featured a thumbnail image section with 26 images that rotated in and out of 10 slots.
My teammate at the time put all 26 images into a sprite, which:
- Increased the total homepage size by 60K with the increased CSS, JavaScript, and image size needed to recreate this effect with the sprite
- Decreased the number of requests by 21 percent
- Cut the total homepage load time by a whopping 35 percent
This proves that it’s worth experimenting: We weren’t sure whether or not this would be a page speed success, but we felt it was worth it to learn from the experiment.
Coding for performance#section3
Clean your HTML, and everything else will follow.
Start by renaming non-semantic elements in your HTML. This is probably the toughest, but once you start thinking about theming in terms of semantics like “nav” or “article” and less with design or grid names, you’ll make significant headway. Often we get to elements with non-semantic names by way of needing more weight in CSS selectors, and instead of cleaning our CSS and adding specificity the right way, we add unnecessary IDs and elements to our HTML.
Then, clean up your CSS. Remove inefficient selectors first. In a study I performed for writegoodcode.com, I found that adding inefficient selectors to a CSS file actually increased page load time by 5.5 percent. More efficient CSS selectors will actually be easier to redesign and customize the styles of in the future since they are easier to read in your stylesheet and have semantic meaning. Repurposable, editable code often goes hand-in-hand with good performance. In that case study, I saved 39 percent of the CSS file size by cleaning my CSS files.
Next, focus on curing your HTML of div-itis. Typically the cleaner your markup ends up, the smaller your CSS will be, and the easier redesigning and editing will be in the future. It saves you not just page load time, but development time too.
Last, focus on creating repurposable code, which saves time and results in smaller CSS and HTML files. Less HTML and CSS will be significantly easier to maintain and redesign later, and the smaller page sizes will have a positive impact on page speed.
Optimizing requests#section4
Requests are when your browser has to go fetch something like a file or a DNS record. The cleaner your markup, the fewer requests the browser has to make—and the less time users will spend waiting for their browser to make those round trips.
In addition to clean markup, minimize JavaScript requests by only loading it when absolutely necessary. Don’t call a file on every page if you don’t need it on every page. Don’t load a JavaScript file on a responsive design that is only needed for larger screens; for example, replace social scripts with simple links instead. You can also load JavaScript asynchronously so that the JavaScript won’t block any content from rendering.
Though a responsive design typically means more CSS and images (larger page weight), you can still get faster load times from larger page sizes if you cut requests.
Optimizing images#section5
Save as many image requests as you can, too. First, focus on creating sprites. In my writegoodcode.com study, I found that a sprite for the icons in the example cut page load time by 16.6 percent. I like to start cleaning up images by creating one sprite for repeating backgrounds. You may need to create one for vertical repeats and one for horizontal repeats.
Next, create one transparent sprite for no-repeat backgrounds. This will include things like your logo and icons. As you get more advanced, you can also use tools like Grunticon, which takes SVG icon and background images and figures out how best to serve them based on the user’s browser’s capabilities.
After you regenerate your images, run them through an optimizer like ImageOptim. Similarly, retina-sized images can still be made smaller with extensive compression that isn’t noticeable in the end result.
Now see which images you can replace with CSS3 gradients. This will not only make a dent in page load time, but it will also make it infinitely easier to edit the site later, as developers won’t have to find original image files to edit, regenerate, or re-optimize in the future.
Last, look at using Base64 encode, which allows you to embed an image into your CSS file instead of calling it using a separate URL. It ends up looking like this:
#nav li:after {
content:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAI0lEQVQIW2P4//8/w8yZM//DMIjPAGPAMIiPWxCIMQQxzAQAoFpF7lGFr24AAAAASUVORK5CYII=);
}The random letters and numbers add up to a small circle that’s used in many places within dyn.com. Embedding the image allows you to save an image request each time you want to use it in your design. Embedding images using this method will make your CSS file larger, so it’s worth testing the page load time before and after to ensure you’re making improvements.
Measuring performance#section6
Now for the fun part: determining whether your efforts are paying off.
Both Google’s PageSpeed and Yahoo!’s YSlow offer suggestions on how you can improve page load time, including identifying which elements block page rendering and the size of your page’s different components like CSS or HTML.
I also recommend the YSlow extension 3PO, which checks your site for integration with popular third-party scripts like Twitter, Facebook, and Google+. The plugin can give you recommendations on how to further optimize the social scripts on your page to improve page load time.
WebPageTest.org has been my go-to benchmarking tool ever since I first started making improvements based on PageSpeed and YSlow’s suggestions. It gives very detailed information about requests, file size, and timing, and it offers multiple locations and browsers to test in.
Benchmarking can help you troubleshoot as you design. Measuring performance and analyzing the results will help you make both your large- and small-screen designs faster. You can also test and benchmark techniques like conditional loading of images as you get more comfortable developing for performance.
The impact of web performance#section7
Web performance affects your users—and that means its everyone’s job to understand it, measure it, and improve it. All of these techniques will lead to better page load time, which creates a significant improvement to your site’s user experience.
Happier users mean better conversion rates, whether you’re measuring in revenue, signups, returning visits, or downloads. With a fast page load time, people can use your site and accomplish what they want in a short amount of time—even if it’s just while they’re waiting for a walk signal.
If these optimizations look like a pain to do manually,
mod_pagespeed (apache) and ngx_pagespeed (nginx) can make many [1] of them automatically.
Disclaimer: I work on pagespeed.
[1] Of the ones mentioned here it can optimize images, inline small images, sprite images, and defer javascript execution. Full feature list: https://developers.google.com/speed/docs/mod_pagespeed/filters
Agree with this article. So many over designed sites out there that focus on looking superb but then have 100’s of requests and bandwidth black holes all over the code.
Excellent stuff Lara! There really does need to be more focus on this aspect of the user experience.
Not so long ago I wrote an article where I outlined ROPS – Return on page speed. A tool to help evaluate the “cost” of extra features (or the “profit” from improvements), and to help explain or sell them to your client/organisation.
Wonderful article! Thank you for the advice, there are to many sites that are made assuming everyone has a high speed internet connection. We need to make this a process in designing all our sites.
Good!!
Great article and good to see this topic getting more and more focus (especially framing performance as a design consideration). I wasn’t 100% sure what you meant by this though: “Start by renaming non-semantic elements in your HTML. This is probably the toughest, but once you start thinking about theming in terms of semantics like “nav” or “article” and less with design or grid names, you’ll make significant headway.” Are you suggesting using HTML5 elements rather than something like
?
First, this article is excellent. Thank you for writing it, Lara.
I’m wondering about “inefficient rules” in CSS. This is an older post from Nicole Sullivan, but Paul Irish tweeted it yesterday and left a comment on the post confirming that “selector performance has changed” is now true in Firefox as well as webkit browsers. http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/
I see that your code tests for inefficient rules are worse for IE than Chrome. I wonder if you have thoughts on this issue and how’s it’s changing. I’m guessing the take-away may be that things are getting better so perhaps we don’t have to obsess about selectors as much, but sane-as-possible code is always a best practice (SMACSS is a great resource, too).
I’m also wondering if you have any thoughts about javascript and CSS aggregation. That’s a tool that’s available to Drupal front-end coders out of the box. I haven’t tested loading a file only when needed vs. just letting it be part of the large aggregated file so that it’s one request instead of two. That’s something I need to investigate.
Thanks again!
There are very few articles I ask my whole team to read and discuss. This is one we’re going to be talking about for months! We are a small shop doing big work and speed optimization usually ends with “png or jpg?”
Thank you (and on behalf of our customers) for a clear, direct, actionable article.
ALA – You guys rock!
Thank you, @Patrick Brown. We try. (And our authors try harder.)
Thank you, now i have the means to convince others of my work value! In the subject of image otimization here is a recent commit made by me with good improvements in compression and robustness of image content type.
(Obs.: Anyone interested in beating jpegmini i have a work in progress, just need more samples to test)
http://commit-digest.org/issues/2013-01-20/moreinfo/1332557/
@Rob Wood – <div class=”nav”> is fine (<ul class=”nav” is likely even better!). What I’m really mean is avoiding <div class=”blue”> or <p class=”left”>. Those are non-semantic elements that you’ll want to rename.
@Johanna Bates – I find that the better-structured the code is (and more easily editable it is by other devs later, as well as the more repurposable it is) the more performant it tends to be. You’re right, we don’t have to obsess about selectors as much, but cleanliness of CSS and high performance go hand-in-hand with ease of editing. For that reason I think it’s great to obsess over specificity 🙂 Also, fewer requests is generally better, but sometimes caching rules, asynchronicity and other performance optimizations can impact your decisions about when to make requests.
Thank you for writing this post. I just found this article after reading http://browserdiet.com and was happy to see so many great resources and insights show up.
Probably better that it tends to be. Your question right, we do not have to obsess about a more and more, but clean and high performance go hand in hand easily edited.Well so I think it is great to remove the images, require less generally better, but the provisions that sometimes other performance optimization http://iosvn.vn – Thay man hinh iphone, thay man hinh ipad, sua chua iphone, sua chua macbook
I have a very hard time believing that if a page doesn’t load after 3 seconds, that a user simply leaves. While I will fully acknowledge that we live in an age of instant gratification, and where a lack of patience is more prevalent than ever before – I don’t think that 3 seconds is even long enough for someone to make the conscious decision to leave and go somewhere else. In order for that to happen, a user would have to go to the URL… wait 2 seconds.. decide that it is taking too long and is no longer worth it, think of another place to take their business, and then either close out their browser or redirect their browser elsewhere. The thing is – even if I could do all of that within 3 seconds – by the time I loaded up the “new” site in my browser, more time would have elapsed than if I had just waited another second for the current site to load. This is not to say that I don’t wholeheartedly agree with the article – and that we should be ever trying for more optimized pages – but I don’t think people are quite as impatient as all of that, just yet. Truth be told – when a user really wants to access something – I have found just the opposite to be true – that they can be surprisingly patient.
Many webmasters ignore the load speed of their sites. In my opinion this is one of the three most important things a website should master. The other two are content and optimization (on and off page SEO).
Look ad Google. They made blogger much simpler (with this white design). And now YouTube with the upcoming “onechannel” thing.
Simplicity is the key I guess.
Great Article. I recently re-designed my portfolio and removed majority of the graphics of the website design. The only images on my site now are my portfolio images and a few social icons.
This article will also add insight for a HCI class I’m taking. Thanks!
I don’t have too much knowledge about UX Design but, a good web page design will help users to easily access your website and less code will improve your website performance and page speed which is helpful to reduce bounce rate…
Thank you Lara for such informative post. I have been searching this information for a long time until i found it here….In today’s modern world, Patience is more widespread than before….therefore it is very important to design user friendly websites which can load easily and quickly. Loved reading this post. Thumbs up!
Good points, but for example if you have few sprites it would be good to cache them. So, how about some cache mechanism via .htaccess?
http://www.bagsshoeswallets.com/
All good points. I have been evangelizing performance driven development (PDD) for a couple of years myself as I outlined in this recent article on SearchCIO – http://bit.ly/Znz8qs
Using svg web fonts instead of symbol / images, can really improve your performance too. Facebook, twitter, and other social networks logos, arrows used in sliders, symbols used in flat design, and even your logo can be stored in only one web font file.
Using a CDN in addition with a page cache will not reduce your number of requests but can improve a lot your page speed too.
Good luck for your page optimizations !
Two things; a great thanks, and a question.
– I used one old article I found on your site, and it really helped me a lot in developing our 404 page: http://www.itware.com/index.php?option=com_k2&view=item&layout=item&id=774
– Than, a balance question: I agree with you about the need to have “speedy” web pages, but how can you balance the quality with the speedness?
On our Home Page itware.com we are use to publish three covers of our magazine Toolnews. If we scale down the size of the images the titles are not readeble any more. If we keep them at the size we are use to, they are slowew to load. Any suggustion about how to choose the best strategy?
Thanks indeed
Alessandro
Great article Lara. Need to focus more on front-end performance. Thanks
Great read and lots of useful information. Thanks!
Great article! This also remind me the design process back to the day I was in the school. While we are designing, we should always keep asking questions to ourselves. What’s the benefit of adding this and that. Is there alternative options?…or I just do this because I like it or this new technique attracts me…
This is the distinctness between design and art, even there are many overlapping areas.
Optimized images, sprites, minified and concatenated CSS/JavaScripts are indeed best practices that should be part of your deployment process. I understand that this article focuses on UX front-end performance, but I have found that the first thing to do is to tweak your server setup.
Techniques like filename-based cache busting and compressed assets can be implemented easily.
See https://developers.google.com/speed/docs/best-practices/caching#LeverageBrowserCaching and https://developers.google.com/speed/docs/best-practices/payload#GzipCompression.
If you are using PHP, then a setup with nginx, PHP5-fpm and APC is a must. I am also using a development version of ngx_pagespeed that does a tremendous job at reducing page load time. Numerous kudos to Jeff Kaufman for this port.
Completely agree – I’ve had enough headaches from badly specified themes, layers, selectors, unnecessary divs etc.
im using the oocss and it’s good for a better web optimization but it’s not enough
“Start by renaming non-semantic elements in your HTML. This is probably the toughest, but once you start thinking about theming in terms of semantics like “nav” or “article” and less with design or grid names, you’ll make significant headway. Often we get to elements with non-semantic names by way of needing more weight in CSS selectors, and instead of cleaning our CSS and adding specificity the right way, we add unnecessary IDs and elements to our HTML.”
What?
The author suggested that designers should begin with renaming the
non-semantic elements in the page. There is a problem with this old approach, which is elements are not location-independent. What if I wanted the nav to appear differently in the footer? What if I wanted the navigation to use a different non-semantic tag? Why over-scope elements with IDs?
The overlooked correct approach to “improving ux performance” is to embrace Nicole Sullivan’s modern philosophy of Object Oriented Style Sheets. For those who do not know about her, she is a Front End UX developer that worked with Facebook and other large scale web sites.
It is the same modern philosophy that is being adopted by Twitter Bootstrap, Inuit, and others. This article is very dangerous and I would recommend that the author look into these things before leading her readers down the wrong path.
I do not mean to sound harsh, but I see articles like this pop up around the web and worry that designers will not be following best-practices and modern approaches. Personally, I have developed 23 websites using the OOCSS / BEM methodology and would never do anything she is suggesting when it comes to writing CSS
thank for lots, nice articles, i am completely agree. front end performance for better business and revenue. it help to optimized website easily. best front end web designing company.