Why are we waiting?
Measuring site speed brings all kinds of benefits. Start by making a video comparing your homepage against your main competitor and it will probably directly result in work to make your site or app faster. Which your users will like. That will make your business more successful. And people who care about that will be happy.
Try it! The Financial Times did and it went well.
Then, when your organisation understands the business value of site speed and its impact on your customers, you can use it as a lever to pull and make other things better.
Yank not jank
The idea of designing Mobile First has gained general currency in the seven years since Luke Wroblewski’s original articulation. Here’s the second of his three main points:
2. Mobile forces you to focus
Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn't room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.
So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today's desktop-accessed Web sites. That's good user experience and good for business.
Luke gave us a lever to pull and we all yanked on it, making better things as a result.
The underlying offer is that constraints force you to remove what’s meaningless, thereby enhancing what’s left. I don’t think you need to be a certified minimalist to buy into that. However, designing for mobile first isn’t a very radical idea in 2016. Let’s keep doing that, but to stay ahead of the pack we’ll need other constraints that further increase our focus.
So, what if we try replacing mobile with speed? Here’s my performance-focused Wroblewski re-write:
2. Web performance forces you to focus
Site speed requires software management, marketing, content, design and development teams to focus on only the most important data and actions in an application. There simply isn't time in the three-second window for your users’ attention to request, negotiate, download, parse, initialise and render extraneous, unnecessary elements, superfluous tracking code, 3rd party widgets, badly coded adverts. You have to prioritize.
So when a team designs with speed in mind, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today's Web sites. That's good user experience and good for business.
Works, yes? We could argue all day about whether (as is commonly and rather casually mooted) 40% of your visitors will really leave your mobile site if the pages don't load within 3 seconds. But you can be sure lots of them will. And if you need convincing, here’s some good old site speed business case.
Using site speed as a constraint will help you make better products.
All roads lead to Rome
Here’s something else I find interesting.
Speed Index is a useful performance metric because it relates more closely to a user’s experience than traditional timings like Page Load Time.
It's concerned with the time taken for content to stop moving on the visible part of the screen as it loads. (Note that I didn’t say page fold there – no sir.)
‘Perfect’ user-centred performance metrics are something of a holy grail and in fairness Speed Index doesn’t claim to be perfect. WebPagetest Documentation written by the venerable Patrick Meenan describes some limitations of measuring Speed Index using visual progress from video capture:
“...web pages are fluid and things like an ad loading can cause the rest of the page to move. In a pixel-comparison mode this would look like every pixel on the screen changed, even if the actual content just shifted down a single pixel.”
“… the original mechanism that was used to calculate visual progress when the Speed Index was initially created [...] still works well but there are some cases where it has problems (video playing on pages, slideshows animating or large interstitials). It is very sensitive to the end state and calculates the progress based on the final image.”
In effect what Patrick is saying is that we can’t accurately measure this user-centric performance metric on pages that include:
- Things that move of their own accord
- Videos that autoplay (if you're lucky, also belching unwanted noise into your quiet office)
- Timed carousels that whisk content away while you’re reading it
- Interruptive popups
- Subscription forms or take-over ads you need to paw away to get to the thing you actually wanted to see
- Supplementary content that causes layout reflows
- Ads, cookie bars or "Install our App" promos that make the page jump, making you chase text around the screen or Click the Wrong Thing (like this)
When did you last visit a website and think “I’m glad they did that!”? These are anti-patterns, and it turns out that a generally user-focussed approach to measuring site speed can help you highlight what a poor experience they create and make the case for eliminating them. I think that’s more than serendipity, don’t you?
Make speed a feature
It seems fairly clear – speed is a UX issue. Make speed a feature now and it will give your product focus, create better experiences, make people happier, make your business better.