The One Second Website : 10x your site performanceGábor Kocsis
Last year, Patrick Hamann gave a talk for Google Developers on Breaking News at 1000ms.
It lays out how Patrick and his team built a 1-second web site for the Guardian, improving performance almost 10 times.
I learned a lot from the talk, and I’ve summarized that below. Here’s the video:
And you can browse the slides here:
Web speed has come to a head recently. Facebook’s Instant Articles put speed on everyone’s radar. A news page takes 8 seconds to load, and that puts people off clicking links. Like many others, I couldn’t quite believe things had got this bad. We have fast broadband and wifi. How can a 1,000 word article take so long?
So there’s a lot of discussion around the problem, but Patrick’s talk lays out many of the solutions. Here’s the keys I took from it:
Sites are slow, really slow. 8 seconds is normal. And yet, people really care about speed. It’s a user’s second most important feature, right after “easy to find content”.
In fact, if it takes more than a second for a page to respond people start to assume the site is broken. If most pages take more than a second, people start to assume the web is broken. And we wonder why 91% of mobile impressions are in apps, not the web.
Patrick set a hard budget for page loads of 1 second, and measured everything against that. This is his BHAG — make the web site nearly 10x faster. But once the goal is clear, people have a habit of finding solutions. The harder the goal, the more radical the solutions people will find. Modest goals lead to modest problem solving. Next time you want to improve something, set a 10x goal, get serious about it — and let everybody’s ingenuity loose on the solution.
Patrick and his team’s radical solutions revolved around 4 key principles.
Deliver core content first
There’s a lot of stuff on a news article page, but what we really want to see is the article content. Patrick’s team got serious about the really important stuff, creating a ‘swim lane’ system. The important stuff — the core article content — was put into a fast lane, loaded first, and then the rest built around it.
This made the goal more doable. The whole page didn’t need to load in 1000ms. If the core content loaded in 1s people could read it, and by the time they had the rest of the page would be ready. (Even the flimsiest Guardian article will take more than 1s to read!.)
Core content should render within 1000ms
Here’s the problem. To get content to the reader in 1000ms you have only 400ms to play with, because the basic network overhead takes 600ms over a good 3g connection.
So to really supercharge speed, the Guardian inlined the critical CSS. For the Guardian, the critical CSS is the article formatting. The rest can come a bit later.
Every feature must fail gracefully
Fonts are a recognizable part of the Guardian brand, important despite the overhead. But not that important. The new design fails decisively and fast when it’s right to do so:
Decision tree — fallback vs. custom font.
The really clever bit of the whole set up is the font JSON. Instead of downloading several font binaries, just one JSON request downloads all the fonts in base64 encoding. This means some overhead in file size, but replaces several requests with just one cachable object:
A nice trick, and one you can use yourself: they made webfontjson an Open Source project.
Every request should be measured
The final pillar really comes down to really knowing your shit. Graph and measure EVERYTHING that affects your performance and your time-to-render budget. In addition to the internal analytics platform Opan, Patrick uses Speedcurve to monitor and report on performance against a set of benchmarks over time:
For everyone… big improvements come from BIG GOALS and ingenious solutions. Be ambitious and set a budget/goal that gives great customer benefit, then work towards it.
For web developers:
- Performance is a requirement. Everybody has to have it as a priority from day one.
- Take the one second web site challenge. Make that your budget, and measure, optimize, repeat.
- Make the core content download first, render it in the fast lane. Then build the rest around the outside.
Now if that whet your appetite, watch the video. Especially if you’re more involved in web dev, I’m sure you’ll learn a lot more from it than I did!
What techniques do you use to 10x your site’s performance?
From 11th to 17th April save up to 70% on some of our very best web development products. It’s the perfect opportunity to explore – and learn – the tools and frameworks that can help you unlock greater performance and build even better user experiences. Find them here.