Click on text below to jump to specific point in the video


We want the page to load quickly. Somewhere along the process things start to get slower, and they don't realize it right away and then all of a sudden "my app is slow". We will tell you about tools, techniques, approaches and workflows on making measurable improvements in performance.
Performance is the art of avoiding work.. and making any work you do as efficient as possible
I will touch on the effective workflow for diagnosing and improving performance.
The basic performance workflow
Measure with a profile
Interpret costs

Identify the bottleneck

Try a fix

Back to measure and repeat

Perf Case Studies
Android auto website
Let us look at the timeline
The header is painting in right away.Frames per second, see what took a while to paint. 3 seconds of spinning. The car image is about 2MB.

What to do next?

Click on the checkbox called network.
We have the same the exact network waterfall we see in the network payload but now integrated into this view.
The colors match the rest of the plan chart.
But we can begin to coordinate what is happening on the network side of things and the actual execution of what is happening on the main thread.

Let us find that image load.
It is a 1MB image. We have 2 seconds of nothing.

Let us see the last thing to load.
We are a bit confused why this happens.Let us look at the image. See the data-breakpoints?

Now what do I do?

CMD + SHIFT + P

Type search

Search across all files for js-header-animate-image

Code is minified. Let us pretty print that.

function loadContent

We set interval every 1000ms and we check if the class has loaded.
We are adding a delay for 1 second.So there are some opportunities where we can improve this.
I want to take a look at the interaction stuff.
I come back to the timeline. I look at the interactions once I start using the page. I will capture a new recording. I will scroll, fling, sign up. And stop the recording. We have identified what interactions are happening. We can magnify and see the response.
The browser is handling the gesture under the hood to handle this input.

What is that red line?
Time waiting for main thread. The browser receives the Tap. And browser needs a second - to evaluate on the main thread and run event handlers.

The other nice thing here - I hit that sign up form - if I bring back network we can also see a little bit of what is happening.

Here we can see it on the mini-map.
The blue bar is the mini view of the network which we can open up to see the details of all that. It is nice to get the interaction between the main thread, network activity and back in a single view.
Case study: modern-web.org
Let us reload this page and look at the timeline. This is on my laptop with good wifi. It took over 10s to load, for all stuff to finish. I see this crazy amount of yellow. The colors are by file.

We want to get an aggregate view.
Click on Bottom-Up. This is a summary of all the costs.So this tells me that we are executing a lot of JavaScript.This is a bit higher level than diving in. Switch dropdown back to group by domain. We have this ytimg. We spend 2 seconds for addthis code. There is a share button you can get behind the click on the audio player.

What if we disable the podcast stuff and see what it looks like?
Let us try that.
There is an experimental feature called request blocking where we can just say - block these requests from going out completely.
Go to Network. Right click - click on Block Request Domain.

This is a responsive site - on the phone it will take longer. 
There is a new feature called CPU throttline. We can slow down everything from JavaScript to layout takes to evaluate inside the page - to sort of emulate on what it would be like on a phone. We dropped down to 7 seconds now.

We are still paying the YouTube cost.
It is all iframe embeds. We can loop over video objects and load them lazily.
Before and after image

We are doing less work.
We are down to about 4 seconds.
Performance everywhere
Let us discuss performance on the server side.
Case study: eslint
Let us measure with a profiler to see what is going on.
What we have here is the modern chrome dev tools inside of chrome and we are talking directly to nodejs.
There are no elements tab. We go to the profiles tab. Let us run the program. Use CMD + E to start and stop these We see a blame chart.
We clicked from profile and go to source.
The colors are line level annotations of all the performance work. Chrome shows perf info not just per function, but even per line - showing where in the function I am doing CPU work. So it looks like all the work is happening in the GlobSync. Zooming out, we see that is starts in the listFilesToProcess function.
Explanation figure

How to improve it?

We call eslint with eslint ignore - it constructs this filter object - passes it to glob.sync and we get 30 files.
Let us try it out and measure it. Lets rerun our profile.
In Review
Let us know what you think.
Video outline created using VideoJots