Making web performance one of your top user experience metrics
It doesn’t matter how good your design is if nobody waits around to see it.
The waiting is the hardest part
There are varying degrees of need or desire to access a website or service online. For example, accessing a government service is usually out of necessity, while visiting an expensive watch shop would usually be about desire.
The willingness for people to wait for an experience might include:
- If it’s something they have to do (pay car tax)
- If it’s something they know is worth it (best stock of vintage car parts in the country)
- If there is no other option (exclusive retailer on this limited edition vinyl record)
Common reasons for not waiting might include:
- There are plenty of other options (losing to competitors)
- They don’t really know what you have to offer (losing browsers, new business)
- The effort is greater than the desire (the hook that brought them into the site is not worth it)
You might read this and think if you run a site with exclusive stock you don’t need to worry about web performance or even a good user experience. This is only true if you don’t mind your users thinking of you as “the best there is right now”, “a bit of a pain” or a “chore to use”, effectively ready to jump ship as soon as a better option comes along.
Likewise, with a government service, a users’ tolerance for something they have to do is much lower than if it’s something they want to do. Public services also have the responsibility to work for everyone regardless of technology, internet connection or even not wasting users’ mobile data.
Why you need to care as a designer
This may sound a little bold but, it doesn’t matter how good your design, product or offering is if nobody waits around to see it.
There are many, many case studies linking web performance to reducing bounce rate and increasing on-site conversions. I’ve pulled out a couple from Jeremy Wagner’s article ‘Why Performance Matters’ below:
- The BBC found they lost an additional 10% of users for every additional second their site took to load.
- DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load.
There’s lots of things that can affect web performance, while many of them may initially seem out of your direct control, you can use your position in the organisation to humanise the issue and affect change.
In my experience, increasing site speed will affect conversion more than any button placement or content tweaks you make. It will give your designs a fighting chance purely in reducing the missed opportunities.
Stop thinking about web performance purely as a developer thing, as a designer it’s your responsibility to consider everything you put on the page against performance goals. For example, do you really need that third font-weight? If you do, what about removing one of those images?
Start with a webpage test
There’s an incredibly useful site at https://www.webpagetest.org/. You can put in any URL and get a free performance report.
You don’t need to be an expert to understand the top-level metrics or the breakdown of content that’s been downloaded.
I would recommend conducting a test of your most complex landing page and use this as a continual benchmark for improvements over time.
I tend to set up tests as follows:
- London — Chrome / Firefox (adjust accordingly)
- 9 tests (creating a more representative median run)
- 4G speed
- Name them using a date / page / speed combination
When the tests are complete you’ll see something that looks like this:
It’s important to not get too overwhelmed. Once you’re more familiar with what this site can do you can delve deeper — I recommend reading Matt Hobbs’ article How to read a web page test waterfall chart.
Right now we’re just getting an idea of how your site is performing. The BBC news site in the above example is scoring very high. I’m going to try and put this into plain language, but metrics you’ll probably be interested in are:
- First byte — How long the user sees a white screen for before anything can even start happening
- First contentful paint — First bit of content loads
- Document complete time — Generally when all of the static content has loaded
If we were to compare the BBC news site to a more commercially driven news site you can see the difference in the results. In this example, the first content doesn’t load until 3.8 seconds, document complete is almost tripled at 11.6s on 4G.
So what can a designer do about it?
Get your own house in order
The first step would be to understand what you can do directly. Check the content breakdown of the core pages of your site. This example shows that almost 60% of the page weight is images so let’s make sure they’re as optimised as they can be.
Take some time to look at the images on the page:
- What are the file sizes? Could they be more compressed?
- Do the “physical” sizes make sense in relation to how they are presented?
- Do all the images actually need to be there?
- Understand how the images are getting on the site, does your site have an image service or are your design assets getting directly uploaded?
On one project, before I even involved a frontend developer I managed to shave off ~50% of image weight just in optimisations to how the images had been processed for the web.
Think about every design decision on each of your core pages, are they actually serving a purpose? Are your design decisions feasible with the product you’re working on? For example, if you work on a site that has hundreds of third-party scripts you can’t do anything about, things that may be seen as “delightful” on a different site, such as motion could add to the chore of using an already painfully slow site.
Speak to your frontend team
The chances are your frontend team are completely aware of many, if not all of the issues your product may have with site speed. A lot of the time it’s not been considered a priority in businesses that tend to focus on shipping features fast. Listen to them, understand the current problems and take a lot of notes.
I’ve found it useful to have a workshop to understand all of the touch points that could affect web performance, from design decisions, image processing all the way up to server configurations.
Get everyone talking about web performance
With the developers blessing, start sharing the results of your webpage tests in places people are going to see them. Slack is good.
One way to get people talking is to run comparisons of your product against competitors. It illustrates exactly what a user might experience and has the added benefit of getting stakeholders interested. If it’s one thing many stakeholders don’t tend to like it’s being beaten by their competitors at anything.
Webpage test allows you to compare previously run tests against each other as a filmstrip or a video. It can be very useful to illustrate the issues without using any web performance language at all.
It’s also worth checking out https://speedcurve.com/benchmarks/ to get an idea of how other sites in your industry are performing against each other.
Put it in language stakeholders will care about
In most cases there is a correlation between site speed and the thing businesses want a user to do, you just need to find it.
Despite it being only a small sample of all users, the page load time distribution on Google Analytics can be helpful to tell a story. You can get a broad idea of the most common buckets your users sit in when it comes to site speed. This example shows that 50% of the page views are in the 3–7s bucket.
I must emphasise that this is sampled data to give you a general idea of the experience your users are having, it can be easily skewed so make sure you look over a long enough period of time to get a good sample size.
Once you’re in this view it’s possible to segment the data by the number of page views that performed a goal you have set up in Google Analytics. This will probably show you that most of the actions you want users to perform happen in the buckets where there is a faster load time.
If this is true, which in my experience is likely, you have some representative data to help kick off a conversation. No need to get technical, explain your goals as simply wanting to move more people from this 3–7s bucket into the the 1–3s bucket because that’s where more site conversions happen.
Don’t just fit this work in, get it on the roadmap
One of the most common things I’ve experienced is developers not being given explicit time to work on things like web performance.
Just like you would with potential feature development take all of the ideas that came out of the conversations with the frontend team, break them down into individual tasks that can be measured against effort and impact and plan a dedicated sprint (or two) to this work.
As I said at the start of this article this work can have more impact than testing new UI or CTA’s and will give you a great foundation for future enhancements.
Measure and share the success
Continue to run webpage tests, show comparison videos of each release and share them with the whole company.
Keep talking about web performance and consider everything you create or add to the codebase through the lens of performance because remember, it should be considered one of your top user experience metrics.
