:format()//media/Diary-of-a-web-developer_-Part-2_RQ.png)
As we saw in the previous post, responsive design is solving lots of problems for us as web developers. However, when performance and speed are not taken into consideration, the rest becomes redundant as users won’t bother sticking around to see all the great work you’ve done.
To give you an idea of why page size matters, studies show that 40% of people will abandon your site after 3 seconds if it does not load. Put simply, weight = load time. Let’s take the online retail giant Amazon.com as an example, for every additional 100milisconds that it takes their site to load Amazon.com loses 1% revenue – 1% sounds acceptable, doesn’t it? Until you realize that for Amazon, 1% equates to $157million.
Other reports have shown that a delay in load time of just one second directly results in:
- 11% less page views
- 16% less customer satisfaction
- 7% less conversions
60% of people who have had a bad experience with a mobile website are less likely to return and 40% will then visit a competitor. As Bobby Pearson put it “Milliseconds matter”.
So what do I do?
Redesign & re-construct
The ideal situation would be to rebuild your website and start from scratch in order to develop the performance into the new website. The whole notion of performance is starting to gain traction but in a way I see it being approached in much the same way accessibility was a few years ago – stuck on at the end of the project. What was found then, and what you’ll find now is that there is a far greater benefit from it if it’s baked right into the process and not as an afterthought. Performance is integral to mobile success – it needs to be given a great deal of consideration right from the outset.
Use TERMINALFOUR Site Manager to your advantage
I’ve written about it before on our community forum but one of the cool things with TERMINALFOUR Site Manager is the ability to start afresh in a different channel with new formatters on existing content. Maybe you’re afraid to take the plunge for a whole new site at once, maybe the politics of doing that is too great, or maybe the sites just way too large to even consider it.
The BBC approach
Take the BBC approach: Start building a mobile first site on your mdot site until it’s finally built up at your own pace, allowing you to take over your main site as a responsive and well performing alternative to your current set up. The different channel approach allows you to use the existing content with a whole new set of content types that suit the new site and that can publish out elsewhere giving you time to develop in a way you want to.
Alright that’s never gonna happen here… what now?
A full redesign and rebuild isn’t always an option so here’s some tips to apply to your existing site which should help you shave some seconds off:
1. Performance Budget
Set a performance budget – a page size you want to get to. The 20% rule dictates that a 20% decrease in your load time will have a noticeable effect on your viewers – so there’s a place to start, something to aim for. Check how big your pages are now and try to reduce them by 20%. Use something like http://www.webpagetest.org/ to see what your current position is.
2. Look for the low hanging fruit - Images
Images are usually the biggest asset on the page – Ensure that your images are as optimized as possible and then optimize them even more by using something like http://www.smushit.com/ysmush.it/
You can also look into Lazy loading images which don’t load all at once when the page is reached. Lazy loading waits until you scroll to that part of the page to load the images.
3. Less requests on the page
Mobile networks suffer badly from a thing called latency which basically means that the more requests to the server that you have (such as links to CSS or JS files), the longer your page will take to load. This happens regardless of whether you’re on high speed phone internet or you’re in the middle of nowhere searching for reception. As a developer if you can group files into few calls there will be less requests and less stalling because of latency. You can automate file concatenation with by looking into something like Grunt.
4. Use CDNS (content delivery networks)
This can also be helpful in reducing latency - rather than making full round trips to the original server, cached versions give quicker delivery. Akamai, Rackspace, Bitgravity and Edgecast are potential CDNs to look into.
5. Check your content
Are you just putting up content because you can or because it’s useful. Carefully consider your content and remember that long content can mean a lot of scrolling for users. http://weedygarden.net/2014/02/the-13-foot-website/
It might be worth setting up scroll tracking in your Google analytics to see if users actually make it down the page. Analytics in general should be closely monitored to determine the use of the content – if the 2nd, 3rd and 4th carousel item on your homepage never gets clicked on then there’s no point loading all of that extra weight on your page to keep it – maybe one flat image is a better option.
6. Fake it ‘til you make it.
Ever notice how Facebook or Twitter says it has posted straight away no matter whether you have a good connection or not? It’s faking it. It gives user feedback immediately so you’re happy but actually it’s still working for a few more seconds in the background to do the heavy lifting. You can do something similar by loading a skeleton version of the site before all the images etc come back – for a user anything is better than watching the spinner, if they see your page even in rudimentary form they’re more likely to stick around to find out more.
That’s it! Remember – Milliseconds Matter!