Ilya Grigorik on web.dev

Reduce web font size

2019-08-16T00:00:00Z

Typography is fundamental to good design, branding, readability, and accessibility. Web fonts enable all of the above and more: the text is selectable, searchable, zoomable, and high-DPI friendly, providing consistent and sharp text rendering regardless of the screen size and resolution. WebFonts are critical to good design, UX, and performance.

Web font optimization is a critical piece of the overall performance strategy. Each font is an additional resource, and some fonts may block rendering of the text, but just because the page is using WebFonts doesn't mean that it has to render slower. On the contrary, optimized fonts, combined with a judicious strategy for how they are loaded and applied on the page, can help reduce the total page size and improve page rendering times.

Anatomy of a web font #

A web font is a collection of glyphs, and each glyph is a vector shape that describes a letter or symbol. As a result, two simple variables determine the size of a particular font file: the complexity of the vector paths of each glyph and the number of glyphs in a particular font. For example, Open Sans, which is one of the most popular WebFonts, contains 897 glyphs, which include Latin, Greek, and Cyrillic characters.

When picking a font, it's important to consider which character sets are supported. If you need to localize your page content to multiple languages, you should use a font that can deliver a consistent look and experience to your users. For example, Google's Noto font family aims to support all the world's languages. Note, however, that the total size of Noto, with all languages included, results in a 1.1GB+ ZIP download.

In this post you will find out how to reduce the delivered filesize of your web fonts.

Web font formats #

Today there are two recommeded font container formats in use on the web:

WOFF and WOFF 2.0 enjoy wide support and are supported by all modern browsers.

Serve WOFF 2.0 variant to modern browsers.
If absolutely necessary—such as if you still need to support Internet Explorer 11, for example—serve the WOFF as a fallback.
Alternatively, consider not using web fonts for legacy browsers and falling back to the system fonts. This may be more performant for older, more constrained, devices as well.
Since WOFF and WOFF 2.0 cover all bases for modern and legacy browsers still in use, use of EOT and TTF are no longer necessary and can result in longer web font download times.

Web fonts and compression #

Both WOFF and WOFF 2.0 have built-in compression. WOFF 2.0's internal compression uses Brotli, and offers up to 30% better compression than WOFF. For more information, see the WOFF 2.0 evaluation report.

Finally, it's worth noting that some font formats contain additional metadata, such as font hinting and kerning information that may not be necessary on some platforms, which allows for further file-size optimization. For example, Google Fonts maintains 30+ optimized variants for each font and automatically detects and delivers the optimal variant for each platform and browser.

Define a font family with `@font-face` #

The @font-face CSS at-rule allows you to define the location of a particular font resource, its style characteristics, and the Unicode codepoints for which it should be used. A combination of such @font-face declarations can be used to construct a "font family," which the browser will use to evaluate which font resources need to be downloaded and applied to the current page.

Consider a variable font #

Variable fonts can significantly reduce the filesize of your fonts in cases where you need multiple variants of a font. Instead of needing to load the regular and bold styles plus their italic versions, you can load a single file that contains all of the information. However, variable font file sizes will be larger than an individual font variant—though smaller than the combination of many variants. Rather than one large variable font, it may be better to serve critical font variants first, with other variants downloaded later.

Variable fonts are now supported by all modern browsers, find out more in the Introduction to variable fonts on the web.

Select the right format #

Each @font-face declaration provides the name of the font family, which acts as a logical group of multiple declarations, font properties such as style, weight, and stretch, and the src descriptor, which specifies a prioritized list of locations for the font resource.

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome.woff2') format('woff2'),
       /* Only serve WOFF if necessary. Otherwise,
          WOFF 2.0 is fine by itself. */
       url('/fonts/awesome.woff') format('woff');
}

@font-face {
  font-family: 'Awesome Font';
  font-style: italic;
  font-weight: 400;
  src: local('Awesome Font Italic'),
       url('/fonts/awesome-i.woff2') format('woff2'),
       url('/fonts/awesome-i.woff') format('woff');
}

First, note that the above examples define a single Awesome Font family with two styles (normal and italic), each of which points to a different set of font resources. In turn, each src descriptor contains a prioritized, comma-separated list of resource variants:

The local() directive allows you to reference, load, and use locally installed fonts. If the user already has the font installed on their system, this bypasses the network entirely, and is the fastest.
The url() directive allows you to load external fonts, and are allowed to contain an optional format() hint indicating the format of the font referenced by the provided URL.

When the browser determines that the font is needed, it iterates through the provided resource list in the specified order and tries to load the appropriate resource. For example, following the example above:

The browser performs page layout and determines which font variants are required to render the specified text on the page. Fonts that aren't part of the page's CSS Object Model (CSSOM) are not downloaded by the browser, as they are not required.
For each required font, the browser checks if the font is available locally.
If the font is not available locally, the browser iterates over external definitions:

If a format hint is present, the browser checks if it supports the hint before initiating the download. If the browser doesn't support the hint, the browser advances to the next one.
If no format hint is present, the browser downloads the resource.

The combination of local and external directives with appropriate format hints allows you to specify all of the available font formats and let the browser handle the rest. The browser determines which resources are required and selects the optimal format.

Unicode-range subsetting #

In addition to font properties such as style, weight, and stretch, the @font-face rule allows you to define a set of Unicode codepoints supported by each resource. This enables you to split a large Unicode font into smaller subsets (for example, Latin, Cyrillic, and Greek subsets) and only download the glyphs required to render the text on a particular page.

The unicode-range descriptor allows you to specify a comma-delimited list of range values, each of which can be in one of three different forms:

Single codepoint (for example, U+416)
Interval range (for example, U+400-4ff): indicates the start and end codepoints of a range
Wildcard range (for example, U+4??): ? characters indicate any hexadecimal digit

For example, you can split your Awesome Font family into Latin and Japanese subsets, each of which the browser downloads on an as-needed basis:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-jp.woff2') format('woff2');
  /* Japanese glyphs */
  unicode-range: U+3000-9FFF, U+ff??;
}

The use of Unicode range subsets and separate files for each stylistic variant of the font allows you to define a composite font family that is both faster and more efficient to download. Visitors only download the variants and subsets they need, and they aren't forced to download subsets that they may never see or use on the page.

Nearly all browsers support unicode-range. For compatibility with older browsers you may need to fall back to "manual subsetting". In this case you have to fall back to providing a single font resource that contains all the necessary subsets and hide the rest from the browser. For example, if the page is only using Latin characters, then you can strip other glyphs and serve that particular subset as a standalone resource.

Determine which subsets are needed:
- If the browser supports unicode-range subsetting, then it will automatically select the right subset. The page just needs to provide the subset files and specify appropriate unicode-ranges in the @font-face rules.
- If the browser doesn't support unicode-range subsetting, then the page needs to hide all unnecessary subsets; that is, the developer must specify the required subsets.
Generate font subsets:
- Use the open-source pyftsubset tool to subset and optimize your fonts.
- Some font servers—such as Google Font—will automatically subset by default.
- Some font services allow manual subsetting via custom query parameters, which you can use to manually specify the required subset for your page. Consult the documentation from your font provider.

Font selection and synthesis #

Each font family may be composed of multiple stylistic variants (regular, bold, italic) and multiple weights for each style. Each of which, in turn, may contain very different glyph shapes—for example, different spacing, sizing, or a different shape altogether.

The above diagram illustrates a font family that offers three different bold weights:

400 (regular).
700 (bold).
900 (extra bold).

All other in-between variants (indicated in gray) are automatically mapped to the closest variant by the browser.

When a weight is specified for which no face exists, a face with a nearby weight is used. In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights.
CSS font matching algorithm

Similar logic applies to italic variants. The font designer controls which variants they will produce, and you control which variants you'll use on the page. Because each variant is a separate download, it's a good idea to keep the number of variants small. For example, you can define two bold variants for the Awesome Font family:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 700;
  src: local('Awesome Font'),
       url('/fonts/awesome-l-700.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

The above example declares the Awesome Font family that is composed of two resources that cover the same set of Latin glyphs (U+000-5FF) but offer two different "weights": normal (400) and bold (700). However, what happens if one of your CSS rules specifies a different font weight, or sets the font-style property to italic?

If an exact font match isn't available, the browser substitutes the closest match.
If no stylistic match is found (for example, no italic variants were declared in the example above), then the browser synthesizes its own font variant.

The example above illustrates the difference between the actual vs. synthesized font results for Open Sans. All synthesized variants are generated from a single 400-weight font. As you can see, there's a noticeable difference in the results. The details of how to generate the bold and oblique variants are not specified. Therefore, the results vary from browser to browser, and are highly dependent on the font.

Web font size optimization checklist #

Audit and monitor your font use: don't use too many fonts on your pages, and, for each font, minimize the number of used variants. This helps produce a more consistent and a faster experience for your users.
Avoid legacy formats if possible: EOT, TTF, and WOFF formats are larger than WOFF 2.0. EOT and TTF are strictly unnecessary formats, where as WOFF may be acceptable if you need to support Internet Explorer 11. If you're only target modern browsers, using WOFF 2.0 only is the simplest and most performant option.
Subset your font resources: many fonts can be subset, or split into multiple unicode-ranges to deliver just the glyphs that a particular page requires. This reduces the file size and improves the download speed of the resource. However, when defining the subsets, be careful to optimize for font re-use. For example, don't download a different but overlapping set of characters on each page. A good practice is to subset based on script: for example, Latin, and Cyrillic.
Give precedence to local() in your src list: listing local('Font Name') first in your src list ensures that HTTP requests aren't made for fonts that are already installed.
Use Lighthouse to test for text compression.

Effects on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) #

Depending on your page's content, text nodes can be considered candidates for Largest Contentful Paint (LCP). It's therefore vital to ensure your web fonts are as small as possible by following the advice in this article so that your users will see the text on your page as soon as they possibly can.

If you're concerned that, despite your optimization efforts, page text might take too long to appear because of large web font resource, the font-display property has a number of settings that can help you to avoid invisible text while a font is downloading. However, using the swap value may cause significant layout shifts that affect your site's Cumulative Layout Shift (CLS). Consider using the optional or fallback values if possible.

If your web fonts are crucial to your branding—and by extension, the user experience— consider preloading your fonts so that the browser has a head start on requesting them. This can reduce both the swap period if you use font-display: swap, or the blocking period if you're not using font-display.

Optimize WebFont loading and rendering

2019-08-16T00:00:00Z

A "full" WebFont that includes all stylistic variants, which you may not need, plus all the glyphs, which may go unused, can easily result in a multi-megabyte download. In this post you will find out how to optimize loading of WebFonts so visitors only download what they will use.

To address the problem of large files containing all variants, the @font-face CSS rule is specifically designed to allow you to split the font family into a collection of resources. For example unicode subsets, and distinct style variants.

Given these declarations, the browser figures out the required subsets and variants and downloads the minimal set required to render the text, which is very convenient. However, if you're not careful, it can also create a performance bottleneck in the critical rendering path and delay text rendering.

The default behavior #

Lazy loading of fonts carries an important hidden implication that may delay text rendering. The browser must construct the render tree, which is dependent on the DOM and CSSOM trees, before it knows which font resources it needs to render the text. As a result, font requests are delayed well after other critical resources, and the browser may be blocked from rendering text until the resource is fetched.

The browser requests the HTML document.
The browser begins parsing the HTML response and constructing the DOM.
The browser discovers CSS, JS, and other resources and dispatches requests.
The browser constructs the CSSOM after all of the CSS content is received and combines it with the DOM tree to construct the render tree.
- Font requests are dispatched after the render tree indicates which font variants are needed to render the specified text on the page.
The browser performs layout and paints content to the screen.
- If the font is not yet available, the browser may not render any text pixels.
- After the font is available, the browser paints the text pixels.

The "race" between the first paint of page content, which can be done shortly after the render tree is built, and the request for the font resource is what creates the "blank text problem" where the browser might render page layout but omits any text.

By preloading WebFonts and using font-display to control how browsers behave with unavailable fonts, you can prevent blank pages and layout shifts due to font loading.

Preload your WebFont resources #

If there's a high probability that your page will need a specific WebFont hosted at a URL you know in advance, you can take advantage of resource prioritization. Using <link rel="preload"> will trigger a request for the WebFont early in the critical rendering path, without having to wait for the CSSOM to be created.

Customize the text rendering delay #

While preloading makes it more likely that a WebFont will be available when a page's content is rendered, it offers no guarantees. You still need to consider how browsers behave when rendering text that uses a font-family which is not yet available.

In the post Avoid invisible text during font loading you can see that default browser behavior is not consistent. However, you can tell modern browsers how you want them to behave by using font-display.

Browser support

Chrome 60, Supported 60
Firefox 58, Supported 58
Edge 79, Supported 79
Safari 11.1, Supported 11.1

Source

Similar to the existing font timeout behaviors that some browsers implement, font-display segments the lifetime of a font download into three major periods:

The first period is the font block period. During this period, if the font face is not loaded, any element attempting to use it must instead render with an invisible fallback font face. If the font face successfully loads during the block period, the font face is then used normally.
The font swap period occurs immediately after the font block period. During this period, if the font face is not loaded, any element attempting to use it must instead render with a fallback font face. If the font face successfully loads during the swap period, the font face is then used normally.
The font failure period occurs immediately after the font swap period. If the font face is not yet loaded when this period starts, it's marked as a failed load, causing normal font fallback. Otherwise, the font face is used normally.

Understanding these periods means you can use font-display to decide how your font should render depending on whether or when it was downloaded.

To work with the font-display property, add it to your @font-face rules:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  font-display: auto; /* or block, swap, fallback, optional */
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2'), /* will be preloaded */
       url('/fonts/awesome-l.woff') format('woff'),
       url('/fonts/awesome-l.ttf') format('truetype'),
       url('/fonts/awesome-l.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

font-display currently supports the following range of values:

auto
block
swap
fallback
optional

For more information on preloading fonts, and the font-display property, see the following posts:

The Font Loading API #

Used together, <link rel="preload"> and the CSS font-display give you a great deal of control over font loading and rendering, without adding in much overhead. But if you need additional customizations, and are willing to incur the overhead introduced by running JavaScript, there is another option.

The Font Loading API provides a scripting interface to define and manipulate CSS font faces, track their download progress, and override their default lazyload behavior. For example, if you're sure that a particular font variant is required, you can define it and tell the browser to initiate an immediate fetch of the font resource:

Browser support

Chrome 35, Supported 35
Firefox 41, Supported 41
Edge 79, Supported 79
Safari 10, Supported 10

Source

var font = new FontFace("Awesome Font", "url(/fonts/awesome.woff2)", {
  style: 'normal', unicodeRange: 'U+000-5FF', weight: '400'
});

// don't wait for the render tree, initiate an immediate fetch!
font.load().then(function() {
  // apply the font (which may re-render text and cause a page reflow)
  // after the font has finished downloading
  document.fonts.add(font);
  document.body.style.fontFamily = "Awesome Font, serif";

  // OR... by default the content is hidden,
  // and it's rendered after the font is available
  var content = document.getElementById("content");
  content.style.visibility = "visible";

  // OR... apply your own render strategy here...
});

Further, because you can check the font status (via the check()) method and track its download progress, you can also define a custom strategy for rendering text on your pages:

You can hold all text rendering until the font is available.
You can implement a custom timeout for each font.
You can use the fallback font to unblock rendering and inject a new style that uses the desired font after the font is available.

Best of all, you can also mix and match the above strategies for different content on the page. For example, you can delay text rendering on some sections until the font is available, use a fallback font, and then re-render after the font download has finished.

Proper caching is a must #

Font resources are, typically, static resources that don't see frequent updates. As a result, they are ideally suited for a long max-age expiry— ensure that you specify both a conditional ETag header, and an optimal Cache-Control policy for all font resources.

If your web application uses a service worker, serving font resources with a cache-first strategy is appropriate for most use cases.

You should not store fonts using localStorage or IndexedDB; each of those has its own set of performance issues. The browser's HTTP cache provides the best and most robust mechanism to deliver font resources to the browser.

WebFont loading checklist #

Customize font loading and rendering using <link rel="preload">, font-display, or the Font Loading API: default lazyloading behavior may result in delayed text rendering. These web platform features allow you to override this behavior for particular fonts, and to specify custom rendering and timeout strategies for different content on the page.
Specify revalidation and optimal caching policies: fonts are static resources that are infrequently updated. Make sure that your servers provide a long-lived max-age timestamp and a revalidation token to allow for efficient font reuse between different pages. If using a service worker, a cache-first strategy is appropriate.

Automated testing for WebFont loading behavior with Lighthouse #

Lighthouse can help automate the process of making sure that you're following web font optimization best practices.

The following audits can help you make sure that your pages are continuing to follow web font optimization best practices over time:

Prevent unnecessary network requests with the HTTP Cache

2018-11-05T00:00:00Z

Fetching resources over the network is both slow and expensive:

Large responses require many roundtrips between the browser and the server.
Your page won't load until all of its critical resources have downloaded completely.
If a person is accessing your site with a limited mobile data plan, every unnecessary network request is a waste of their money.

How can you avoid unnecessary network requests? The browser's HTTP Cache is your first line of defense. It's not necessarily the most powerful or flexible approach, and you have limited control over the lifetime of cached responses, but it's effective, it's supported in all browsers, and it doesn't require much work.

This guide shows you the basics of an effective HTTP caching implementation.

Browser compatibility #

There isn't actually a single API called the HTTP Cache. It's the general name for a collection of web platform APIs. Those APIs are supported in all browsers:

How the HTTP Cache works #

All HTTP requests that the browser makes are first routed to the browser cache to check whether there is a valid cached response that can be used to fulfill the request. If there's a match, the response is read from the cache, which eliminates both the network latency and the data costs that the transfer incurs.

The HTTP Cache's behavior is controlled by a combination of request headers and response headers. In an ideal scenario, you'll have control over both the code for your web application (which will determine the request headers) and your web server's configuration (which will determine the response headers).

Check out MDN's HTTP Caching article for a more in-depth conceptual overview.

Request headers: stick with the defaults (usually) #

While there are a number of important headers that should be included in your web app's outgoing requests, the browser almost always takes care of setting them on your behalf when it makes requests. Request headers that affect checking for freshness, like If-None-Match and If-Modified-Since just appear based on the browser's understanding of the current values in the HTTP Cache.

This is good news—it means that you can continue including tags like <img src="my-image.png"> in your HTML, and the browser automatically takes care of HTTP caching for you, without extra effort.

Response headers: configure your web server #

The part of the HTTP caching setup that matters the most is the headers that your web server adds to each outgoing response. The following headers all factor into effective caching behavior:

Cache-Control. The server can return a Cache-Control directive to specify how, and for how long, the browser and other intermediate caches should cache the individual response.
ETag. When the browser finds an expired cached response, it can send a small token (usually a hash of the file's contents) to the server to check if the file has changed. If the server returns the same token, then the file is the same, and there's no need to re-download it.
Last-Modified. This header serves the same purpose as ETag, but uses a time-based strategy to determine if a resource has changed, as opposed to the content-based strategy of ETag.

Some web servers have built-in support for setting those headers by default, while others leave the headers out entirely unless you explicitly configure them. The specific details of how to configure headers varies greatly depending on which web server you use, and you should consult your server's documentation to get the most accurate details.

To save you some searching, here are instructions on configuring a few popular web servers:

Leaving out the Cache-Control response header does not disable HTTP caching! Instead, browsers effectively guess what type of caching behavior makes the most sense for a given type of content. Chances are you want more control than that offers, so take the time to configure your response headers.

Which response header values should you use? #

There are two important scenarios that you should cover when configuring your web server's response headers.

Long-lived caching for versioned URLs #

How versioned URLs can help your caching strategy

Versioned URLs are a good practice because they make it easier to invalidate cached responses.

Suppose your server instructs browsers to cache a CSS file for 1 year (Cache-Control: max-age=31536000) but your designer just made an emergency update that you need to roll out immediately. How do you notify browsers to update the "stale" cached copy of the file? You can't, at least not without changing the URL of the resource. After the browser caches the response, the cached version is used until it's no longer fresh, as determined by max-age or expires, or until it is evicted from the cache for some other reason—for example, the user clearing their browser cache. As a result, different users might end up using different versions of the file when the page is constructed: users who just fetched the resource use the new version, while users who cached an earlier (but still valid) copy use an older version of its response. How do you get the best of both worlds: client-side caching and quick updates? You change the URL of the resource and force the user to download the new response whenever its content changes. Typically, you do this by embedding a fingerprint of the file, or a version number, in its filename—for example, style.x234dff.css.

When responding to requests for URLs that contain "fingerprint" or versioning information, and whose contents are never meant to change, add Cache-Control: max-age=31536000 to your responses.

Setting this value tells the browser that when it needs to load the same URL anytime over the next one year (31,536,000 seconds; the maximum supported value), it can immediately use the value in the HTTP Cache, without having to make a network request to your web server at all. That's great—you've immediately gained the reliability and speed that comes from avoiding the network!

Build tools like webpack can automate the process of assigning hash fingerprints to your asset URLs.

Server revalidation for unversioned URLs #

Unfortunately, not all of the URLs you load are versioned. Maybe you're not able to include a build step prior to deploying your web app, so you can't add hashes to your asset URLs. And every web application needs HTML files—those files are (almost!) never going to include versioning information, since no one will bother to use your web app if they need to remember that the URL to visit is https://example.com/index.34def12.html. So what can you do for those URLs?

This is one scenario in which you need to admit defeat. HTTP caching alone isn't powerful enough to avoid the network completely. (Don't worry—you'll soon learn about service workers, which will provide the support we need to swing the battle back in your favor.) But there are a few steps you can take to make sure that network requests are as quick and efficient as possible.

The following Cache-Control values can help you fine-tune where and how unversioned URLs are cached:

no-cache. This instructs the browser that it must revalidate with the server every time before using a cached version of the URL.
no-store. This instructs the browser and other intermediate caches (like CDNs) to never store any version of the file.
private. Browsers can cache the file but intermediate caches cannot.
public. The response can be stored by any cache.

Check out Appendix: Cache-Control flowchart to visualize the process of deciding which Cache-Control value(s) to use. Note also that Cache-Control can accept a comma-separated list of directives. See Appendix: Cache-Control examples.

Along with that, setting one of two additional response headers can also help: either ETag or Last-Modified. As mentioned in Response headers, ETag and Last-Modified both serve the same purpose: determining if the browser needs to re-download a cached file that has expired. ETag is the recommended approach because it's more accurate.

ETag example

Assume that 120 seconds have passed since the initial fetch and the browser has initiated a new request for the same resource. First, the browser checks the HTTP Cache and finds the previous response. Unfortunately, the browser can't use the previous response because the response has now expired. At this point, the browser could dispatch a new request and fetch the new full response. However, that's inefficient because if the resource hasn't changed, then there's no reason to download the same information that's already in the cache! That's the problem that validation tokens, as specified in the ETag header, are designed to solve. The server generates and returns an arbitrary token, which is typically a hash or some other fingerprint of the contents of the file. The browser doesn't need to know how the fingerprint is generated; it only needs to send it to the server on the next request. If the fingerprint is still the same, then the resource hasn't changed and the browser can skip the download.

By setting ETag or Last-Modified, you'll end up making the revalidation request much more efficient. They end up triggering the If-Modified-Since or If-None-Match request headers that were mentioned in Request headers.

When a properly configured web server sees those incoming request headers, it can confirm whether the version of the resource that the browser already has in its HTTP Cache matches the latest version on the web server. If there's a match, then the server can respond with a 304 Not Modified HTTP response, which is the equivalent of "Hey, keep using what you've already got!" There's very little data to transfer when sending this type of response, so it's usually much faster than having to actually send back a copy of the actual resource being requested.

The browser requests /file from the server and includes the If-None-Match header to instruct the server to only return the full file if the ETag of the file on the server doesn't match the browser's If-None-Match value. In this case, the 2 values did match, so the server returns a 304 Not Modified response with instructions on how much longer the file should be cached (Cache-Control: max-age=120).

Summary #

The HTTP Cache is an effective way to improve load performance because it reduces unnecessary network requests. It's supported in all browsers and doesn't take too much work to set up.

The following Cache-Control configurations are a good start:

Cache-Control: no-cache for resources that should be revalidated with the server before every use.
Cache-Control: no-store for resources that should never be cached.
Cache-Control: max-age=31536000 for versioned resources.

And the ETag or Last-Modified header can help you revalidate expired cache resources more efficiently.

Learn more #

If you're looking to go beyond the basics of using the Cache-Control header, check out Jake Archibald's Caching best practices & max-age gotchas guide.

See Love your cache for guidance on how to optimize your cache usage for return visitors.

Appendix: More tips #

If you have more time, here are further ways that you can optimize your usage of the HTTP Cache:

Use consistent URLs. If you serve the same content on different URLs, then that content will be fetched and stored multiple times.
Minimize churn. If part of a resource (such as a CSS file) updates frequently, whereas the rest of the file does not (such as library code), consider splitting the frequently updating code into a separate file and using a short duration caching strategy for the frequently updating code and a long caching duration strategy for the code that doesn't change often.
Check out the new stale-while-revalidate directive if some degree of staleness is acceptable in your Cache-Control policy.

Appendix: `Cache-Control` flowchart #

Appendix: `Cache-Control` examples #

`Cache-Control` value	Explanation
`max-age=86400`	The response can be cached by browsers and intermediary caches for up to 1 day (60 seconds x 60 minutes x 24 hours).
`private, max-age=600`	The response can be cached by the browser (but not intermediary caches) for up to 10 minutes (60 seconds x 10 minutes).
`public, max-age=31536000`	The response can be stored by any cache for 1 year.
`no-store`	The response is not allowed to be cached and must be fetched in full on every request.

Choose the right image format

2018-08-30T00:00:00Z

The very first question you should ask yourself is whether an image is, in fact, required to achieve the effect you are after. Good design is simple and will also always yield the best performance. If you can eliminate an image resource, which often requires a large number of bytes relative to HTML, CSS, JavaScript and other assets on the page, then that is always the best optimization strategy. That said, a well-placed image can also communicate more information than a thousand words, so it is up to you to find that balance.

Next, you should consider if there is an alternative technology that could deliver the desired results, but in a more efficient manner:

CSS effects (such as shadows or gradients) and CSS animations can be used to produce resolution-independent assets that always look sharp at every resolution and zoom level, often at a fraction of the bytes required by an image file.
Web fonts enable use of beautiful typefaces while preserving the ability to select, search, and resize text—a significant improvement in usability.

If you ever find yourself encoding text in an image asset, stop and reconsider. Great typography is critical to good design, branding, and readability, but text-in-images delivers a poor user experience: the text is not selectable, not searchable, not zoomable, not accessible, and not friendly for high-DPI devices. The use of web fonts requires its own set of optimizations, but it addresses all of these concerns and is always a better choice for displaying text.

Choose the right image format #

If you are sure an image is the correct option, you should carefully select the right kind of image for the job.

Zoomed-in vector image (L) raster image (R)

Vector graphics use lines, points, and polygons to represent an image.
Raster graphics represent an image by encoding the individual values of each pixel within a rectangular grid.

Each format has its own set of pros and cons. Vector formats are ideally suited for images that consist of simple geometric shapes such as logos, text, or icons. They deliver sharp results at every resolution and zoom setting, which makes them an ideal format for high-resolution screens and assets that need to be displayed at varying sizes.

However, vector formats fall short when the scene is complicated (for example, a photo): the amount of SVG markup to describe all the shapes can be prohibitively high and the output may still not look "photorealistic". When that's the case, that's when you should be using a raster image format such as PNG, JPEG, WebP, or AVIF.

Raster images do not have the same nice properties of being resolution or zoom independent —when you scale up a raster image you'll see jagged and blurry graphics. As a result, you may need to save multiple versions of a raster image at various resolutions to deliver the optimal experience to your users.

Implications of high-resolution screens #

There are two different kinds of pixels: CSS pixels and device pixels. A single CSS pixel may correspond directly to a single device pixel, or may be backed by multiple device pixels. What's the point? Well, the more device pixels there are, the finer the detail of the displayed content on the screen.

The difference between CSS pixels and device pixels.

High DPI (HiDPI) screens produce beautiful results, but there is one obvious tradeoff: image assets require more detail to take advantage of the higher device pixel counts. The good news is, vector images are ideally suited for this task, as they can be rendered at any resolution with sharp results— you might incur a higher processing cost to render the finer detail, but the underlying asset is the same and is resolution independent.

On the other hand, raster images pose a much larger challenge because they encode image data on a per-pixel basis. Hence, the larger the number of pixels, the larger the filesize of a raster image. As an example, let's consider the difference between a photo asset displayed at 100x100 (CSS) pixels:

Screen resolution	Total pixels	Uncompressed filesize (4 bytes per pixel)
1x	100 x 100 = 10,000	40,000 bytes
2x	100 x 100 x 4 = 40,000	160,000 bytes
3x	100 x 100 x 9 = 90,000	360,000 bytes

When we double the resolution of the physical screen, the total number of pixels increases by a factor of four: double the number of horizontal pixels, times double the number of vertical pixels. Hence, a "2x" screen not just doubles, but quadruples the number of required pixels!

So, what does this mean in practice? High-resolution screens enable you to deliver beautiful images, which can be a great product feature. However, high-resolution screens also require high-resolution images, therefore:

Prefer vector images whenever possible as they are resolution-independent and always deliver sharp results.
If a raster image is required, serve responsive images.

Features of different raster image formats #

In addition to different lossy and lossless compression algorithms, different image formats support different features such as animation and transparency (alpha) channels. As a result, the choice of the "right format" for a particular image is a combination of desired visual results and functional requirements.

Format	Transparency	Animation	Browser
PNG	Yes	No	All
JPEG	No	No	All
WebP	Yes	Yes	All modern browsers. See Can I use?
AVIF	Yes	Yes	No. See Can I use?

There are two universally supported raster image formats: PNG and JPEG. In addition to these formats, modern browsers support the newer format WebP, while only some support the newer AVIF format. Both of the newer formats offer better overall compression and more features. So, which format should you use?

WebP and AVIF will generally provide better compression than older formats, and should be used where possible. You can use WebP or AVIF images along with a JPEG or PNG image as a fallback. See Use WebP images for more details.

In terms of older image formats, consider the following:

Do you need animation? Use <video> elements.
- What about GIF? GIF limits the color palette to at most 256 colors, and creates significantly larger file sizes than <video> elements. See Replace animated GIFs with video.
Do you need to preserve fine detail with highest resolution? Use PNG or lossless WebP.
- PNG does not apply any lossy compression algorithms beyond the choice of the size of the color palette. As a result, it will produce the highest quality image, but at a cost of significantly higher filesize than other formats. Use judiciously.
- WebP has a lossless encoding mode that may be more efficient than PNG.
- If the image asset contains imagery composed of geometric shapes, consider converting it to a vector (SVG) format!
- If the image asset contains text, stop and reconsider. Text in images is not selectable, searchable, or "zoomable". If you need to convey a custom look (for branding or other reasons), use a web font instead.
Are you optimizing a photo, screenshot, or a similar image asset? Use JPEG, lossy WebP, or lossy AVIF.
- JPEG uses a combination of lossy and lossless optimization to reduce filesize of the image asset. Try several JPEG quality levels to find the best quality versus filesize tradeoff for your asset.
- Lossy WebP or lossy AVIF may be acceptable JPEG alternatives, but be aware that WebP's lossy mode in particular discards some chroma information to achieve smaller images. This means that select colors may not be the same as an equivalent JPEG.

Finally, note that if you are using a WebView to render content in your platform-specific application, then you have full control of the client and can use WebP exclusively! Facebook and many others use WebP to deliver all of their images within their applications— the savings are definitely worth it.

Impact on Largest Contentful Paint (LCP) #

Images may be LCP candidates. That means the size of an image affects its load time. When an image is an LCP candidate, efficiently encoding that image is crucial to improving LCP.

You should strive to apply the advice given in this article so that the perceptual performance of a page is as fast as it can possibly be for all users. LCP is part of perceptual performance, as it measures how fast the largest (and therefore most perceivable) element on the page displays.

Choose the correct level of compression

2018-08-30T00:00:00Z

Images often account for most of the downloaded bytes on a web page and also often occupy a significant amount of visual space. As a result, optimizing images can often yield some of the largest byte savings and performance improvements for your website: the fewer bytes the browser has to download, the less competition there is for the client's bandwidth and the faster the browser can download and render useful content on the screen.

Image optimization is both an art and science: an art because there is no one definitive answer for how best to compress an individual image, and a science because there are many well developed techniques and algorithms that can significantly reduce the size of an image. Finding the optimal settings for your image requires careful analysis along many dimensions: format capabilities, content of encoded data, quality, pixel dimensions, and more.

Optimizing vector images #

All modern browsers support Scalable Vector Graphics (SVG), which is an XML-based image format for two-dimensional graphics. You can embed the SVG markup directly on the page or as an external resource. Most vector-based drawing software can create SVG files or you can write them by hand directly in your favorite text editor.

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px" viewBox="0 0 612 792" xml:space="preserve">
<g id="XMLID_1_">
  <g>
    <circle fill="red" stroke="black" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/>
  </g>
</g>
</svg>

The above example renders the below simple circle shape with a black outline and red background and was exported from Adobe Illustrator.

As you can tell, it contains a lot of metadata, such as layer information, comments, and XML namespaces that are often unnecessary to render the asset in the browser. As a result, it is always a good idea to minify your SVG files by running through a tool like SVGO.

Case in point, SVGO reduces the size of the above SVG file generated by Illustrator by 58%, taking it from 470 to 199 bytes.

<svg version="1.2" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 612 792"><circle fill="red" stroke="#000" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/></svg>

Because SVG is an XML-based format, you can also apply GZIP compression to reduce its transfer size—make sure your server is configured to compress SVG assets!

A raster image is simply a two-dimensional grid of individual "pixels"—for example, a 100x100 pixel image is a sequence of 10,000 pixels. In turn, each pixel stores the "RGBA" values: (R) red channel, (G) green channel, (B) blue channel, and (A) alpha (transparency) channel.

Internally, the browser allocates 256 values (shades) for each channel, which translates to 8 bits per channel (2 ^ 8 = 256), and 4 bytes per pixel (4 channels x 8 bits = 32 bits = 4 bytes). As a result, if we know the dimensions of the grid we can easily calculate the filesize:

100x100 pixel image is composed of 10,000 pixels
10,000 pixels x 4 bytes = 40,000 bytes
40,000 bytes / 1024 = 39 KB

Dimensions	Pixels	File size
100 x 100	10,000	39 KB
200 x 200	40,000	156 KB
300 x 300	90,000	351 KB
500 x 500	250,000	977 KB
800 x 800	640,000	2500 KB

39 KB for a 100x100 pixel image may not seem like a big deal, but the filesize quickly explodes for larger images and makes image assets both slow and expensive to download. This post has so far only focused on the "uncompressed" image format. Thankfully, a lot can be done to reduce the image file size.

One simple strategy is to reduce the "bit-depth" of the image from 8 bits per channel to a smaller color palette: 8 bits per channel gives us 256 values per channel and 16,777,216 (256 ^ 3) colors in total. What if you reduce the palette to 256 colors? Then you would only need 8 bits in total for the RGB channels and immediately save two bytes per pixel—that's 50% compression savings over the original 4 bytes per pixel format!

Left to right (PNG): 32-bit (16M colors), 7-bit (128 colors), 5-bit (32 colors).

Complex scenes with gradual color transitions (for example, gradients or sky) require larger color palettes to avoid visual artifacts such as the pixelated sky in the 5-bit asset. On the other hand, if the image only uses a few colors, then a large palette is simply wasting precious bits!

Next, once you've optimized the data stored in individual pixels you could get more clever and look at nearby pixels as well: turns out, many images, and especially photos, have many nearby pixels with similar colors— for example, the sky, repeating textures, and so on. Using this information to your advantage the compressor can apply delta encoding where instead of storing the individual values for each pixel, you can store the difference between nearby pixels: if the adjacent pixels are the same, then the delta is "zero" and you only need to store a single bit! But why stop there…

The human eye has different level of sensitivity to different colors: you can optimize your color encoding to account for this by reducing or increasing the palette for those colors. "Nearby" pixels form a two-dimensional grid. This means that each pixel has multiple neighbors: you can use this fact to further improve delta encoding. Instead of looking at just the immediate neighbors for each pixel, you can look at larger blocks of nearby pixels and encode different blocks with different settings.

As you can tell, image optimization gets complicated quickly (or fun, depending on your perspective), and is an active area of academic and commercial research. Images occupy a lot of bytes and there is a lot of value in developing better image compression techniques! If you're curious to learn more, head to the Wikipedia page, or check out the WebP compression techniques whitepaper for a hands-on example.

So, once again, this is all great, but also very academic: how does it help you to optimize images on your site? Well, it's important to understand the shape of the problem: RGBA pixels, bit-depth, and various optimization techniques. All of these concepts are critical to understand and keep in mind before you dive into the discussions of various raster image formats.

Lossless versus lossy image compression #

For certain types of data, such as source code for a page, or an executable file, it is critical that a compressor does not alter or lose any of the original information: a single missing or wrong bit of data could completely change the meaning of the contents of the file, or worse, break it entirely. For some other types of data, such as images, audio, and video, it may be perfectly acceptable to deliver an "approximate" representation of the original data.

In fact, due to how the eye works, we can often get away with discarding some information about each pixel in order to reduce the filesize of an image— for example, our eyes have different sensitivity to different colors, which means that we can use fewer bits to encode some colors. As a result, a typical image optimization pipeline consists of two high level steps:

Image is processed with a lossy filter that eliminates some pixel data.
Image is processed with a lossless filter that compresses the pixel data.

The first step is optional, and the exact algorithm will depend on the particular image format, but it is important to understand that any image can undergo a lossy compression step to reduce its size. In fact, the difference between various image formats, such as GIF, PNG, JPEG, and others, is in the combination of the specific algorithms they use (or omit) when applying the lossy and lossless steps.

So, what is the "optimal" configuration of lossy and lossless optimization? The answer depends on the image contents and your own criteria such as the tradeoff between filesize and artifacts introduced by lossy compression: In some cases, you may want to skip lossy optimization to communicate intricate detail in its full fidelity. In other cases, you may be able to apply aggressive lossy optimization to reduce the filesize of the image asset. This is where your own judgment and context need to come into play—there is no one universal setting.

As a hands-on example, when using a lossy format such as JPEG, the compressor will typically expose a customizable "quality" setting (for example, the quality slider provided by the "Save for Web" functionality in Adobe Photoshop), which is typically a number between 1 and 100 that controls the inner workings of the specific collection of lossy and lossless algorithms. For best results, experiment with various quality settings for your images, and don't be afraid to dial down the quality—the visual results are often very good and the filesize savings can be quite large.

Effects of image compression on Core Web Vitals #

Because images are often candidates for Largest Contentful Paint, reducing the resource load time of an image can translate into better LCP in both the lab and in the field.

When playing with compression settings on raster image formats, be sure to experiment with WebP and AVIF formats to see if you can deliver the same image in a small footprint as compared to older formats.

You want to be careful not to overcompress raster images, though. A good solution is to use an image optimization CDN to find the best compression settings for you, but an alternative may be to use tools like Butteraugli to estimate visual differences so that you don't encode images too aggressively and lose too much quality.

Image optimization checklist #

Some tips and techniques to keep in mind as you work on optimizing your images:

Prefer vector formats: vector images are resolution and scale independent, which makes them a perfect fit for the multi-device and high-resolution world.
Minify and compress SVG assets: XML markup produced by most drawing applications often contains unnecessary metadata which can be removed; Ensure that your servers are configured to apply GZIP compression for SVG assets.
Prefer WebP or AVIF over older raster formats: WebP and AVIF images will usually be far smaller than older image formats.
Pick best raster image format: determine your functional requirements and select the one that suits each particular asset.
Experiment with optimal quality settings for raster formats: don't be afraid to dial down the "quality" settings, the results are often very good and byte savings are significant.
Remove unnecessary image metadata: many raster images contain unnecessary metadata about the asset: geo information, camera information, and so on. Use appropriate tools to strip this data.
Serve scaled images: resize images and ensure that the "display" size is as close as possible to the "natural" size of the image. Pay close attention to large images in particular, as they account for largest overhead when resized!
Automate, automate, automate: invest into automated tools and infrastructure that will ensure that all of your image assets are always optimized.

PageSpeed Rules and Recommendations

2018-08-17T00:00:00Z

This guide examines PageSpeed Insights rules in context: what to pay attention to when optimizing the critical rendering path, and why.

Eliminate render-blocking JavaScript and CSS #

To deliver the fastest time to first render, minimize and (where possible) eliminate the number of critical resources on the page, minimize the number of downloaded critical bytes, and optimize the critical path length.

Optimize JavaScript use #

JavaScript resources are parser blocking by default unless marked as async or added via a special JavaScript snippet. Parser blocking JavaScript forces the browser to wait for the CSSOM and pauses construction of the DOM, which in turn can significantly delay the time to first render.

Prefer asynchronous JavaScript resources #

Asynchronous resources unblock the document parser and allow the browser to avoid blocking on CSSOM prior to executing the script. Often, if the script can use the async attribute, it also means it is not essential for the first render. Consider loading scripts asynchronously after the initial render.

Avoid synchronous server calls #

Use the navigator.sendBeacon() method to limit data sent by XMLHttpRequests in unload handlers. Because many browsers require such requests to be synchronous, they can slow page transitions, sometimes noticeably. The following code shows how to use navigator.sendBeacon() to send data to the server in the pagehide handler instead of in the unload handler.

    <script>
      function() {
        window.addEventListener('pagehide', logData, false);
        function logData() {
          navigator.sendBeacon(
            'https://putsreq.herokuapp.com/Dt7t2QzUkG18aDTMMcop',
            'Sent by a beacon!');
        }
      }();
    </script>

The new fetch() method provides an easy way to asynchronously request data. Because it is not available everywhere yet, you should use feature detection to test for its presence before use. This method processes responses with Promises rather than multiple event handlers. Unlike the response to an XMLHttpRequest, a fetch response is a stream object starting in Chrome 43. This means that a call to json() also returns a Promise.

    <script>
    fetch('./api/some.json')
      .then(
        function(response) {
          if (response.status !== 200) {
            console.log('Looks like there was a problem. Status Code: ' +  response.status);
            return;
          }
          // Examine the text in the response
          response.json().then(function(data) {
            console.log(data);
          });
        }
      )
      .catch(function(err) {
        console.log('Fetch Error :-S', err);
      });
    </script>

The fetch() method can also handle POST requests.

    <script>
    fetch(url, {
      method: 'post',
      headers: {
        "Content-type": "application/x-www-form-urlencoded; charset=UTF-8"
      },
      body: 'foo=bar&lorem=ipsum'
    }).then(function() { // Additional code });
    </script>

Defer parsing JavaScript #

To minimize the amount of work the browser has to perform to render the page, defer any non-essential scripts that are not critical to constructing the visible content for the initial render.

Avoid long running JavaScript #

Long running JavaScript blocks the browser from constructing the DOM, CSSOM, and rendering the page, so defer until later any initialization logic and functionality that is non-essential for the first render. If a long initialization sequence needs to run, consider splitting it into several stages to allow the browser to process other events in between.

Optimize CSS Use #

CSS is required to construct the render tree and JavaScript often blocks on CSS during initial construction of the page. Ensure that any non-essential CSS is marked as non-critical (for example, print and other media queries), and that the amount of critical CSS and the time to deliver it is as small as possible.

Put CSS in the document head #

Specify all CSS resources as early as possible within the HTML document so that the browser can discover the <link> tags and dispatch the request for the CSS as soon as possible.

Avoid CSS imports #

The CSS import (@import) directive enables one stylesheet to import rules from another stylesheet file. However, avoid these directives because they introduce additional roundtrips into the critical path: the imported CSS resources are discovered only after the CSS stylesheet with the @import rule itself is received and parsed.

Inline render-blocking CSS #

For best performance, you may want to consider inlining the critical CSS directly into the HTML document. This eliminates additional roundtrips in the critical path and if done correctly can deliver a "one roundtrip" critical path length where only the HTML is a blocking resource.

Feedback #

Introduction to HTTP/2

2016-09-29T00:00:00Z

HTTP/2 will make our applications faster, simpler, and more robust — a rare combination — by allowing us to undo many of the HTTP/1.1 workarounds previously done within our applications and address these concerns within the transport layer itself. Even better, it also opens up a number of entirely new opportunities to optimize our applications and improve performance!

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push. To implement these requirements, there is a large supporting cast of other protocol enhancements, such as new flow control, error handling, and upgrade mechanisms, but these are the most important features that every web developer should understand and leverage in their applications.

HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.

Why not HTTP/1.2? #

To achieve the performance goals set by the HTTP Working Group, HTTP/2 introduces a new binary framing layer that is not backward compatible with previous HTTP/1.x servers and clients—hence the major protocol version increment to HTTP/2.

That said, unless you are implementing a web server (or a custom client) by working with raw TCP sockets, then you won’t see any difference: all the new, low-level framing is performed by the client and server on your behalf. The only observable differences will be improved performance and availability of new capabilities like request prioritization, flow control, and server push.

A brief history of SPDY and HTTP/2 #

SPDY was an experimental protocol, developed at Google and announced in mid 2009, whose primary goal was to try to reduce the load latency of web pages by addressing some of the well-known performance limitations of HTTP/1.1. Specifically, the outlined project goals were set as follows:

Target a 50% reduction in page load time (PLT).
Avoid the need for any changes to content by website authors.
Minimize deployment complexity, and avoid changes in network infrastructure.
Develop this new protocol in partnership with the open-source community.
Gather real performance data to (in)validate the experimental protocol.

Not long after the initial announcement, Mike Belshe and Roberto Peon, both software engineers at Google, shared their first results, documentation, and source code for the experimental implementation of the new SPDY protocol:

So far we have only tested SPDY in lab conditions. The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance—pages loaded up to 55% faster. (Chromium Blog)

Fast-forward to 2012 and the new experimental protocol was supported in Chrome, Firefox, and Opera, and a rapidly growing number of sites, both large (for example, Google, Twitter, Facebook) and small, were deploying SPDY within their infrastructure. In effect, SPDY was on track to become a de facto standard through growing industry adoption.

Observing this trend, the HTTP Working Group (HTTP-WG) kicked off a new effort to take the lessons learned from SPDY, build and improve on them, and deliver an official "HTTP/2" standard. A new charter was drafted, an open call for HTTP/2 proposals was made, and after a lot of discussion within the working group, the SPDY specification was adopted as a starting point for the new HTTP/2 protocol.

Over the next few years SPDY and HTTP/2 continued to coevolve in parallel, with SPDY acting as an experimental branch that was used to test new features and proposals for the HTTP/2 standard. What looks good on paper may not work in practice, and vice versa, and SPDY offered a route to test and evaluate each proposal before its inclusion in the HTTP/2 standard. In the end, this process spanned three years and resulted in a over a dozen intermediate drafts:

March 2012: Call for proposals for HTTP/2
November 2012: First draft of HTTP/2 (based on SPDY)
August 2014: HTTP/2 draft-17 and HPACK draft-12 are published
August 2014: Working Group last call for HTTP/2
February 2015: IESG approved HTTP/2 and HPACK drafts
May 2015: RFC 7540 (HTTP/2) and RFC 7541 (HPACK) are published

In early 2015 the IESG reviewed and approved the new HTTP/2 standard for publication. Shortly after that, the Google Chrome team announced their schedule to deprecate SPDY and NPN extension for TLS:

HTTP/2's primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.

We’re happy to have contributed to the open standards process that led to HTTP/2, and hope to see wide adoption given the broad industry engagement on standardization and implementation. (Chromium Blog)

The coevolution of SPDY and HTTP/2 enabled server, browser, and site developers to gain real-world experience with the new protocol as it was being developed. As a result, the HTTP/2 standard is one of the best and most extensively tested standards right out of the gate. By the time HTTP/2 was approved by the IESG, there were dozens of thoroughly tested and production-ready client and server implementations. In fact, just weeks after the final protocol was approved, many users were already enjoying its benefits as several popular browsers (and many sites) deployed full HTTP/2 support.

Design and technical goals #

Earlier versions of the HTTP protocol were intentionally designed for simplicity of implementation: HTTP/0.9 was a one-line protocol to bootstrap the World Wide Web; HTTP/1.0 documented the popular extensions to HTTP/0.9 in an informational standard; HTTP/1.1 introduced an official IETF standard; see Brief History of HTTP. As such, HTTP/0.9-1.x delivered exactly what it set out to do: HTTP is one of the most widely adopted application protocols on the Internet.

Unfortunately, implementation simplicity also came at a cost of application performance: HTTP/1.x clients need to use multiple connections to achieve concurrency and reduce latency; HTTP/1.x does not compress request and response headers, causing unnecessary network traffic; HTTP/1.x does not allow effective resource prioritization, resulting in poor use of the underlying TCP connection; and so on.

These limitations were not fatal, but as the web applications continued to grow in their scope, complexity, and importance in our everyday lives, they imposed a growing burden on both the developers and users of the web, which is the exact gap that HTTP/2 was designed to address:

HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection… Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.

The resulting protocol is more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity. Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing. (Hypertext Transfer Protocol version 2, Draft 17)

It is important to note that HTTP/2 is extending, not replacing, the previous HTTP standards. The application semantics of HTTP are the same, and no changes were made to the offered functionality or core concepts such as HTTP methods, status codes, URIs, and header fields. These changes were explicitly out of scope for the HTTP/2 effort. That said, while the high-level API remains the same, it is important to understand how the low-level changes address the performance limitations of the previous protocols. Let’s take a brief tour of the binary framing layer and its features.

Binary framing layer #

At the core of all performance enhancements of HTTP/2 is the new binary framing layer, which dictates how the HTTP messages are encapsulated and transferred between the client and server.

The "layer" refers to a design choice to introduce a new optimized encoding mechanism between the socket interface and the higher HTTP API exposed to our applications: the HTTP semantics, such as verbs, methods, and headers, are unaffected, but the way they are encoded while in transit is different. Unlike the newline delimited plaintext HTTP/1.x protocol, all HTTP/2 communication is split into smaller messages and frames, each of which is encoded in binary format.

As a result, both client and server must use the new binary encoding mechanism to understand each other: an HTTP/1.x client won’t understand an HTTP/2 only server, and vice versa. Thankfully, our applications remain blissfully unaware of all these changes, as the client and server perform all the necessary framing work on our behalf.

Streams, messages, and frames #

The introduction of the new binary framing mechanism changes how the data is exchanged between the client and server. To describe this process, let’s familiarize ourselves with the HTTP/2 terminology:

Stream: A bidirectional flow of bytes within an established connection, which may carry one or more messages.
Message: A complete sequence of frames that map to a logical request or response message.
Frame: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs.

The relation of these terms can be summarized as follows:

All communication is performed over a single TCP connection that can carry any number of bidirectional streams.
Each stream has a unique identifier and optional priority information that is used to carry bidirectional messages.
Each message is a logical HTTP message, such as a request, or response, which consists of one or more frames.
The frame is the smallest unit of communication that carries a specific type of data—e.g., HTTP headers, message payload, and so on. Frames from different streams may be interleaved and then reassembled via the embedded stream identifier in the header of each frame.

In short, HTTP/2 breaks down the HTTP protocol communication into an exchange of binary-encoded frames, which are then mapped to messages that belong to a particular stream, all of which are multiplexed within a single TCP connection. This is the foundation that enables all other features and performance optimizations provided by the HTTP/2 protocol.

Request and response multiplexing #

With HTTP/1.x, if the client wants to make multiple parallel requests to improve performance, then multiple TCP connections must be used (see Using Multiple TCP Connections ). This behavior is a direct consequence of the HTTP/1.x delivery model, which ensures that only one response can be delivered at a time (response queuing) per connection. Worse, this also results in head-of-line blocking and inefficient use of the underlying TCP connection.

The new binary framing layer in HTTP/2 removes these limitations, and enables full request and response multiplexing, by allowing the client and server to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end.

The snapshot captures multiple streams in flight within the same connection. The client is transmitting a DATA frame (stream 5) to the server, while the server is transmitting an interleaved sequence of frames to the client for streams 1 and 3. As a result, there are three parallel streams in flight.

The ability to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end is the single most important enhancement of HTTP/2. In fact, it introduces a ripple effect of numerous performance benefits across the entire stack of all web technologies, enabling us to:

Interleave multiple requests in parallel without blocking on any one.
Interleave multiple responses in parallel without blocking on any one.
Use a single connection to deliver multiple requests and responses in parallel.
Remove unnecessary HTTP/1.x workarounds (see Optimizing for HTTP/1.x, such as concatenated files, image sprites, and domain sharding).
Deliver lower page load times by eliminating unnecessary latency and improving utilization of available network capacity.
And much more…

The new binary framing layer in HTTP/2 resolves the head-of-line blocking problem found in HTTP/1.x and eliminates the need for multiple connections to enable parallel processing and delivery of requests and responses. As a result, this makes our applications faster, simpler, and cheaper to deploy.

Stream prioritization #

Once an HTTP message can be split into many individual frames, and we allow for frames from multiple streams to be multiplexed, the order in which the frames are interleaved and delivered both by the client and server becomes a critical performance consideration. To facilitate this, the HTTP/2 standard allows each stream to have an associated weight and dependency:

Each stream may be assigned an integer weight between 1 and 256.
Each stream may be given an explicit dependency on another stream.

The combination of stream dependencies and weights allows the client to construct and communicate a "prioritization tree" that expresses how it would prefer to receive responses. In turn, the server can use this information to prioritize stream processing by controlling the allocation of CPU, memory, and other resources, and once the response data is available, allocation of bandwidth to ensure optimal delivery of high-priority responses to the client.

A stream dependency within HTTP/2 is declared by referencing the unique identifier of another stream as its parent; if the identifier is omitted the stream is said to be dependent on the "root stream". Declaring a stream dependency indicates that, if possible, the parent stream should be allocated resources ahead of its dependencies. In other words, "Please process and deliver response D before response C".

Streams that share the same parent (in other words, sibling streams) should be allocated resources in proportion to their weight. For example, if stream A has a weight of 12 and its one sibling B has a weight of 4, then to determine the proportion of the resources that each of these streams should receive:

Sum all the weights: 4 + 12 = 16
Divide each stream weight by the total weight: A = 12/16, B = 4/16

Thus, stream A should receive three-quarters and stream B should receive one- quarter of available resources; stream B should receive one-third of the resources allocated to stream A. Let’s work through a few more hands-on examples in the image above. From left to right:

Neither stream A nor B specifies a parent dependency and are said to be dependent on the implicit "root stream"; A has a weight of 12, and B has a weight of 4. Thus, based on proportional weights: stream B should receive one-third of the resources allocated to stream A.
Stream D is dependent on the root stream; C is dependent on D. Thus, D should receive full allocation of resources ahead of C. The weights are inconsequential because C’s dependency communicates a stronger preference.
Stream D should receive full allocation of resources ahead of C; C should receive full allocation of resources ahead of A and B; stream B should receive one-third of the resources allocated to stream A.
Stream D should receive full allocation of resources ahead of E and C; E and C should receive equal allocation ahead of A and B; A and B should receive proportional allocation based on their weights.

As the above examples illustrate, the combination of stream dependencies and weights provides an expressive language for resource prioritization, which is a critical feature for improving browsing performance where we have many resource types with different dependencies and weights. Even better, the HTTP/2 protocol also allows the client to update these preferences at any point, which enables further optimizations in the browser. In other words, we can change dependencies and reallocate weights in response to user interaction and other signals.

One connection per origin #

With the new binary framing mechanism in place, HTTP/2 no longer needs multiple TCP connections to multiplex streams in parallel; each stream is split into many frames, which can be interleaved and prioritized. As a result, all HTTP/2 connections are persistent, and only one connection per origin is required, which offers numerous performance benefits.

For both SPDY and HTTP/2 the killer feature is arbitrary multiplexing on a single well congestion controlled channel. It amazes me how important this is and how well it works. One great metric around that which I enjoy is the fraction of connections created that carry just a single HTTP transaction (and thus make that transaction bear all the overhead). For HTTP/1 74% of our active connections carry just a single transaction—persistent connections just aren’t as helpful as we all want. But in HTTP/2 that number plummets to 25%. That’s a huge win for overhead reduction. (HTTP/2 is Live in Firefox, Patrick McManus)

Most HTTP transfers are short and bursty, whereas TCP is optimized for long- lived, bulk data transfers. By reusing the same connection, HTTP/2 is able to both make more efficient use of each TCP connection, and also significantly reduce the overall protocol overhead. Further, the use of fewer connections reduces the memory and processing footprint along the full connection path (in other words, client, intermediaries, and origin servers). This reduces the overall operational costs and improves network utilization and capacity. As a result, the move to HTTP/2 should not only reduce network latency, but also help improve throughput and reduce the operational costs.

Flow control #

Flow control is a mechanism to prevent the sender from overwhelming the receiver with data it may not want or be able to process: the receiver may be busy, under heavy load, or may only be willing to allocate a fixed amount of resources for a particular stream. For example, the client may have requested a large video stream with high priority, but the user has paused the video and the client now wants to pause or throttle its delivery from the server to avoid fetching and buffering unnecessary data. Alternatively, a proxy server may have fast downstream and slow upstream connections and similarly wants to regulate how quickly the downstream delivers data to match the speed of upstream to control its resource usage; and so on.

Do the above requirements remind you of TCP flow control? They should, as the problem is effectively identical (see Flow Control). However, because the HTTP/2 streams are multiplexed within a single TCP connection, TCP flow control is both not granular enough, and does not provide the necessary application-level APIs to regulate the delivery of individual streams. To address this, HTTP/2 provides a set of simple building blocks that allow the client and server to implement their own stream- and connection-level flow control:

Flow control is directional. Each receiver may choose to set any window size that it desires for each stream and the entire connection.
Flow control is credit-based. Each receiver advertises its initial connection and stream flow control window (in bytes), which is reduced whenever the sender emits a DATA frame and incremented via a WINDOW_UPDATE frame sent by the receiver.
Flow control cannot be disabled. When the HTTP/2 connection is established the client and server exchange SETTINGS frames, which set the flow control window sizes in both directions. The default value of the flow control window is set to 65,535 bytes, but the receiver can set a large maximum window size (2^31-1 bytes) and maintain it by sending a WINDOW_UPDATE frame whenever any data is received.
Flow control is hop-by-hop, not end-to-end. That is, an intermediary can use it to control resource use and implement resource allocation mechanisms based on own criteria and heuristics.

HTTP/2 does not specify any particular algorithm for implementing flow control. Instead, it provides the simple building blocks and defers the implementation to the client and server, which can use it to implement custom strategies to regulate resource use and allocation, as well as implement new delivery capabilities that may help improve both the real and perceived performance (see Speed, Performance, and Human Perception) of our web applications.

For example, application-layer flow control allows the browser to fetch only a part of a particular resource, put the fetch on hold by reducing the stream flow control window down to zero, and then resume it later. In other words, it allows the browser to fetch a preview or first scan of an image, display it and allow other high priority fetches to proceed, and resume the fetch once more critical resources have finished loading.

Server push #

Another powerful new feature of HTTP/2 is the ability of the server to send multiple responses for a single client request. That is, in addition to the response to the original request, the server can push additional resources to the client (Figure 12-5), without the client having to request each one explicitly.

Why would we need such a mechanism in a browser? A typical web application consists of dozens of resources, all of which are discovered by the client by examining the document provided by the server. As a result, why not eliminate the extra latency and let the server push the associated resources ahead of time? The server already knows which resources the client will require; that’s server push.

In fact, if you have ever inlined a CSS, JavaScript, or any other asset via a data URI (see Resource Inlining), then you already have hands-on experience with server push. By manually inlining the resource into the document, we are, in effect, pushing that resource to the client, without waiting for the client to request it. With HTTP/2 we can achieve the same results, but with additional performance benefits. Push resources can be:

Cached by the client
Reused across different pages
Multiplexed alongside other resources
Prioritized by the server
Declined by the client

PUSH_PROMISE 101 #

All server push streams are initiated via PUSH_PROMISE frames, which signal the server’s intent to push the described resources to the client and need to be delivered ahead of the response data that requests the pushed resources. This delivery order is critical: the client needs to know which resources the server intends to push to avoid creating duplicate requests for these resources. The simplest strategy to satisfy this requirement is to send all PUSH_PROMISE frames, which contain just the HTTP headers of the promised resource, ahead of the parent’s response (in other words, DATA frames).

Once the client receives a PUSH_PROMISE frame it has the option to decline the stream (via a RST_STREAM frame) if it wants to. (This might occur for example because the resource is already in cache.) This is an important improvement over HTTP/1.x. By contrast, the use of resource inlining, which is a popular "optimization" for HTTP/1.x, is equivalent to a "forced push": the client cannot opt-out, cancel it, or process the inlined resource individually.

With HTTP/2 the client remains in full control of how server push is used. The client can limit the number of concurrently pushed streams; adjust the initial flow control window to control how much data is pushed when the stream is first opened; or disable server push entirely. These preferences are communicated via the SETTINGS frames at the beginning of the HTTP/2 connection and may be updated at any time.

Each pushed resource is a stream that, unlike an inlined resource, allows it to be individually multiplexed, prioritized, and processed by the client. The only security restriction, as enforced by the browser, is that pushed resources must obey the same-origin policy: the server must be authoritative for the provided content.

Header compression #

Each HTTP transfer carries a set of headers that describe the transferred resource and its properties. In HTTP/1.x, this metadata is always sent as plain text and adds anywhere from 500–800 bytes of overhead per transfer, and sometimes kilobytes more if HTTP cookies are being used. (See Measuring and Controlling Protocol Overhead .) To reduce this overhead and improve performance, HTTP/2 compresses request and response header metadata using the HPACK compression format that uses two simple but powerful techniques:

It allows the transmitted header fields to be encoded via a static Huffman code, which reduces their individual transfer size.
It requires that both the client and server maintain and update an indexed list of previously seen header fields (in other words, it establishes a shared compression context), which is then used as a reference to efficiently encode previously transmitted values.

Huffman coding allows the individual values to be compressed when transferred, and the indexed list of previously transferred values allows us to encode duplicate values by transferring index values that can be used to efficiently look up and reconstruct the full header keys and values.

As one further optimization, the HPACK compression context consists of a static and dynamic table: the static table is defined in the specification and provides a list of common HTTP header fields that all connections are likely to use (e.g., valid header names); the dynamic table is initially empty and is updated based on exchanged values within a particular connection. As a result, the size of each request is reduced by using static Huffman coding for values that haven’t been seen before, and substitution of indexes for values that are already present in the static or dynamic tables on each side.

Security and performance of HPACK #

Early versions of HTTP/2 and SPDY used zlib, with a custom dictionary, to compress all HTTP headers. This delivered an 85% to 88% reduction in the size of the transferred header data, and a significant improvement in page load time latency:

On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (in other words, those that issued large number of resource requests). We found a reduction of 45–1142 ms in page load time simply due to header compression. (SPDY whitepaper, chromium.org)

However, in the summer of 2012, a "CRIME" security attack was published against TLS and SPDY compression algorithms, which could result in session hijacking. As a result, the zlib compression algorithm was replaced by HPACK, which was specifically designed to: address the discovered security issues, be efficient and simple to implement correctly, and of course, enable good compression of HTTP header metadata.

For full details of the HPACK compression algorithm, see IETF HPACK - Header Compression for HTTP/2.

Feedback #

Delivering Fast and Light Applications with Save-Data

2016-02-18T00:00:00Z

The Save-Data client hint request header available in Chrome, Opera, and Yandex browsers lets developers deliver lighter, faster applications to users who opt-in to data saving mode in their browser.

The need for lightweight pages #

Everyone agrees that faster and lighter web pages provide a more satisfying user experience, allow better content comprehension and retention, and deliver increased conversions and revenue. Google research has shown that "…optimized pages load four times faster than the original page and use 80% fewer bytes. Because these pages load so much faster, we also saw a 50% increase in traffic to these pages."

And, although the number of 2G connections is finally on the decline, 2G was still the dominant network technology in 2015. The penetration and availability of 3G and 4G networks is growing rapidly, but the associated ownership costs and network constraints are still a significant factor for hundreds of millions of users.

These are strong arguments for page optimization.

There are alternative methods for improving site speed without direct developer involvement, such as proxy browsers and transcoding services. Although such services are quite popular, they come with substantial drawbacks — simple (and sometimes unacceptable) image and text compression, inability to process secure (HTTPS) pages, only optimizing pages visited via a search result, and more. The very popularity of these services is itself an indicator that web developers are not properly addressing the high user demand for fast and light applications and pages. But reaching that goal is a complex and sometimes difficult path.

The `Save-Data` request header #

One fairly straightforward technique is to let the browser help, using the Save-Data request header. By identifying this header, a web page can customize and deliver an optimized user experience to cost- and performance-constrained users.

Supported browsers (below) allow the user to enable a *data saving- mode that gives the browser permission to apply a set of optimizations to reduce the amount of data required to render the page. When this feature is exposed, or advertised, the browser may request lower resolution images, defer loading of some resources, or route requests through a service that applies other content-specific optimizations such as image and text resource compression.

Browser support #

Chrome 49+ advertises Save-Data when the user enables the "Data Saver" option on mobile, or the "Data Saver" extension on desktop browsers.
Opera 35+ advertises Save-Data when the user enables "Opera Turbo" mode on desktop, or the "Data savings" option on Android browsers.
Yandex 16.2+ advertises Save-Data when Turbo mode is enabled on desktop or mobile browsers.

Detecting the `Save-Data` setting #

To determine when to deliver the "light" experience to your users, your application can check for the Save-Data client hint request header. This request header indicates the client's preference for reduced data usage due to high transfer costs, slow connection speeds, or other reasons.

When the user enables the data saving mode in their browser, the browser appends the Save-Data request header to all outgoing requests (both HTTP and HTTPS). As of this writing, the browser only advertises one *on- token in the header (Save-Data: on), but this may be extended in the future to indicate other user preferences.

Additionally, it's possible to detect if Save-Data is turned on in JavaScript:

if ('connection' in navigator) {
  if (navigator.connection.saveData === true) {
    // Implement data saving operations here.
  }
}

Checking for the presence of the connection object within the navigator object is vital, as it represents the Network Information API, which is only implemented in Chrome, Chrome for Android, and Samsung Internet browsers. From there, you only need to check if navigator.connection.saveData is equal to true, and you can implement any data saving operations in that condition.

Enabling the Data Saver extension in Chrome desktop.

If your application uses a service worker, it can inspect the request headers and apply relevant logic to optimize the experience. Alternatively, the server can look for the advertised preferences in the Save-Data request header and return an alternate response — different markup, smaller images and video, and so on.

Tip: If you use PageSpeed for Apache or Nginx to optimize your pages, see this discussion to learn how to enable Save-Data savings for your users._

Implementation tips and best practices #

When using Save-Data, provide some UI devices that support it and allow users to easily toggle between experiences. For example:
- Notify users that Save-Data is supported and encourage them to use it.
- Allow users to identify and choose the mode with appropriate prompts and intuitive on/off buttons or checkboxes.
- When data saving mode is selected, announce and provide an easy and obvious way to disable it and revert back to the full experience if desired.
Remember that lightweight applications are not lesser applications. They don't omit important functionality or data, they're just more cognizant of the involved costs and the user experience. For example:
- A photo gallery application may deliver lower resolution previews, or use a less code-heavy carousel mechanism.
- A search application may return fewer results at a time, limit the number of media-heavy results, or reduce the number of dependencies required to render the page.
- A news-oriented site may show fewer stories, omit less popular categories, or provide smaller media previews.
Provide server logic to check for the Save-Data request header and consider providing an alternate, lighter page response when it is enabled — e.g., reduce the number of required resources and dependencies, apply more aggressive resource compression, etc.
- If you're serving an alternate response based on the Save-Data header, remember to add it to the Vary list — Vary: Save-Data — to tell upstream caches that they should cache and serve this version only if the Save-Data request header is present. For more details, see the best practices for interaction with caches.
If you use a service worker, your application can detect when the data saving option is enabled by checking for the presence of the Save-Data request header, or by checking the value of the navigator.connection.saveData property. If enabled, consider whether you can rewrite the request to fetch fewer bytes, or use an already fetched response.
Consider augmenting Save-Data with other signals, such as information about the user's connection type and technology (see NetInfo API). For example, you might want to serve the lightweight experience to any user on a 2G connection even if Save-Data is not enabled. Conversely, just because the user is on a "fast" 4G connection doesn't mean they aren't interested in saving data — for example, when roaming. Additionally, you could augment the presence of Save-Data with the Device-Memory client hint to further adapt to users on devices with limited memory. User device memory is also advertised in the navigator.deviceMemory client hint.

Recipes #

What you can achieve via Save-Data is limited only to what you can come up with. To give you an idea of what's possible, let's run through a couple of use cases. You may come up with other use cases of your own as you read this, so feel free to experiment and see what's possible!

Checking for `Save-Data` in server side code #

While the Save-Data state is something you can detect in JavaScript via the navigator.connection.saveData property, detecting it on the server side is sometimes preferable. JavaScript can fail to execute in some cases. Plus, server side detection is the only way to modify markup before it's sent to the client, which is involved in some of Save-Datas most beneficial use cases.

The specific syntax for detecting the Save-Data header in server side code depends on the language used, but the basic idea should be the same for any application back end. In PHP, for example, request headers are stored in the $_SERVER superglobal array at indexes starting with HTTP_. This means you can detect the Save-Data header by checking the existence and value of the $_SERVER["HTTP_SAVE_DATA"] variable like so:

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

If you place this check before any markup is sent to the client, the $saveData variable will contain the Save-Data state, and will be available anywhere for use on the page. With this mechanism illustrated, let's look a few examples of how we can use it to limit how much data we send to the user.

Serve low resolution images for high resolution screens #

A common use case for images on the web involves serving images in sets of two: One image for "standard" screens (1x), and another image that's twice as large (2x) for high resolution screens (e.g., Retina Display). This class of high resolution screens is not necessarily limited to high end devices, and is becoming increasingly common. In cases where a lighter application experience is preferred, it might be prudent to send lower resolution (1x) images to these screens, rather than larger (2x) variants. To achieve this when the Save-Data header is present, we simply modify the markup we send to the client:

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}

This use case is a perfect example of how little effort it takes to accommodate someone who is specifically asking you to send them less data. If you don't like modifying markup on the back end, you could also achieve the same result by using a URL rewrite module such as Apache's mod_rewrite. There are examples of how to achieve this with relatively little configuration.

You could also extend this concept to CSS background-image properties by simply adding a class to the <html> element:

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

From here, you can target the save-data class on the <html> element in your CSS to change how images are delivered. You could send low resolution background images to high resolution screens as shown in the above HTML example, or omit certain resources altogether.

Omit non-essential imagery #

Some image content on the web is simply non-essential. While such imagery can make for nice asides to content, they may not be desirable by those trying to squeeze all they can out of metered data plans. In what is perhaps the simplest use case of Save-Data, we can use the PHP detection code from earlier and omit non-essential image markup altogether:

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

This technique can certainly have a pronounced effect, as you can see in the figure below:

A comparison of non-critical imagery being loaded when Save-Data is absent, versus that same imagery being omitted when Save-Data is present.

Of course, omitting images isn't the only possibility. You can also act on Save-Data to forego sending other non-critical resources, such as certain typefaces.

Omit non-essential web fonts #

While web fonts don't usually make up nearly as much of a given page's total payload as images often do, they're still quite popular. They don't consume an insignificant amount of data, either. Furthermore, the way browsers fetch and render fonts is more complicated than you might think, with concepts such as FOIT, FOUT, and browser heuristics making rendering a nuanced operation.

It might stand to reason then that you might want to leave out non-essential web fonts for users who want leaner user experiences. Save-Data makes this a reasonably painless thing to do.

For example, let's say you've included Fira Sans from Google Fonts on your site. Fira Sans is an excellent body copy font, but maybe it isn't so crucial to users trying to save data. By adding a class of save-data to the <html> element when the Save-Data header is present, we can write styles that invoke the non-essential typeface at first, but then opts out of it when the Save-Data header is present:

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

Using this approach, you can leave the <link> snippet from Google Fonts in place, because the browser speculatively loads CSS resources (including web fonts) by first applying styles to the DOM, and then checking if any HTML elements invoke any of the resources in the style sheet. If someone happens by with Save-Data on, Fira Sans will never load because the styled DOM never invokes it. Arial will kick in, instead. It's not as nice as as Fira Sans, but it may be preferable to those users trying to stretch their data plans.

Opting out of server pushes #

HTTP/2 server push is often the most touted feature of HTTP/2. While it can boost performance, it can potentially be problematic due to caching "gotchas".

If you're comfortable using server push and understand its current, quirky way of interacting with the browser cache, then great. But you may want to consider disabling it altogether if the Save-Data header is present.

Many HTTP/2 implementations kick off a server push for a resource when a Link response header invoking rel=preload is set. This leads to some confusion as to whether rel=preload and server push are one and the same, but they're two distinct things. rel=preload is a resource hint, and server push is part of HTTP/2. It just so happens the Link header kicks off a server push in a number of HTTP/2 implementations.

The specification for rel=preload addresses this potential pain point by offering a nopush keyword to be used in Link HTTP response headers. Using the back end detection logic outlined earlier, you could append nopush if Save-Data is present:

// `preload` like usual…
$preload = "</css/styles.css>; rel=preload; as=style";

if($saveData === true) {
  // …but don't push anything if `Save-Data` is detected!
  $preload .= "; nopush";
}

header("Link: " . $preload);

There are other ways to achieve this, some more more nuanced than others, but the idea is the same: HTTP/2 server push is turned off when Save-Data is present.

As you can see, there's a lot that can be accomplished with Save-Data. These are just a couple simple use cases to get you going, so feel free to experiment and see what novel use cases you can come up with!

Summary #

The Save-Data header does not have much nuance; it is either on or off, and the application bears the burden of providing appropriate experiences based on its setting, regardless of the reason.

For example, some users might not allow data saving mode if they suspect there will be a loss of app content or function, even in a poor connectivity situation. Conversely, some users might enable it as a matter of course to keep pages as small and simple as possible, even in a good connectivity situation. It's best for your app to assume that the user wants the full and unlimited experience until you have a clear indication otherwise via an explicit user action.

As site owners and web developers, let's take on the responsibility of managing our content to improve the user experience for data- and cost-constrained users.

For more detail on Save-Data and excellent practical examples, see Help Your Users Save Data.

Eliminate unnecessary downloads

2014-03-31T00:00:00Z

The fastest and best-optimized resource is a resource not sent. You should eliminate unnecessary resources from your application. It's a good practice to question—and periodically revisit—the implicit and explicit assumptions with your team. Here are a few examples:

You've always included resource X on your pages, but does the cost of downloading and displaying it offset the value it delivers to the user? Can you measure and prove its value?
Does the resource (especially if it's a third-party resource) deliver consistent performance? Is this resource in the critical path, or need to be? If the resource is in the critical path, could it be a single point of failure for the site? That is, if the resource is unavailable, does it affect performance and the user experience of your pages?
Does this resource need or have an SLA? Does this resource follow performance best practices: compression, caching, and so on?

Too often, pages contain resources that are unnecessary, or worse, that hinder page performance without delivering much value to the visitor or to the site they're hosted on. This applies equally to first-party and third-party resources and widgets:

Site A has decided to display a photo carousel on its homepage to allow the visitor to preview multiple photos with a quick click. All of the photos are loaded when the page is loaded, and the user advances through the photos.
- Question: Have you measured how many users view multiple photos in the carousel? You might be incurring high overhead by downloading resources that most visitors never view.
Site B has decided to install a third-party widget to display related content, improve social engagement, or provide some other service.
- Question: Have you tracked how many visitors use the widget or click-through on the content that the widget provides? Is the engagement that this widget generates enough to justify its overhead? Furthermore, is it feasible for you to use a loading strategy to ensure the script isn't loaded until it's needed?

Determining whether to eliminate unnecessary downloads often requires a lot of careful thinking and measurement. For best results, periodically inventory and revisit these questions for every asset on your pages.

Effects on Core Web Vitals #

The Core Web Vitals initative was introduced by Google to provide a set of metrics that reflect what users are experiencing as they use the web. While there are many optimization strategies for Core Web Vitals, questioning whether to load a particular resource on a page may light a path for you to improve these metrics on your website. Below are a few examples—grouped by each Core Web Vital—that are worth your consideration. Though this isn't an exhaustive list of examples (and there are many!), reading them over may give you food for thought.

Largest Contentful Paint (LCP) #

Largest Contentful Paint (LCP) measures when the largest content (for example a hero image, or a headline) is loaded. It's considered an important perceptual metric that gives the user the impression that a site is loading quickly.

In general, downloading less resources means that the bandwidth the user does have will be allocated across less resources, and may translate to an improvement in LCP. A classic example is that of lazy loading, where images outside of the viewport during page load will not be downloaded until the browser has determined the user is more likely to see them. If you have a large thumbnail gallery of, say, 50 images, lazy loading all but the top ten of them means that the browser can make more efficient use of the bandwidth available to it, and the first images the user will see will load more quickly.

However, it's not just about loading less images, necessarily. The browser has an internal prioritization scheme that determines how much bandwidth each resource should receive. However, even with this all resources—particularly those downloaded at high priority—have the potential to deprive a potential LCP element's dependent resource. This is especially true on slow network connections. That dependent resource may be an image file that represents the page's LCP element, but it could also very well be a web font resource that the browser needs to render a text node that may be determined as the page's LCP element.

If your website is heavy on text, it may be the case that a page's LCP element is a text node. While there are many good font optimization and loading strategies, it may be worth considering whether a system font is sufficient for your website's needs, so that LCP elements which are text nodes can load without a dependency on a web font resource and paint almost immediately as the CSS and HTML arrives from the server.

Cumulative Layout Shift (CLS) #

Every resource you load has the potential to contribute to a page's Cumulative Layout Shift (CLS), particularly if has not finished downloading by the time of the initial paint. For images, avoid CLS involves practices such as setting explicit dimensions. For fonts, managing font loading and potentially fallback font matching can minimize shifts during a web font's swap period. For JavaScript, it could be managing how that script manipulates the DOM so that layout shifts are reduced to an acceptable amount.

Every resource that contributes to a page's CLS requires some amount of work to ensure page layout is sufficiently stable. By questioning whether or not you need a specific resource, you're not just speeding up page loads, you're also reducing the cognitive effort necessary to preserve layout stability. That leads to not only a much less frustrating user experience, but a less frustrating developer experience, as you'll have more time to pursue other goals in your projects.

Interaction to Next Paint (INP) and First Input Delay (FID) #

Interaction to Next Paint (INP) and First Input Delay (FID) are metrics that measure responsiveness to user inputs. While INP is slated to replace FID as a Core Web Vital in March of 2024, optimization strategies for FID tend to also apply to INP. Furthermore, INP is generally more difficult to optimize for than FID, as it tracks the full interaction latency for all page interactions, not just the input delay of the first interaction as FID measures.

INP and FID tend to be most affected by JavaScript, as JavaScript is what drives most of the interactivity one experiences across the web. For both INP and FID, the amount of script resources downloaded during page load will kick off potentially expensive work involved in script evaluation and compilation. The less JavaScript you load during startup, the less work the browser has to do at that critical point in the page experience.

While there are strategies for reducing the size of JavaScript resources downloaded during startup—such as code splitting and tree shaking—it's worth auditing the packages you use in your projects to see if they're necessary at all. For example, lodash has many methods that are still useful today, but ships with methods that the browser provides out of the box, such as Array-specific functions for mapping, reducing, and filtering, and many others.

Progressive enhancement is also a useful approach to JavaScript, as it enables you to serve a baseline (but still functional) experience for users that you can add to for users with more powerful devices and faster network connections. Whether you adhere to the principle of progressive enhancement or not, the point remains: Every JavaScript resource you can avoid downloading can result in an experience that responds faster to user interactions, which is a vital aspect of web performance.

Conclusion #

Auditing your website for unnecessary downloads may be just one aspect of delivering fast user experiences, but it's one that has the potential for high impact. To recap:

Inventory your own assets and third-party assets on your pages.
Measure the performance of each asset: its value and its technical performance.
Determine if the resources are providing sufficient value.
Understand the effect of unnecessary downloads on Core Web Vitals and supporting metrics.

By optimizing content efficiency in this way, you're not only improving performance overall, you're also taking care not to waste users' bandwidth, as well as potentially improving user-centric metrics and delivering a better user experience.

Constructing the Object Model

2014-03-31T00:00:00Z

Before the browser can render the page, it needs to construct the DOM and CSSOM trees. As a result, we need to ensure that we deliver both the HTML and CSS to the browser as quickly as possible.

Summary #

Bytes → characters → tokens → nodes → object model.
HTML markup is transformed into a Document Object Model (DOM); CSS markup is transformed into a CSS Object Model (CSSOM).
DOM and CSSOM are independent data structures.
Chrome DevTools Performance panel allows us to capture and inspect the construction and processing costs of DOM and CSSOM.

Document Object Model (DOM) #

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Try it

Let’s start with the simplest possible case: a plain HTML page with some text and a single image. How does the browser process this page?

Conversion: The browser reads the raw bytes of HTML off the disk or network, and translates them to individual characters based on specified encoding of the file (for example, UTF-8).
Tokenizing: The browser converts strings of characters into distinct tokens—as specified by the W3C HTML5 standard for example, "<html>", "<body>"—and other strings within angle brackets. Each token has a special meaning and its own set of rules.
Lexing: The emitted tokens are converted into "objects," which define their properties and rules.
DOM construction: Finally, because the HTML markup defines relationships between different tags (some tags are contained within other tags) the created objects are linked in a tree data structure that also captures the parent-child relationships defined in the original markup: the HTML object is a parent of the body object, the body is a parent of the paragraph object, and so on.

The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing of the page.

Every time the browser processes HTML markup, it goes through all of the steps above: convert bytes to characters, identify tokens, convert tokens to nodes, and build the DOM tree. This entire process can take some time, especially if we have a large amount of HTML to process.

If you open up Chrome DevTools and record a timeline while the page is loaded, you can see the actual time taken to perform this step—in the example above, it took us ~5ms to convert a chunk of HTML into a DOM tree. For a larger page, this process could take significantly longer. When creating smooth animations, this can easily become a bottleneck if the browser has to process large amounts of HTML.

The DOM tree captures the properties and relationships of the document markup, but it doesn't tell us how the element will look when rendered. That’s the responsibility of the CSSOM.

CSS Object Model (CSSOM) #

While the browser was constructing the DOM of our simple page, it encountered a link tag in the head section of the document referencing an external CSS stylesheet: style.css. Anticipating that it needs this resource to render the page, it immediately dispatches a request for this resource, which comes back with the following content:

body {
  font-size: 16px;
}
p {
  font-weight: bold;
}
span {
  color: red;
}
p span {
  display: none;
}
img {
  float: right;
}

We could have declared our styles directly within the HTML markup (inline), but keeping our CSS independent of HTML allows us to treat content and design as separate concerns: designers can work on CSS, developers can focus on HTML, and so on.

As with HTML, we need to convert the received CSS rules into something that the browser can understand and work with. Hence, we repeat the HTML process, but for CSS instead of HTML:

The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the "CSS Object Model" (CSSOM):

Why does the CSSOM have a tree structure? When computing the final set of styles for any object on the page, the browser starts with the most general rule applicable to that node (for example, if it is a child of a body element, then all body styles apply) and then recursively refines the computed styles by applying more specific rules; that is, the rules "cascade down."

To make it more concrete, consider the CSSOM tree above. Any text contained within the <span> tag that is placed within the body element, has a font size of 16 pixels and has red text—the font-size directive cascades down from the body to the span. However, if a span tag is child of a paragraph (p) tag, then its contents are not displayed.

Also, note that the above tree is not the complete CSSOM tree and only shows the styles we decided to override in our stylesheet. Every browser provides a default set of styles also known as "user agent styles"—that’s what we see when we don’t provide any of our own—and our styles simply override these defaults.

To find out how long the CSS processing takes you can record a timeline in DevTools and look for "Recalculate Style" event: unlike DOM parsing, the timeline doesn’t show a separate "Parse CSS" entry, and instead captures parsing and CSSOM tree construction, plus the recursive calculation of computed styles under this one event.

Our trivial stylesheet takes ~0.6ms to process and affects eight elements on the page—not much, but once again, not free. However, where did the eight elements come from? The CSSOM and DOM are independent data structures! Turns out, the browser is hiding an important step. Next, lets talk about the render tree that links the DOM and CSSOM together.

Feedback #

Analyzing Critical Rendering Path Performance

2014-03-31T00:00:00Z

Identifying and resolving critical rendering path performance bottlenecks requires good knowledge of the common pitfalls. Let's take a hands-on tour and extract common performance patterns that will help you optimize your pages.

Optimizing the critical rendering path allows the browser to paint the page as quickly as possible: faster pages translate into higher engagement, more pages viewed, and improved conversion. To minimize the amount of time a visitor spends viewing a blank screen, we need to optimize which resources are loaded and in which order.

To help illustrate this process, let's start with the simplest possible case and incrementally build up our page to include additional resources, styles, and application logic. In the process, we'll optimize each case; we'll also see where things can go wrong.

So far we've focused exclusively on what happens in the browser after the resource (CSS, JS, or HTML file) is available to process. We've ignored the time it takes to fetch the resource either from cache or from the network. We'll assume the following:

A network roundtrip (propagation latency) to the server costs 100ms.
Server response time is 100ms for the HTML document and 10ms for all other files.

The hello world experience #

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Try it

We'll start with basic HTML markup and a single image; no CSS or JavaScript. Let's open up our Network timeline in Chrome DevTools and inspect the resulting resource waterfall:

As expected, the HTML file took approximately 200ms to download. Note that the transparent portion of the blue line represents the length of time that the browser waits on the network without receiving any response bytes whereas the solid portion shows the time to finish the download after the first response bytes have been received. The HTML download is tiny (<4K), so all we need is a single roundtrip to fetch the full file. As a result, the HTML document takes approximately 200ms to fetch, with half the time spent waiting on the network and the other half waiting on the server response.

When the HTML content becomes available, the browser parses the bytes, converts them into tokens, and builds the DOM tree. Notice that DevTools conveniently reports the time for the DOMContentLoaded event at the bottom (216ms), which also corresponds to the blue vertical line. The gap between the end of the HTML download and the blue vertical line (DOMContentLoaded) is the time it takes the browser to build the DOM tree—in this case, just a few milliseconds.

Notice that our "awesome photo" did not block the domContentLoaded event. Turns out, we can construct the render tree and even paint the page without waiting for each asset on the page: not all resources are critical to deliver the fast first paint. In fact, when we talk about the critical rendering path we are typically talking about the HTML markup, CSS, and JavaScript. Images do not block the initial render of the page—although we should also try to get the images painted as soon as possible.

That said, the load event (also known as onload), is blocked on the image: DevTools reports the onload event at 335ms. Recall that the onload event marks the point at which all resources that the page requires have been downloaded and processed; at this point, the loading spinner can stop spinning in the browser (the red vertical line in the waterfall).

Adding JavaScript and CSS into the mix #

Our "Hello World experience" page seems simple but a lot goes on under the hood. In practice we'll need more than just the HTML: chances are, we'll have a CSS stylesheet and one or more scripts to add some interactivity to our page. Let's add both to the mix and see what happens:

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Script</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="timing.js"></script>
  </body>
</html>

Try it

Before adding JavaScript and CSS:

With JavaScript and CSS:

Adding external CSS and JavaScript files adds two extra requests to our waterfall, all of which the browser dispatches at about the same time. However, note that there is now a much smaller timing difference between the domContentLoaded and onload events.

What happened?

Unlike our plain HTML example, we also need to fetch and parse the CSS file to construct the CSSOM, and we need both the DOM and CSSOM to build the render tree.
Because the page also contains a parser blocking JavaScript file, the domContentLoaded event is blocked until the CSS file is downloaded and parsed: because the JavaScript might query the CSSOM, we must block the CSS file until it downloads before we can execute JavaScript.

What if we replace our external script with an inline script? Even if the script is inlined directly into the page, the browser can't execute it until the CSSOM is constructed. In short, inlined JavaScript is also parser blocking.

That said, despite blocking on CSS, does inlining the script make the page render faster? Let's try it and see what happens.

External JavaScript:

Inlined JavaScript:

We are making one less request, but both our onload and domContentLoaded times are effectively the same. Why? Well, we know that it doesn't matter if the JavaScript is inlined or external, because as soon as the browser hits the script tag it blocks and waits until the CSSOM is constructed. Further, in our first example, the browser downloads both CSS and JavaScript in parallel and they finish downloading at about the same time. In this instance, inlining the JavaScript code doesn't help us much. But there are several strategies that can make our page render faster.

First, recall that all inline scripts are parser blocking, but for external scripts we can add the "async" keyword to unblock the parser. Let's undo our inlining and give that a try:

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Async</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script async src="timing.js"></script>
  </body>
</html>

Try it

Parser-blocking (external) JavaScript:

Async (external) JavaScript:

Much better! The domContentLoaded event fires shortly after the HTML is parsed; the browser knows not to block on JavaScript and since there are no other parser blocking scripts the CSSOM construction can also proceed in parallel.

Alternatively, we could have inlined both the CSS and JavaScript:

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Inlined</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <style>
      p {
        font-weight: bold;
      }
      span {
        color: red;
      }
      p span {
        display: none;
      }
      img {
        float: right;
      }
    </style>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script>
      var span = document.getElementsByTagName('span')[0];
      span.textContent = 'interactive'; // change DOM text content
      span.style.display = 'inline'; // change CSSOM property
      // create a new element, style it, and append it to the DOM
      var loadTime = document.createElement('div');
      loadTime.textContent = 'You loaded this page on: ' + new Date();
      loadTime.style.color = 'blue';
      document.body.appendChild(loadTime);
    </script>
  </body>
</html>

Try it

Notice that the domContentLoaded time is effectively the same as in the previous example; instead of marking our JavaScript as async, we've inlined both the CSS and JS into the page itself. This makes our HTML page much larger, but the upside is that the browser doesn't have to wait to fetch any external resources; everything is right there in the page.

As you can see, even with a very simple page, optimizing the critical rendering path is a non-trivial exercise: we need to understand the dependency graph between different resources, we need to identify which resources are "critical," and we must choose among different strategies for how to include those resources on the page. There is no one solution to this problem; each page is different. You need to follow a similar process on your own to figure out the optimal strategy.

That said, let's see if we can step back and identify some general performance patterns.

Performance patterns #

The simplest possible page consists of just the HTML markup; no CSS, no JavaScript, or other types of resources. To render this page the browser has to initiate the request, wait for the HTML document to arrive, parse it, build the DOM, and then finally render it on the screen:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Try it

The time between T₀ and T₁ captures the network and server processing times. In the best case (if the HTML file is small), just one network roundtrip fetches the entire document. Due to how the TCP transports protocols work, larger files may require more roundtrips. As a result, in the best case the above page has a one roundtrip (minimum) critical rendering path.

Now, let's consider the same page but with an external CSS file:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Try it

Once again, we incur a network roundtrip to fetch the HTML document, and then the retrieved markup tells us that we also need the CSS file; this means that the browser has to go back to the server and get the CSS before it can render the page on the screen. As a result, this page incurs a minimum of two roundtrips before it can be displayed. Once again, the CSS file may take multiple roundtrips, hence the emphasis on "minimum".

Let's define the vocabulary we use to describe the critical rendering path:

Critical Resource: Resource that could block initial rendering of the page.
Critical Path Length: Number of roundtrips, or the total time required to fetch all of the critical resources.
Critical Bytes: Total number of bytes required to get to first render of the page, which is the sum of the transfer filesizes of all critical resources. Our first example, with a single HTML page, contained a single critical resource (the HTML document); the critical path length was also equal to one network roundtrip (assuming file was small), and the total critical bytes was just the transfer size of the HTML document itself.

Now let's compare that to the critical path characteristics of the HTML + CSS example above:

2 critical resources
2 or more roundtrips for the minimum critical path length
9 KB of critical bytes

We need both the HTML and CSS to construct the render tree. As a result, both HTML and CSS are critical resources: the CSS is fetched only after the browser gets the HTML document, hence the critical path length is at minimum two roundtrips. Both resources add up to a total of 9KB of critical bytes.

Now let's add an extra JavaScript file into the mix.

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js"></script>
  </body>
</html>

Try it

We added app.js, which is both an external JavaScript asset on the page and a parser blocking (that is, critical) resource. Worse, in order to execute the JavaScript file we have to block and wait for CSSOM; recall that JavaScript can query the CSSOM and hence the browser pauses until style.css is downloaded and CSSOM is constructed.

That said, in practice if we look at this page's "network waterfall," you'll see that both the CSS and JavaScript requests are initiated at about the same time; the browser gets the HTML, discovers both resources, and initiates both requests. As a result, the above page has the following critical path characteristics:

3 critical resources
2 or more roundtrips for the minimum critical path length
11 KB of critical bytes

We now have three critical resources that add up to 11KB of critical bytes, but our critical path length is still two roundtrips because we can transfer the CSS and JavaScript in parallel. Figuring out the characteristics of your critical rendering path means being able to identify the critical resources and also understanding how the browser will schedule their fetches. Let's continue with our example.

After chatting with our site developers, we realize that the JavaScript we included on our page doesn't need to be blocking; we have some analytics and other code in there that doesn't need to block the rendering of our page. With that knowledge, we can add the "async" attribute to the script tag to unblock the parser:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

Try it

An asynchronous script has several advantages:

The script is no longer parser blocking and is not part of the critical rendering path.
Because there are no other critical scripts, the CSS doesn't need to block the domContentLoaded event.
The sooner the domContentLoaded event fires, the sooner other application logic can begin executing.

As a result, our optimized page is now back to two critical resources (HTML and CSS), with a minimum critical path length of two roundtrips, and a total of 9KB of critical bytes.

Finally, if the CSS stylesheet were only needed for print, how would that look?

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" media="print" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

Try it

Because the style.css resource is only used for print, the browser doesn't need to block on it to render the page. Hence, as soon as DOM construction is complete, the browser has enough information to render the page. As a result, this page has only a single critical resource (the HTML document), and the minimum critical rendering path length is one roundtrip.

Feedback #

Measuring the Critical Rendering Path

2014-03-31T00:00:00Z

The foundation of every solid performance strategy is good measurement and instrumentation. You can't optimize what you can't measure. This doc explains different approaches for measuring CRP performance.

The Lighthouse approach runs a series of automated tests against a page, and then generates a report on the page's CRP performance. This approach provides a quick and easy high-level overview of CRP performance of a particular page loaded in your browser, allowing you to rapidly test, iterate, and improve its performance.
The Navigation Timing API approach captures Real User Monitoring (RUM) metrics. As the name implies, these metrics are captured from real user interactions with your site and provide an accurate view into real-world CRP performance, as experienced by your users across a variety of devices and network conditions.

In general, a good approach is to use Lighthouse to identify obvious CRP optimization opportunities, and then to instrument your code with the Navigation Timing API to monitor how your app performs out in the wild.

Auditing a page with Lighthouse #

Lighthouse is a web app auditing tool that runs a series of tests against a given page, and then displays the page's results in a consolidated report. You can run Lighthouse as a Chrome Extension or NPM module, which is useful for integrating Lighthouse with continuous integration systems.

See Auditing Web Apps With Lighthouse to get started.

When you run Lighthouse as a Chrome Extension, your page's CRP results look like the screenshot below.

See Critical Request Chains for more information on this audit's results.

The combination of the Navigation Timing API and other browser events emitted as the page loads allows you to capture and record the real-world CRP performance of any page.

Each of the labels in the above diagram corresponds to a high resolution timestamp that the browser tracks for each and every page it loads. In fact, in this specific case we're only showing a fraction of all the different timestamps — for now we're skipping all network related timestamps, but we'll come back to them in a future lesson.

So, what do these timestamps mean?

domLoading: this is the starting timestamp of the entire process, the browser is about to start parsing the first received bytes of the HTML document.
domInteractive: marks the point when the browser has finished parsing all of the HTML and DOM construction is complete.
domContentLoaded: marks the point when both the DOM is ready and there are no stylesheets that are blocking JavaScript execution - meaning we can now (potentially) construct the render tree.
- Many JavaScript frameworks wait for this event before they start executing their own logic. For this reason the browser captures the EventStart and EventEnd timestamps to allow us to track how long this execution took.
domComplete: as the name implies, all of the processing is complete and all of the resources on the page (images, etc.) have finished downloading - in other words, the loading spinner has stopped spinning.
loadEvent: as a final step in every page load the browser fires an onload event which can trigger additional application logic.

The HTML specification dictates specific conditions for each and every event: when it should be fired, which conditions should be met, and so on. For our purposes, we'll focus on a few key milestones related to the critical rendering path:

domInteractive marks when DOM is ready.
domContentLoaded typically marks when both the DOM and CSSOM are ready.
- If there is no parser blocking JavaScript then DOMContentLoaded will fire immediately after domInteractive.
domComplete marks when the page and all of its subresources are ready.

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent =
          'interactive: ' +
          interactive +
          'ms, ' +
          'dcl: ' +
          dcl +
          'ms, complete: ' +
          complete +
          'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Try it

The above example may seem a little daunting on first sight, but in reality it is actually pretty simple. The Navigation Timing API captures all the relevant timestamps and our code simply waits for the onload event to fire — recall that onload event fires after domInteractive, domContentLoaded and domComplete — and computes the difference between the various timestamps.

All said and done, we now have some specific milestones to track and a simple function to output these measurements. Note that instead of printing these metrics on the page you can also modify the code to send these metrics to an analytics server (Google Analytics does this automatically), which is a great way to keep tabs on performance of your pages and identify candidate pages that can benefit from some optimization work.

What about DevTools? #

Although these docs sometimes use the Chrome DevTools Network panel to illustrate CRP concepts, DevTools is currently not well-suited for CRP measurements because it does not have a built-in mechanism for isolating critical resources. Run a Lighthouse audit to help identify such resources.

Feedback #

Optimizing the Critical Rendering Path

2014-03-31T00:00:00Z

To deliver the fastest possible time to first render, we need to minimize three variables:

The number of critical resources.
The critical path length.
The number of critical bytes.

A critical resource is a resource that could block initial rendering of the page. The fewer of these resources, the less work for the browser, the CPU, and other resources.

Similarly, the critical path length is a function of the dependency graph between the critical resources and their bytesize: some resource downloads can only be initiated after a previous resource has been processed, and the larger the resource the more roundtrips it takes to download.

Finally, the fewer critical bytes the browser has to download, the faster it can process content and render it visible on the screen. To reduce the number of bytes, we can reduce the number of resources (eliminate them or make them non-critical) and ensure that we minimize the transfer size by compressing and optimizing each resource.

The general sequence of steps to optimize the critical rendering path is:

Analyze and characterize your critical path: number of resources, bytes, length.
Minimize number of critical resources: eliminate them, defer their download, mark them as async, and so on.
Optimize the number of critical bytes to reduce the download time (number of roundtrips).
Optimize the order in which the remaining critical resources are loaded: download all critical assets as early as possible to shorten the critical path length.

Feedback #

Render Blocking CSS

2014-03-31T00:00:00Z

By default, CSS is treated as a render blocking resource, which means that the browser won't render any processed content until the CSSOM is constructed. Make sure to keep your CSS lean, deliver it as quickly as possible, and use media types and queries to unblock rendering.

In the render tree construction we saw that the critical rendering path requires both the DOM and the CSSOM to construct the render tree. This creates an important performance implication: both HTML and CSS are render blocking resources. The HTML is obvious, since without the DOM we would not have anything to render, but the CSS requirement may be less obvious. What would happen if we try to render a typical page without blocking rendering on CSS?

Summary #

By default, CSS is treated as a render blocking resource.
Media types and media queries allow us to mark some CSS resources as non-render blocking.
The browser downloads all CSS resources, regardless of blocking or non-blocking behavior.

The New York Times with CSS

The New York Times without CSS (FOUC)

The above example, showing the NYTimes website with and without CSS, demonstrates why rendering is blocked until CSS is available---without CSS the page is relatively unusable. The experience on the right is often referred to as a "Flash of Unstyled Content" (FOUC). The browser blocks rendering until it has both the DOM and the CSSOM.

CSS is a render blocking resource. Get it to the client as soon and as quickly as possible to optimize the time to first render.

However, what if we have some CSS styles that are only used under certain conditions, for example, when the page is being printed or being projected onto a large monitor? It would be nice if we didn’t have to block rendering on these resources.

CSS "media types" and "media queries" allow us to address these use cases:

<link href="style.css" rel="stylesheet" />
<link href="print.css" rel="stylesheet" media="print" />
<link href="other.css" rel="stylesheet" media="(min-width: 40em)" />

A media query consists of a media type and zero or more expressions that check for the conditions of particular media features. For example, our first stylesheet declaration doesn't provide a media type or query, so it applies in all cases; that is to say, it is always render blocking. On the other hand, the second stylesheet declaration applies only when the content is being printed---perhaps you want to rearrange the layout, change the fonts, and so on, and hence this stylesheet declaration doesn't need to block the rendering of the page when it is first loaded. Finally, the last stylesheet declaration provides a "media query," which is executed by the browser: if the conditions match, the browser blocks rendering until the style sheet is downloaded and processed.

By using media queries, we can tailor our presentation to specific use cases, such as display versus print, and also to dynamic conditions such as changes in screen orientation, resize events, and more. When declaring your style sheet assets, pay close attention to the media type and queries; they greatly impact critical rendering path performance.

Let's consider some hands-on examples:

<link href="style.css" rel="stylesheet" />
<link href="style.css" rel="stylesheet" media="all" />
<link href="portrait.css" rel="stylesheet" media="orientation:portrait" />
<link href="print.css" rel="stylesheet" media="print" />

The first declaration is render blocking and matches in all conditions.
The second declaration is also render blocking: "all" is the default type so if you don’t specify any type, it’s implicitly set to "all". Hence, the first and second declarations are actually equivalent.
The third declaration has a dynamic media query, which is evaluated when the page is loaded. Depending on the orientation of the device while the page is loading, portrait.css may or may not be render blocking.
The last declaration is only applied when the page is being printed so it is not render blocking when the page is first loaded in the browser.

Finally, note that "render blocking" only refers to whether the browser has to hold the initial rendering of the page on that resource. In either case, the browser still downloads the CSS asset, albeit with a lower priority for non-blocking resources.

Feedback #

Render-tree Construction, Layout, and Paint

2014-03-31T00:00:00Z

The CSSOM and DOM trees are combined into a render tree, which is then used to compute the layout of each visible element and serves as an input to the paint process that renders the pixels to screen. Optimizing each of these steps is critical to achieving optimal rendering performance.

In the previous section on constructing the object model, we built the DOM and the CSSOM trees based on the HTML and CSS input. However, both of these are independent objects that capture different aspects of the document: one describes the content, and the other describes the style rules that need to be applied to the document. How do we merge the two and get the browser to render pixels on the screen?

Summary #

The DOM and CSSOM trees combine to form the render tree.
Render tree contains only the nodes required to render the page.
Layout computes the exact position and size of each object.
The last step is paint, which takes in the final render tree and renders the pixels to the screen.

First, the browser combines the DOM and CSSOM into a "render tree," which captures all the visible DOM content on the page and all the CSSOM style information for each node.

To construct the render tree, the browser roughly does the following:

Starting at the root of the DOM tree, traverse each visible node.
- Some nodes are not visible (for example, script tags, meta tags, and so on), and are omitted since they are not reflected in the rendered output.
- Some nodes are hidden via CSS and are also omitted from the render tree; for example, the span node---in the example above---is missing from the render tree because we have an explicit rule that sets the "display: none" property on it.
For each visible node, find the appropriate matching CSSOM rules and apply them.
Emit visible nodes with content and their computed styles.

The final output is a render tree that contains both the content and style information of all the visible content on the screen. With the render tree in place, we can proceed to the "layout" stage.

Up to this point we've calculated which nodes should be visible and their computed styles, but we have not calculated their exact position and size within the viewport of the device---that's the "layout" stage, also known as "reflow."

To figure out the exact size and position of each object on the page, the browser begins at the root of the render tree and traverses it. Let's consider a simple, hands-on example:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critial Path: Hello world!</title>
  </head>
  <body>
    <div style="width: 50%">
      <div style="width: 50%">Hello world!</div>
    </div>
  </body>
</html>

Try it

The body of the above page contains two nested div's: the first (parent) div sets the display size of the node to 50% of the viewport width, and the second div---contained by the parent---sets its width to be 50% of its parent; that is, 25% of the viewport width.

The output of the layout process is a "box model," which precisely captures the exact position and size of each element within the viewport: all of the relative measurements are converted to absolute pixels on the screen.

Finally, now that we know which nodes are visible, and their computed styles and geometry, we can pass this information to the final stage, which converts each node in the render tree to actual pixels on the screen. This step is often referred to as "painting" or "rasterizing."

This can take some time because the browser has to do quite a bit of work. However, Chrome DevTools can provide some insight into all three of the stages described above. Let's examine the layout stage for our original "hello world" example:

The "Layout" event captures the render tree construction, position, and size calculation in the Timeline.
When layout is complete, the browser issues "Paint Setup" and "Paint" events, which convert the render tree to pixels on the screen.

The time required to perform render tree construction, layout and paint varies based on the size of the document, the applied styles, and the device it is running on: the larger the document, the more work the browser has; the more complicated the styles, the more time taken for painting also (for example, a solid color is "cheap" to paint, while a drop shadow is "expensive" to compute and render).

The page is finally visible in the viewport:

Here's a quick recap of the browser's steps:

Process HTML markup and build the DOM tree.
Process CSS markup and build the CSSOM tree.
Combine the DOM and CSSOM into a render tree.
Run layout on the render tree to compute geometry of each node.
Paint the individual nodes to the screen.

Our demo page may look simple, but it requires quite a bit of work. If either the DOM or CSSOM were modified, you would have to repeat the process in order to figure out which pixels would need to be re-rendered on the screen.

Optimizing the critical rendering path is the process of minimizing the total amount of time spent performing steps 1 through 5 in the above sequence. Doing so renders content to the screen as quickly as possible and also reduces the amount of time between screen updates after the initial render; that is, achieve higher refresh rates for interactive content.

Feedback #

Critical Rendering Path

2014-03-31T00:00:00Z

Optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.

Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from us as web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen?

Optimizing for performance is all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels - that's the critical rendering path.

By optimizing the critical rendering path we can significantly improve the time to first render of our pages. Further, understanding the critical rendering path also serves as a foundation for building well-performing interactive applications. The interactive updates process is the same, just done in a continuous loop and ideally at 60 frames per second! But first, an overview of how the browser displays a simple page.

Critical Rendering Path #

You will learn how to optimize any website for speed by diving into the details of how mobile and desktop browsers render pages. You’ll learn about the Critical Rendering Path, or the set of steps browsers must take to convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance and simple strategies to deliver the first pixels to the screen as early as possible. You’ll learn how to dive into recommendations from PageSpeed Insights and the Timeline view of Google Chrome’s Developer Tools to find the data you need to achieve immediate performance boosts!

This is a free course offered through Udacity.

Additional resources #

Feedback #

Optimizing Encoding and Transfer Size of Text-Based Assets

2014-03-31T00:00:00Z

Next to eliminating unnecessary resource downloads, the best thing you can do to improve page-load speed is to minimize the overall download size by optimizing and compressing the remaining resources.

Data compression 101 #

After you’ve eliminated any unnecessary resources, the next step is to compress the remaining resources that the browser has to download. Depending on the resource type—text, images, fonts, and so on—there are many different techniques to choose from: generic tools that can be enabled on the server, pre-processing optimizations for specific content types, and resource-specific optimizations that require input from the developer.

Delivering the best performance requires a combination of all of these techniques.

Summary #

Compression is the process of encoding information using fewer bits.
Eliminating unnecessary data always yields the best results.
There are many different compression techniques and algorithms.
You will need a variety of techniques to achieve the best compression.

The process of reducing the size of data is data compression. Many people have contributed algorithms, techniques, and optimizations to improve compression ratios, speed, and memory requirements of various compressors. A full discussion of data compression is beyond the scope of this topic. However, it's important to understand, at a high level, how compression works and the techniques you can use to reduce the size of various assets that your pages require.

To illustrate the core principles of these techniques, consider the process of optimizing a simple text message format that was invented just for this example:

    # Below is a secret message, which consists of a set of headers in
    # key-value format followed by a newline and the encrypted message.
    format: secret-cipher
    date: 08/25/16
    AAAZZBBBBEEEMMM EEETTTAAA

Messages may contain arbitrary annotations, which are indicated by the "#" prefix. Annotations do not affect the meaning or any other behavior of the message.
Messages may contain headers, which are key-value pairs (separated by ":") that appear at the beginning of the message.
Messages carry text payloads.

What can you do to reduce the size of the above message, which is currently 200 characters?

The comment is interesting, but it doesn’t actually affect the meaning of the message. Eliminate it when transmitting the message.
There are good techniques to encode headers in an efficient manner. For example, if you know that all messages have "format" and "date," you could convert those to short integer IDs and just send those. However, that might not be true, so just leave it alone for now.
The payload is text only, and while we don’t know what the contents of it really are (apparently, it’s using a "secret-message"), just looking at the text shows that there's a lot of redundancy in it. Perhaps instead of sending repeated letters, you can just count the number of repeated letters and encode them more efficiently. For example, "AAA" becomes "3A", which represents a sequence of three A’s.

Combining these techniques produces the following result:

    format: secret-cipher
    date: 08/25/16
    3A2Z4B3E3M 3E3T3A

The new message is 56 characters long, which means that you've compressed the original message by an impressive 72%.

This is all great, but how does this help us optimize our web pages? We’re not going to try to invent our compression algorithms, but, as you will see, we can use the exact same techniques and thought processes when optimizing various resources on our pages: preprocessing, context-specific optimizations, and different algorithms for different content.

Minification: preprocessing & context-specific optimizations #

Summary #

Content-specific optimizations can significantly reduce the size of delivered resources.
Content-specific optimizations are best applied as part of your build/release cycle.

The best way to compress redundant or unnecessary data is to eliminate it altogether. We can’t just delete arbitrary data, but in some contexts where we have content-specific knowledge of the data format and its properties, it's often possible to significantly reduce the size of the payload without affecting its actual meaning.

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }
      .awesome-container {
        width: 50%;
      }
    </style>
  </head>

  <body>
    <!-- awesome container content: START -->
    <div>…</div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // beacon conversion metrics
    </script>
  </body>
</html>

Try it

Consider the simple HTML page above and the three different content types that it contains: HTML markup, CSS styles, and JavaScript. Each of these content types has different rules for what constitutes valid content, different rules for indicating comments, and so on. How can we reduce the size of this page?

Code comments are a developer’s best friend, but the browser doesn't need to see them! Simply stripping the CSS (/* … */), HTML (), and JavaScript (// …) comments can significantly reduce the total size of the page.
A "smart" CSS compressor could notice that we’re using an inefficient way of defining rules for ".awesome-container" and collapse the two declarations into one without affecting any other styles, saving more bytes.
Whitespace (spaces and tabs) is a developer convenience in HTML, CSS, and JavaScript. An additional compressor could strip out all the tabs and spaces.

<html>
  <head>
    <style>
      .awesome-container {
        font-size: 120%;
        width: 50%;
      }
    </style>
  </head>
  <body>
    <div>…</div>
    <script>
      awesomeAnalytics();
    </script>
  </body>
</html>

Try it

After applying the above steps, the page goes from 406 to 150 characters, a 63% compression savings. Granted, it’s not very readable, but it also doesn’t have to be: you can keep the original page as your "development version" and then apply the steps above whenever you're ready to release the page on your website.

Taking a step back, the above example illustrates an important point: a general-purpose compressor—say, one designed to compress arbitrary text—could probably do a pretty good job of compressing the page above, but it would never know to strip the comments, collapse the CSS rules, or dozens of other content-specific optimizations. This is why preprocessing/minification/context-aware optimization can be such a powerful tool.

Similarly, the techniques described above can be extended beyond just text-based assets. Images, video, and other content types all contain their own forms of metadata and various payloads. For example, whenever you take a picture with a camera, the photo also typically embeds a lot of extra information: camera settings, location, and so on. Depending on your application, this data might be critical (for example, a photo-sharing site) or completely useless, and you should consider whether it is worth removing. In practice, this metadata can add up to tens of kilobytes for every image.

In short, as a first step in optimizing the efficiency of your assets, build an inventory of the different content types and consider what kinds of content-specific optimizations you can apply to reduce their size. Then, after you’ve figured out what they are, automate these optimizations by adding them to your build and release processes to ensure that the optimizations are applied.

Text compression with GZIP #

Summary #

GZIP performs best on text-based assets: CSS, JavaScript, HTML.
All modern browsers support GZIP compression and will automatically request it.
Your server must be configured to enable GZIP compression.
Some CDNs require special care to ensure that GZIP is enabled.

GZIP is a generic compressor that can be applied to any stream of bytes. Under the hood, it remembers some of the previously seen content and attempts to find and replace duplicate data fragments in an efficient way. (If you're curious, here's a great low-level explanation of GZIP.) However, in practice, GZIP performs best on text-based content, often achieving compression rates of as high as 70-90% for larger files, whereas running GZIP on assets that are already compressed via alternative algorithms (for example, most image formats) yields little to no improvement.

All modern browsers support and automatically negotiate GZIP compression for all HTTP requests. You must ensure that the server is properly configured to serve the compressed resource when the client requests it.

Library	Size	Compressed size	Compression ratio
jquery-1.11.0.js	276 KB	82 KB	70%
jquery-1.11.0.min.js	94 KB	33 KB	65%
angular-1.2.15.js	729 KB	182 KB	75%
angular-1.2.15.min.js	101 KB	37 KB	63%
bootstrap-3.1.1.css	118 KB	18 KB	85%
bootstrap-3.1.1.min.css	98 KB	17 KB	83%
foundation-5.css	186 KB	22 KB	88%
foundation-5.min.css	146 KB	18 KB	88%

The above table shows the savings that GZIP compression produces for a few of the most popular JavaScript libraries and CSS frameworks. The savings range from 60 to 88%, and the combination of minified files (identified by “.min” in their filenames), plus GZIP, offers even more savings.

Apply content-specific optimizations first: CSS, JS, and HTML minifiers.
Apply GZIP to compress the minified output.

Enabling GZIP is one of the simplest and highest-payoff optimizations to implement, and yet, many people don't implement it. Most web servers compress content on your behalf, and you just need to verify that the server is correctly configured to compress all the content types that benefit from GZIP compression.

The HTML5 Boilerplate project contains sample configuration files for all the most popular servers with detailed comments for each configuration flag and setting. To determine the best configuration for your server, do the following:

Find your favorite server in the list.
Look for the GZIP section.
Confirm that your server is configured with the recommended settings.

A quick and simple way to see GZIP in action is to open Chrome DevTools and inspect the “Size / Content” column in the Network panel: “Size” indicates the transfer size of the asset, and “Content” the uncompressed size of the asset. For the HTML asset in the preceding example, GZIP saved 98.8 KB during the transfer.

Finally, while most servers automatically compress the assets for you when serving them to the user, some CDNs require extra care and manual effort to ensure that the GZIP asset is served. Audit your site and ensure that your assets are, in fact, being compressed.

Feedback #

Optimizing Content Efficiency

2014-03-31T00:00:00Z

Our web applications continue to grow in their scope, ambition, and functionality -- that's a good thing. However, the relentless march toward a richer web is driving another trend: the amount of data downloaded by each application continues to increase at a steady pace. To deliver great performance we need to optimize delivery of each and every byte!

What does a modern web application look like? HTTP Archive can help us answer this question. The project tracks how the web is built by periodically crawling the most popular sites (300,000+ from the Alexa Top 1M list) and recording and aggregating analytics on the number of resources, content types, and other metadata for each individual destination.

	50th percentile	75th percentile	90th percentile
HTML	13 KB	26 KB	54 KB
Images	528 KB	1213 KB	2384 KB
JavaScript	207 KB	385 KB	587 KB
CSS	24 KB	53 KB	108 KB
Other	282 KB	308 KB	353 KB
Total	1054 KB	1985 KB	3486 KB

The above data captures the trend in growth of number of downloaded bytes for popular destinations on the web between January 2013 and January 2014. Of course, not every site grows at the same rate or requires the same amount of data, hence the reason why we are highlighting the different quantiles within the distribution: 50th (median), 75th, and 90th.

A median site at the beginning of 2014 is composed of 75 requests that add up to 1054 KB of total transferred bytes, and the total number of bytes (and requests) has grown at a steady pace throughout the previous year. This by itself should not be all that surprising, but it does carry important performance implications: yes, internet speeds are getting faster, but they are getting faster at different rates in different countries, and many users are still subject to data caps and expensive metered plans - especially on mobile.

Unlike their desktop counterparts, web applications do not require a separate installation process: enter the URL and we are up and running -- that’s a key feature of the web. However, to make this happen we often have to fetch dozens, and sometime hundreds, of various resources, all of which can add up to megabytes of data and must come together in hundreds of milliseconds to facilitate the instant web experience we are aiming for.

Achieving an instant web experience in light of these requirements is no small feat, which is why optimizing content efficiency is critical: eliminating unnecessary downloads, optimizing transfer encoding of each resource through various compression techniques, and leveraging caching whenever possible to eliminate redundant downloads.

Adding Interactivity with JavaScript

2013-12-31T00:00:00Z

JavaScript allows us to modify just about every aspect of the page: content, styling, and its response to user interaction. However, JavaScript can also block DOM construction and delay when the page is rendered. To deliver optimal performance, make your JavaScript async and eliminate any unnecessary JavaScript from the critical rendering path.

Summary #

JavaScript can query and modify the DOM and the CSSOM.
JavaScript execution blocks on the CSSOM.
JavaScript blocks DOM construction unless explicitly declared as async.

JavaScript is a dynamic language that runs in a browser and allows us to alter just about every aspect of how the page behaves: we can modify content by adding and removing elements from the DOM tree; we can modify the CSSOM properties of each element; we can handle user input; and much more. To illustrate this, let's augment our previous "Hello World" example with a simple inline script:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <title>Critical Path: Script</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script>
      var span = document.getElementsByTagName('span')[0];
      span.textContent = 'interactive'; // change DOM text content
      span.style.display = 'inline'; // change CSSOM property
      // create a new element, style it, and append it to the DOM
      var loadTime = document.createElement('div');
      loadTime.textContent = 'You loaded this page on: ' + new Date();
      loadTime.style.color = 'blue';
      document.body.appendChild(loadTime);
    </script>
  </body>
</html>

Try it

JavaScript allows us to reach into the DOM and pull out the reference to the hidden span node; the node may not be visible in the render tree, but it's still there in the DOM. Then, when we have the reference, we can change its text (via .textContent), and even override its calculated display style property from "none" to "inline." Now our page displays "Hello interactive students!".
JavaScript also allows us to create, style, append, and remove new elements in the DOM. Technically, our entire page could be just one big JavaScript file that creates and styles the elements one by one. Although that would work, in practice using HTML and CSS is much easier. In the second part of our JavaScript function we create a new div element, set its text content, style it, and append it to the body.

With that, we've modified the content and the CSS style of an existing DOM node, and added an entirely new node to the document. Our page won't win any design awards, but it illustrates the power and flexibility that JavaScript affords us.

However, while JavaScript affords us lots of power, it creates lots of additional limitations on how and when the page is rendered.

First, notice that in the above example our inline script is near the bottom of the page. Why? Well, you should try it yourself, but if we move the script above the span element, you'll notice that the script fails and complains that it cannot find a reference to any span elements in the document; that is, getElementsByTagName(‘span') returns null. This demonstrates an important property: our script is executed at the exact point where it is inserted in the document. When the HTML parser encounters a script tag, it pauses its process of constructing the DOM and yields control to the JavaScript engine; after the JavaScript engine finishes running, the browser then picks up where it left off and resumes DOM construction.

In other words, our script block can't find any elements later in the page because they haven't been processed yet! Or, put slightly differently: executing our inline script blocks DOM construction, which also delays the initial render.

Another subtle property of introducing scripts into our page is that they can read and modify not just the DOM, but also the CSSOM properties. In fact, that's exactly what we're doing in our example when we change the display property of the span element from none to inline. The end result? We now have a race condition.

What if the browser hasn't finished downloading and building the CSSOM when we want to run our script? The answer is simple and not very good for performance: the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.

In short, JavaScript introduces a lot of new dependencies between the DOM, the CSSOM, and JavaScript execution. This can cause the browser significant delays in processing and rendering the page on the screen:

The location of the script in the document is significant.
When the browser encounters a script tag, DOM construction pauses until the script finishes executing.
JavaScript can query and modify the DOM and the CSSOM.
JavaScript execution pauses until the CSSOM is ready.

To a large degree, "optimizing the critical rendering path" refers to understanding and optimizing the dependency graph between HTML, CSS, and JavaScript.

Parser blocking versus asynchronous JavaScript #

By default, JavaScript execution is "parser blocking": when the browser encounters a script in the document it must pause DOM construction, hand over control to the JavaScript runtime, and let the script execute before proceeding with DOM construction. We saw this in action with an inline script in our earlier example. In fact, inline scripts are always parser blocking unless you write additional code to defer their execution.

What about scripts included via a script tag? Let's take our previous example and extract the code into a separate file:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <title>Critical Path: Script External</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js"></script>
  </body>
</html>

app.js

var span = document.getElementsByTagName('span')[0];
span.textContent = 'interactive'; // change DOM text content
span.style.display = 'inline'; // change CSSOM property
// create a new element, style it, and append it to the DOM
var loadTime = document.createElement('div');
loadTime.textContent = 'You loaded this page on: ' + new Date();
loadTime.style.color = 'blue';
document.body.appendChild(loadTime);

Try it

Whether we use a <script> tag or an inline JavaScript snippet, you'd expect both to behave the same way. In both cases, the browser pauses and executes the script before it can process the remainder of the document. However, in the case of an external JavaScript file the browser must pause to wait for the script to be fetched from disk, cache, or a remote server, which can add tens to thousands of milliseconds of delay to the critical rendering path.

By default all JavaScript is parser blocking. Because the browser does not know what the script is planning to do on the page, it assumes the worst case scenario and blocks the parser. A signal to the browser that the script does not need to be executed at the exact point where it's referenced allows the browser to continue to construct the DOM and let the script execute when it is ready; for example, after the file is fetched from cache or a remote server.

To achieve this, we mark our script as async:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <title>Critical Path: Script Async</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

Try it

Adding the async keyword to the script tag tells the browser not to block DOM construction while it waits for the script to become available, which can significantly improve performance.

Ilya Grigorik on web.dev

Reduce web font size

Anatomy of a web font #

Web font formats #

Web fonts and compression #

Define a font family with @font-face #

Consider a variable font #

Select the right format #

Unicode-range subsetting #

Font selection and synthesis #

Web font size optimization checklist #

Effects on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) #

Optimize WebFont loading and rendering

The default behavior #

Preload your WebFont resources #

Customize the text rendering delay #

The Font Loading API #

Proper caching is a must #

WebFont loading checklist #

Automated testing for WebFont loading behavior with Lighthouse #

Prevent unnecessary network requests with the HTTP Cache

Browser compatibility #

How the HTTP Cache works #

Request headers: stick with the defaults (usually) #

Response headers: configure your web server #

Which response header values should you use? #

Long-lived caching for versioned URLs #

Server revalidation for unversioned URLs #

Summary #

Learn more #

Appendix: More tips #

Appendix: Cache-Control flowchart #

Appendix: Cache-Control examples #

Choose the right image format

Choose the right image format #

Implications of high-resolution screens #

Features of different raster image formats #

Impact on Largest Contentful Paint (LCP) #

Choose the correct level of compression

Optimizing vector images #

Lossless versus lossy image compression #

Effects of image compression on Core Web Vitals #

Image optimization checklist #

PageSpeed Rules and Recommendations

Eliminate render-blocking JavaScript and CSS #

Optimize JavaScript use #

Prefer asynchronous JavaScript resources #

Avoid synchronous server calls #

Defer parsing JavaScript #

Avoid long running JavaScript #

Optimize CSS Use #

Put CSS in the document head #

Avoid CSS imports #

Inline render-blocking CSS #

Feedback #

Introduction to HTTP/2

Why not HTTP/1.2? #

A brief history of SPDY and HTTP/2 #

Design and technical goals #

Binary framing layer #

Streams, messages, and frames #

Request and response multiplexing #

Stream prioritization #

One connection per origin #

Flow control #

Server push #

PUSH_PROMISE 101 #

Header compression #

Security and performance of HPACK #

Further reading #

Feedback #

Delivering Fast and Light Applications with Save-Data

The need for lightweight pages #

The Save-Data request header #

Browser support #

Detecting the Save-Data setting #

Implementation tips and best practices #

Recipes #

Checking for Save-Data in server side code #

Serve low resolution images for high resolution screens #

Define a font family with `@font-face` #

Appendix: `Cache-Control` flowchart #

Appendix: `Cache-Control` examples #

The `Save-Data` request header #

Detecting the `Save-Data` setting #

Checking for `Save-Data` in server side code #