Skip to content

#perfmatters

On Tuesday 4th April, Dani and I gave a 25 minute talk about Front-end Performance to a lovely crowd of mostly UX Designers at the Pixel Up! meetup in Cape Town. The slides from the talk are up on SpeakerDeck and some links from the talk (including the slides) are up at naga.co.za/pup2017. Here’s my write-up of our talk, in a weird like-I’m-talking-at-you style.

#perfmatters. It’s a thing. You can look it up on Twitter. Our goal is to help you think about perf more in your day to day work. What this comes down to is that we want to save users time and money and save us time and money.

Here’s what we’re going to cover:

  1. What (is perf)?
  2. So what? (Why should we care?)
  3. Now what (can we do)?

1. What?

What do we mean by Front-end? As opposed to back-end. It’s the bit that you see. We’re going to talk about a slightly simplified version of performance because of time constraints: there are two big bits.

1 is speed. This is complicated because different bits can load at different times leading to fast(er) perceived performance. What’s important is that we want to save time for our users.

2 is weight. Again, it’s complicated. What’s important is that we’re talking about how much stuff is on a page. Less stuff means it’s cheaper in data costs for our users. Less stuff means less work for us, which means less time and money spent by us.

2. So what?

Now we’re going to hit you in the feels. We’re going to talk about why should you care about your site’s speed and weight. Let’s look at a proto-persona like thing. This is Bongani.

She’s a cashier who works at Pluck n Pay and she earns R5,000 a month. Yes, people do get paid this amount of money. Perhaps you’re thinking “data’s cheap, though, right?” Or perhaps you’re thinking “Well, she won’t use the web.” Putting aside the whole Facebook thing (which it seems every human alive uses), there are lots of things she might use the web for.

What about if Bongani says “I want to look for a new job.” That means looking for work on the web. That means going on LinkedIn. She can’t afford a computer, so she’s gonna be using her phone for this. Let’s have a look at what it’s going to cost her.

Super-useful internet web site httparchive.org has the current average web page size at around 2.5MB. Maybe that doesn’t seem so bad. But how much does that cost?

On Vodacom pre-paid (which Bongani might be on), that’s about R1.5 per page. (It’s R9 for 15MB. That means R0.60 per MB. That means about R1.5 for a 2.5MB page.). Usually it’s worse than this, though. People on an income level like Bongani limit their usage by buying small amounts, because data’s expensive. But buying in small amounts makes the cost per MB even higher. On top of that, people often convert airtime to data which means they pay out of bundle rates, which is even more expensive. Boo!

So let’s say Bongani looks for a job. Let’s say she looks at 10 pages a day. That means R15. Her salary for the day is R240. Whisky Tango Foxtrot? That is a large percentage of her income for the day. That is a very shit thing. ???

2. So what? (Part 2)

This next section could also be called “time is money.” At this point maybe you’re thinking: “But personas are made up. I work in the real world.“ Or perhaps you’re thinking “I sell organic artisanal diamonds, my customers are rich! They don’t care how much a page costs to load.“

We’re going to look at a handful of sites and some performance stats. First let’s look at some “Yikes!” ones.

  • Google, a little web site you may have heard of, found that a 0.5s slower load time resulted in 25% fewer searches.
  • Amazon, another small site you may know, found that with a 0.1s slower load time, they had a 1% decrease in revenue. That’s a small percent, but for Amazon that means a big number of dollars.
  • Etsy, the huge online marketplace, found that when they implemented a redesign that had 160kb more images on mobile, then had a 12% increase in bounce rate.

That was a bit rough. Now let’s look at some “Yay!” ones.

  • Video site YouTube achieved a 90% smaller page size and found a large increase in traffic in areas with poor connectivity (like Southeast Asia, South America, Africa, and Siberia.). That seems a bit odd, so what’s up with that? Before, the page wouldn’t load at all: it timed out. The much smaller page loads fine!
  • Photo sharing service Instagram achieved a 30% smaller page size and found they had increased impressions and interactions.
  • Ecommerce (and other things) giant AliExpress achieved a 36% faster load time and found they had a 11% increase in orders.

2. So What? (Part 3)

Now let’s look at some local sites. Not as a blame game, but more as a “this could happen to us!” These sites were put through (the dog ugly, but very awesome) WebPageTest on a 3G connection. What we’d like you to think about is a kind of Cost Benefit analysis for each of these. What is each thing costing the user, and what’s the benefit to them?

We’re going to look at the number of requests each page makes, the number of MBs it weighs, and how long it takes to load. Remember that the average weight (not a target!) is 2.5MB. The average number of requests is a rather large 100.

  • dailymaverick.co.za has 310 requests, 3.6MB, 40s. The thing that stands out is 1.7MB of JavaScript, which looks like it’s all for ads and tracking. What’s the benefit to the users of that?
  • mg.co.za has 290 requests, 9.9MB, 62s. 8.2MB of that weight are images: there are lots of them, they’re large, and hi-res. And there are 160 of them. That seems a bit excessive.
  • cellc.co.za has 150 requests, 2MB, 33s. 1MB of that is images in every designer and developer’s favourite bit of UI: the carousel. Remember Bongani? It costs her about R1 every time she visits a page here.
  • capetown.gov.za has 70 requests, 2.0MB, 20s. About 1.7MB of that is JS, mostly for animations. What’s the cost-benefit analysis for those animations? How about Bongani? She might be coming here to look up stuff about health, education, water and electricity. She probably uses an older, slower, phone that will struggle to run that 1.7MB of JavaScript.

4. Now what?

That was all a bit hectic. So what can we do? How can we save users time and money? How can we save ourselves time and money?

The biggest, broadest, thing is to use less stuff. Do a mental cost-benefit analysis for each new thing someone suggests adding. What is it costing the user, and what’s the benefit to them? Having less stuff means less work means less maintaining of it. Having less stuff means less weight and a faster site. What are some things that we might try and have less of?

  • Images. Threat Level: 1 scream ?. Don’t use too many and make sure you optimise them.
  • Carousels. Threat Level: 2 screams ??. Are you sure you need one? Are you using a good one? At least keep it small!
  • Video. Threat Level: 3 screams ???
  • Auto-playing Video. Threat Level: deathrage! ? + ?. If you do this, we’re not saying you’re a monster. We’re saying you’re a bit naughty.
  • Animations. Threat Level: 1 or 2 screams ? or ??. Think carefully about the cost-benefit analysis. Do they help your users?
  • Custom UI. Threat Level: 1 to 3 screams ? to ???. Your special custom widget, sprockets, geegaws, and doodads. Apart from the UX and maintenance headaches you’ll give yourself: they tend to be heavy.
  • Tracking, Ads. Threat Level: 3 screams ???. Especially the cumulative effect of having lots. Yes, #itscomplicated, but…

Another important thing to do is measure performance. There are couple of ways of doing this.

  • Your browser’s Dev Tools, in particular the “Network” panel. There’s lots of stuff there and it looks a bit scary at first. But, you only need to look at a few bits.
  • PageSpeedInsights. Not because OMG Google ?, but because it’s good advice. You can use the results as a checklist, and as a way to start a (friendly!) conversation with your FEDs.
  • WebPageTest isn’t very pretty, but it gives you detailed, useful, stats.
  • If you want a hosted WPT, and recording of regular stats, have a look at SpeedCurve.

So that was #perfmatters. We talked about how FED Perf is speed and weight, how we can save time and money, how to think about performance when designing, and how to measure performance.

Thanks! ✌