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

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.

Jonathan Fielding

November 13, 2015
Tweet

More Decks by Jonathan Fielding

Other Decks in Programming

Transcript

  1. Jonathan Fielding @jonthanfielding
    The Critical JavaScript Path

    View full-size slide

  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’

    View full-size slide

  3. JavaScript has become a
    critical part of our websites

    View full-size slide

  4. Used correctly it can add
    interactivity to our web page

    View full-size slide

  5. But used incorrectly it can
    lead to a performance
    bottleneck

    View full-size slide

  6. So today we are going to look
    at how we can optimise how
    we build and load our
    JavaScript to maximise
    performance

    View full-size slide

  7. What is performance?

    View full-size slide

  8. – Google
    “the action or process of
    performing a task or function”

    View full-size slide

  9. In relation to a website,
    performance is the measure
    of how long it takes to deliver
    the content to the user

    View full-size slide

  10. Different types of
    performance

    View full-size slide

  11. There are three key types of
    performance that are
    important to a website

    View full-size slide

  12. Render performance
    The time it takes for the
    browser to start rendering
    the page

    View full-size slide

  13. Page load performance
    The time it takes to fully load
    a page and be fully
    interactive

    View full-size slide

  14. Perceived performance
    the perception of the user of
    the performance of our site

    View full-size slide

  15. Let’s watch a video that
    demonstrates the three kinds
    of performance

    View full-size slide

  16. Why is performance
    important?

    View full-size slide

  17. A responsive site is expected
    to work on a wide variety of
    internet connections

    View full-size slide

  18. The number of users who use
    the web on phones and
    tablets is increasing

    View full-size slide

  19. and from a financial point of
    view, it can affect your
    business

    View full-size slide

  20. Amazon found every 100ms
    delay in loading a page cost
    them 1% in sales

    View full-size slide

  21. Google found an extra
    500ms delay in loading of
    search results decreased
    traffic by 20%

    View full-size slide

  22. Yahoo found if their site
    loaded only 400ms faster
    their traffic went up 9%

    View full-size slide

  23. Finally, Google uses web
    page speed as a factor when
    ranking search results

    View full-size slide

  24. What sort of things can
    affect the user’s perception
    of our page?

    View full-size slide

  25. Seeing a blank page for
    an extended period

    View full-size slide

  26. Simple Interactions

    View full-size slide

  27. How do I optimise
    performance of my site?

    View full-size slide

  28. The Critical Rendering
    Path

    View full-size slide

  29. The Critical Rendering Path
    is the cornerstone of a
    performant page

    View full-size slide

  30. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  31. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  32. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  33. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  34. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  35. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  36. Critical Rendering Path
    Network
    HTML
    CSS
    Render Tree
    DOM
    CSSOM
    Layout Paint
    JavaScript

    View full-size slide

  37. But what has all this got
    to do with JavaScript?

    View full-size slide

  38. Web pages are increasing in
    size

    View full-size slide

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

    View full-size slide

  40. 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

    View full-size slide

  41. Current JavaScript delivery
    techniques focus on delivering a
    single package

    View full-size slide

  42. This means on average
    websites are downloading
    354kb of JavaScript before
    any can be executed

    View full-size slide

  43. If the JavaScript hasn’t
    loaded, the user can’t interact
    with things on the page that
    depend upon it

    View full-size slide

  44. This affects the perceived
    performance of the page

    View full-size slide

  45. Is there a maximum
    amount of JavaScript I
    should use?

    View full-size slide

  46. Short Answer:
    Yes

    View full-size slide

  47. To determine the maximum
    amount of JavaScript, we
    need to understand the
    bigger picture of our site’s
    assets

    View full-size slide

  48. To do this we need a
    performance budget

    View full-size slide

  49. A performance budget
    relates to the size of the
    assets in our page

    View full-size slide

  50. 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/

    View full-size slide

  51. At the start of your project
    you need to understand the
    metrics you want to achieve

    View full-size slide

  52. As we are building a
    responsive site, today’s
    example will aim to start
    rendering in 5 seconds on a
    slow 3G connection

    View full-size slide

  53. To start with we need to
    define ‘slow 3G’

    View full-size slide

  54. WebPageTest defines this as
    96 kilobytes per second

    View full-size slide

  55. So as we want to load our site
    in 5 seconds…

    View full-size slide

  56. 96KB x 5secs = 480KB

    View full-size slide

  57. We can then split 480KB
    across our assets

    View full-size slide

  58. Budget we defined
    HTML CSS JavaScript Images
    30kb 40kb 50kb 360kb

    View full-size slide

  59. If we then decide we want to
    add web fonts to our website
    we then adjust our budget

    View full-size slide

  60. Budget we defined
    HTML CSS JavaScript Images Fonts
    30kb 40kb 50kb 300kb 60kb

    View full-size slide

  61. These figures seem very
    ambitious when we compare
    them against the industry
    averages but it is achievable

    View full-size slide

  62. Calculate your budget
    yourself using
    www.performancebudget.io

    View full-size slide

  63. How can I apply this
    performance budget to my
    JavaScript?

    View full-size slide

  64. The first thing to do is to split
    our JavaScript into two
    distinct types

    View full-size slide

  65. Critical JavaScript is the
    JavaScript required to
    initialise our page.

    View full-size slide

  66. Main JavaScript handles the
    more complicated user
    interactions

    View full-size slide

  67. How this works in
    practice

    View full-size slide

  68. Critical JavaScript Path
    Network Critical JavaScript

    View full-size slide

  69. Critical JavaScript Path
    Network Critical JavaScript Adjust Layout
    Handle simple user
    interactions
    Network
    Defer more complex
    user interactions

    View full-size slide

  70. Critical JavaScript Path
    Main JavaScript
    Network Critical JavaScript Adjust Layout
    Handle simple user
    interactions
    Network
    Defer more complex
    user interactions

    View full-size slide

  71. 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

    View full-size slide

  72. Let’s have a look at this
    working on a demo website

    View full-size slide

  73. Implementation

    View full-size slide

  74. Identify which parts of your
    website are critical to
    providing a good user
    experience

    View full-size slide

  75. Implement the critical parts
    of the site using minimal
    JavaScript

    View full-size slide

  76. For interactions which are
    not ‘critical’, capture user
    input and defer handling it
    using a library called
    CriticalJS

    View full-size slide

  77. Download CriticalJS from
    https://github.com/jonathan-
    fielding/criticaljs

    View full-size slide


  78. Load the CriticalJS library
    Tell it where your main JavaScript is

    View full-size slide

  79. Alternatively, you can bundle
    it as part of your main Critical
    JavaScript package

    View full-size slide


  80. Your critical JavaScript including the CriticalJS lib
    Tell it where your main JavaScript is in the same way

    View full-size slide


  81. Click Me

    Add data attribute specifying
    what events are to be deferred

    View full-size slide

  82. Then in your main JavaScript

    View full-size slide

  83. 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

    View full-size slide

  84. Identifying bloat

    View full-size slide

  85. Despite trying to keep bloat
    to a minimum, it does like to
    rear its ugly head

    View full-size slide

  86. If we build our JavaScript
    bundle using Browserify
    we can easily identify
    bloat in our project

    View full-size slide

  87. In order to identify bloat in a
    Browserify project we can
    use Discify

    View full-size slide

  88. To get started with Discify
    install it using npm.
    npm install -g disc

    View full-size slide

  89. Then, to analyse your browserify
    bundle use
    discify app-bundle.js > map.html

    View full-size slide

  90. As we saw from our analysis
    map, it is very easy to include
    large libraries in our projects

    View full-size slide

  91. When optimising for
    perfomance we have to be
    ruthless, if a library will
    increase the size of the
    JavaScript unnecessarily it
    has to go

    View full-size slide

  92. Lodash - 18kb
    Handlebars - 20kb
    jQuery - 30kb

    View full-size slide

  93. If we are not taking full
    advantage of a library we
    should explore alternatives

    View full-size slide

  94. Lodash
    Handlebars
    jQuery
    Hogan.js
    qwery
    lodash.partial
    dom-delegate

    View full-size slide

  95. When building a website we
    need to consider how we
    load our JavaScript

    View full-size slide

  96. We want to prioritise
    delivering our core
    experience as quickly as
    possible

    View full-size slide

  97. This enables us to create the
    perception that our site is
    both responsive and
    performant

    View full-size slide

  98. A special thanks goes out to to
    Charlie Fielding, Kate Montgomery
    and everyone at Beamly who helped
    me with putting these slides together.

    View full-size slide

  99. Thank you,
    any questions?

    View full-size slide