Temporal
JavaScript Performance
4 hours, 55 minutes
CC
Course Description
Learn techniques to write efficient JavaScript, optimize render performance, load assets faster using a CDN and split resource loading with Webpack. You'll learn how to diagnose and fix common performance problems to make your web apps more performant!
This course and others like it are available as part of our Frontend Masters video subscription.
Preview
CloseWhat They're Saying
I just completed "JavaScript Performance"
and this was really amazing and shape my vision to think better as a front-end engineer. Thank you.
Mobashir Farhan
MobashirFarhan
I highly recommend buying and watching this JavaSciprt Performance. Awesome course by Steve Kinney. It helped me understand the core parts of JavaScript. This is the most valuable course I’ve taken this year. Thank you Steve for sharing this with us.
Elvis Šabanović
elvis_339
Course Details
Published: April 5, 2018
Learning Paths
Topics
Learn Straight from the Experts Who Shape the Modern Web
Your Path to Senior Developer and Beyond
- 200+ In-depth courses
- 18 Learning Paths
- Industry Leading Experts
- Live Interactive Workshops
Table of Contents
Introduction
Section Duration: 29 minutes
Steve Kinney introduces himself and gives an overview of why performance is essential in modern web applications.
Steve talks about three different ways of thinking about performance: network load performance, JavaScript performance, and rendering performance.
Before beginning to improve performance, Steve mentions the need to determine whether or not there is a performance problem. Steve introduces his Golden Rules of web performance.
JavaScript Performance
Section Duration: 1 hour, 26 minutes
A lot of performance advice recommends that we compress our assets and worry about download times. Steve reviews how to measure our applications to determine where most of the startup time is spent.
Before code can be executed, it has to be read. V8 parses code in two steps. This is a good thing, but can have some negative implications if we're not careful.
While Optimize, which is JS file that tries to use a heuristic to reduce parsing times, is great tool for impacting performance, it's effectiveness varies across libraries and browsers. In this exercise, students set up and test Opitmize in with different browsers and JS libraries.
Steve walks through the Solution to Reducing Parsing Times Exercise underscoring the importance of measuring the impact of a tool before adding it to the build process.
Once the code has been parsed, an abstract syntax tree is created. The AST is a representation of our code that can be turned into byte code by the baseline compiler.
Steve benchmarks a small addition function and then uses V8's internal flags to trace the work done by the optimizing compiler to make it fast.
The optimizing compiler optimizes for what it’s seen. If it sees something new, that’s problematic. Steve traces deoptimization in the example from earlier. Deleting properties has some strange implications on performance. Steve takes questions from students.
In this exercise, students delete properties to determine an impact on performance.
Steve walks through the Solution to Deleting, Feeding Objects Exercise.
JavaScript is a dynamic language, but JavaScript keeps track of types under the hood. Functions can be optimized for the types of object's they've seen in the past.
Steve experiments by feeding similar objects to a function as well as then again with sending different types of objects to the same function and measuring the performance implications.
Steve compares objects created in different ways to see if they have the same hidden class.
Scoping can have dramatic implications on the performance of our code. Steve investigates with the curious case of a constructor class inside of a function. He compares the hidden classes of objects that were created by what looks like the same constructor.
Steve states that the code we write is not always the code that is executed. Hot functions can be re-written by the compiler to be more performant, and there isn't anything we need to do.
Steve wraps up JavaScript Performance by reviewing the main takeaways.
Rendering Performance
Section Duration: 1 hour, 29 minutes
HTML and CSS go through a similar process as JavaScript to be turned from a string of text into a real web page. Steve covers the DOM, CSSOM, and Render Tree at a high level.
JavaScript can change the look and behavior of a web page after it has been loaded. Depending on how it is used, it can trigger some or all of the steps taken to create the web page in the first place.
Steve illustrates that changing the elements on the page can cause the browser to recalculate the position of all of the objects on the page. This technique is an expensive operation and should be done as much as necessary, but as little as possible.
In this exercise, students examine how changing elements in a web page create additional render time within a browser.
Steve walks through the Solution to Layouts and Reflows Exercise.
Steve states that if we're not careful, we can write JavaScript that triggers an additional number of reflows. Steve shows how we can use our tools to determine if this is happening.
Steve looks at another Layout Thrashing example before exploring strategies for reducing unnecessary reflows of the page.
FastDOM, a library for separating reading and writing to and from the DOM automatically, is a helpful abstraction that reduces the number of forced synchronized layouts.
In this exercise, students work with FastDOM.
Steve walks through the Solution to the FastDOM Exercise.
While frameworks are incredibly helpful for implementing performant patterns, they come with overhead that needs to be considered.
Once the page has been laid out, elements in the Render Tree must be turned into images that can be displayed on the screen. While not all changes will cause a reflow, but most will trigger a repaint.
The compositor thread is a thread in the browser that leverages the GPU to create the final version of the page seen on the screen.
The compositor thread manages layers. One can make our applications perform better by having the compositor thread take care of moving objects around as opposed to the main thread, which has many other responsibilities.
The will-change property is a hint to the browser that something might happen to an element soon, which would make it worthy of its layer. The browser can choose to take this hint and promote it to its thread in anticipation.
will-change indicates to the browser that a CSS property is likely to change in the near future. JavaScript is typically the change agent and can let the browser know beforehand that it's getting ready to change a property on an element.
In this exercise, students work on an element, which is currently the cause of a paint storm, and refactor it to use layers.
Steve walks through the Solution to the will-change Exercise. Steve takes questions from students.
Load Performance
Section Duration: 1 hour, 5 minutes
Where assets are located can have an important impact on the time it takes for web pages to load. Using a CDN can solve this by distributing assets around the world.
The browser will not ask for assets that it believes it already has recent versions of. Caching headers can be set in HTTP responses that let the browser know what it should and should not cache.
Service Worker is a new web technology that allows us to programmatically control caches and network requests without relying on HTTP headers.
Steve introduces Lazy Loading. Lazy Loading is a technique to delay initialization of an object until the point at which it is needed.
Steve takes a tour of a demonstration application called "Noted" and showcases how to optimize with lazy loading components as needed.
Webpack's bundle analyzer can be used for visualizing the size and contents of the bundles it produces.
Steve states that not every part of a library is needs to be included in applications. In some cases, picking out only the parts needed is possible. Steve selects the one method he needs from Lodash and then re-evaluates the size of the application's bundle.
React-Loadable is an abstraction that dynamically lazy-loads react components and renders a loading component.
In this exercise, students need to work on coding the markdown component to be loaded dynamically—further reducing the size of the initial bundle.
Steve walks through the Solution to the Component Lazy-Loading Exercise.
HTTP/2 is a significant update to the transport protocol that gets web pages to browsers. It also invalidates some performance advice that was once standard in the industry.
Tools
Section Duration: 16 minutes
Build tools can help automate best practices for delivering performant web applications.
Babel is an indispensable tool for most front-end engineers these days, but it can have some adverse effects on the size of parse times of JavaScript bundles.
Steve reviews some Babel plugins that help implement some of the best practices with little to no additional work.
Prepack is an experimental library for reducing the computing needed to execute JavaScript.
Wrapping Up
Section Duration: 7 minutes
Steve discusses final thoughts on performance as well as some paths for further research and topics not covered in this workshop.
Steve answers questions from the audience.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops