Critical JavaScript Path

When building websites we often think about the critical rendering path, the sequence of steps the browser goes through to render the initial view of the site. The problem comes that with so much interaction of our sites relying on JavaScript, there is often a limbo where the browser has started to render the initial content but as the JavaScript has not yet downloaded our interactions do not work.

In some cases progressive enhancement allows us to fall back to the server handling the user interaction for things like forms but in many cases this isn’t appropriate. In order to give the user the perception that our site is fully interactive we need to give them the perception that these interactive elements are ready fast, we need to be considering the ‘Critical JavaScript Path’. The steps we can take to allow the users browser to be no only rendered but ready to capture user interactions. In this talk we will explore what is the Critical JavaScript Path and how we can optimise it to offer a better perceived performance.

Transcript

1. Jonathan Fielding @jonthanfielding The Critical JavaScript Path
2. A bit about me… • Technical Architect at Beamly • Author of Beginning Responsive Design • Regular contributor to open source, including SimpleStateManager, Echo.js, CriticalJS, FT’s Polyfill Service, Doccy among many projects • Lover and user of ‘the Twitter’
3. JavaScript has become a critical part of our websites
4. Used correctly it can add interactivity to our web page
5. But used incorrectly it can lead to a performance bottleneck
6. So today we are going to look at how we can optimise how we build and load our JavaScript to maximise performance
7. What is performance?
8. – Google “the action or process of performing a task or function”
9. In relation to a website, performance is the measure of how long it takes to deliver the content to the user
10. Different types of performance
11. There are three key types of performance that are important to a website
12. Render performance The time it takes for the browser to start rendering the page
13. Page load performance The time it takes to fully load a page and be fully interactive
14. Perceived performance the perception of the user of the performance of our site
15. Let’s watch a video that demonstrates the three kinds of performance
17. Why is performance important?
18. A responsive site is expected to work on a wide variety of internet connections
19. The number of users who use the web on phones and tablets is increasing
20. and from a financial point of view, it can affect your business
21. Amazon found every 100ms delay in loading a page cost them 1% in sales
22. Google found an extra 500ms delay in loading of search results decreased traffic by 20%
23. Yahoo found if their site loaded only 400ms faster their traffic went up 9%
24. Finally, Google uses web page speed as a factor when ranking search results
25. What sort of things can affect the user’s perception of our page?
26. Seeing a blank page for an extended period
28. Layout
31. Simple Interactions
34. How do I optimise performance of my site?
35. The Critical Rendering Path
36. The Critical Rendering Path is the cornerstone of a performant page
37. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
38. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
39. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
40. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
41. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
42. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
43. Critical Rendering Path Network HTML CSS Render Tree DOM CSSOM Layout Paint JavaScript
44. But what has all this got to do with JavaScript?
45. Web pages are increasing in size
46. Average page weight has been increasing year on year Average Page Size (kB) 0 550 1100 1650 2200 September 2012 September 2013 September 2014 September 2015 Data from http://httparchive.org/interesting.php
47. Scripts Fonts Video Images Stylesheets HTML Other 0 350 700 1050 1400 4 56 69 1,350 209 107 354 Average KB per Page by Content Type
48. Current JavaScript delivery techniques focus on delivering a single package
49. This means on average websites are downloading 354kb of JavaScript before any can be executed
50. If the JavaScript hasn’t loaded, the user can’t interact with things on the page that depend upon it
51. This affects the perceived performance of the page
52. Is there a maximum amount of JavaScript I should use?
53. Short Answer: Yes
54. To determine the maximum amount of JavaScript, we need to understand the bigger picture of our site’s assets
55. To do this we need a performance budget
56. A performance budget relates to the size of the assets in our page
57. 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/
58. At the start of your project you need to understand the metrics you want to achieve
59. As we are building a responsive site, today’s example will aim to start rendering in 5 seconds on a slow 3G connection
60. To start with we need to define ‘slow 3G’
61. WebPageTest defines this as 96 kilobytes per second
62. So as we want to load our site in 5 seconds…
63. 96KB x 5secs = 480KB
64. We can then split 480KB across our assets
65. Budget we defined HTML CSS JavaScript Images 30kb 40kb 50kb 360kb
66. If we then decide we want to add web fonts to our website we then adjust our budget
67. Budget we defined HTML CSS JavaScript Images Fonts 30kb 40kb 50kb 300kb 60kb
68. These figures seem very ambitious when we compare them against the industry averages but it is achievable
69. Calculate your budget yourself using www.performancebudget.io
70. How can I apply this performance budget to my JavaScript?
71. The first thing to do is to split our JavaScript into two distinct types
72. Critical JavaScript is the JavaScript required to initialise our page.
73. Main JavaScript handles the more complicated user interactions
74. How this works in practice
75. Critical JavaScript Path Network Critical JavaScript
76. Critical JavaScript Path Network Critical JavaScript Adjust Layout Handle simple user interactions Network Defer more complex user interactions
77. Critical JavaScript Path Main JavaScript Network Critical JavaScript Adjust Layout Handle simple user interactions Network Defer more complex user interactions
78. Critical JavaScript Path Main JavaScript Handle deferred user interactions Network Critical JavaScript Adjust Layout Handle simple user interactions Network Defer more complex user interactions Includes any models, frameworks, services etc
79. Let’s have a look at this working on a demo website
82. Implementation
83. Identify which parts of your website are critical to providing a good user experience
84. Implement the critical parts of the site using minimal JavaScript
85. For interactions which are not ‘critical’, capture user input and defer handling it using a library called CriticalJS
86. Download CriticalJS from https://github.com/jonathan- fielding/criticaljs
87. <script src="../src/criticaljs.js" data-deferredjs="scripts/main.js"></script> Load the CriticalJS library Tell it where your main JavaScript is
88. Alternatively, you can bundle it as part of your main Critical JavaScript package
89. <script src="app-critical.js" data-deferredjs="app-main.js"></script> Your critical JavaScript including the CriticalJS lib Tell it where your main JavaScript is in the same way
90. <button data-deferred="click"> Click Me </button> Add data attribute specifying what events are to be deferred
91. Then in your main JavaScript
92. var button = document.querySelector('button') var clicked = criticaljs.deferred(button, 'click'); var ev = function(){ alert('clicked'); } if (clicked) { ev.bind(button)(); } button.addEventListener(ev); Check if the event has been triggered Handle deferred user interaction Attach the real interaction
93. Identifying bloat
94. Despite trying to keep bloat to a minimum, it does like to rear its ugly head
95. If we build our JavaScript bundle using Browserify we can easily identify bloat in our project
96. In order to identify bloat in a Browserify project we can use Discify
97. To get started with Discify install it using npm. npm install -g disc
98. Then, to analyse your browserify bundle use discify app-bundle.js > map.html
100. As we saw from our analysis map, it is very easy to include large libraries in our projects
101. When optimising for perfomance we have to be ruthless, if a library will increase the size of the JavaScript unnecessarily it has to go
102. Lodash - 18kb Handlebars - 20kb jQuery - 30kb
103. If we are not taking full advantage of a library we should explore alternatives
104. Lodash Handlebars jQuery Hogan.js qwery lodash.partial dom-delegate
105. In Summary
106. When building a website we need to consider how we load our JavaScript
107. We want to prioritise delivering our core experience as quickly as possible
108. This enables us to create the perception that our site is both responsive and performant
109. A special thanks goes out to to Charlie Fielding, Kate Montgomery and everyone at Beamly who helped me with putting these slides together.
110. Thank you, any questions?