Need For Speed
Adam and Kamila went to Cardiff, and all they got was a lousy T-Shirt - Plus a few blogs about some of the talks they saw, including this one.
Stat attack! Only 12% of the top 100 retail sites (US) render is less than 3 seconds. Year on year, the average (Median) page load of these sites has slowed down by 23%. This is staggering.
Andy Davies had arrived to share his talk at The Web Is, Day 2. Entitled “The Web Is Too Slow… But We Can Fix That”.
His talk was primarily made to teach us that we need to be deliberate about performance - And he also shared some processes which can help make your websites faster.
Speed, he says, is the second most important thing to users (After clear content/layout). There are almost definitely massive gains for your company to be made in this area - Just look at Staples, who shaved 1 second off the median page load, and gained a 10% increase(!) on conversions. Website performance is big business, whether you’ve noticed yet or not.
Interestingly, when Youtube invested in improving their site speed, their average page load time went up, rather than down. The reason for this is really interesting - They were now reaching people they had never reached before. Suddenly, Youtube was viable in rural areas where it had previously been too slow to even use. To them (And hopefully, to you) this is obviously a big deal - A whole new audience!
But the speed of your site isn’t an exact science, and you also cannot definitively say that faster = better - It’s more that your site speed needs to match up with user expectations. While the vast majority of these expecations are for the page to load very rapidly, Andy told us about how Kayak deliberately slow down their comparison price search because people got suspicious when it ran at full speed. The expectation isn’t always for the fastest page imaginable, but really for the page to load in a speed which the user deems ‘satisfactory’ or 'worthwhile’.
The key takeaway here really is that no matter what you do with your performance, you really need to think about this stuff during the project rather than it being an afterthought - It’s too important to do anything else. I’ve never thought of it like this before but when Andy said it, it made so much sense to me: Performance should be considered as a design constraint, from the start, in the design phase, not something you deal with at the end of a project.
We should all be setting ourselves per-project targets: X event should happen in Y seconds when under Z network conditions. This target is the yard stick by which you determine whether you’re meeting your goals. With tools like PerfBar and Grunt PerfBudget you can even build these requirements into your workflow, and this is something we’ll be considering at Etch in our next review.
Chrome tracing is an obvious help to the hunt for bad performance, but there are other things you can do on top of this - Simulate bad connections during your testing. Use WebPageTest to run tests and compare your competitors, or use SpeedCurve, or one of the numerous other services - The important part is that you track and monitor it at all times.
Having drilled this message into our brains, Andy shed some light on how internet performance can be attained - He aptly described Critical Path (the process by which your browser turns markup and JS and CSS into something you can actually see), and explained that contrary to popular belief, the internet is not like a pipe.
The internet is more like a bucket line, with people passing buckets of water. The round trip time for water to pass along (known as latency) matters more than the mbps someone has.
Andy also shared an interesting cheat I liked a lot - Did you know Instagram visually shows that you have ‘liked’ an image immediately, even before it has actually done all the AJAX posting to actually ‘like’ it? I didn’t, but it’s a piece of simple genius. The slowness of having to wait for an action is negated by cleverly doing it when the user thinks it has already been done.
Nearing the end of his talk, Andy criticised font foundries which value their licensing over user experience, and encouraged us not to use them. These foundries use aggressive cache techniques which result in worse performance for your user, so according to Andy should always be shunned in favour of more user friendly alternatives - Not sure I’ll get that one past management, but interesting all the same!
As a finale, Andy told us some of the new and potentially future stuff coming down the pipeline which may help his cause, like the CSS rules of ‘font-timeout’ and ”font-desirability’, plus HTTP 2’s Server Push functionality.
I’m not much of a server admin so the most interesting part of this for me was the CSS rules - A way to designate in CSS how important your font is and a timeout before the CSS tries something else.
All in all this talk was an interesting insight into web performance - One which will have us reviewing our internal practices and workflows to try and improve our own load times.
Ready, set, go.
- Adam