Delivering Performant Websites Consistently

6c8618df1a325d0fb9644ee221086fb7?s=47 Jonathan Fielding
July 12, 2017
280

Delivering Performant Websites Consistently

6c8618df1a325d0fb9644ee221086fb7?s=128

Jonathan Fielding

July 12, 2017
Tweet

Transcript

  1. Jonathan Fielding @jonthanfielding Delivering Performant Websites Consistently

  2. 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
  3. Today we are going to talk about processes in the

    context of a project at Beamly
  4. Just over a year ago Beamly wrote a report for

    our primary client
  5. The report highlighted the poor performance of the brands websites

  6. To fix this we took a two pronged approach

  7. The first of which was taking over the hosting of

    the existing websites
  8. The problem with many of these websites was they were

    built poorly
  9. The second was to deliver a platform for the next

    generation of performant websites
  10. The company had acknowledged the importance of their sites

  11. As part of this we needed to build 6 beauty

    websites
  12. These websites had to be beautiful

  13. The websites had to be functional

  14. The websites had to be fast

  15. Fast in the context of a beauty website

  16. “A typical beauty website is not very performant”

  17. To start with I found 15 popular beauty brands and

    put their urls into WebPageTest
  18. None
  19. The problem with this is while it shows us visually

    the difference it is easier to benchmark against improvements with metrics
  20. To create these metrics quickly I used “Web Page Test

    Bulk Tester” written by Andy Davies http://bit.ly/wpt-bulk
  21. None
  22. Start Render Time Visually Complete Requests

  23. Start Render Time Visually Complete Requests 5.68 secs 25.12 secs

    102
  24. Images JavaScript Fonts CSS Standard Beauty Difference Industry data taken

    from the HTTP Archive database on Google Big Query
  25. 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
  26. There is no metric under which we can call these

    sites performant
  27. Having identified some metrics, we can come back to these

    later to measure the success of the project
  28. Determining the objective of the sites

  29. There are two key types of websites in the beauty

    industry
  30. The first is a brochureware site

  31. The second is an e-commerce website

  32. A second function of both of these is brand awareness

  33. Aim is to gather data

  34. Definition of performant for these sites

  35. Determining the objective of your sites

  36. Determine whether to prioritise first page load vs second page

    load
  37. Determining the technologies

  38. To start with we defined a set of principles

  39. ‘Don't deploy one stack for every client’

  40. ‘Invent once’

  41. ‘Don't be afraid to use things that were not invented

    here’
  42. We also wanted to consider users, developers and clients

  43. Looked at different solutions

  44. We then considered how we could combine technologies

  45. CMS

  46. Content Pipeline CMS

  47. Content Pipeline CMS Presentation

  48. Next step was to look at how we should build

    our frontend
  49. We started off by looking at off the shelf frontend

    open source projects
  50. Often these frontend open source project sit in two camps

  51. We have our libraries

  52. This might be to normalise the browsers like normalize.css

  53. Or provide a set of standard animations like Animations.css

  54. Using redux.js to manage the state of the data

  55. Through to using Qwery used to simplify DOM selection

  56. At the other end of the spectrum we have our

    frameworks
  57. We have CSS Framework’s that try to cover all the

    standard use cases for CSS
  58. The majority of which follow a common established architecture

  59. They provide us with a foundation of CSS

  60. And they offer a buffet of components

  61. We also have our JavaScript frameworks

  62. They help us architect our code

  63. Ilustration by Jake Archibald

  64. If you are building a Web App a framework will

    solve a lot of your problems
  65. Normalize.css

  66. Normalize.css Beamly Base

  67. Normalize.css Beamly Base Components

  68. Building out the teams

  69. Every member of these teams had a technical interview

  70. We ensured website performance featured prominently in these interviews

  71. ‘Tell me about how you ensure a website is performant

    enough?’
  72. ‘Tell me how you have considered performance during your design

    process?’
  73. We didn’t set out to hire performance experts

  74. Starting the UX process

  75. At the start of the UX process we introduced the

    team to performance budgets
  76. A performance budget is a goal which guides design and

    development
  77. 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/
  78. In order for you to determine what your performance budget

    should be, you need to determine what you’re going to measure
  79. We chose to use Milestone Timing

  80. Therefore the maximum time it takes to get to our

    milestone forms our performance budget
  81. We had already agreed with our clients that we want

    our page to be interactive within 5 seconds on a slow 3G connection
  82. 96KB x 5secs = 480KB

  83. We can then split 480KB across our assets

  84. Budget HTML CSS JavaScript Images 30kb 40kb 50kb 360kb

  85. If our designers then decided they wanted to add web

    fonts to our website we then adjust our budget
  86. HTML CSS JavaScript Images Fonts 30kb 40kb 50kb 300kb 60kb

    Adjusted budget
  87. The budget only covers the data required until we reach

    our milestone
  88. Experimenting with different performance budgets

  89. Building a performance budget is about reaching the correct balance

  90. and creating the performance budget should be a collaboration between

    the various stakeholders
  91. One such tool that helps you do this is performancebudget.io

  92. None
  93. None
  94. None
  95. Once we had set upon a performance budget for our

    site we then looked at techniques we could use to achieve it
  96. One way was to lazy load our imagery so that

    the browser focused on loading the images that were in view first
  97. Moving from design into development

  98. Start by defining the acceptance criteria for the developers to

    implement
  99. The performance characteristics of each component need to be carefully

    considered
  100. The developers paired with the designers to validate the way

    in which the site prioritised the content it loaded
  101. Repeatability vs Uniqueness

  102. What is repeatable

  103. Express middleware

  104. A set of CSS components

  105. What is unique

  106. Each site has a unique performance budget

  107. If your unsure build for one site and make it

    generic later
  108. Working with third parties

  109. There are three different kinds of integrations we did

  110. Implementing 3rd party scripts

  111. Work with your 3rd parties to implement their code asynchronously

  112. Proxy through your CDN where approriate

  113. Implementing a 3rd Party API

  114. Implementing a wrapper around a server only API

  115. Mis-steps we made

  116. Cache headers would be handled elsewhere in the stack

  117. Lazy loading all the images

  118. Blocking requests on different hosts

  119. Monitoring for changes in performance

  120. When these sites are done we don't want our performance

    to degrade
  121. It is very easy to blow your budget

  122. You might implement a new component on your site

  123. Or your client might make changes to the content

  124. To help prevent this there are a number of tools

    you can use to monitor your budget
  125. We can use web page test as part of our

    Continuous Integration
  126. If you want to regularly run tests you can use

    a service like SpeedCurve
  127. Demo of speedcurve.com

  128. None
  129. None
  130. None
  131. None
  132. The result of our project

  133. None
  134. None
  135. 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
  136. This project is still ongoing

  137. 2nd page load and onwards

  138. The project will also continue to evolve

  139. Summary

  140. Performant sites provide a better user experience

  141. We should therefore be ensuring that performance is a goal

    of every website we build
  142. Building one performant website can be a challenge

  143. Building multiple performant websites may even feel impossible

  144. But by iterating a process you can get to a

    state where your delivering performant websites every time
  145. A special thanks goes out to Charlie Fielding along with

    the folks at Beamly for being the guinea pigs for this talk
  146. Thank you, any questions?