Negotiating for performance

As a developer you need to be able to champion performance to the business you work in. This is because performance matters and as a developer you are best placed to understand the implications things have on how fast a web page will load.

As part of championing performance, you need to be able to negotiate with the stakeholders of the site. This might involve working with the designers to work on building a user experience that loads fast and working with the project managers to put aside time to spend optimising the site performance.

Transcript

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