Critical JavaScript Path - Speaker Deck

Tweet

Tweet

Slide 1

Slide 1 text

Jonathan Fielding @jonthanﬁelding The Critical JavaScript Path

Slide 2

Slide 2 text

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 Polyﬁll Service, Doccy among many projects • Lover and user of ‘the Twitter’

Slide 3

Slide 3 text

JavaScript has become a critical part of our websites

Slide 4

Slide 4 text

Used correctly it can add interactivity to our web page

Slide 5

Slide 5 text

But used incorrectly it can lead to a performance bottleneck

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

What is performance?

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Different types of performance

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Why is performance important?

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

and from a ﬁnancial point of view, it can affect your business

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Google found an extra 500ms delay in loading of search results decreased trafﬁc by 20%

Slide 23

Slide 23 text

Yahoo found if their site loaded only 400ms faster their trafﬁc went up 9%

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Seeing a blank page for an extended period

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

Layout

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Simple Interactions

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

How do I optimise performance of my site?

Slide 35

Slide 35 text

The Critical Rendering Path

Slide 36

Slide 36 text

The Critical Rendering Path is the cornerstone of a performant page

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

But what has all this got to do with JavaScript?

Slide 45

Slide 45 text

Web pages are increasing in size

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Current JavaScript delivery techniques focus on delivering a single package

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

This affects the perceived performance of the page

Slide 52

Slide 52 text

Is there a maximum amount of JavaScript I should use?

Slide 53

Slide 53 text

Short Answer: Yes

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

To do this we need a performance budget

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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 ﬁrst 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/

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

To start with we need to deﬁne ‘slow 3G’

Slide 61

Slide 61 text

WebPageTest deﬁnes this as 96 kilobytes per second

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

96KB x 5secs = 480KB

Slide 64

Slide 64 text

We can then split 480KB across our assets

Slide 65

Slide 65 text

Budget we deﬁned HTML CSS JavaScript Images 30kb 40kb 50kb 360kb

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Budget we deﬁned HTML CSS JavaScript Images Fonts 30kb 40kb 50kb 300kb 60kb

Slide 68

Slide 68 text

These ﬁgures seem very ambitious when we compare them against the industry averages but it is achievable

Slide 69

Slide 69 text

Calculate your budget yourself using www.performancebudget.io

Slide 70

Slide 70 text

How can I apply this performance budget to my JavaScript?

Slide 71

Slide 71 text

The ﬁrst thing to do is to split our JavaScript into two distinct types

Slide 72

Slide 72 text

Critical JavaScript is the JavaScript required to initialise our page.

Slide 73

Slide 73 text

Main JavaScript handles the more complicated user interactions

Slide 74

Slide 74 text

How this works in practice

Slide 75

Slide 75 text

Critical JavaScript Path Network Critical JavaScript

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

Implementation

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

Implement the critical parts of the site using minimal JavaScript

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Download CriticalJS from https://github.com/jonathan- ﬁelding/criticaljs

Slide 87

Slide 87 text

Load the CriticalJS library Tell it where your main JavaScript is

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

Click Me Add data attribute specifying what events are to be deferred

Slide 91

Slide 91 text

Then in your main JavaScript

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

Identifying bloat

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

In Summary

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

Thank you, any questions?