Common Sense of Web Performance

A presentation at Front Endgineers London in August 2018 in London, UK by Shane Hudson

Slide 1

Slide 1

Common Sense of Web Performance Shane Hudson Front Endgineers London, August 2018

Common sense is different for everyone

This is about building a common sense foundation for everyone, understanding the performance mindset without all the technical jargon

Slide 2

Slide 2

I’m Shane, I’m a freelancer and have worked on many projects

Currently working with the NHS in England to build a national product called 111 online

Slide 3

Slide 3

@shanehudson Getting your team on board

Last time I gave this talk I was asked a question about how to get the team to care about performance

Slide 4

Slide 4

@shanehudson Discuss performance impact

of tasks/features

Everyone in the team should have it at the back of their mind

How will a feature change affect it

Show in show and tell

Slide 5

Slide 5

@shanehudson Performance is for the whole team to think about. Even if they never write a line of code in their life.

The most important bit of common sense is that everyone plays their part.

Whether you’re a developer, designer, or manager, you make decisions that affect every part of the website’s experience particularly performance

Slide 6

Slide 6

@shanehudson If you’re the one that cares about performance, foster it within your team

It’s often a front end developers job to fix (or sometimes ignore) performance

But a longer term goal should be foster a performance mindset within the team

Not by making rules about what is allowed, but by everyone considering it as part of their work

Slide 7

Slide 7

@shanehudson

This article is an incredible source of information

43 items on the checklist

But it feels like a massive amount. Can just imagine being a beginner, I would have taken one look at it and exited the page.

Slide 8

Slide 8

@shanehudson You don’t need to learn everything all at once

People try to learn everything at once, doesn’t work

Learn what you need, when you need it

You can make decisions about how a change affects the performance without knowing all the techniques/technologies

Slide 9

Slide 9

@shanehudson

  1. The web is fast

If you think about how the web works, it is obvious that it was designed to be fast by default

A website can function without any CSS, images or JavaScript.

Each layer enhances it, but if it required everything to be available and working before showing the site it would be much slower

Slide 10

Slide 10

@shanehudson Our job is to make the web slower, and fix it before anyone notices

Knowing that the web is fast, I started realising that we are purposely making it slow by adding lots of content and large pages etc We know it is going to slow the site down

That is completely fine as long as we do our best to mitigate it as we go

Every decision anyone makes about a website affects the performance

Every image, js file, video, embed, advert.. all makes the web slower. It’s okay if we understand that

Slide 11

Slide 11

@shanehudson Use the way the web works , instead of workarounds

Things like JavaScript at end of page, as it is render blocking

Critical CSS so that the important stuff loads, but load the rest later

Same with CSS, mastering the cascade is a very handy skill

Slide 12

Slide 12

@shanehudson 2. “performance” can mean so many things

When we say performance, we mean a lot of different things. And everyone thinks di ff erently about them all

Slide 13

Slide 13

@shanehudson Network

  • The stuff that people usually class as performance. Often technical solutions such as optimising, CDNs.

Slide 14

Slide 14

@shanehudson https://www.webpagetest.org Time to first byte,

DOM Load, Ready, etc.

https://www.webpagetest.org

Slide 15

Slide 15

@shanehudson Page performance More technical, often ignored. But still important, how quickly the page works. Does it lag. Does it work on really slow phones etc.

Slide 16

Slide 16

@shanehudson Canvas, scrolling, fps, repaint, reflow etc.

Slide 17

Slide 17

@shanehudson Speed of journey Usually ignored or classed as a content issue. Can have fastest site in the world but if users cannot use it or are slowed down, then it has same issue. Point being that performance and design are one and the same, teams should work together strongly.

Slide 18

Slide 18

@shanehudson Performance can be affected by Ads, content, pop ups, sign ups, confusion etc.

Slide 19

Slide 19

@shanehudson 3. Performance is accessibility

A website is useless if you cannot use it

Slide 20

Slide 20

@shanehudson “ ! ings that hit general performance will have an impact on accessibility performance. For example, re-writing large sections of the DOM is likely to be poor performance both visually and on a screen reader.” Léonie Watson

It’s not just about how quick the site loads either.

Slide 21

Slide 21

@shanehudson If a website is hard to use on an developer’s laptop with fast internet, what chance does anyone else have?

The more I thought of it, I realised that we all struggle to use websites sometimes.

Signal changes, scripts can be blocked

A large amount of people pay for data PAYG or have small 500mb data packages.

Slide 22

Slide 22

@shanehudson Pricing trends for communications services in the UK (PDF, 1.3 MB) 15 Mar 2017 - Ofcom Perfect allowance? 
 I doubt it 63% of people use their monthly allowance

63% of people use the same amount of data as their allowance, presumably so they won’t go over their limit as it costs more

Only 2% use more… which means majority of those 63% likely don’t want to spend the extra money

https://www.ofcom.org.uk/__data/assets/pdf_file/0028/98605/Pricing-report-2017.pdf

Slide 23

Slide 23

@shanehudson When we make websites, we must remember there is a cost to view

A lot of developers have massive data allowances, and it is easy to forget people don’t have large data allowances

But if the majority of people on a monthly contract are hitting their limit then it is down to us to ensure we don’t waste it.

Slide 24

Slide 24

@shanehudson Progressive enhancement and performance go hand in hand. 
 It’s all about the baselines .

  • Always figure out what the baseline experience is, then enhance from there

  • The response web design mindset tells us you can’t know exactly what the user will see, it will be different everywhere, and that is absolutely fine.

  • Same for performance. It isn’t about just optimising your images or using a CDN. It’s about considering the impact as you design and build the site.

Slide 25

Slide 25

@shanehudson

Tunnels

The biggest benefit of the web is that you can be anywhere, we should appreciate that not consider it a burden

Sometimes the conditions are such that no matter how good your technology is, how much you pay for your data package, sometimes you still can’t get a good connection

You could be:

on a train in a tunnel

Travelling in another country

Tethering from another machine

Slide 26

Slide 26

@shanehudson What happens if your assets don’t load fully?

So if assets aren’t always guaranteed to load, we must consider what happens if they fail or partially load

Slide 27

Slide 27

@shanehudson

  • This is Jeremy Keith’s personal blog, it is enhanced using service workers to work even when o ffl ine. You don’t get every image, but you get the main structure of the site and quite a lot of the content.

Slide 28

Slide 28

@shanehudson

  • He wrote a book called Going O ffl ine about what he has learned

Slide 29

Slide 29

@shanehudson 4. Less is more

Slide 30

Slide 30

@shanehudson Here’s a rectangle

Slide 31

Slide 31

@shanehudson

  • This is the rectangle I created with Sketch and exported as SVG

Slide 32

Slide 32

@shanehudson https://jakearchibald.github.io/svgomg/

  • https://jakearchibald.github.io/svgomg/

Slide 33

Slide 33

@shanehudson

Here is the optimised SVG

  • SVG is notorious for badly generated exports. It’s easier to see the damage as it is human readable but we should expect all assets to be poorly optimised.

Slide 34

Slide 34

@shanehudson Optimise all assets

It’s common sense, but why should images be optimised?

Speed up download

Speed up decode

Is an image even needed? Deleting it is a big optimisation

Slide 35

Slide 35

@shanehudson

Bottleneck has been legacy code. Often we deprecate features or rework pages without completely removing old code or assets.

User needs come before tech debt, which is the right way

But sometimes we have to realise the tech debt is both slowing down the user and the developers

Slide 36

Slide 36

@shanehudson 5. Performance is designed

Hopefully you can see that all the stuff I’ve been talking about has been less how to do technical things and more about design

Slide 37

Slide 37

@shanehudson The homepage may load quickly but the journey can be awful

Lots of people focus on performance of homepage

Need to consider the user’s journeys, make it as quick as possible to complete tasks

Test all pages

Slide 38

Slide 38

@shanehudson How do you make a journey quicker/easier? Repetition

Even if we ask loads of questions, people still zoom through (inc assistive technologies)

Repetition of design patterns makes it easy to use. Question page is most common page

Most pages are lightweight but the performance of the site as a whole comes from the repetition of the easy to use design pattern and optimisation for those pages

Also good for caching, if the same patterns are used everywhere

Slide 39

Slide 39

@shanehudson “When you are tired, distracted or confused, 
 you can’t use new or novel interactions. You go back to the stuff you know.” Joe Leech 
 https://mrjoe.uk/ux100/

  • Saw Joe give a talk in Bristol, he said some interesting things about cognitive load.

Really liked his point about going back to stuff you know when tired, distracted or confused

On this site our main target audience are likely to be in pain, anxious and so we want to make it as easy to use as possible

Slide 40

Slide 40

@shanehudson Every content update 
 Every new feature Every design tweak and bug fix 
 Every blog post 
 Everything affects performance

Slide 41

Slide 41

@shanehudson “It’s only slow the

rst time, then it gets cached” Said pretty much everyone—including me—at some point they are wrong.

If second load is magically quicker then not enough effort. “Your cache is showing”

Ideal world people wait, real world they don’t. They go and don’t come back

It ruins first impressions. Also cache can break, of course use it but never rely on it.

  • Fast should be your baseline, not your future ambition

Slide 42

Slide 42

@shanehudson Take responsibility , don’t rely on technology

Very easy to think of performance as something you can buy

There are loads of ways to let technology deal with performance

Slide 43

Slide 43

@shanehudson You can’t fix performance by chucking money at it

As with the idea of relying on caching, you cannot rely on scaling resources

Even if adding more RAM or storage helps, probably hiding bigger issue

Story about PHP on server being configured badly despite masses of RAM

Slide 44

Slide 44

@shanehudson 6. There can be valid reasons for a slower website

Content

Privacy

Business requirements etc.

Slide 45

Slide 45

@shanehudson Can a website be too fast?

Slide 46

Slide 46

@shanehudson No… but perception is important

Slide 47

Slide 47

@shanehudson Slow but felt 
 like it was loading Flash of invisible Text Fast but felt broken

In September we were making big progress with performance, the slow one is still far better than it was before hand but wanted to make even faster, it was quicker but page went blue till everything loaded

We improved and removed the blue, but the site was so much quicker the text (and at one point logo) didn’t load quick enough. Felt worse even though a second faster.

Slide 48

Slide 48

@shanehudson Wait, did something happen? Too fast , add friction

It is possible to make websites load so quickly that the user doesn’t notice they have changed.

This is the kind of use-case that animation is perfect for solving

Credit card handling, slow is better (did it work?)

If things happen too fast, users don’t trust it worked.

Slide 49

Slide 49

@shanehudson

Gmail show an alert that message has been sent

After a couple of seconds the undo disappears, but not the whole alert so you can trust it did send etc.

Slide 50

Slide 50

@shanehudson

Slide 51

Slide 51

@shanehudson

Less clunky

More likely to actually read it all

Slide 52

Slide 52

@shanehudson

Nick Babich https://www.smashingmagazine.com/2016/12/best-practices-for-animated-progress-indicators/

From Material Design

Shows how animation can be used as a benefit alongside performance.

It doesn’t matter that it is may be a bit slow, it is really useful to know how long something will take.

If a spinner keeps spinning, you quite quickly think it is broken

Slide 53

Slide 53

@shanehudson Summary

  1. The web is fast
  2. “performance” can mean so many things
  3. Performance is accessibility
  4. Less is more
  5. Performance is designed
  6. There can be valid reasons for a slower website

Slide 54

Slide 54

Thank you! @ShaneHudson