Slide 1
Slide 1 text
Jonathan Fielding @jonthanfielding
Delivering
Performant Websites
Consistently
Slide 2
Slide 2 text
A bit about me…
• Engineering Manager 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
Today we are going to
talk about processes in
the context of a project
at Beamly
Slide 4
Slide 4 text
Just over a year ago
Beamly wrote a report
for our primary client
Slide 5
Slide 5 text
The report highlighted
the poor performance of
the brands websites
Slide 6
Slide 6 text
To fix this we took a two
pronged approach
Slide 7
Slide 7 text
The first of which was
taking over the hosting of
the existing websites
Slide 8
Slide 8 text
The problem with many
of these websites was
they were built poorly
Slide 9
Slide 9 text
The second was to
deliver a platform for the
next generation of
performant websites
Slide 10
Slide 10 text
The company had
acknowledged the
importance of their sites
Slide 11
Slide 11 text
As part of this we needed
to build 6 beauty
websites
Slide 12
Slide 12 text
These websites had to be
beautiful
Slide 13
Slide 13 text
The websites had to be
functional
Slide 14
Slide 14 text
The websites had to be
fast
Slide 15
Slide 15 text
Fast in the context
of a beauty website
Slide 16
Slide 16 text
“A typical beauty website
is not very performant”
Slide 17
Slide 17 text
To start with I found 15
popular beauty brands
and put their urls into
WebPageTest
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
The problem with this is
while it shows us visually
the difference it is easier to
benchmark against
improvements with metrics
Slide 20
Slide 20 text
To create these metrics
quickly I used “Web Page
Test Bulk Tester” written
by Andy Davies
http://bit.ly/wpt-bulk
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
Start Render
Time
Visually
Complete
Requests
Slide 23
Slide 23 text
Start Render
Time
Visually
Complete
Requests
5.68 secs 25.12 secs 102
Slide 24
Slide 24 text
Images JavaScript Fonts CSS
Standard
Beauty
Difference
Industry data taken from the HTTP Archive database on Google Big Query
Slide 25
Slide 25 text
Images JavaScript Fonts CSS
Standard 789kb 228kb 44kb 23kb
Beauty 1471kb 586kb 135kb 140kb
Difference +86% +157% +207% +508%
Industry data taken from the HTTP Archive database on Google Big Query
Slide 26
Slide 26 text
There is no metric under
which we can call these
sites performant
Slide 27
Slide 27 text
Having identified some
metrics, we can come
back to these later to
measure the success of
the project
Slide 28
Slide 28 text
Determining the
objective of the sites
Slide 29
Slide 29 text
There are two key types
of websites in the beauty
industry
Slide 30
Slide 30 text
The first is a
brochureware site
Slide 31
Slide 31 text
The second is an
e-commerce website
Slide 32
Slide 32 text
A second function of
both of these is brand
awareness
Slide 33
Slide 33 text
Aim is to gather data
Slide 34
Slide 34 text
Definition of performant
for these sites
Slide 35
Slide 35 text
Determining the
objective of your sites
Slide 36
Slide 36 text
Determine whether to
prioritise first page load
vs second page load
Slide 37
Slide 37 text
Determining the
technologies
Slide 38
Slide 38 text
To start with we defined
a set of principles
Slide 39
Slide 39 text
‘Don't deploy one stack
for every client’
Slide 40
Slide 40 text
‘Invent once’
Slide 41
Slide 41 text
‘Don't be afraid to use
things that were not
invented here’
Slide 42
Slide 42 text
We also wanted to
consider users,
developers and clients
Slide 43
Slide 43 text
Looked at different
solutions
Slide 44
Slide 44 text
We then considered how
we could combine
technologies
Slide 45
Slide 45 text
CMS
Slide 46
Slide 46 text
Content Pipeline
CMS
Slide 47
Slide 47 text
Content Pipeline
CMS Presentation
Slide 48
Slide 48 text
Next step was to look at
how we should build our
frontend
Slide 49
Slide 49 text
We started off by looking
at off the shelf frontend
open source projects
Slide 50
Slide 50 text
Often these frontend
open source project sit in
two camps
Slide 51
Slide 51 text
We have our libraries
Slide 52
Slide 52 text
This might be to
normalise the browsers
like normalize.css
Slide 53
Slide 53 text
Or provide a set of
standard animations like
Animations.css
Slide 54
Slide 54 text
Using redux.js to manage
the state of the data
Slide 55
Slide 55 text
Through to using Qwery
used to simplify DOM
selection
Slide 56
Slide 56 text
At the other end of the
spectrum we have our
frameworks
Slide 57
Slide 57 text
We have CSS
Framework’s that try to
cover all the standard
use cases for CSS
Slide 58
Slide 58 text
The majority of which
follow a common
established architecture
Slide 59
Slide 59 text
They provide us with a
foundation of CSS
Slide 60
Slide 60 text
And they offer a buffet of
components
Slide 61
Slide 61 text
We also have our
JavaScript frameworks
Slide 62
Slide 62 text
They help us architect
our code
Slide 63
Slide 63 text
Ilustration by Jake Archibald
Slide 64
Slide 64 text
If you are building a Web
App a framework will
solve a lot of your
problems
Slide 65
Slide 65 text
Normalize.css
Slide 66
Slide 66 text
Normalize.css Beamly Base
Slide 67
Slide 67 text
Normalize.css Beamly Base
Components
Slide 68
Slide 68 text
Building out
the teams
Slide 69
Slide 69 text
Every member of these
teams had a technical
interview
Slide 70
Slide 70 text
We ensured website
performance featured
prominently in these
interviews
Slide 71
Slide 71 text
‘Tell me about how you
ensure a website is
performant enough?’
Slide 72
Slide 72 text
‘Tell me how you have
considered performance
during your design
process?’
Slide 73
Slide 73 text
We didn’t set out to hire
performance experts
Slide 74
Slide 74 text
Starting the
UX process
Slide 75
Slide 75 text
At the start of the UX
process we introduced
the team to performance
budgets
Slide 76
Slide 76 text
A performance budget is
a goal which guides
design and development
Slide 77
Slide 77 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 78
Slide 78 text
In order for you to determine
what your performance
budget should be, you need
to determine what you’re
going to measure
Slide 79
Slide 79 text
We chose to use
Milestone Timing
Slide 80
Slide 80 text
Therefore the maximum
time it takes to get to our
milestone forms our
performance budget
Slide 81
Slide 81 text
We had already agreed with
our clients that we want our
page to be interactive
within 5 seconds on a slow
3G connection
Slide 82
Slide 82 text
96KB x 5secs = 480KB
Slide 83
Slide 83 text
We can then split 480KB
across our assets
Slide 84
Slide 84 text
Budget
HTML CSS JavaScript Images
30kb 40kb 50kb 360kb
Slide 85
Slide 85 text
If our designers then
decided they wanted to
add web fonts to our
website we then adjust
our budget
Slide 86
Slide 86 text
HTML CSS JavaScript Images Fonts
30kb 40kb 50kb 300kb 60kb
Adjusted budget
Slide 87
Slide 87 text
The budget only covers
the data required until
we reach our milestone
Slide 88
Slide 88 text
Experimenting with
different performance
budgets
Slide 89
Slide 89 text
Building a performance
budget is about reaching
the correct balance
Slide 90
Slide 90 text
and creating the
performance budget
should be a collaboration
between the various
stakeholders
Slide 91
Slide 91 text
One such tool that helps
you do this is
performancebudget.io
Slide 92
Slide 92 text
No content
Slide 93
Slide 93 text
No content
Slide 94
Slide 94 text
No content
Slide 95
Slide 95 text
Once we had set upon a
performance budget for
our site we then looked
at techniques we could
use to achieve it
Slide 96
Slide 96 text
One way was to lazy load
our imagery so that the
browser focused on
loading the images that
were in view first
Slide 97
Slide 97 text
Moving from design
into development
Slide 98
Slide 98 text
Start by defining the
acceptance criteria for
the developers to
implement
Slide 99
Slide 99 text
The performance
characteristics of each
component need to be
carefully considered
Slide 100
Slide 100 text
The developers paired
with the designers to
validate the way in which
the site prioritised the
content it loaded
Slide 101
Slide 101 text
Repeatability vs
Uniqueness
Slide 102
Slide 102 text
What is repeatable
Slide 103
Slide 103 text
Express middleware
Slide 104
Slide 104 text
A set of CSS components
Slide 105
Slide 105 text
What is unique
Slide 106
Slide 106 text
Each site has a unique
performance budget
Slide 107
Slide 107 text
If your unsure build for one
site and make it generic later
Slide 108
Slide 108 text
Working with
third parties
Slide 109
Slide 109 text
There are three different
kinds of integrations we
did
Slide 110
Slide 110 text
Implementing 3rd party
scripts
Slide 111
Slide 111 text
Work with your 3rd
parties to implement
their code
asynchronously
Slide 112
Slide 112 text
Proxy through your CDN
where approriate
Slide 113
Slide 113 text
Implementing a 3rd Party
API
Slide 114
Slide 114 text
Implementing a wrapper
around a server only API
Slide 115
Slide 115 text
Mis-steps we
made
Slide 116
Slide 116 text
Cache headers would be
handled elsewhere in the
stack
Slide 117
Slide 117 text
Lazy loading all the
images
Slide 118
Slide 118 text
Blocking requests on
different hosts
Slide 119
Slide 119 text
Monitoring for changes
in performance
Slide 120
Slide 120 text
When these sites are
done we don't want our
performance to degrade
Slide 121
Slide 121 text
It is very easy to blow
your budget
Slide 122
Slide 122 text
You might implement a
new component on your
site
Slide 123
Slide 123 text
Or your client might
make changes to the
content
Slide 124
Slide 124 text
To help prevent this
there are a number of
tools you can use to
monitor your budget
Slide 125
Slide 125 text
We can use web page
test as part of our
Continuous Integration
Slide 126
Slide 126 text
If you want to regularly
run tests you can use a
service like SpeedCurve
Slide 127
Slide 127 text
Demo of
speedcurve.com
Slide 128
Slide 128 text
No content
Slide 129
Slide 129 text
No content
Slide 130
Slide 130 text
No content
Slide 131
Slide 131 text
No content
Slide 132
Slide 132 text
The result of our
project
Slide 133
Slide 133 text
No content
Slide 134
Slide 134 text
No content
Slide 135
Slide 135 text
Images JavaScript Fonts CSS
Beauty 1471kb 586kb 135kb 140kb
New Cover Girl
Site
1400kb 33kb * 44.38kb 21.3kb
Difference -4.8% -94% -67% -85%
* excluding polyfills that are downloaded only in specific browsers
Slide 136
Slide 136 text
This project is still
ongoing
Slide 137
Slide 137 text
2nd page load and
onwards
Slide 138
Slide 138 text
The project will also
continue to evolve
Slide 139
Slide 139 text
Summary
Slide 140
Slide 140 text
Performant sites
provide a better user
experience
Slide 141
Slide 141 text
We should therefore be
ensuring that performance is
a goal of every website we
build
Slide 142
Slide 142 text
Building one performant
website can be a
challenge
Slide 143
Slide 143 text
Building multiple
performant websites
may even feel impossible
Slide 144
Slide 144 text
But by iterating a process
you can get to a state
where your delivering
performant websites
every time
Slide 145
Slide 145 text
A special thanks goes out
to Charlie Fielding along
with the folks at Beamly for
being the guinea pigs for
this talk
Slide 146
Slide 146 text
Thank you, any questions?