Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Negotiating for performance

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.

Jonathan Fielding

August 02, 2016

More Decks by Jonathan Fielding

Other Decks in Programming


  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

  24. Analytics teams don’t want to have any impact on your

  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

  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
  39. None
  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

  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

  60. None
  61. We then need to sit patiently while our tests are

  62. None
  63. None
  64. We can also export the comparison from Web Page Test

    as video
  65. None
  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

  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

  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

  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

  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
  115. None
  116. For Facebook this might be the time until the user

    is able to make a post
  117. None
  118. The FT might simply want to lay out their page

    ready for content to load into as it loads
  119. None
  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

  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

  142. None
  143. None
  144. None
  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
  148. None
  149. None
  150. None
  151. None
  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

  155. To do this we need to find out what our

    site’s metrics are
  156. None
  157. None
  158. None
  159. None
  160. None
  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
  165. None
  166. None
  167. 133KB 19KB

  168. Adjusted Budget HTML CSS JavaScript Images Fonts Other 20kb 98kb

    632kb 358kb 46kb 29kb
  169. None
  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

  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

  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

  197. None
  198. None
  199. None
  200. None
  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/