With the recent changes in googles page rank algorithm; the subject of page optimization is back on everyones mind, and people are once again looking to cut precious milliseconds from their loading times.
There are also many other reasons to optimise your page speed, for-instance, case studies have shown a correlation between loading time and conversion rate1, and everyone loves higher conversion rates.
Instead of the standard approach, where developers delve into the code hunting or sore spots and optimising until things appear fast, I lean towards a system of targets, where predefined quotas are assigned to execution time and page weight, and both designers and developers make achieving them a part of their standard workflow.
Targets give us something to work towards, they tell us when we have done enough, and prevent our expectation from drifting upwards over time, and with the entire team working towards the same goal, the optimization effort becomes easier to manage.
The problem is that testing page loading times after every change is time consuming, but by fixing the values, we can then write unit tests to automate the process, allowing the work to be shifted to a continuos integration server.
Clear targets can also be used as part of the decision making process, if a feature will push the loading time beyond the targets, is the feature likely to generate more conversion than will be lost due to the longer rendering time?
And finally there is the impact on mobile broadband users to consider, where connections are generally slower and bandwidth far more costly.
As one second is the accepted time we can spend doing things before the user becomes susceptible to distraction2, we should aim to have the page completely rendered by then, this means page execution time, downloading its content, any external assets, rendering, and initial javascript execution.
Ideally, execution time should feel instantaneous to the user, this gives us a window of 100ms[2] and should be our target for getting things done, with a maximum of 250 ms if we are to hit our one second overall target.
When it comes to page weight things start to get a little more complicated, according to OFCom the average connection in the UK is around 4Mbps3. Even if we dedicate half our remaining time, for the user to download everything in 500 ms, we need to aim for a page weight of around 200KB, and should generally strive for about half that.
In total we have now used up to 75% of our one second target, this gives us another 250 ms for the browser to execute javascript, and finish rendering the page.
So to summarize, by adopting a targets orientated approach, we should be able to keep on top of our page execution times and weight, providing a faster and more fluid user experience, resulting in happier users, higher conversion, reduced bandwidth bills, and partially future proof our sites towards the growing number of 3G connections.
| Criteria | Target |
|---|---|
| Execution Time | 100 ms |
| Page Weight | 100KB |
| Maximum Execution Time | 250 ms |
| Maximum Page Weight | 200KB |
© 2010-2012 Daniel Knell