Web Performance
The ultimate guide to HTTP resource prioritization
How to make sure your data arrives at the browser in the optimal order
Come learn about how browsers try to guess in what order web page resources should be loaded and how servers use that information to often (accidentally) make your web page slower instead.
We look at what resource prioritization is, how it's often implemented terribly in modern HTTP/2 stacks and how we're trying to fix it in QUIC and HTTP/3.
We use clear visualizations and images to help explain the nuances in this complex topic and also muse a bit on whether prioritization actually has that large an impact on web performance.
HTTP/2 started the move from multiple parallel TCP connections to a single underlying pipe. QUIC and HTTP/3 continue that trend.
While this reduces the connection overhead and lets congestion controllers do their work, it also means we no longer send data in a truly parallel fashion.
As such, we need to be careful about how exactly we send our resource data, as some files are more important than others to achieve good web performance.
To help regulate this, HTTP/2 introduced a complex prioritization mechanism. Browsers use complex heuristics to try and estimate the importance of a resource and, with various success, communicate their preferences to the servers.
It has however become clear that this scheme does not work well in practice. Between server implementation bugs, questionable browser choices and bufferbloat in caches and network setups, HTTP/2 prioritization is sometimes more a liability than a useful feature.
For this reason, this feature is being completely reworked in HTTP/3 over QUIC. However, there a whole new can of worms is opened.
One of QUIC's main features for improving performance over TCP is that it removes "head of line blocking": if one resource suffers packet loss, other can still make progress.
That is... if there are other resources in progress! What performs well for lossy links turns out to be exactly what to prevent for high speed connections.
Along the way, we also discuss existing options for web developers to impact the browser's heuristics and server behaviour (such as resource hints (e.g., preload) and the upcoming priority hints).
Finally, we question about how we got in this terrible state of things to begin with: if people made so many mistakes implementing HTTP/2 prioritization, why didn't anyone really notice until 3 years later?
Could it be its impact on web performance is actually limited? Or have we just not seen its full potential yet?
We make this complex topic approachable with plenty of visualizations and animations.
The content is mainly based on our own research (and papers) and that of others in the web community, such as Patrick Meenan and Andy Davies.
Additional information
| Type | devroom |
|---|
More sessions
| 2/1/20 |
Boomerang is an open-source Real User Monitoring (RUM) JavaScript library used by thousands of websites to measure their visitor's experiences. The developers behind Boomerang take pride in building a reliable and performant third-party library that everyone can use without being concerned about its measurements affecting their site. We recently performed and shared an audit of Boomerang's performance, to help communicate its "cost of doing business", and in doing so we found several areas of ...
|
| 2/1/20 |
The World Wide Web is still among the most prominent Internet applications. While the Web landscape has been in perpetual movement since the very beginning, these last few years have witnessed some noteworthy proposals such as SPDY, HTTP/2 and QUIC, which profoundly reshape the application-layer protocols family. To measure the impact of such changes, going beyond the classic W3C notion of page load time, a number of Web performance metrics has been proposed (such as SpeedIndex, Above-The-Fold ...
|
| 2/1/20 |
We all love fonts. From Google Fonts to Typekit, Hoefler&Co and more, they give character and tone to our websites. The down side of fonts is that they can really slow down our loads. In this talk we'll learn about common pitfalls like critical requests depth and how to use resource hints to play tricks with latency to load web applications faster. We'll walk through a network profile to understand what's going on in the browser and how to make it faster.
|
| 2/1/20 |
Adding new web performance APIs to the web is a complex process. In this talk, I'll go over the steps we went through to ship the Element Timing API in Chromium, which enables measuring rendering timing of image and text content. You'll learn about the process to ship an API exposing performance information to web developers. There were many steps involved in the process: engaging with developers and other browser vendors, brainstorming, privacy and security reviews, Origin Trials, posting an ...
|
| 2/1/20 |
Keeping track caring about web performance is hard with constantly changing standards, improving browsers, frameworks and devices. It gets even harder when you develop a tool meeting these changing requirements. Eight years ago, as an IT service provider, we were faced with the task of permanently monitoring the performance of one of the largest e-commerce platforms. After the initial use of WebPagetest, we quickly needed to develop our own features. What started as minor extensions became a ...
|
