ilya grigorik interview on scaleyourcode...view original post ilya grigorik interview on...
TRANSCRIPT
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)