Speed at scale: what's new in web performance?

Learn about three new web performance launches from I/O 2019.

Addy Osmani
Addy Osmani
Katie Hempenius
Katie Hempenius

During the "Speed at Scale" talk at Google I/O 2019, we announced three things that we hope will improve web performance over the coming year.

Lighthouse now supports Performance Budgeting

LightWallet is a new feature in Lighthouse that adds support for performance budgets. Performance budgets establish standards for the performance of your site. More importantly, they make it is easy to identify and fix performance regressions before they ship.

A LightWallet report showing which assets are over the file size budget.

LightWallet is available in the newest version of the Lighthouse CLI and only takes a couple minutes to set up. These instructions provide more information.

Unsure what your budgets should be? Try our experimental Performance Budget Calculator which can generate a LightWallet compatible budget configuration.

Browser-level image and iframe lazy loading comes to the web

Web pages often contain a large number of images, which contribute to data-usage, page-bloat and slower page loads. Many of these images are offscreen, requiring a user to scroll in order to view them.

Until now, you've needed to solve lazy loading images using a JavaScript library but that may soon change. This summer, Chrome will be launching support for the loading attribute which brings standardized <img> and <iframe> lazy loading to the web.

Browser-level lazy-loading highlighting offscreen content being loaded on-demand

The loading attribute allows a browser to defer loading offscreen images and iframes until users scroll near them. loading supports three values:

  • lazy: is a good candidate for lazy loading.
  • eager: is not a good candidate for lazy loading. Load right away.
  • auto: browser will determine whether or not to lazily load.
<img src="io2019.jpg" loading="lazy" alt="..." />
<iframe src="video-player.html" loading="lazy"></iframe>

The exact heuristics for "when the user scrolls near" is left up to the browser. In general, our hope is that browsers will start fetching deferred images and iframe content a little before it comes into the viewport.

The loading attribute is implemented behind flags in Chrome Canary. You can try out this demo in Chrome 75+ with the about://flags/#enable-lazy-image-loading and about://flags/#enable-lazy-frame-loading flags turned on.

A write-up on the lazy loading feature is available with more details.

Google Fonts now supports font-display as a query parameter

We announced support for font-display is now available in production for all Google Fonts via the display query-string parameter:

https://fonts.googleapis.com/css?family=Lobster&display=swap

The font-display descriptor lets you decide how your web fonts will render or fallback, depending on how long it takes for them to load. It supports a number of values including auto, block, swap, fallback and optional.

Previously, the only way to specify font-display for web fonts from Google Fonts was to self-host them but this change removes the need to do so.

The Google Fonts documentation has been updated to include font-display in the default code embeds (as seem below). We hope this will encourage more developers to try out this exciting addition.

Google Fonts embed code with font-display included in the URL as a query-parameter

Here's a demo on Glitch of using display with multiple font families. Try it out with DevTools network emulation to see the impact of font-display: swap.

Watch for more

Our talk also covered several production case studies of using advanced performance patterns to improve user-experience. These included sites leveraging image CDNs, Brotli compression, smart JavaScript serving and prefetching to speed up their pages. Watch the talk to learn more :)