The web is fat, says Tim Kedlec, independent web developer and author of Implementing Responsive Design.
We’ve created beautiful websites, added stunning imagery and amazing interactive features, but forgotten to consider performance in our workflow.
The result? Slow websites.
And frustrated users.
Consider that the median weight of a web page was 1.5MB on January 1, 2014, a 38% increase over the past year (data source: HTTP Archive), and you know there’s a problem.
In his presentation at In Control 2014, Kadlec outlined what web designers and developers can do to improve user experience by incorporating performance throughout the web project workflow.
Here are my notes and some of the backchannel conversation during Tim’s presentation:
- A lack of performance = a lack of planning. We need to be deliberate in our approach toward websites
- Preparing multi-page reports detailing performance issues doesn’t always work. Showing graphs and videos of performance problems can help you make your case for improving performance. Use WebPageTest (an open-source project developed and supported by Google) to show screenshots and videos of performance problems.
- Speed performance has to matter to the person you’re talking to, and to the team members working on the web project
- Show statistics. Speed impacts revenue. When Amazon improved performance by 100 milliseconds, revenue increased by 1% (source: How website performance affected conversions).
- Where to start? Look at your site today. Run WebPageTest on your pages. Do the same for your competitors. Plug them through same network and get performance results. Then apply 20% rule: to be perceived to be faster, your page needs to be about 20% faster. Example: If your page is loading in five seconds, you want to be loading in four seconds. This process provides you with a minimum viable target.
- The easy part: setting the performance budget. The hard part: sticking to it. That’s where your team support comes into play. Build performance into your build process (have build fail if it goes over a performance budget). Make sure it’s in everyone’s face. Example: Etsy colors switch from green to yellow to red to show performance. (Check out Web Performance Culture and Tools at Etsy on Slideshare)
- Reinforce that performance matters. It creates a competition within the team; you don’t want to be the person who causes bad performance.
- Want to see what users think about site performance? Do a search on Twitter on “slow performance.”
- Bad performance is bad business
- 60% of users will not return to a slow loading site. 40% will go to a competitor site.(Source: How Loading Time Affects Your Bottom Line)
- Respect people’s desire for content, keep your client side code small and lightweight
- Faster networks aren’t going to improve performance. Latency is the issue.
- 3G networks aren’t going away. We’re not ditching the older networks, they’ll be around for a while. Test in a 3G environment for an hour a week. Test your site under different networks, not just different browsers.
- Designers/developers: don’t build an application for users like you. You’re the exception, not the rule. You need to experience the website in less than ideal circumstances.
- This is performance by design. Get the entire team invested in making performance a priority.
- Bake performance into the web process from start to finish. Make sure performance issues are discovered before they’re inflicted on users.
- So much of performance is about perception
- We can build a web that’s more enjoyable to use and most importantly is accessible to everyone
