Critical JavaScript Path

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.

6c8618df1a325d0fb9644ee221086fb7?s=128

Jonathan Fielding

November 13, 2015
Tweet

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

  27. None
  28. Layout

  29. None
  30. None
  31. Simple Interactions

  32. None
  33. None
  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
  80. None
  81. None
  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
  99. None
  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?