View original post

Ilya Grigorik Interview on ScaleYourCode.com

10 mins summary

Feel free to email, tweet, blog, and pass this around the web … but

please don’t alter any of its contents when you do. Thanks, and enjoy!

ScaleYourCode.com

View original post

Who is Ilya Grigorik?

Ilya’s day-to-day job involves being a developer

advocate and performance engineer. He works

with both internal Google teams, and external

developers. This helps him understand what

pieces are missing in today's web platform, and

if they're not missing, how they can make them

better. The same goes for browsers—

“How can we make them better for a wider

range of use cases?”

Mobile is getting more and more important, so part of his job is also figuring out

how to make pages and browsers work better for mobile users.

Ilya pointed something out that we easily forget:

Some of these mobile devices and networks are slower than the dial-up we had a

decade ago. That's remarkable and sad at the same time...but it's something we

need to keep in mind.

View original post

Is there one thing people do that really slows down their

pages?

There are many, which is why you need performance analytics (which we’ll cover

in a little bit). However, here are two things everyone should be doing:

1) Compression

Many sites deliver their HTML, CSS, and JS, without enabling gzip. Gzip gives a big

saving on the number of bytes that need to be transferred, which is very

important.

2) Optimizing images

It's common to grab a photo off of a phone and upload it to a website. Even

though it's being resized in CSS, you're still transferring a massive image across

the wire.

If you look at web pages, images today contribute more than 50-60% of the total

weight of a page. Yet, a lot of times, they're not optimized at all.

The episode before this one is all about optimizing images. I highly recommend

you check it out if you haven’t already.

View original post

How can you minimize the number of bytes being

transferred?

1) Don’t transfer things you don’t need

Look at scripts and CSS files on your different pages and ask yourself whether

those files are actually needed for that page or not. You'll probably find some

things that were added there a while back and never removed.

I go on WordPress sites all the time that load CSS and JavaScript assets that aren’t

used at all on that page. Many non-WordPress sites also do this. Shoot, I just

checked and I’m doing that on a few pages! It’s a waste of bytes!

2) Fetch the most optimized version of the asset

This includes compression, minification, and using the right image formats. For

example, SVG can be served in a much smaller container.

We've also seen a resurgence of GIF files on the Internet. These GIFs are funny,

but poorly optimized (ie: very heavy). They're much bigger than regular video files

(like MP4), because of the compression algorithms used. We're talking about 10-

20x smaller. In fact, Twitter actually takes user uploaded GIFs and transforms

them into MP4s. You can check this by inspecting a GIF on your Twitter timeline

next time you see one.

Why is MP4 smaller? GIFs take each frame individually and compresses them

frame by frame. If you think about it, an animation is just a bunch of back-to-back

frames which are very similar. Movie compressors use that fact to compress each

particular frame and also share information between frames so they don't have to

encode each frame. Thanks to that, movie files are much smaller than GIFs.

View original post

Is Time to First Byte still an important metric?

It is, absolutely.

You really want to give back the HTML bytes to the browser as soon as possible.

So, for example, a request comes in and (ideally) your data is cached so your

server can stream it back quickly. Then, the browser can start parsing it and

displaying something on the screen.

When people say that a page should load quickly, it doesn't have to display the

entire page at once. In fact, all the browsers are built around progressive

rendering.

As soon as we have some HTML, we should start parsing it and displaying

something to the user while everything else continues to load.

That's where the Time to First Byte (TTFB) comes from. There's a huge difference

between the browser sending a request and receiving it 5 seconds later, versus

displaying something as soon as you receive that first byte.

Then the main question is, how much of a relative impact will it have on a page

compared to other optimizations?

View original post

What does Waiting (TTFB) in Chrome's DevTools really

represent? Is it how long the browser waits for a response

from the server?

When the browser sends a request for a page, it sits there waiting for a response.

The Waiting (TTFB) represents how long it took to receive the very first response

byte. This time doesn’t just represent how long it took for your server to generate

a response, but also the time it took to travel across the wire.

View original post

This first byte response will contain HTTP headers, and a part of the HTML

document.

After that, in the first image, Content Download represents how long it took to

receive the bytes. This part is very quick (in this example) because the HTML file is

small enough to fit in one round-trip.

Then we must shorten the network trip time and speed

up the server response

Yes. Ideally, we want to have a cached response at the CDN so we don't even

have to go to the server.

Can we measure the network trip time separate from the

server response time?

Yes, you can, using the Navigation Timing API. There's also a Resource Timing API.

These expose performance data to scripts, which makes it easy to use a data

analytics tool to chart and track different performance metrics. All you have to do

is drop in the script on your pages.

Having a better idea of what's slowing down things for your websites can help you

optimize. Is it that the majority of your users have slower networks? If so, you can

lower the number of images and assets on your pages. Or maybe it's because

your server is slow to respond. Then, you can look into that.

I cover this in a little bit more detail here.

View original post

What kinds of things block the loading of additional assets

(or block rendering)?

If you look at your timeline, sometimes there is a gap between one file being

loaded and another being fetched. While there could be a few different reasons

for that, it's probably because we're parsing the HTML, doing background work,

or being blocked by another request. This is where we talk about optimizing the

Critical Render Path.

The Critical Rendering path is the sequence of steps your browser has to take in

order to get the HTML, construct the DOM, get the style information, execute

critical JavaScript, and then paint the content.

CSS is obviously critical for all of this, but some of the JavaScript may not be. And

yet, because of the way it's put on the page, it is treated as a critical resource and

is blocking the rendering of the page.

View original post

How can we make sure JavaScript doesn't block this

render path?

Since the browser has no idea whether the JavaScript code is going to modify the

DOM in any way, it has to assume that it will. That's why it loads it before going

further.

If we're talking about an external script, that means your rendering has to wait for

your browser to download that script, parse it, and execute it. Only then can the

browser keep rendering the page.

See how this is getting ugly?

One solution to this problem is to make scripts async. Async is probably not new

to you, but you might have been using it without really understanding the reason.

Async promises the browser that it's not going to manipulate the DOM, so you

can start fetching it and execute it when it's ready--without blocking the HTML

parsing and rendering.

It is ideal for scripts that don't depend on anything else, and don't affect the page

at all (like analytics). If your script does have dependencies, there are other ways

of loading them without blocking.

What if your scripts have dependencies? Can you use

async?

It depends. This is really when you need to dig in the application and see what the

dependency is being used for.

If your script is constructing the page and has behavior that is absolutely critical to

have in order to display the page, then you may need to block the rendering.

Often, though, even if you async scripts that modify the page, it is still perfectly

functional from a user's perspective. They can see the content and they can start

using it. Sure, some of the actions may not be available yet, but that can wait a

little bit longer.

View original post

How can you measure if using async is beneficial to your

app or hurting it?

Historically, we haven’t had a great set of tools to actually measure that. The best

tool that we had for a long time was the WebPage test film strip, which shows the

visual progress. You can set up a test and compare with and without async side-

by-side.

More recently, DevTools now has the film view as well.

Go to Timeline -> Enable Screenshots -> Reload your page

You'll see screenshots of your page load. It's pretty nice.

Here's what you can do:

1. Toggle your network like we talked about earlier

2. Take a look at the film strip

3. Change your scripts to async/move them around

4. Compare film strips

DevTools can be overwhelming. How can we get a better

understanding of how to use it?

While you wait for the Dev Team to simplify things, check out videos from Paul

Lewis and others who walk through how to use DevTools. These are quite

informative.

What's really cool about these videos is that they can speed up websites on the

screen without having access to the website's servers. They've optimized things

like jank on window scroll, or janky touch events, etc...

View original post

DevTools can be overwhelming. How can we get a better

understanding of how to use it?

The main differences between HTTP1 and 2 are in the framing. How the request is

laid out on the wire, if you will. The semantics are exactly the same, so you don't

have to modify your website if you want to upgrade. The only difference is how

the request is sent on the wire.

With HTTP1, you negotiate a connection to the server. If we send a request over

that connection, it becomes occupied. No other request can be sent over it until

we receive a response. The way around this is to open multiple connections (6

with Chrome, usually). That means we can fetch at most 6 resources at a time.

With HTTP2, we can use one connection for multiple requests. How? By slicing

requests and responses into smaller chunks called frames. These frames are

tagged with an ID that connects the data to the request/response. That way, we

can send everything over the same connection.

This also opens the door to other optimizations like prioritization. Prioritization

sends hints to the server to tell it which assets are more important than others.

Like main.css is more important than image1.jpg, for example, because CSS blocks

rendering but images do not.

There is also Server Push. Server Push allows the server to send multiple

responses. Example: you request an HTML page and the JavaScript and CSS files

are needed to render that HTML page, so the server will send those files before

the browser even asks for them. Nice, huh?

In addition, HTTP2 has compression for HTTP headers. We've talked about

compressing the response body with gzip, but headers (like user-agent, cookies,

etc...) in HTTP1 aren't compressed. That doesn't seem like a big deal until you

account for cookies which can get quite big.

HTTP2 introduced HPACK which compresses headers and reduces that overhead.

Here's an example of how it works:

View original post

Whereas HTTP1 always sends the user-agent (which doesn't change), HTTP2

sends it out during the first trip, and then references it as an ID for subsequent

trips. It really reduces the amount of data transferred.

You get the benefit of:

1) Smaller requests

2) Multiplexing (more explanation here)

3) Prioritizing requests

4) Makes the server be smarter about how it responds with data

5) Gives the server more flexibility in how it sends the response

Do we still need to concatenate and minify with HTTP/2?

Yes and no.

Minification, yes. Reducing the number of bytes we transfer still helps.

Concatenation, mostly not. Since we can send potentially hundreds of requests in

one connection, we don't have to bundle files together anymore. Now, that

doesn't mean it's a good idea to separate your scripts into hundreds of different

scripts (nightmare to maintain and what would be the point?), but it's not a

benefit anymore with HTTP2.

View original post

Conclusion

I have to try and fit as much information in this summary as possible without

making it too long. This means I cut out some information that could really help

you out one day. I highly recommend you view the full interview if you found this

interesting, as there are more hidden gems.

You can watch it, read it, or even listen to it. There's also an option to download

the MP3 so you can listen on your way to work. Of course, the show is also on

iTunes (https://itunes.apple.com/tt/podcast/scale-your-code-

podcast/id987253051?mt=2) and Stitcher

(http://www.stitcher.com/podcast/scaleyourcode?refid=stpr)

Thanks for reading, and please let me know if you have any feedback!

- Christophe Limpalair (@ScaleYourCode)