Slide 1
Slide 1 text
Negotiating for
performance
Jonathan Fielding @jonthanfielding
Slide 2
Slide 2 text
A bit about me…
• Technical Architect at Beamly (WE ARE
HIRING)
• Author of ‘Beginning Responsive Design’
• Regular contributor to open source, including
SimpleStateManager, Echo.js, CriticalJS, FT’s
Polyfill Service, Doccy among many projects
• Here as a warm up prior to the Pizza
Slide 3
Slide 3 text
Many talks about
performance focus on
implementation
Slide 4
Slide 4 text
They look at the steps we take
to make a site performant
Slide 5
Slide 5 text
focusing on the techniques
we use instead of the
process we take
Slide 6
Slide 6 text
So today we are going to
be focusing on how we
can make performance
the centre of our process
Slide 7
Slide 7 text
Looking at how we can
raise awareness about
performance within our
teams
Slide 8
Slide 8 text
We will identify how we
can use performance as a
competitive advantage
Slide 9
Slide 9 text
We will look at this
initially from the
perspective of a new site
Slide 10
Slide 10 text
Then looking at how we
can retrospectively apply
these techniques to our
existing sites
Slide 11
Slide 11 text
And ultimately we will start
to understand the language
we should use when trying
to communicate with
others about performance
Slide 12
Slide 12 text
Situations you might
have found yourself in
Slide 13
Slide 13 text
“The client wants to use a
background gif for each
block on the homepage”
Slide 14
Slide 14 text
“And they are 5MB EACH”
Slide 15
Slide 15 text
“The designer used 6
different fonts AGAIN”
Slide 16
Slide 16 text
“and it’s already been
approved by the client!”
Slide 17
Slide 17 text
“The analytics team
wants to track how users
interact with the site”
Slide 18
Slide 18 text
“and the tracking script is
larger than the rest of my page”
Slide 19
Slide 19 text
The thing is….
Slide 20
Slide 20 text
Clients don’t ask for sites
that take forever to load
Slide 21
Slide 21 text
They ask for a site that
will enable them to
achieve specific goals
Slide 22
Slide 22 text
Designers don’t design
sites to be slow
Slide 23
Slide 23 text
They design sites that are
user focused, on brand and
eye-catching
Slide 24
Slide 24 text
Analytics teams don’t
want to have any impact
on your site
Slide 25
Slide 25 text
They just need a way to
track user behaviour
Slide 26
Slide 26 text
Unfortunately, the
requirements of our
stakeholders are often at
odds with performance
Slide 27
Slide 27 text
Stakeholders aims are:
• Feature rich
• Tracked
• On-brand
• Achieve KPIs
• Appealing design
• Eye-catching
Slide 28
Slide 28 text
Whilst we need to ensure it is:
• Performant
• Functional
• Lightweight
Slide 29
Slide 29 text
That’s why building a site
starts to become a
balancing act
Slide 30
Slide 30 text
Where we need to engage
with stakeholders to balance
our site’s requirements
Slide 31
Slide 31 text
We first need to look at
how we make our
stakeholders more
aware of performance
Slide 32
Slide 32 text
When I build a website I
obsess over performance
Slide 33
Slide 33 text
I do this because I
understand the impact of
performance
Slide 34
Slide 34 text
Being aware of why
performance matters can
help your stakeholders
get on board
Slide 35
Slide 35 text
There are three key types
of performance that you
need to make your
stakeholders aware of
Slide 36
Slide 36 text
Render performance -
The time it takes for the
browser to start
rendering the page
Slide 37
Slide 37 text
Page load performance -
The time it takes to fully
load a page and be fully
interactive
Slide 38
Slide 38 text
Perceived performance -
the perception of the
user of the performance
of our site
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
Of these three the most
important is perceived
performance
Slide 41
Slide 41 text
To designers the
perceived performance
has an impact on the user
experience of the site
Slide 42
Slide 42 text
It is the first impression
the user gets when they
visit your site
Slide 43
Slide 43 text
To clients/product
managers, performance
can affect what they are
trying to achieve
Slide 44
Slide 44 text
The majority of clients/
product managers are
aiming to reach specific
KPIs
Slide 45
Slide 45 text
Performance however
has an impact on all the
KPIs of our site
Slide 46
Slide 46 text
This is reflected in some
studies carried out by
some big brands
Slide 47
Slide 47 text
Amazon found every
100ms delay in loading a
page cost them 1% in sales
Slide 48
Slide 48 text
Google found an extra 500ms
delay loading search results
decreased traffic by 20%
Slide 49
Slide 49 text
The Trainline reduced latency
by 0.3 seconds and customers
spent an extra £8 million a year
Slide 50
Slide 50 text
Walmart saw for every 1 second
decrease in page load they had a
2% increase in conversions
Slide 51
Slide 51 text
More examples of
studies can be found at
wpostats.com
Slide 52
Slide 52 text
The site performance
also has an impact on
search engine ranking
Slide 53
Slide 53 text
With Google, Bing and other
search engines using it as
part of the ranking algorithms
Slide 54
Slide 54 text
With the benefit it brings to
business, performance is
clearly a competitive
advantage
Slide 55
Slide 55 text
We therefore want to
ensure our site loads faster
than our client’s
competitors’
Slide 56
Slide 56 text
To enable us to do this we
need to test competitors’
sites
Slide 57
Slide 57 text
If we take Beamly for
example, our site is a lot like
Buzzfeed so we want to
benchmark against that
Slide 58
Slide 58 text
and due to the audience here
today we will also throw the
FT and Guardian into the mix
Slide 59
Slide 59 text
To run our test we can
use Web Page Test
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
We then need to sit patiently
while our tests are run
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
We can also export the
comparison from Web
Page Test as video
Slide 65
Slide 65 text
No content
Slide 66
Slide 66 text
When running these
benchmarks against our
competitors we will want
to do it for different
types of page
Slide 67
Slide 67 text
Having seen how our
competitors perform we
should aim to be faster
Slide 68
Slide 68 text
Tim Kadlec
“For example, say a competitor’s
site loads in 5 seconds. 20% of 5
seconds is 1 second. So to be
perceived as faster than them, you
need to have your pages taking no
longer than 4 seconds (5 seconds
load time - 20% difference).”
https://timkadlec.com/2014/01/fast-enough/
Slide 69
Slide 69 text
So we should expect to
be a minimum of 20%
faster than our
competitors
Slide 70
Slide 70 text
We shouldn’t only try to
achieve this though, we should
try our best to go further
Slide 71
Slide 71 text
80% of 10 seconds is still
8 seconds and that is still
a slow website
Slide 72
Slide 72 text
In his book Usability
Engineering, Jakob Nielsen
identified response time limits.
Slide 73
Slide 73 text
0.1 SECONDS
Feels instantaneous
Slide 74
Slide 74 text
1 SECOND
Lets you think
seamlessly
Slide 75
Slide 75 text
10 SECONDS
Keeps your attention
….barely
Slide 76
Slide 76 text
+10 SECONDS
User is going to
abandon your site
in frustration
Slide 77
Slide 77 text
This reinforces the need
to ensure our site is
performant
Slide 78
Slide 78 text
You can use building a new
site as a way to establish
awareness
Slide 79
Slide 79 text
Look at the existing site
Slide 80
Slide 80 text
This enables you to
identify strengths and
weaknesses of the
current user experience
Slide 81
Slide 81 text
This should include
looking at how the
existing site performs
when it comes to
performance
Slide 82
Slide 82 text
This data can then be
used to link a increase in
performance to an
increase of KPI’s
Slide 83
Slide 83 text
Ensure you’re planning
performance as part of
your build
Slide 84
Slide 84 text
It is not uncommon for a
developer to first see a
design when they are
asked to build it
Slide 85
Slide 85 text
At this point it’s too late
to start planning how to
make the site performant
Slide 86
Slide 86 text
The client has already
approved the design
Slide 87
Slide 87 text
They love the carousels,
the 6 fonts, the crazy
animated background gif
Slide 88
Slide 88 text
This is happening every
day across our industry
Slide 89
Slide 89 text
The result is that our
web pages are getting
bigger and bigger
Slide 90
Slide 90 text
Average
Page
Weight
>
Slide 91
Slide 91 text
This isn’t down to lack of
knowledge in teams
Slide 92
Slide 92 text
It is down to a problem in
the processes we are
going through to build
our sites
Slide 93
Slide 93 text
This is why you need to
ensure that one of your
project goals is for the
site to be performant
Slide 94
Slide 94 text
Development
Design
Research
Business
development
Don’t start thinking of
performance here
Slide 95
Slide 95 text
Development
Design
Research
Business
development
Think about it from
the start of
your project
Slide 96
Slide 96 text
When working with your
clients, include it within
your statement of work
Slide 97
Slide 97 text
Then as you carry out
your research look at the
connection speeds your
users have
Slide 98
Slide 98 text
During design and build,
regularly get your team
together to review work
Slide 99
Slide 99 text
You should then aim to
get your designs into
build as soon as possible
Slide 100
Slide 100 text
Encourage
communication
Slide 101
Slide 101 text
Having brought
performance to the
beginning of our process
we need a common way
to talk about it
Slide 102
Slide 102 text
The way in which we do
this is to use
performance budgets
Slide 103
Slide 103 text
A performance budget is
a goal which guides
design and development
Slide 104
Slide 104 text
Tim Kadlec
“The purpose of a performance
budget is to make sure you focus
on performance throughout a
project. The reason you go through
the trouble in the first place though
is because you want to build a site
that feels fast for your visitors.”
http://www.timkadlec.com/2014/11/performance-budget-metrics/
Slide 105
Slide 105 text
In order for you to determine
what your performance
budget should be, you need
to determine what you’re
going to measure
Slide 106
Slide 106 text
In his post, Tim Kadlec
identified four such
metrics
Slide 107
Slide 107 text
Milestone Timing
Slide 108
Slide 108 text
SpeedIndex
Slide 109
Slide 109 text
Quantity based metrics
Slide 110
Slide 110 text
Rule based metrics
Slide 111
Slide 111 text
To put together our
budget we can use a
combination of these
metrics
Slide 112
Slide 112 text
Andy Davies
To me a perf budget needs to be
"an event that matters to the
visitor within a set time under
defined network conditions"
Tweet: https://twitter.com/AndyDavies/status/534474109741465601
Slide 113
Slide 113 text
To identify our metric we
therefore need to
identify the event that
matters to our users on
our site
Slide 114
Slide 114 text
For Twitter this might be
the time until the
navigation is visible
Slide 115
Slide 115 text
No content
Slide 116
Slide 116 text
For Facebook this might
be the time until the user
is able to make a post
Slide 117
Slide 117 text
No content
Slide 118
Slide 118 text
The FT might simply
want to lay out their page
ready for content to load
into as it loads
Slide 119
Slide 119 text
No content
Slide 120
Slide 120 text
For our site, an event
that matters could be the
user being able to start
interacting with the page
Slide 121
Slide 121 text
Therefore the time it
takes until it gets to this
point should be our
performance budget
Slide 122
Slide 122 text
So we might decide that
we want our page to be
interactive within 5
seconds on a slow 3G
connection
Slide 123
Slide 123 text
In order to calculate our
budget we need to define
‘slow 3G’
Slide 124
Slide 124 text
WebPageTest defines
this as 96 kilobytes per
second
Slide 125
Slide 125 text
So as we want to load our
site in 5 seconds…
Slide 126
Slide 126 text
96KB x 5secs = 480KB
Slide 127
Slide 127 text
We can then split 480KB
across our assets
Slide 128
Slide 128 text
Budget
HTML CSS JavaScript Images
30kb 40kb 50kb 360kb
Slide 129
Slide 129 text
If we then decide we
want to add web fonts to
our website we then
adjust our budget
Slide 130
Slide 130 text
HTML CSS JavaScript Images Fonts
30kb 40kb 50kb 300kb 60kb
Adjusted budget
Slide 131
Slide 131 text
You can have multiple
performance budgets to
handle different
conditions
Slide 132
Slide 132 text
HTML CSS JavaScript Images Fonts
30kb 40kb 50kb 800kb 60kb
Larger devices budget
Slide 133
Slide 133 text
The budget only covers
the data required until
we reach the event the
budget is based upon
Slide 134
Slide 134 text
The budget this method
produces is a bit rough
Slide 135
Slide 135 text
It doesn't account for
poor network conditions
beyond being slow
Slide 136
Slide 136 text
It does however provide
you with a set of guides
you can use
Slide 137
Slide 137 text
Experimenting with
different performance
budgets
Slide 138
Slide 138 text
Building a performance
budget is about reaching
the correct balance
Slide 139
Slide 139 text
and creating the
performance budget
should be a collaboration
between the various
stakeholders
Slide 140
Slide 140 text
One such tool that helps
you do this is
performancebudget.io
Slide 141
Slide 141 text
Demo of
performancebudget.io
Slide 142
Slide 142 text
No content
Slide 143
Slide 143 text
No content
Slide 144
Slide 144 text
No content
Slide 145
Slide 145 text
Measuring your
performance budget
Slide 146
Slide 146 text
For your performance
budget to be successful it
needs to be measured
Slide 147
Slide 147 text
A tool we can use to do
this is Web Page Test
Slide 148
Slide 148 text
No content
Slide 149
Slide 149 text
No content
Slide 150
Slide 150 text
No content
Slide 151
Slide 151 text
No content
Slide 152
Slide 152 text
Building a performance
budget for an existing site
Slide 153
Slide 153 text
The problem with existing
sites is that they likely have
performance problems
Slide 154
Slide 154 text
We should therefore
create our budget based
on our existing site
Slide 155
Slide 155 text
To do this we need to find
out what our site’s
metrics are
Slide 156
Slide 156 text
No content
Slide 157
Slide 157 text
No content
Slide 158
Slide 158 text
No content
Slide 159
Slide 159 text
No content
Slide 160
Slide 160 text
No content
Slide 161
Slide 161 text
Using WebPageTest has
given us a wealth of data
that we can use to put
together a performance
budget
Slide 162
Slide 162 text
Base Budget - 1483kb
HTML CSS JavaScript Images Fonts Other
20kb 98kb 632kb 658kb 46kb 29kb
Slide 163
Slide 163 text
Having determined a
budget for the existing
site we now need to look
at where we want to
make improvements
Slide 164
Slide 164 text
Firstly we identify areas
of concern
HTML CSS JavaScript Images Fonts Other
20kb 98kb 632kb 658kb 46kb 29kb
Slide 165
Slide 165 text
No content
Slide 166
Slide 166 text
No content
Slide 167
Slide 167 text
133KB
19KB
Slide 168
Slide 168 text
Adjusted Budget
HTML CSS JavaScript Images Fonts Other
20kb 98kb 632kb 358kb 46kb 29kb
Slide 169
Slide 169 text
No content
Slide 170
Slide 170 text
Adjusted Budget
HTML CSS JavaScript Images Fonts Other
20kb 98kb 600kb 358kb 46kb 29kb
Slide 171
Slide 171 text
Maintaining your
performance budget
Slide 172
Slide 172 text
It is important that you
don't forget about your
performance budget
Slide 173
Slide 173 text
You therefore need to
ensure that it forms part
of your process
Slide 174
Slide 174 text
Document your
performance budget
Slide 175
Slide 175 text
At Beamly we started
keeping our performance
budgets in a PERF.md file
Slide 176
Slide 176 text
# BeamlySite Performance Budget
## Expectation
A page is expected to load in 5 seconds on a slow 3G
connection.
## Budget
| HTML | CSS | JavaScript | Images |
|:----:|:----:|:----------:|:------:|
| 30kb | 40kb | 50kb | 360kb |
## Contributors
* Jonathan
* Sasha
* Izzy
Slide 177
Slide 177 text
By storing the file in the
repository it is version
controlled
Slide 178
Slide 178 text
We then ensure that it is
available to all
stakeholders
Slide 179
Slide 179 text
We then use a style guide
to communicate site
changes
Slide 180
Slide 180 text
Nicole Sullivan wrote a
great post on how having
a living style guide can
help you improve
performance
Slide 181
Slide 181 text
She worked with a
company called Trulia in
2013 to improve
performance
Slide 182
Slide 182 text
Reduce their HTML
payload by 48%
Slide 183
Slide 183 text
Reduced load
time by 21%
Slide 184
Slide 184 text
Achieve a 60%
improvement in
time to first byte
Slide 185
Slide 185 text
Reduce unused
CSS by 135kb
Slide 186
Slide 186 text
She also noted on her
blog post that it also led
to the design being used
across their site being
more consistent
Slide 187
Slide 187 text
Ensure you educate
anyone who joins your
project
Slide 188
Slide 188 text
Monitor your performance
budget
Slide 189
Slide 189 text
It is very easy to blow
your budget
Slide 190
Slide 190 text
You might implement a
new component on your
site
Slide 191
Slide 191 text
Or you might simply have
different content in live
than you had on stage
Slide 192
Slide 192 text
To help prevent this
there are a number of
tools you can use to
monitor your budget
Slide 193
Slide 193 text
Earlier we mentioned
WebPageTest
Slide 194
Slide 194 text
Aside from using it to run
one off tests, we can also
use it as part of our
Continuous Integration
Slide 195
Slide 195 text
If you want to regularly
run tests you can use a
service like SpeedCurve
Slide 196
Slide 196 text
Demo of
speedcurve.com
Slide 197
Slide 197 text
No content
Slide 198
Slide 198 text
No content
Slide 199
Slide 199 text
No content
Slide 200
Slide 200 text
No content
Slide 201
Slide 201 text
In Summary
Slide 202
Slide 202 text
Performant sites
provide a better user
experience and are a
competitive advantage
Slide 203
Slide 203 text
We should therefore be
ensuring that performance is
a goal of our project
Slide 204
Slide 204 text
To make this possible we should
use a common language that
all stakeholders understand
Slide 205
Slide 205 text
Ensuring that during our
regular testing of our site
we are also testing the
performance
Slide 206
Slide 206 text
Introducing monitoring
where necessary to
ensure we are able to
maintain performance
Slide 207
Slide 207 text
A special thanks goes out to to
Charlie Fielding for being so patient
and watching this talk 100x,
Andrew Davies for design, Phil
Nash for looking through and
advice and Kate Montgomery for
proof reading
Slide 208
Slide 208 text
Thank you, any questions?
Useful links
https://wpostats.com/
http://www.performancebudget.io/