Delivering Performant Websites Consistently

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
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
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
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
132. The result of our project
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?