Houssein Djirdeh on web.dev

Publish, ship, and install modern JavaScript for faster applications

2020-12-10T00:00:00Z

Over 90% of browsers are capable of running modern JavaScript, but the prevalence of legacy JavaScript remains a large source of performance problems on the web today.

Modern JavaScript #

Modern JavaScript is not characterized as code written in a specific ECMAScript specification version, but rather in syntax that is supported by all modern browsers. Modern web browsers like Chrome, Edge, Firefox, and Safari make up more than 90% of the browser market, and different browsers that rely on the same underlying rendering engines make up an additional 5%. This means that 95% of global web traffic comes from browsers that support the most widely used JavaScript language features from the past 10 years, including:

Classes (ES2015)
Arrow functions (ES2015)
Generators (ES2015)
Block scoping (ES2015)
Destructuring (ES2015)
Rest and spread parameters (ES2015)
Object shorthand (ES2015)
Async/await (ES2017)

Features in newer versions of the language specification generally have less consistent support across modern browsers. For example, many ES2020 and ES2021 features are only supported in 70% of the browser market—still the majority of browsers, but not enough that it's safe to rely on those features directly. This means that although "modern" JavaScript is a moving target, ES2017 has the widest range of browser compatibility while including most of the commonly used modern syntax features. In other words, ES2017 is the closest to modern syntax today.

Legacy JavaScript #

Legacy JavaScript is code that specifically avoids using all the above language features. Most developers write their source code using modern syntax, but compile everything to legacy syntax for increased browser support. Compiling to legacy syntax does increase browser support, however the effect is often smaller than we realize. In many cases the support increases from around 95% to 98% while incurring a significant cost:

Legacy JavaScript is typically around 20% larger and slower than equivalent modern code. Tooling deficiencies and misconfiguration often widen this gap even further.
Installed libraries account for as much as 90% of typical production JavaScript code. Library code incurs an even higher legacy JavaScript overhead due to polyfill and helper duplication that could be avoided by publishing modern code.

Modern JavaScript on npm #

Recently, Node.js has standardized an "exports" field to define entry points for a package:

{
  "exports": "./index.js"
}

Modules referenced by the "exports" field imply a Node version of at least 12.8, which supports ES2019. This means that any module referenced using the "exports" field can be written in modern JavaScript. Package consumers must assume modules with an "exports" field contain modern code and transpile if necessary.

Modern-only #

If you want to publish a package with modern code and leave it up to the consumer to handle transpiling it when they use it as a dependency—use only the "exports" field.

{
  "name": "foo",
  "exports": "./modern.js"
}

Modern with legacy fallback #

Use the "exports" field along with "main" in order to publish your package using modern code but also include an ES5 + CommonJS fallback for legacy browsers.

{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs"
}

Modern with legacy fallback and ESM bundler optimizations #

In addition to defining a fallback CommonJS entrypoint, the "module" field can be used to point to a similar legacy fallback bundle, but one that uses JavaScript module syntax (import and export).

{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs",
  "module": "./module.js"
}

Many bundlers, such as webpack and Rollup, rely on this field to take advantage of module features and enable tree shaking. This is still a legacy bundle that does not contain any modern code aside from import/export syntax, so use this approach to ship modern code with a legacy fallback that is still optimized for bundling.

Modern JavaScript in applications #

Third-party dependencies make up the vast majority of typical production JavaScript code in web applications. While npm dependencies have historically been published as legacy ES5 syntax, this is no longer a safe assumption and risks dependency updates breaking browser support in your application.

With an increasing number of npm packages moving to modern JavaScript, it's important to ensure that the build tooling is set up to handle them. There's a good chance some of the npm packages you depend on are already using modern language features. There are a number of options available to use modern code from npm without breaking your application in older browsers, but the general idea is to have the build system transpile dependencies to the same syntax target as your source code.

webpack #

As of webpack 5, it is now possible to configure what syntax webpack will use when generating code for bundles and modules. This doesn't transpile your code or dependencies, it only affects the "glue" code generated by webpack. To specify the browser support target, add a browserslist configuration to your project, or do it directly in your webpack configuration:

module.exports = {
  target: ['web', 'es2017'],
};

It is also possible to configure webpack to generate optimized bundles that omit unnecessary wrapper functions when targeting a modern ES Modules environment. This also configures webpack to load code-split bundles using <script type="module">.

module.exports = {
  target: ['web', 'es2017'],
  output: {
    module: true,
  },
  experiments: {
    outputModule: true,
  },
};

There are a number of webpack plugins available that make it possible to compile and ship modern JavaScript while still supporting legacy browsers, such as Optimize Plugin and BabelEsmPlugin.

Optimize Plugin #

Optimize Plugin is a webpack plugin that transforms final bundled code from modern to legacy JavaScript instead of each individual source file. It's a self-contained setup that allows your webpack configuration to assume everything is modern JavaScript with no special branching for multiple outputs or syntaxes.

Since Optimize Plugin operates on bundles instead of individual modules, it processes your application's code and your dependencies equally. This makes it safe to use modern JavaScript dependencies from npm, because their code will be bundled and transpiled to the correct syntax. It can also be faster than traditional solutions involving two compilation steps, while still generating separate bundles for modern and legacy browsers. The two sets of bundles are designed to be loaded using the module/nomodule pattern.

// webpack.config.js
const OptimizePlugin = require('optimize-plugin');

module.exports = {
  // ...
  plugins: [new OptimizePlugin()],
};

Optimize Plugin can be faster and more efficient than custom webpack configurations, which typically bundle modern and legacy code separately. It also handles running Babel for you, and minifies bundles using Terser with separate optimal settings for the modern and legacy outputs. Finally, polyfills needed by the generated legacy bundles are extracted into a dedicated script so they are never duplicated or unnecessarily loaded in newer browsers.

Comparison: transpiling source modules twice versus transpiling generated bundles.

BabelEsmPlugin #

BabelEsmPlugin is a webpack plugin that works along with @babel/preset-env to generate modern versions of existing bundles to ship less transpiled code to modern browsers. It is the most popular off-the-shelf solution for module/nomodule, used by Next.js and Preact CLI.

// webpack.config.js
const BabelEsmPlugin = require('babel-esm-plugin');

module.exports = {
  //...
  module: {
    rules: [
      // your existing babel-loader configuration:
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
  plugins: [new BabelEsmPlugin()],
};

BabelEsmPlugin supports a wide array of webpack configurations, because it runs two largely separate builds of your application. Compiling twice can take a little bit of extra time for large applications, however this technique allows BabelEsmPlugin to integrate seamlessly into existing webpack configurations and makes it one of the most convenient options available.

Configure babel-loader to transpile node_modules #

If you are using babel-loader without one of the previous two plugins, there's an important step required in order to consume modern JavaScript npm modules. Defining two separate babel-loader configurations makes it possible to automatically compile modern language features found in node_modules to ES2017, while still transpiling your own first-party code with the Babel plugins and presets defined in your project's configuration. This doesn't generate modern and legacy bundles for a module/nomodule setup, but it does make it possible to install and use npm packages that contain modern JavaScript without breaking older browsers.

webpack-plugin-modern-npm uses this technique to compile npm dependencies that have an "exports" field in their package.json, since these may contain modern syntax:

// webpack.config.js
const ModernNpmPlugin = require('webpack-plugin-modern-npm');

module.exports = {
  plugins: [
    // auto-transpile modern stuff found in node_modules
    new ModernNpmPlugin(),
  ],
};

Alternatively, you can implement the technique manually in your webpack configuration by checking for an "exports" field in the package.json of modules as they are resolved. Omitting caching for brevity, a custom implementation might look like this:

// webpack.config.js
module.exports = {
  module: {
    rules: [
      // Transpile for your own first-party code:
      {
        test: /\.js$/i,
        loader: 'babel-loader',
        exclude: /node_modules/,
      },
      // Transpile modern dependencies:
      {
        test: /\.js$/i,
        include(file) {
          let dir = file.match(/^.*[/\\]node_modules[/\\](@.*?[/\\])?.*?[/\\]/);
          try {
            return dir && !!require(dir[0] + 'package.json').exports;
          } catch (e) {}
        },
        use: {
          loader: 'babel-loader',
          options: {
            babelrc: false,
            configFile: false,
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
};

When using this approach, you'll need to ensure modern syntax is supported by your minifier. Both Terser and uglify-es have an option to specify {ecma: 2017} in order to preserve and in some cases generate ES2017 syntax during compression and formatting.

Rollup #

Rollup has built-in support for generating multiple sets of bundles as part of a single build, and generates modern code by default. As a result, Rollup can be configured to generate modern and legacy bundles with the official plugins you're likely already using.

@rollup/plugin-babel #

If you use Rollup, the getBabelOutputPlugin() method (provided by Rollup's official Babel plugin) transforms the code in generated bundles rather than individual source modules. Rollup has built-in support for generating multiple sets of bundles as part of a single build, each with their own plugins. You can use this to produce different bundles for modern and legacy by passing each through a different Babel output plugin configuration:

// rollup.config.js
import {getBabelOutputPlugin} from '@rollup/plugin-babel';

export default {
  input: 'src/index.js',
  output: [
    // modern bundles:
    {
      format: 'es',
      plugins: [
        getBabelOutputPlugin({
          presets: [
            [
              '@babel/preset-env',
              {
                targets: {esmodules: true},
                bugfixes: true,
                loose: true,
              },
            ],
          ],
        }),
      ],
    },
    // legacy (ES5) bundles:
    {
      format: 'amd',
      entryFileNames: '[name].legacy.js',
      chunkFileNames: '[name]-[hash].legacy.js',
      plugins: [
        getBabelOutputPlugin({
          presets: ['@babel/preset-env'],
        }),
      ],
    },
  ],
};

Additional build tools #

Rollup and webpack are highly-configurable, which generally means each project must update its configuration enable modern JavaScript syntax in dependencies. There are also higher-level build tools that favor convention and defaults over configuration, like Parcel, Snowpack, Vite and WMR. Most of these tools assume npm dependencies may contain modern syntax, and will transpile them to the appropriate syntax level(s) when building for production.

In addition to dedicated plugins for webpack and Rollup, modern JavaScript bundles with legacy fallbacks can be added to any project using devolution. Devolution is a standalone tool that transforms the output from a build system to produce legacy JavaScript variants, allowing bundling and transformations to assume a modern output target.

Optimize First Input Delay

2020-05-05T00:00:00Z

I clicked but nothing happened! Why can't I interact with this page? 😢

First Contentful Paint (FCP) and Largest Contentful Paint (LCP) are both metrics that measure the time it takes for content to visually render (paint) on a page. Although important, paint times do not capture load responsiveness: or how quickly a page responds to user interaction.

First Input Delay (FID) is a Core Web Vitals metric that captures a user's first impression of a site's interactivity and responsiveness. It measures the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction. FID is a field metric and cannot be simulated in a lab environment. A real user interaction is required in order to measure the response delay.

To help predict FID in the lab, we recommend Total Blocking Time (TBT). They measure different things, but improvements in TBT usually correspond to improvements in FID.

The main cause of a poor FID is heavy JavaScript execution. Optimizing how JavaScript parses, compiles, and executes on your web page will directly reduce FID.

Heavy JavaScript execution #

The browser cannot respond to most user input while it's executing JavaScript on the main thread. In other words, the browser can't respond to user interactions while the main thread is busy. To improve this:

Break up Long Tasks #

If you've already attempted to reduce the amount of JavaScript that loads on a single page, it can be useful to break down long-running code into smaller, asynchronous tasks.

Long Tasks are JavaScript execution periods where users may find your UI unresponsive. Any piece of code that blocks the main thread for 50 ms or more can be characterized as a Long Task. Long Tasks are a sign of potential JavaScript bloat (loading and executing more than a user may need right now). Splitting up long tasks can reduce input delay on your site.

Chrome DevTools visualizes Long Tasks in the Performance Panel

FID should improve noticeably as you adopt best practices like code-splitting and breaking up your Long Tasks. While TBT is not a field metric, it's useful for checking progress towards ultimately improving both Time To Interactive (TTI) and FID.

Optimize your page for interaction readiness #

There are a number of common causes for poor FID and TBT scores in web apps that rely heavily on JavaScript:

First-party script execution can delay interaction readiness #

JavaScript size bloat, heavy execution times and inefficient chunking can slow down how soon a page can respond to user input and impact FID, TBT, and TTI. Progressive loading of code and features can help spread this work out and improve interaction readiness.
Server-side rendered apps may look like they're getting pixels painted on the screen quickly, but beware of user interactions being blocked by large script executions (e.g. re-hydration to wire up event listeners). This can take several hundred milliseconds, sometimes even seconds, if route-based code splitting is being used. Consider shifting more logic server-side or generating more content statically during build time.

Below are the TBT scores before and after optimizing first-party script loading for an application. By moving costly script loading (and execution) for a non-essential component off the critical path, users were able to interact with the page much sooner.

Data-fetching can impact many aspects of interaction readiness #

Waiting on a waterfall of cascading fetches (e.g. JavaScript and data fetches for components) can impact interaction latency. Aim to minimize a reliance on cascading data fetches.
Large inline datastores can push out HTML parsing time and impact both paint and interaction metrics. Aim to minimize how much data needs to be post-processed on the client-side.

Third-party script execution can delay interaction latency too #

Many sites include third-party tags and analytics which can keep the network busy and make the main thread periodically unresponsive, impacting interaction latency. Explore on-demand loading of third-party code (e.g. maybe don't load those below-the-fold ads until they're scrolled closer to the viewport).
In some cases, third-party scripts can pre-empt first-party ones in terms of priority and bandwidth on the main thread, also delaying how soon a page is interaction-ready. Attempt to prioritize loading what you believe offers the greatest value to users first.

Use a web worker #

A blocked main thread is one of the main causes of input delay. Web workers make it possible to run JavaScript on a background thread. Moving non-UI operations to a separate worker thread can cut down main thread blocking time and consequently improve FID.

Consider using the following libraries to make it easier to use web workers on your site:

Comlink: A helper library that abstracts postMessage and makes it easier to use
Workway: A general purpose web worker exporter
Workerize: Move a module into a web worker

Reduce JavaScript execution time #

Limiting the amount of JavaScript on your page reduces the amount of time that the browser needs to spend executing JavaScript code. This speeds up how fast the browser can begin to respond to any user interactions.

To reduce the amount of JavaScript executed on your page:

Defer unused JavaScript
Minimize unused polyfills

Defer unused JavaScript #

By default all JavaScript is render-blocking. When the browser encounters a script tag that links to an external JavaScript file, it must pause what it's doing and download, parse, compile, and execute that JavaScript. Therefore you should only load the code that's needed for the page or responding to user input.

The Coverage tab in Chrome DevTools can tell you how much JavaScript is not being used on your web page.

To cut down on unused JavaScript:

Code-split your bundle into multiple chunks
Defer any non-critical JavaScript, including third-party scripts, using async or defer

Code-splitting is the concept of splitting a single large JavaScript bundle into smaller chunks that can be conditionally loaded (also known as lazy loading). Most newer browsers support dynamic import syntax, which allows for module fetching on demand:

import('module.js').then((module) => {
  // Do something with the module.
});

Dynamically importing JavaScript on certain user interactions (such as changing a route or displaying a modal) will make sure that code not used for the initial page load is only fetched when needed.

Aside from general browser support, dynamic import syntax can be used in many different build systems.

If you use webpack, Rollup, or Parcel as a module bundler, take advantage of their dynamic import support.
Client-side frameworks, like React, Angular, and Vue provide abstractions to make it easier to lazy-load at the component-level.

Aside from code-splitting, always use async or defer for scripts that are not necessary for critical-path or above-the-fold content.

<script defer src="…"></script>
<script async src="…"></script>

Unless there is a specific reason not to, all third-party scripts should be loaded with either defer or async by default.

Minimize unused polyfills #

If you author your code using modern JavaScript syntax and reference modern browsers APIs, you will need to transpile it and include polyfills in order for it to work in older browsers.

One of the main performance concerns of including polyfills and transpiled code in your site is that newer browsers shouldn't have to download it if they do not need it. To cut down on the JavaScript size of your application, minimize unused polyfills as much as possible and restrict their usage to environments where they're needed.

To optimize polyfill usage on your site:

If you use Babel as a transpiler, use @babel/preset-env to only include the polyfills needed for the browsers you plan on targeting. For Babel 7.9, enable the bugfixes option to further cut down on any unneeded polyfills
Use the module/nomodule pattern to deliver two separate bundles (@babel/preset-env also supports this via target.esmodules)
```
<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js" defer></script>
```
Many newer ECMAScript features compiled with Babel are already supported in environments that support JavaScript modules. So by doing this, you simplify the process of making sure that only transpiled code is used for browsers that actually need it.

Developer tools #

A number of tools are available to measure and debug FID:

Lighthouse 6.0 does not include support for FID since it is a field metric. However, Total Blocking Time (TBT) can be used as a proxy. Optimizations that improve TBT should also improve FID in the field.
Chrome User Experience Report provides real-world FID values aggregated at the origin-level

With thanks to Philip Walton, Kayce Basques, Ilya Grigorik, and Annie Sullivan for their reviews.

Improved Next.js and Gatsby page load performance with granular chunking

2020-04-29T00:00:00Z

Chrome is collaborating with tooling and frameworks in the JavaScript open-source ecosystem. A number of newer optimizations were recently added to improve the loading performance of Next.js and Gatsby. This article covers an improved granular chunking strategy that is now shipped by default in both frameworks.

Introduction #

Like many web frameworks, Next.js and Gatsby use webpack as their core bundler. webpack v3 introduced CommonsChunkPlugin to make it possible to output modules shared between different entry points in a single (or few) "commons" chunk (or chunks). Shared code can be downloaded separately and stored in the browser cache early on which can result in a better loading performance.

This pattern became popular with many single-page application frameworks adopting an entrypoint and bundle configuration that looked like this:

Although practical, the concept of bundling all shared module code into a single chunk has its limitations. Modules not shared in every entry point can be downloaded for routes that do not use it resulting in more code being downloaded than necessary. For example, when page1 loads the common chunk, it loads the code for moduleC even though page1 doesn't use moduleC. For this reason, along with a few others, webpack v4 removed the plugin in favor of a new one: SplitChunksPlugin.

Improved Chunking #

The default settings for SplitChunksPlugin works well for most users. Multiple split chunks are created depending on a number of conditions to prevent fetching duplicated code across multiple routes.

However, many web frameworks that use this plugin still follow a "single-commons" approach to chunk splitting. Next.js, for example, would generate a commons bundle that contained any module that is used in more than 50% of pages and all framework dependencies (react, react-dom, and so on).

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

Although including framework-dependent code into a shared chunk means that it can be downloaded and cached for any entrypoint, the usage-based heuristic of including common modules used in more than half of pages isn't very effective. Modifying this ratio would only result in one of two outcomes:

If you reduce the ratio, more unnecessary code gets downloaded.
If you increase the ratio, more code gets duplicated across multiple routes.

To solve this problem, Next.js adopted a different configuration forSplitChunksPlugin that reduces unnecessary code for any route.

Any sufficiently large third-party module (greater than 160 KB) is split into its own individual chunk
A separate frameworks chunk is created for framework dependencies (react, react-dom, and so on)
As many shared chunks as needed are created (up to 25)
The minimum size for a chunk to be generated is changed to 20 KB

This granular chunking strategy provides the following benefits:

Page load times are improved. Emitting multiple shared chunks, instead of a single one, minimizes the amount of unneeded (or duplicate) code for any entrypoint.
Improved caching during navigations. Splitting large libraries and framework dependencies into separate chunks reduces the possibility of cache invalidation since both are unlikely to change until an upgrade is made.

You can see the entire configuration that Next.js adopted in webpack-config.ts.

More HTTP requests #

SplitChunksPlugin defined the basis for granular chunking, and applying this approach to a framework like Next.js was not an entirely new concept. Many frameworks, however, still continued to use a single heuristic and "commons" bundle strategy for a few reasons. This includes the concern that many more HTTP requests can negatively affect site performance.

Browsers can only open a limited number of TCP connections to a single origin (6 for Chrome), so minimizing the number of chunks outputted by a bundler can ensure that the total number of requests stays under this threshold. However, this only holds true for HTTP/1.1. Multiplexing in HTTP/2 allows for multiple requests to be streamed in parallel using a single connection over a single origin. In other words, we generally do not need to worry about limiting the number of chunks emitted by our bundler.

All major browsers support HTTP/2. The Chrome and Next.js teams wanted to see if increasing the number of requests by splitting Next.js's single "commons" bundle into multiple shared chunks would affect loading performance in any way. They began by measuring the performance of a single site while modifying the maximum number of parallel requests using the maxInitialRequests property.

In an average of three runs of multiple trials on a single web page, the load, start-render and First Contentful Paint times all remained about the same when varying the max initial request count (from 5 to 15). Interestingly enough, we noticed a slight performance overhead only after splitting aggressively to hundreds of requests.

This showed that staying under a reliable threshold (20~25 requests) struck the right balance between loading performance and caching efficiency. After some baseline testing, 25 was selected as the maxInitialRequest count.

Modifying the maximum number of requests that happen in parallel resulted in more than a single shared bundle, and separating them appropriately for each entry point significantly reduced the amount of unneeded code for the same page.

This experiment was only about modifying the number of requests to see if there would be any negative effect on page load performance. The results suggest that setting maxInitialRequests to 25 on the test page was optimal because it reduced the JavaScript payload size without slowing down the page. The total amount of JavaScript that was needed to hydrate the page still remained about the same, which explains why page load performance didn't necessarily improve with the reduced amount of code.

webpack uses 30 KB as a default minimum size for a chunk to be generated. However, coupling a maxInitialRequests value of 25 with a 20 KB minimum size instead resulted in better caching.

Size reductions with granular chunks #

Many frameworks, including Next.js, rely on client-side routing (handled by JavaScript) to inject newer script tags for every route transition. But how do they predetermine these dynamic chunks at build time?

Next.js uses a server-side build manifest file to determine which outputted chunks are used by different entry points. To provide this information to the client as well, an abridged client-side build manifest file was created to map all the dependencies for every entry point.

// Returns a promise for the dependencies for a particular route
getDependencies (route) {
  return this.promisedBuildManifest.then(
    man => (man[route] && man[route].map(url => `/_next/${url}`)) || []
  )
}

This newer granular chunking strategy was first rolled out in Next.js behind a flag, where it was tested on a number of early adopters. Many saw significant reductions to the total JavaScript used for their entire site:

JavaScript size reductions - across all routes (compressed)
Website	Total JS Change	% Difference
https://www.barnebys.com/	-238 KB	-23%
https://sumup.com/	-220 KB	-30%
https://www.hashicorp.com/	-11 MB	-71%

The final version was shipped by default in version 9.2.

Gatsby #

Gatsby used to follow the same approach of using a usage-based heuristic for defining common modules:

config.optimization = {
  …
  splitChunks: {
    name: false,
    chunks: `all`,
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: `commons`,
        chunks: `all`,
        // if a chunk is used more than half the components count,
        // we can assume it's pretty global
        minChunks: componentsCount > 2 ? componentsCount * 0.5 : 2,
      },
      react: {
        name: `commons`,
        chunks: `all`,
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
      },

By optimizing their webpack configuration to adopt a similar granular chunking strategy, they also noticed sizeable JavaScript reductions in many large sites:

JavaScript size reductions - across all routes (compressed)
Website	Total JS Change	% Difference
https://www.gatsbyjs.org/	-680 KB	-22%
https://www.thirdandgrove.com/	-390 KB	-25%
https://ghost.org/	-1.1 MB	-35%
https://reactjs.org/	-80 Kb	-8%

Take a look at the PR to understand how they implemented this logic into their webpack configuration, which is shipped by default in v2.20.7.

Conclusion #

The concept of shipping granular chunks is not specific to Next.js, Gatsby or even webpack. Everyone should consider improving their application's chunking strategy if it follows a large "commons" bundle approach, regardless of the framework or module bundler used.

If you would like to see the same chunking optimizations applied to a vanilla React application, take a look at this sample React app. It uses a simplified version of the granular chunking strategy and can help you start applying the same sort of logic to your site.
For Rollup, chunks are created granularly by default. Take a look at manualChunks if you would like to manually configure the behavior.

Resolving Glitch issues

2020-04-27T00:00:00Z

web.dev uses Glitch to embed web-based sample apps and development environments in its posts and codelabs. See the Sample apps post for information about how to set up a Glitch.

This post will show you how to resolve some common Glitch issues.

Project is suspended #

If you see a "Project has been suspended" message when opening a new project, contact support via their public forum or by emailing support@glitch.com. You should receive a reply soon with steps you can take to fix your project.

Exceeding disk usage #

If you see an App Status warning with exceeded disk limits, you'll need to clear up some space before you can edit and use the project.

Remove any unnecessary dependencies from package.json
In the terminal, run git gc and git prune to remove unneeded files
Run du -hd1 to to see which directories are taking up disk space

If an unneeded directory is bloating up on every build and taking up disk space:

Remove it (rm -rf directory_name)
Consider adding a prestart script in package.json to ensure it gets deleted on every build
```
"scripts": {
  "prestart": "rimraf directory_name",
  "start": "..."
},
```

If the .git directory is taking up disk space:

Run git log --name-only --format="" | cat | sort | uniq -c | sort -nbr to see which files are being committed to history (note: this will still include files previously committed even if they are now in .gitignore)

If you see any directories committed many times that shouldn't be, add them to .gitignore
If you don't need .git history, remove the .git folder (rm -rf .git)

Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fonts

2020-03-18T00:00:00Z

By optimizing rendering cycles, Chrome 83 eliminates layout shifting when preloading optional fonts. Combining <link rel="preload"> with font-display: optional is the most effective way to guarantee no layout jank when rendering custom fonts.

Browser compatibility #

Check out MDN's data for up-to-date cross-browser support information:

Font rendering #

Layout shifting, or re-layout, occurs when a resource on a web page changes dynamically, resulting in a "shift" of content. Fetching and rendering web fonts can directly cause layout shifts in one of two ways:

A fallback font is swapped with a new font ("flash of unstyled text")
"Invisible" text is shown until a new font is rendered into the page ("flash of invisible text")

The CSS font-display property provides a way to modify rendering behavior of custom fonts through a range of different supported values (auto, block, swap, fallback, and optional). Choosing which value to use depends on the preferred behavior for asynchronously loaded fonts. However, every one of these supported values can trigger re-layout in one of the two ways listed above, until now!

Optional fonts #

The font-display property uses a timeline of three periods to handle fonts that need to be downloaded before they can be rendered:

Block: Render "invisible" text, but switch to the web font as soon as it finishes loading.
Swap: Render text using a fallback system font, but switch to the web font as soon as it finishes loading.
Fail: Render text using a fallback system font.

Previously, fonts designated with font-display: optional had a 100ms block period and no swap period. This means that "invisible" text is displayed very briefly before switching to a fallback font. If the font is not downloaded within 100ms, then the fallback font is used and no swapping occurs.

Previous font-display: optional behavior in Chrome when font is downloaded after the 100ms block period

However, in the case that the font is downloaded before the 100ms block period completes, the custom font is rendered and used on the page.

Previous font-display: optional behavior in Chrome when font is downloaded before the 100ms block period

Chrome re-renders the page twice in both instances, regardless of whether the fallback font is used or if the custom font finishes loading in time. This causes a slight flicker of invisible text and, in cases when a new font is rendered, layout jank that moves some of the page's content. This occurs even if the font is stored in the browser's disk cache and can load well before the block period is complete.

Optimizations have landed in Chrome 83 to entirely remove the first render cycle for optional fonts that are preloaded with <link rel="preload'>. Instead, rendering is blocked until the custom font has finished loading or a certain period of time has passed. This timeout period is currently set at 100ms, but may possibly change in the near future to optimize performance.

New font-display: optional behavior in Chrome when fonts are preloaded and font is downloaded after the 100ms block period (no flash of invisible text)

New font-display: optional behavior in Chrome when fonts are preloaded and font is downloaded before the 100ms block period (no flash of invisible text)

Preloading optional fonts in Chrome removes the possibility of layout jank and flash of unstyled text. This matches the required behavior as specified in CSS Fonts Module Level 4 where optional fonts should never cause re-layout and user agents can instead delay rendering for a suitable period of time.

Although it is not necessary to preload an optional font, it greatly improves the chance for it to load before the first render cycle, especially if it is not yet stored in the browser's cache.

Conclusion #

The Chrome team is interested to hear your experiences preloading optional fonts with these new optimizations in place! File an issue if you experience any problems or would like to drop any feature suggestions.

Advancing the web framework ecosystem

2020-01-08T00:00:00Z

Chrome is an active contributor to the web framework ecosystem and our talk at Chrome Dev Summit 2019 covers what we've worked on in the past year.

Read on for an extended recap of the talk with additional details and resources.

How do we make the web better? #

The goal of everyone on the Chrome team is to make the web better. We work on improving browser APIs and V8--the core JavaScript and WebAssembly engine that powers Chrome--so that developers are equipped with features that help them build great web pages. We also try to improve websites that are already in production today by contributing to open-source tooling in many ways.

Most web developers rely on open source tools whenever possible and they prefer not to build entirely custom infrastructure. Client-side JavaScript frameworks and UI libraries make up a growing portion of open-source usage. Data on the three most popular client-side frameworks and libraries, React, Angular, and Vue, shows that:

72% of participants in the MDN's First Annual Web Developer & Designer Survey use at least one of these frameworks and libraries.
Over 320,000 sites in the top 5 million URLs analyzed by HTTP Archive use at least one of these frameworks and libraries.
When grouped by time spent, 30 of the top 100 URLs use at least one of these frameworks and libraries. (Research was done on internal data.)

This means that better open-source tooling can directly result in a better web and that's why Chrome engineers have started working directly with external framework and library authors.

Contributions to web frameworks #

Frameworks commonly used to build and structure web pages fall into two categories:

UI frameworks (or libraries), such as Preact, React, or Vue, which provide control over an application's view layer (through a component model for example).
Web frameworks, such as Next.js, Nuxt.js, and Gatsby, which provide an end-to-end system with opinionated features built-in, such as server-side rendering. These frameworks usually leverage a UI framework or library for the view layer.

Developers can choose not to use frameworks but by piecing together a view layer library, router, styling system, server renderer and so forth, they often end up creating their own type of a framework. Although opinionated, web frameworks take care of many of these concerns by default.

The rest of this post highlights many improvements that have recently landed in different frameworks and tools, including contributions from the Chrome team.

Angular #

The Angular team has shipped a number of improvements to version 8 of the framework:

Differential loading by default to minimize unneeded polyfills for newer browsers.

Bundle size reduction for angular.io with differential builds (from Version 8 of Angular)

Support for standard dynamic import syntax for lazy-loading routes.
Web worker support to run operations in a background thread separate from the main thread.
Ivy, Angular's new rendering engine which provides better re-compilation performance and a reduction in bundle sizes, is available in preview mode for existing projects.

You can learn more about these improvements in "Version 8 of Angular" and the Chrome team looks forward to working with them closely in the next year as more features land.

Next.js #

Next.js is a web framework that uses React as a view layer. In addition to a UI component model that many developers expect from a client-side framework, Next.js provides a number of built-in default features:

Routing with default code-splitting
Compilation and bundling (using Babel and webpack)
Server-side rendering
Mechanisms to fetch data at a per-page level
Encapsulated styling (with styled-jsx)

Next.js optimizes for reduced bundle sizes, and the Chrome team helped identify areas where we could help further improve performance. You can learn more about each of them by viewing their requests for comments (RFCs) and pull requests (PRs):

An improved webpack chunking strategy that emits more granular bundles, reducing the amount of duplicate code fetched through multiple routes (RFC, PR).
Differential loading with the module/nomodule pattern which can reduce the total amount of JavaScript in Next.js apps by up to 20% with no code changes (RFC, PR).
Improved performance metric tracking which utilizes the User Timing API (PR).

Barnebys.com, a large search engine for antiques and collectibles, saw a 23% reduction in total JavaScript after enabling granular chunking

We are also exploring other features to improve both the user and developer experience of using Next.js, such as:

Enabling concurrent mode to unlock progressive or partial hydration of components.
A webpack based conformance system that analyzes all source files and generated assets to surface better errors and warnings (RFC).

An example of a conformance build error in Next.js (prototype)

Nuxt.js #

Nuxt.js is a web framework that combines Vue.js with different libraries to provide an opinionated setup. Similar to Next.js, it includes many features out-of-the-box:

Routing with default code-splitting
Compilation and bundling (using Babel and webpack)
Server-side rendering
Asynchronous data fetching for every page
Default data store (Vuex)

Along with working directly on improving the performance of different tools, we've expanded the framework fund to provide monetary support to more open-source frameworks and libraries. With our recent support to Nuxt.js, a few features are slated to land in the near future including smarter server-rendering and image optimizations.

Babel #

We've also made progress on improving the performance of an important underlying tool in almost all of the mentioned frameworks--Babel.

Babel compiles code that contains newer syntax into code that different browsers can understand. It's become common to use @babel/preset-env to target modern browsers where different browser targets can be specified to provide enough polyfilling required for all the chosen environments. One way to specify the targets is to use <script type="module"> to target all browsers that support ES Modules.

To optimize for this case, we launched a brand new preset; @babel/preset-modules. Instead of converting modern syntax to older syntax to avoid browser bugs, preset-modules fixes each specific bug by transforming to the closest possible non-broken modern syntax. This results in modern code that can be delivered nearly unmodified to most browsers.

Developers who already use preset-env will also benefit from these optimizations without having to do anything, as they'll soon be incorporated into preset-env too.

What's next? #

Working closely with open-source frameworks and libraries to provide better experiences helps the Chrome team realize what is fundamentally important to users and developers alike.

If you work on a web framework, UI library, or any form of web tooling (bundler, compiler, linter), apply for the framework fund!

How AMP can guarantee fastness in your Next.js app

2019-11-08T00:00:00Z

AMP is a web component framework that guarantees fast page loads. Next.js has built-in support for AMP.

What will you learn? #

This guide first briefly describes how AMP guarantees fast page loads, then explains the different ways you can support AMP in a Next.js app, then helps you decide which approach is best for you.

The intended audience for this guide is a web developer who has decided to use Next.js but is unsure of whether to support AMP.

How AMP guarantees fast page loads #

AMP has two main strategies for guaranteeing fastness:

AMP HTML: A restricted form of HTML that makes certain optimizations mandatory and prohibits architectural patterns that lead to slowness. See How AMP works for a high-level overview of the optimizations and restrictions.
AMP Cache: A content cache used by some search engines, such as Google and Bing, that uses prerendering to speed up page loads. See Why AMP Caches exist to learn more about the benefits and tradeoffs of the caches and How does my AMP page get cached? to understand how your AMP pages get into the caches.

How you can use AMP in Next.js #

There are two ways to use AMP in Next.js:

The Hybrid AMP approach lets you create an accompanying AMP version of any Next.js page.
The AMP-only approach lets you make AMP the only option for a page.

Although Next.js is usually thought of as a React framework, it's important to understand that when you use Next.js to serve AMP pages, you can no longer run React components client-side because React components are not valid AMP components. In other words, Next.js is no longer a React framework but rather a server-side templating engine for generating AMP pages.

How to decide whether to use the Hybrid AMP or AMP-only approach #

If you're serious about load performance, an AMP-only page could be a good way to make sure that your page gets fast and stays fast. But here's the catch: in order to guarantee fastness, AMP prohibits certain architectural patterns and HTML elements that often lead to slow pages. For example, AMP doesn't allow custom synchronous JavaScript because render-blocking resources are a common cause of slow page loads.

In order to understand whether an AMP-only approach is right for you, you need to figure out whether all of your frontend code can be represented in AMP HTML:

Read How AMP works to understand AMP's high-level architectural restrictions and mandatory optimizations.
Read HTML Tags to see what HTML tags AMP allows and prohibits, browse the AMP component catalogue to see the custom components that the AMP community has built to solve common use cases, and check out amp-script to learn how to use custom JavaScript to implement features that AMP doesn't currently support.

Even if an AMP-only approach won't work for your page, it might still be a good idea to use AMP whenever possible, because of the guaranteed fastness of AMP HTML and the AMP Caches. The Hybrid AMP approach in Next.js provides a way to conditionally serve AMP pages. However, it also creates a higher maintenance cost because it requires you to maintain two versions of each page.

Conclusion #

AMP guarantees that your site gets fast and stays fast by enforcing patterns that lead to fastness and prohibiting patterns that lead to slowness. AMP HTML and AMP Caches are the two main ways that AMP guarantees fastness. But before adopting AMP you should make sure that it can support all of your site's requirements.

How to use AMP in Next.js

2019-11-08T00:00:00Z

What will you learn? #

This codelab lets you try out the two ways that you can use AMP in a Next.js app. Check out How AMP can guarantee fastness in your Next.js app to learn why you might want to add AMP support to your Next.js app.

How to create Hybrid AMP pages #

The Hybrid AMP approach creates an accompanying AMP version of any Next.js page. In the past the Hybrid approach was frequently used when there was an experience on the main version of your page that AMP couldn't support. The main version had the full experience while the AMP page had a slightly degraded experience. With the introduction of amp-script there's less of a need for the Hybrid approach, but we'll cover it here just in case you still need it.

There are multiple ways to configure how Next.js renders and serves pages. Using a config object allows you to modify these on a per-page basis. In order to serve a specific page as an AMP page, you need to export the amp property in the object:

import React from 'react'

export const config = { amp: 'hybrid' };

const Home = () => (
  <p>This is the home page</p>
);

export default Home;

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .
Add ?amp=1 to the end of the URL. The page looks the same, but if you look in the Console you'll see that the AMP version of the page is being rendered.

Since the page only has a single <p> tag, there's no visible difference between the main page and its AMP version.

How to conditionally serve AMP components #

AMP pages need to have their own set of valid components in place of many HTML elements. It's important to make sure that the AMP components are conditionally served only for the AMP page. Next.js provides a hook called useAmp to allow you to conditionally serve different elements depending on which version of the page was requested.

To view the source, press View Source.

Edit pages/index.js so that it renders a different paragraph element to the page depending on whether the main version or the AMP version was requested:

import React from 'react';
import { useAmp } from 'next/amp';

export const config = { amp: 'hybrid' };

const Home = () => (
  useAmp() ? (
    <p>This is the <strong>AMP</strong> version of the home page</p>
  ) : (
    <p>This is the main version of the home page</p>
  )
);

export default Home;

Load the main version of the page:
Add ?amp=1 to the end of the URL again to load the AMP version of the page:

Try rendering AMP's replacement of the image tag, amp-img:

import React from 'react';
import { useAmp } from 'next/amp';

export const config = { amp: 'hybrid' };

const imgSrc = 'https://placekitten.com/1000/1000';

const Image = () => (
  useAmp() ? (
    <amp-img alt="A cute kitten"
      src={imgSrc}
      width="1000"
      height="1000"
      layout="responsive">
    </amp-img>
  ) : (
    <img alt="A cute kitten"
      src={imgSrc}
      width="1000"
      height="1000">
    </img>
  )
);

const Home = () => (
  <div>
    <Image />
  </div>
);

export default Home;

layout="responsive" automatically renders a fully responsive image with an aspect ratio specified by width and height. Check out Layout & media queries to learn more about the supported layouts of AMP elements, and amp-img to learn more about that element's optimizations.

View the main version of the page again.
View the AMP version of the page again.

How to create AMP-only pages #

Next.js also supports AMP-only pages. With this approach, a single AMP page is served and rendered to users and search engines at all times.

To render an AMP-only page, change the value of the amp property in the config object to true.

import React from 'react'

export const config = { amp: true };

const Home = () => (
  <p>This is an AMP-only page</p>
);

export default Home;

Performance as a default with Next.js

2019-11-08T00:00:00Z

Next.js is an opinionated React framework with a number of performance optimizations baked in. The main idea behind the framework is to ensure applications start and remain as performant as possible by having these capabilities included by default.

This introduction will briefly cover many features provided by the framework at a high level. The other guides in this collection will explore the features in more detail.

What will you learn? #

Although Next.js provides a number of performance optimizations by default, these guides aim to explain them in more detail and show you how you can use them to build a fast and performant experience.

There are many optimizations that can be added to React sites in general that would also work for applications built with Next.js. These will not be covered since the focus is on what Next.js specifically provides. To learn more about general React optimizations, check out our React collection.

How is Next.js different from React? #

React is a library that makes it easier to build user interfaces using a component-based approach. Although powerful, React is specifically a UI library. Many developers include additional tooling such as a module bundler (webpack for example) and a transpiler (Babel for example) to have a complete build toolchain.

In the React collection, we took the approach of using Create React App (CRA) to spin up React apps quickly. CRA takes the hassle out of setting up a React application by providing a complete build toolchain with a single command.

Although there are a few default optimizations baked into CRA, the tool aims to provide a simple and straightforward setup. The choice is given to developers to decide whether to eject and modify the configurations themselves.

Next.js, which can also be used to create a new React application, takes a different approach. It immediately provides a number of common optimizations that many developers would like to have but find difficult to set up, such as:

Server-side rendering
Automatic code-splitting
Route prefetching
File-system routing
CSS-in-JS styling (styled-jsx)

Setting up #

To create a new Next.js application, run the following command:

npx create-next-app new-app

Then navigate to the directory and start the development server:

cd new-app
npm run dev

The following embed shows the directory structure of a new Next.js app.

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .

Notice that a pages/ directory is created with a single file: index.jsx. Next.js follows a file-system routing approach, where every page within this directory is served as a separate route. Creating a new file in this directory, such as about.js, will automatically create a new route (/about).

Components can also be created and used like any other React application. A components/ directory has already been created with a single component, nav.js, which is already imported in index.js. By default, every import used in Next.js is only fetched when that page is loaded, providing the benefits of automated code-splitting.

Moreover, every initial page load in Next.js is server-side rendered. If you open the Network panel in DevTools, you can see the initial request for the document returns a fully server-rendered page.

The Preview tab of the Network panel shows that Next.js returns visually complete HTML when a page is requested.

These are only a few of the many features provided by Next.js automatically. Many are customizable and can be modified for different use cases.

What's next? #

Pun intended 😛

Every other guide in this collection will explore a specific Next.js feature in detail:

Route prefetching to speed up page navigations
Serving hybrid and AMP-only pages for faster loading from search engines
Code-splitting components with dynamic imports to reduce JavaScript footprints

Browser-level image lazy loading for the web

2019-08-06T00:00:00Z

Browser-level support for lazy loading images is now supported on the web! This video shows a demo of the feature:

You can use the loading attribute to lazy-load images without the need to write custom lazy loading code or use a separate JavaScript library. Let's dive into the details.

Browser compatibility #

Browser support

Chrome 77, Supported 77
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Browsers that do not support the loading attribute simply ignore it without side effects.

Why browser-level lazy loading? #

According to the HTTP Archive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send over 5 MB of images on desktop and mobile. That's a lot of cat pictures.

Previously, there were two ways to defer the loading of off-screen images:

Using the Intersection Observer API
Using scroll, resize, or orientationchange event handlers

Either option can let developers include lazy loading functionality, and many developers have built third-party libraries to provide abstractions that are even easier to use. With lazy loading supported directly by the browser, however, there's no need for an external library. Browser-level lazymloading also ensures that deferred loading of images still works even if JavaScript is disabled on the client.

The `loading` attribute #

Chrome loads images at different priorities depending on where they're located with respect to the device viewport. Images below the viewport are loaded with a lower priority, but they're still fetched as the page loads.

You can use the loading attribute to completely defer the loading of offscreen images that are reached by scrolling:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Here are the supported values for the loading attribute:

lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.
eager: Default loading behavior of the browser, which is the same as not including the attribute and means the image is loaded regardless of where it's located on the page. While this is the default, it can be useful to explicitly set this if your tooling automatically adds loading="lazy" if there is no explicit value, or if your linter complains if it is not explicitly set.

Relationship between the `loading` attribute and fetch priority #

The eager value is simply an instruction to load the image as usual, without delaying the load further if it is off-screen. It does not imply that the image is loaded any quicker than another image without the loading="eager" attribute.

Browsers prioritize resources based on various heuristics, and the loading attribute just states when the image resource is queued, not how it is prioritized in that queue. eager just implies the usual eager queueing browsers use by default.

If you want to increase the fetch priority of an important image (for example the LCP image), then Fetch Priority should be used with fetchpriority="high".

Note that an image with loading="lazy" and fetchpriority="high" will still be delayed while it is off-screen, and then fetched with a high priority when it is nearly within the viewport. It would likely be fetched with a high priority in this case anyway, so this combination should not really be needed nor used.

Distance-from-viewport thresholds #

All images that are above the fold—that is, immediately viewable without scrolling—load normally. Those that are far below the device viewport are only fetched when the user scrolls near them.

Chromium's implementation of lazy loading tries to ensure that offscreen images are loaded early enough so that they have finished loading once the user scrolls near to them. By fetching nearby images well before they become visible in the viewport, we maximize the chance they are already loaded by the time they become visible.

Compared to JavaScript lazy loading libraries, the thresholds for fetching images that scroll into view may be considered conservative.

The distance threshold is not fixed and varies depending on several factors:

The type of image resource being fetched
The effective connection type

You can find the default values for the different effective connection types in the Chromium source. These numbers, and even the approach of fetching only when a certain distance from the viewport is reached, may change in the future as the Chrome team improves heuristics to determine when to begin loading.

Improved data-savings and distance-from-viewport thresholds #

As of July 2020, Chrome has made significant improvements to align the image lazy loading distance-from-viewport thresholds to better meet developer expectations.

On fast connections (4G), we reduced Chrome's distance-from-viewport thresholds from 3000px to 1250px and on slower connections (3G or lower), changed the threshold from 4000px to 2500px. This change achieves two things:

<img loading=lazy> behaves closer to the experience offered by JavaScript lazy loading libraries.
The new distance-from-viewport thresholds still allow us to guarantee images have probably loaded by the time a user has scrolled to them.

You can find a comparison between the old vs. new distance-from-viewport thresholds for one of our demos on a fast connection (4G) below:

Old thresholds. vs new thresholds:

and the new thresholds vs. LazySizes (a popular JS lazy loading library):

We are committed to working with the web standards community to explore better alignment in how distance-from-viewport thresholds are approached across different browsers.

Images should include dimension attributes #

While the browser loads an image, it does not immediately know the image's dimensions, unless these are explicitly specified. To enable the browser to reserve sufficient space on a page for images, it is recommended that all <img> tags include both width and height attributes. Without dimensions specified, layout shifts can occur, which are more noticeable on pages that take some time to load.

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Alternatively, specify their values directly in an inline style:

<img src="image.png" loading="lazy" alt="…" style="height:200px; width:200px;">

The best practice of setting dimensions applies to <img> tags regardless of whether or not they are being loaded lazily. With lazy loading, this can become more relevant. Setting width and height on images in modern browsers also allows browsers to infer their intrinsic size.

In most scenarios images still lazy-load if dimensions are not included, but there are a few edge cases you should be aware of. Without width and height specified, image dimensions are 0×0 pixels at first. If you have a gallery of such images, the browser may conclude that all of them fit inside the viewport at the start, as each takes up practically no space and no image is pushed offscreen. In this case the browser determines that all of them are visible to the user and decides to load everything.

Also, specifying image dimensions decreases the chances of layout shifts happening. If you are unable to include dimensions for your images, lazy loading them can be a trade-off between saving network resources and potentially being more at risk of layout shift.

While lazy loading in Chromium is implemented in a way such that images are likely to be loaded once they are visible, there is still a small chance that they might not be loaded yet. In this case, missing width and height attributes on such images increase their impact on Cumulative Layout Shift.

Images that are defined using the <picture> element can also be lazy-loaded:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" loading="lazy">
</picture>

Although a browser will decide which image to load from any of the <source> elements, the loading attribute only needs to be included to the fallback <img> element.

Avoid lazy loading images that are in the first visible viewport #

You should avoid setting loading=lazy for any images that are in the first visible viewport. This is particularly relevant for LCP images. See the article The performance effects of too much lazy-loading for more information.

It is recommended to only add loading=lazy to images which are positioned below the fold, if possible. Images that are eagerly loaded can be fetched right away, while images which are loaded lazily the browser currently needs to wait until it knows where the image is positioned on the page, which relies on the IntersectionObserver to be available.

Generally, any images within the viewport should be loaded eagerly using the browser's defaults. You do not need to specify loading=eager for this to be the case for in-viewport images.

<!-- visible in the viewport -->
<img src="product-1.jpg" alt="..." width="200" height="200">
<img src="product-2.jpg" alt="..." width="200" height="200">
<img src="product-3.jpg" alt="..." width="200" height="200">

<!-- offscreen images -->
<img src="product-4.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-5.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-6.jpg" loading="lazy" alt="..." width="200" height="200">

Graceful degradation #

Browsers that do not support the loading attribute will ignore its presence. While these browsers will of course not get the benefits of lazy loading, including the attribute has no negative impact on them.

FAQ #

Are there plans to automatically lazy-load images in Chrome? #

Previously, Chromium automatically lazy-loaded any images that were well suited to being deferred if Lite mode was enabled on Chrome for Android and the loading attribute was either not provided or set as loading="auto". However, Lite mode has been deprecated (as was the non-standard loading="auto") and there are currently no plans to provide automatically lazy-load of images in Chrome.

Can I change how close an image needs to be before a load is triggered? #

These values are hardcoded and can't be changed through the API. However, they may change in the future as browsers experiment with different threshold distances and variables.

Can CSS background images take advantage of the `loading` attribute? #

No, it can currently only be used with <img> tags.

Is there a downside to lazy loading images that are within the device viewport? #

It is safer to avoid putting loading=lazy on above-the-fold images, as Chrome won't preload loading=lazy images in the preload scanner and will also delay fetching such images until all layout is complete. See Avoid lazy-loading images that are in the first visible viewport for more information.

How does the `loading` attribute work with images that are in the viewport but not immediately visible (for example: behind a carousel, or hidden by CSS for certain screen sizes)? #

Using loading="lazy" may prevent them being loaded when they are not visible but within the calculated-distance. For example, Chrome, Safari and Firefox do not load images using display: none; styling—either on the image element or on a parent element. However, other techniques to hide images—such as using opacity:0 styling—will still result in the images being loaded. Always test your implementation thoroughly to ensure it's acting as intended.

What if I'm already using a third-party library or a script to lazy-load images? #

With full support of native lazy loading now available in modern browsers, you may wish to reconsider if you still need a third-party library or script to lazy-load images.

One reason to continue to use a third-party library along with loading="lazy" is to provide a polyfill for browsers that do not support the attribute, or to have more control over when lazy loading is triggered.

How do I handle browsers that don't support lazy loading? #

Create a polyfill or use a third-party library to lazy-load images on your site. The loading property can be used to detect if the feature is supported in the browser:

if ('loading' in HTMLImageElement.prototype) {
  // supported in browser
} else {
  // fetch polyfill/third-party library
}

For example, lazysizes is a popular JavaScript lazy loading library. You can detect support for the loading attribute to load lazysizes as a fallback library only when loading isn't supported. This works as follows:

Replace <img src> with <img data-src> to avoid an eager load in unsupported browsers. If the loading attribute is supported, swap data-src for src.
If loading is not supported, load a fallback (lazysizes) and initiate it. As per lazysizes docs, you use the lazyload class as a way to indicate to lazysizes which images to lazy-load.

<!-- Let's load this in-viewport image normally -->
<img src="hero.jpg" alt="…">

<!-- Let's lazy-load the rest of these images -->
<img data-src="unicorn.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="cats.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="dogs.jpg" alt="…" loading="lazy" class="lazyload">

<script>
  if ('loading' in HTMLImageElement.prototype) {
    const images = document.querySelectorAll('img[loading="lazy"]');
    images.forEach(img => {
      img.src = img.dataset.src;
    });
  } else {
    // Dynamically import the LazySizes library
    const script = document.createElement('script');
    script.src =
      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.1.2/lazysizes.min.js';
    document.body.appendChild(script);
  }
</script>

Here's a demo of this pattern. Try it out in an older browser to see the fallback in action.

Is lazy loading for iframes also supported in browsers? #

Browser support

Chrome 77, Supported 77
Firefox, Not supported
Edge 79, Supported 79
Safari 16.4, Supported 16.4

<iframe loading=lazy> has also been standardized and is already implemented in Chromium and Safari. This allows you to lazy-load iframes using the loading attribute. See this dedicated article about iframe lazy-loading for more information.

How does browser-level lazy loading affect advertisements on a web page? #

All ads displayed to the user in the form of an image or iframe lazy-load just like any other image or iframe.

How are images handled when a web page is printed? #

All images and iframes are immediately loaded if the page is printed. See issue #875403 for details.

Does Lighthouse recognize browser-level lazy loading? #

Lighthouse 6.0 and above factor in approaches for offscreen image lazy loading that may use different thresholds, allowing them to pass the Defer offscreen images audit.

Conclusion #

Baking in support for lazy loading images can make it significantly easier for you to improve the performance of your web pages.

Are you noticing any unusual behavior with this feature enabled in Chrome? File a bug!

Add a web app manifest with Create React App

2019-04-29T00:00:00Z

Create React App (CRA) includes a web app manifest by default. Modifying this file will allow you to change how your application is displayed when installed on the user's device.

Why is this useful? #

Web app manifest files provide the capability to change how an installed application will look like on the user's desktop or mobile device. By modifying properties in the JSON file, you can modify a number of details in your application, including its:

Name
Description
App icon
Theme color

The MDN documentation covers all the properties that can be changed in detail.

Modify the default manifest #

In CRA, a default manifest file, /public/manifest.json is included automatically when a new app is created:

{
  "short_name": "React App",
  "name": "Create React App Sample",
  "icons": [
    {
      "src": "favicon.ico",
      "sizes": "64x64 32x32 24x24 16x16",
      "type": "image/x-icon"
    },
    {
      "src": "logo192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "logo512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "start_url": ".",
  "display": "standalone",
  "theme_color": "#000000",
  "background_color": "#ffffff"
}

This allows anybody to install the application on their device and see some default details of the application. The HTML file, public/index.html, also includes a <link> element to load the manifest.

<link rel="manifest" href="%PUBLIC_URL%/manifest.json" />

Here is an example of an application built with CRA that has a modified manifest file:

To find out if all the properties are working correctly in this example:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Application tab.
In the Application panel, click the Manifest tab.

Conclusion #

If you're building a site that you think does not need to be installed on a device, remove the manifest and the <link> element in the HTML file that points to it.
If you would like users to install the application on their device, modify the manifest file (or create one if you are not using CRA) with any properties that you like. The MDN documentation explains all the required and optional attributes.

Accessibility auditing with react-axe and eslint-plugin-jsx-a11y

2019-04-29T00:00:00Z

react-axe is a library that audits a React application and logs any accessibility issues to the Chrome DevTools console. It uses the open-source axe testing library to flag any issues and their severity.

eslint-plugin-jsx-a11y is an ESLint plugin that identifies and enforces a number of accessibility rules directly in your JSX. Using this in combination with a tool that tests the final rendered DOM, such as react-axe, can help you find and fix any accessibility concerns on your site.

Why is this useful? #

It is crucial to build websites that provide every user, regardless of their impairment or restriction, the capability to access its content. Using auditing libraries such as react-axe and eslint-plugin-jsx-a11y during the development of your React application will automatically expose any accessibility issues as they pop up.

React already supports writing accessible HTML elements within JSX syntax. For example, you only need to use the htmlFor attribute instead of for to link a label to a specific form element within a React component.

<input id="promo" type="checkbox">
<label htmlFor="promo">Receive promotional offers?</label>

The React accessibility documentation covers all the nuances of handling accessibility concerns within a React component. To make it easier to spot these issues during development, Create React App (CRA) includes the eslint-plugin-jsx-a11y plugin for ESLint by default.

To enable pre-configured linting provided by CRA:

Install the appropriate ESLint plugin for your code editor
Add a .eslintrc.json file to your project

{
  "extends": "react-app"
}

Some common accessibility issues will now show up.

To check for even more accessibility rules, modify the file to automatically include all the recommended rules by the plugin:

{
  "extends": ["react-app", "plugin:jsx-a11y/recommended"]
}

If you would like an even stricter subset of rules, switch to strict mode:

{
  "extends": ["react-app", "plugin:jsx-a11y/strict"]
}

The project documentation provides information on the differences between recommended and strict mode.

Use react-axe #

eslint-plugin-jsx-a11y can help you easily pinpoint any accessibility issues in your JSX, but it does not test any of the final HTML output. react-axe is a library that does exactly this by providing a React wrapper around the axe-core testing tool by Deque Labs.

Install the library as a development dependency to begin:

npm install --save-dev react-axe

You now only need to initialize the module in index.js:

if (process.env.NODE_ENV !== 'production') {
  import('react-axe').then(axe => {
    axe.default(React, ReactDOM, 1000);
    ReactDOM.render(<App />, document.getElementById('root'));
  });
} else {
  ReactDOM.render(<App />, document.getElementById('root'));
}

A dynamic import is used here to only load the library when it is not in production mode before rendering and booting up the root App component. This ensures that it is not unnecessarily included in the final production bundle.

Now when you run the application during development, issues are surfaced directly to the Chrome DevTools console.

A severity level is also assigned for each violation. These levels are:

Minor
Moderate
Serious
Critical

Conclusion #

If you are building a site with React, include accessibility auditing into your workflow early to catch problems as you build your components.
Use eslint-plugin-jsx-a11y to add accessibility checks into your linting workflow. CRA already comes with it included, but switch to either the recommended or strict mode.
In addition to local development testing, include react-axe into your application to catch any issues on the final rendered DOM. Do not include it into your production bundle.

Code splitting with React.lazy and Suspense

2019-04-29T00:00:00Z

The React.lazy method makes it easy to code-split a React application on a component level using dynamic imports.

import React, { lazy } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));

const DetailsComponent = () => (
  <div>
    <AvatarComponent />
  </div>
)

Why is this useful? #

A large React application will usually consist of many components, utility methods, and third-party libraries. If an effort isn't made to try to load different parts of an application only when they're needed, a single, large bundle of JavaScript will be shipped to your users as soon as they load the first page. This can affect page performance significantly.

The React.lazy function provides a built-in way to separate components in an application into separate chunks of JavaScript with very little legwork. You can then take care of loading states when you couple it with the Suspense component.

Suspense #

The problem with shipping a large JavaScript payload to users is the length of time it would take for the page to finish loading, especially on weaker devices and network connections. This is why code splitting and lazy loading is extremely useful.

However, there will always be a slight delay that users have to experience when a code-split component is being fetched over the network, so it's important to display a useful loading state. Using React.lazy with the Suspense component helps solve this problem.

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));

const renderLoader = () => <p>Loading</p>;

const DetailsComponent = () => (
  <Suspense fallback={renderLoader()}>
    <AvatarComponent />
  </Suspense>
)

Suspense accepts a fallback component which allows you to display any React component as a loading state. The following example shows how this works. The avatar is only rendered when the button is clicked, where a request is then made to retrieve the code necessary for the suspended AvatarComponent. In the meantime, the fallback loading component is shown.

In here, the code that makes up AvatarComponent is small which is why the loading spinner only shows for a short amount of time. Larger components can take much longer to load, especially on weak network connections.

To better demonstrate how this works:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Click the Throttling dropdown, which is set to No throttling by default. Select Fast 3G.
Click the Click Me button in the app.

The loading indicator will show for longer now. Notice how all the code that makes up the AvatarComponent is fetched as a separate chunk.

Suspending multiple components #

Another feature of Suspense is that it allows you to suspend multiple components from loading, even if they are all lazy loaded.

For example:

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));
const InfoComponent = lazy(() => import('./InfoComponent'));
const MoreInfoComponent = lazy(() => import('./MoreInfoComponent'));

const renderLoader = () => <p>Loading</p>;

const DetailsComponent = () => (
  <Suspense fallback={renderLoader()}>
    <AvatarComponent />
    <InfoComponent />
    <MoreInfoComponent />
  </Suspense>
)

This is an extremely useful way to delay rendering of multiple components while only showing a single loading state. Once all the components have finished fetching, the user gets to see them all displayed at the same time.

You can see this with the following embed:

Without this, it's easy to run into the problem of staggered loading, or different parts of a UI loading one after the other with each having their own loading indicator. This can make the user experience feel more jarring.

Handle loading failures #

Suspense allows you to display a temporary loading state while network requests are made under the hood. But what if those network requests fail for some reason? You might be offline, or perhaps your web app is attempting to lazy-load a versioned URL that is out of date, and no longer available following a server redeployment.

React has a standard pattern for gracefully handling these types of loading failures: using an error boundary. As described in the documentation, any React component can serve as an error boundary if it implements either (or both) of the lifecycle methods static getDerivedStateFromError() or componentDidCatch().

To detect and handle lazy loading failures, you can wrap your Suspense component with a parent components that serves as an error boundary. Inside the error boundary's render() method, you can render the children as-is if there's no error, or render a custom error message if something goes wrong:

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));
const InfoComponent = lazy(() => import('./InfoComponent'));
const MoreInfoComponent = lazy(() => import('./MoreInfoComponent'));

const renderLoader = () => <p>Loading</p>;

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = {hasError: false};
  }

  static getDerivedStateFromError(error) {
    return {hasError: true};
  }

  render() {
    if (this.state.hasError) {
      return <p>Loading failed! Please reload.</p>;
    }

    return this.props.children;
  }
}

const DetailsComponent = () => (
  <ErrorBoundary>
    <Suspense fallback={renderLoader()}>
      <AvatarComponent />
      <InfoComponent />
      <MoreInfoComponent />
    </Suspense>
  </ErrorBoundary>
)

Conclusion #

If you are unsure where to begin applying code splitting to your React application, follow these steps:

Begin at the route level. Routes are the simplest way to identify points of your application that can be split. The React docs show how Suspense can be used along with react-router.
Identify any large components on a page on your site that only render on certain user interactions (like clicking a button). Splitting these components will minimize your JavaScript payloads.
Consider splitting anything else that is offscreen and not critical for the user.

Get started: optimize your React app

2019-04-29T00:00:00Z

React is an open-source library that makes building UIs easier. This learning path will cover different APIs and tools within the ecosystem that you should consider using to improve the performance and usability of your application.

This guide will show you how to get up and running with a React application. Every other guide in this section will cover topics to optimize the speed or accessibility of a React app.

Why is this useful? #

There's a lot of content that explains how to build fast and reliable applications, but not many that show how to build fast and reliable React applications. These guides cover all this from the perspective of a React app where only libraries, APIs, and features specific to the React ecosystem are mentioned.

What will you learn? #

The tutorials in this learning path do not focus on:

How to use React
How React works under the hood

Although both of these concepts will be touched on when needed, all the guides and codelabs in this section will instead focus on how to build fast and accessible React sites. For this reason, a basic knowledge of React is required.

Create React App #

Create React App (CRA) is the easiest way to get started building React applications. It provides a default setup with a number of core features baked in, including a build system containing a module bundler (webpack) and a transpiler (Babel).

On a command-line shell, you only need to run the following to create a new application:

npx create-react-app app-name

Once the command finishes executing, you can navigate to and run the application with the following commands:

cd new-app
npm start

The following embed shows the directory structure and the actual web page of a newly bootstrapped CRA application.

There are multiple configuration files and build scripts that CRA uses to set up a webpack and Babel build process that includes a base Jest setup for testing. To make things simpler for the user, these files are hidden and cannot be accessed until you eject from CRA. It is always best to avoid ejecting whenever possible, since this means taking on all of these configuration files as your own source code, which can become difficult to manage.

The directory structure of a new CRA application only contains the files that you would actually need to modify in order to work on your application. The CRA documentation explains this in detail.

What's next? #

Now that you know how to get started building a Create React App, learn how to improve your app's performance and accessibility with all the guides in this learning path:

Precaching in Create React App with Workbox

2019-04-29T00:00:00Z

Workbox is built into Create React App (CRA) with a default configuration that precaches all the static assets in your application with every build.

Why is this useful? #

Service workers enable you to store important resources in its cache (precaching) so that when a user loads the web page for a second time, the browser can retrieve them from the service worker instead of making requests to the network. This results in faster page loads on repeat visits as well as in the ability to surface content when the user is offline.

Workbox in CRA #

Workbox is a collection of tools that allow you create and maintain service workers. In CRA, the workbox-webpack-plugin is already included into the production build and only needs to be enabled in the src/index.js file in order to register a new service worker with every build:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import * as serviceWorker from './serviceWorker';
ReactDOM.render(<App />, document.getElementById('root'));

serviceWorker.unregister();
serviceWorker.register();

Here is an example of a React app built with CRA that has a service worker enabled through this file:

To see which assets are being cached:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Reload the app.

You'll notice that instead of showing the payload size, the Size column shows a (from ServiceWorker) message to indicate that these resources were retrieved from the service worker.

Since the service worker caches all static assets, try to use the application while offline:

In the Network tab in DevTools, enable the Offline checkbox to simulate an offline experience.

Reload the app.

The application works in exactly the same way, even without a network connection!

Modifying caching strategies #

The default precaching strategy used by Workbox in CRA is cache-first, where all static assets are fetched from the service worker cache and if that fails (if the resource is not cached for example), the network request is made. This is how content can still be served to users even when they are in a complete offline state.

Although Workbox provides support to define different strategies and approaches to caching static and dynamic resources, the default configuration in CRA cannot be modified or overwritten unless you eject entirely. However, there is an open proposal to explore adding support for an external workbox.config.js file. This would allow developers to override the default settings by just creating a single workbox.config.js file.

Handling a cache-first strategy #

Relying on the service worker cache first and then falling back to the network is an excellent way to build sites that load faster on subsequent visits and work offline to some extent. However, there are a few things that need to be taken into consideration:

How can caching behaviors by a service worker be tested?
Should there be a message for users to let them know they are looking at cached content?

The CRA documentation explains these points, and more, in detail.

Conclusion #

Use a service worker to precache important resources in your application to provide a faster experience for your users as well as offline support.

If you are using CRA, enable the pre-configured service worker in src/index.js.
If you are not using CRA to build a React application, include one of the many libraries Workbox provides, such as workbox-webpack-plugin, into your build process.
Keep an eye out for when CRA will support a workbox.config.js override file in this GitHub issue.

Pre-render routes with react-snap

2019-04-29T00:00:00Z

react-snap is a third-party library that pre-renders pages on your site into static HTML files. This can improve First Paint times in your application.

Here's a comparison of the same application with and without pre-rendering loaded on a simulated 3G connection and mobile device:

Why is this useful? #

The main performance problem with large single-page applications is that the user needs to wait for the JavaScript bundle(s) that make up the site to finish downloading before they can see any real content. The larger the bundles, the longer the user will have to wait.

To solve this, many developers take the approach of rendering the application on the server instead of only booting it up on the browser. With each page/route transition, the complete HTML is generated on the server and sent to the browser, which reduces First Paint times but comes at the cost of a slower Time to First Byte.

Pre-rendering is a separate technique that is less complex than server rendering, but also provides a way to improve First Paint times in your application. A headless browser, or a browser without a user interface, is used to generate static HTML files of every route during build time. These files can then be shipped along with the JavaScript bundles that are needed for the application.

react-snap #

react-snap uses Puppeteer to create pre-rendered HTML files of different routes in your application. To begin, install it as a development dependency:

npm install --save-dev react-snap

Then add a postbuild script in your package.json:

"scripts": {
  //...
  "postbuild": "react-snap"
}

This would automatically run the react-snap command every time a new build of the applications made (npm build).

The last thing you will need to do is change how the application is booted. Change the src/index.js file to the following:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';

ReactDOM.render(<App />, document.getElementById('root'));
const rootElement = document.getElementById("root");

if (rootElement.hasChildNodes()) {
  ReactDOM.hydrate(<App />, rootElement);
} else {
  ReactDOM.render(<App />, rootElement);
}

Instead of only using ReactDOM.render to render the root React element directly into the DOM, this checks to see if any child nodes are already present to determine whether HTML contents were pre-rendered (or rendered on the server). If that's the case, ReactDOM.hydrate is used instead to attach event listeners to the already created HTML instead of creating it anew.

Building the application will now generate static HTML files as payloads for each route that is crawled. You can take a look at what the HTML payload looks like by clicking the URL of the HTML request and then clicking the Previews tab within Chrome DevTools.

Flash of unstyled content #

Although static HTML is now rendered almost immediately, it still remains unstyled by default which may cause the issue of showing a "flash of unstyled content" (FOUC). This can be especially noticeable if you are using a CSS-in-JS library to generate selectors since the JavaScript bundle will have to finish executing before any styles can be applied.

To help prevent this, the critical CSS, or the minimum amount of CSS that is needed for the initial page to render, can be inlined directly to the <head> of the HTML document. react-snap uses another third-party library under the hood, minimalcss, to extract any critical CSS for different routes. You can enable this by specifying the following in your package.json file:

"reactSnap": {
  "inlineCss": true
}

Taking a look at the response preview in Chrome DevTools will now show the styled page with critical CSS inlined.

Conclusion #

If you are not server-side rendering routes in your application, use react-snap to pre-render static HTML to your users.

Install it as a development dependency and begin with just the default settings.
Use the experimental inlineCss option to inline critical CSS if it works for your site.
If you are using code splitting on a component level within any routes, be careful not to pre-render a loading state to your users. The react-snap README covers this in more detail.

Virtualize large lists with react-window

2019-04-29T00:00:00Z

react-window is a library that allows large lists to be rendered efficiently.

Here's an example of a list that contains 1000 rows being rendered with react-window. Try scrolling as fast you can.

Why is this useful? #

There may be times where you need to display a large table or list that contains many rows. Loading every single item on such a list can affect performance significantly.

List virtualization, or "windowing", is the concept of only rendering what is visible to the user. The number of elements that are rendered at first is a very small subset of the entire list and the "window" of visible content moves when the user continues to scroll. This improves both the rendering and scrolling performance of the list.

Moving "window" of content in a virtualized list

DOM nodes that exit the "window" are recycled, or immediately replaced with newer elements as the user scrolls down the list. This keeps the number of all rendered elements specific to the size of the window.

react-window #

react-window is a small, third-party library that makes it easier to create virtualized lists in your application. It provides a number of base APIs that can be used for different types of lists and tables.

When to use fixed size lists #

Use the FixedSizeList component if you have a long, one-dimensional list of equally sized items.

import React from 'react';
import { FixedSizeList } from 'react-window';

const items = [...] // some list of items

const Row = ({ index, style }) => (
  <div style={style}>
     {/* define the row component using items[index] */}
  </div>
);

const ListComponent = () => (
  <FixedSizeList
    height={500}
    width={500}
    itemSize={120}
    itemCount={items.length}
  >
    {Row}
  </FixedSizeList>
);

export default ListComponent;

The FixedSizeList component accepts a height, width and itemSize prop to control the size of the items within the list.
A function that renders the rows is passed as a child to FixedSizeList. Details about the particular item can be accessed with the index argument (items[index]).
A style parameter is also passed in to the row rendering method that must be attached to the row element. List items are absolutely positioned with their height and width values assigned inline, and the style parameter is responsible for this.

The Glitch example shown earlier in this article shows an example of a FixedSizeList component.

When to use variable sized lists #

Use the VariableSizeList component to render a list of items that have different sizes. This component works in the same way as a fixed size list, but instead expects a function for the itemSize prop instead of a specific value.

import React from 'react';
import { VariableSizeList } from 'react-window';

const items = [...] // some list of items

const Row = ({ index, style }) => (
  <div style={style}>
     {/* define the row component using items[index] */}
  </div>
);

const getItemSize = index => {
  // return a size for items[index]
}

const ListComponent = () => (
  <VariableSizeList
    height={500}
    width={500}
    itemCount={items.length}
    itemSize={getItemSize}
  >
    {Row}
  </VariableSizeList>
);

export default ListComponent;

The following embed shows an example of this component.

The item size function passed to the itemSize prop randomizes the row heights in this example. In a real application however, there should be actual logic defining the sizes of each item. Ideally, these sizes should be calculated based on data or obtained from an API.

Grids #

react-window also provides support for virtualizing multi-dimensional lists, or grids. In this context, the "window" of visible content changes as the user scrolls horizontally and vertically.

Moving "window" of content in a virtualized grid is two-dimensional

Similarly, both FixedSizeGrid and VariableSizeGrid components can be used depending on whether the size of specific list items can vary.

For FixedSizeGrid, the API is about the same but with the fact that heights, widths and item counts need to be represented for both columns and rows.
For VariableSizeGrid, both the column widths and row heights can be changed by passing in functions instead of values to their respective props.

Take a look at the documentation to see examples of virtualized grids.

Lazy loading on scroll #

Many websites improve performance by waiting to load and render items in a long list until the user has scrolled down. This technique, commonly referred to as "infinite loading", adds new DOM nodes into the list as the user scrolls past a certain threshold close to the end. Although this is better than loading all items on a list at once, it still ends up populating the DOM with thousands of row entries if the user has scrolled past that many. This can lead to an excessively large DOM size, which starts to impact performance by making style calculations and DOM mutations slower.

The following diagram might help summarize this:

Difference in scrolling between a regular and virtualized list

The best approach to solve this problem is continue to use a library like react-window to maintain a small "window" of elements on a page, but to also lazy load newer entries as the user scrolls down. A separate package, react-window-infinite-loader, makes this possible with react-window.

Consider the following piece of code which shows an example of state that is managed in a parent App component.

import React, { Component } from 'react';

import ListComponent from './ListComponent';

class App extends Component {
  constructor(props) {
    super(props);
    this.state = {
      items: [], // instantiate initial list here
      moreItemsLoading: false,
      hasNextPage: true
    };

    this.loadMore = this.loadMore.bind(this);
  }

  loadMore() {
   // method to fetch newer entries for the list
  }

  render() {
    const { items, moreItemsLoading, hasNextPage } = this.state;

    return (
      <ListComponent
        items={items}
        moreItemsLoading={moreItemsLoading}
        loadMore={this.loadMore}
        hasNextPage={hasNextPage}
      />
    );
  }
}

export default App;

A loadMore method is passed into a child ListComponent that contains the infinite loader list. This is important because the infinite loader needs to fire a callback to load more items once the user has scrolled past a certain point.

Here's how the ListComponent that renders the list can look like:

import React from 'react';
import { FixedSizeList } from 'react-window';
import InfiniteLoader from "react-window-infinite-loader";

const ListComponent = ({ items, moreItemsLoading, loadMore, hasNextPage }) => {
  const Row = ({ index, style }) => (
     {/* define the row component using items[index] */}
  );

  const itemCount = hasNextPage ? items.length + 1 : items.length;

  return (
    <InfiniteLoader
      isItemLoaded={index => index < items.length}
      itemCount={itemCount}
      loadMoreItems={loadMore}
    >
      {({ onItemsRendered, ref }) => (
        <FixedSizeList
          height={500}
          width={500}
          itemCount={itemCount}
          itemSize={120}
          onItemsRendered={onItemsRendered}
          ref={ref}
        >
          {Row}
        </FixedSizeList>
      )}
  </InfiniteLoader>
  )
};

export default ListComponent;

In here, the FixedSizeList component is wrapped within the InfiniteLoader. The props assigned to the loader are:

isItemLoaded: Method that checks whether a certain item has loaded
itemCount: Number of items on the list (or expected)
loadMoreItems: Callback that returns a promise that resolves to additional data for the list

A render prop is used to return a function that the list component uses in order to render. Both onItemsRendered and ref attributes are attributes that need to be passed in.

The following is an example of how infinite loading can work with a virtualized list.

Scrolling down the list might feel the same, but a request is now made to retrieve 10 users from a random user API every time you scroll close to the end of the list. This is all done while only rendering a single "window" of results at at a time.

By checking the index of a certain item, a different loading state can be shown for an item depending on whether a request has been made for newer entries and the item is still loading.

For example:

const Row = ({ index, style }) => {
  const itemLoading = index === items.length;

  if (itemLoading) {
      // return loading state
  } else {
      // return item
  }
};

Overscanning #

Since items in a virtualized list only change when the user scrolls, blank space can briefly flash as newer entries are about to be displayed. You can try quickly scrolling any of the previous examples in this guide to notice this.

To improve the user experience of virtualized lists, react-window allows you to overscan items with the overscanCount property. This allows you to define how many items outside of the visible "window" to render at all times.

<FixedSizeList
  //...
  overscanCount={4}
>
  {...}
</FixedSizeList>

overscanCount works for both the FixedSizeList and VariableSizeList components and has a default value of 1. Depending on how large a list is as well as the size of each item, overscanning more than just one entry can help prevent a noticeable flash of empty space when the user scrolls. However, overscanning too many entries can affect performance negatively. The whole point of using a virtualized list is to minimize the number of entries to what the user can see at any given moment, so try to keep the number of overscanned items as low as possible.

For FixedSizeGrid and VariableSizeGrid, use the overscanColumnsCount and overscanRowsCount properties to control the number of columns and rows to overscan respectively.

Conclusion #

If you are unsure where to begin virtualizing lists and tables in your application, follow these steps:

Measure rendering and scrolling performance. This article shows how the FPS meter in Chrome DevTools can be used to explore how efficiently items are rendered on a list.
Include react-window for any long lists or grids that are affecting performance.
If there are certain features not supported in react-window, consider using react-virtualized if you cannot add this functionality yourself.
Wrap your virtualized list with react-window-infinite-loader if you need to lazy load items as the user scrolls.
Use the overscanCount property for your lists and the overscanColumnsCount and overscanRowsCount properties for your grids to prevent a flash of empty content. Do not overscan too many entries as this will affect performance negatively.

Codelab: Preload critical assets to improve loading speed

2019-04-24T00:00:00Z

In this codelab, the performance of the following web page is improved by preloading and prefetching a few resources:

Measure #

First measure how the website performs before adding any optimizations.

To preview the site, press View App. Then press Fullscreen .

Run the Lighthouse performance audit (Lighthouse > Options > Performance) on the live version of your Glitch (see also Discover performance opportunities with Lighthouse).

Lighthouse shows the following failed audit for a resource that is fetched late:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.

The main.css file is not fetched by a Link element (<link>) placed in the HTML document, but a separate JavaScript file, fetch-css.js, attaches the Link element to the DOM after the window.onLoad event. This means that the file is only fetched after the browser finishes parsing and executing the JS file. Similarly, a web font (K2D.woff2) specified within main.css is only fetched once the CSS file has finished downloading.

The critical request chain represents the order of resources that are prioritized and fetched by the browser. For this web page, it currently looks like this:

├─┬ / (initial HTML file)
  └── fetch-css.js
    └── main.css
      └── K2D.woff2

Since the CSS file is on the third level of the request chain, Lighthouse has identified it as a late-discovered resource.

Preload critical resources #

The main.css file is a critical asset that's needed immediately as soon as the page is loaded. For important files like this resource that are fetched late in your application, use a link preload tag to inform the browser to download it sooner by adding a Link element to the head of the document.

Add a preload tag for this application:

<head>
  <!-- ... -->
  <link rel="preload" href="main.css" as="style">
</head>

The as attribute is used to identify which type of resource is being fetched, and as="style" is used to preload stylesheet files.

Reload the application and take a look at the Network panel in DevTools.

Notice how the browser fetches the CSS file before the JavaScript responsible for fetching it has even been finished parsing. With preload, the browser knows to make a preemptive fetch for the resource with the assumption that it is critical for the web page.

If not used correctly, preload can harm performance by making unnecessary requests for resources that aren't used. In this application, details.css is another CSS file located at the root of the project but is used for a separate /details route. To show an example of how preload can be used incorrectly, add a preload hint for this resource as well.

<head>
  <!-- ... -->
  <link rel="preload" href="main.css" as="style">
  <link rel="preload" href="details.css" as="style">
</head>

Reload the application and take a look at the Network panel. A request is made to retrieve details.css even though it is not being used by the web page.

Chrome displays a warning in the Console panel when a preloaded resource is not used by the page within a few seconds after it has loaded.

Use this warning as an indicator to identify if you have any preloaded resources that are not being used immediately by your web page. You can now remove the unnecessary preload link for this page.

<head>
  <!-- ... -->
  <link rel="preload" href="main.css" as="style">
  <link rel="preload" href="details.css" as="style">
</head>

For a list of all the types of resources that can be fetched along with the correct values that should be used for the as attribute, refer to the MDN article on Preloading.

Prefetch future resources #

Prefetch is another browser hint that can be used to make a request for an asset used for a different navigation route but at a lower priority than other important assets needed for the current page.

In this website, clicking the image takes you to a separate details/ route.

A separate CSS file, details.css, contains all the styles needed for this simple page. Add a link element to index.html to prefetch this resource.

<head>
  <!-- ... -->
  <link rel="prefetch" href="details.css">
</head>

To understand how this triggers a request for the file, open the Network panel in DevTools and uncheck the Disable cache option.

Reload the application and notice how a very low priority request is made for details.css after all the other files have been fetched.

With DevTools open, click the image on the website to navigate to the details page. Since a link element is used in details.html to fetch details.css, a request is made for the resource as expected.

Click the details.css network request in DevTools to view its details. You'll notice that the file is retrieved from the browser's disk cache.

By taking advantage of browser idle time, prefetch makes an early request for a resource needed for a different page. This speeds up future navigation requests by allowing the browser to cache the asset sooner and serve it from the cache when needed.

Preloading and prefetching with webpack #

The Reduce JavaScript payloads with code splitting post explores the use of dynamic imports to split a bundle into multiple chunks. This is demonstrated with a simple application that dynamically imports a module from Lodash when a form is submitted.

You can access the Glitch for this application here.

The following block of code, which lives in src/index.js, is responsible for dynamically importing the method when the button is clicked.

form.addEventListener("submit", e => {
  e.preventDefault()
  import('lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

Splitting a bundle improves page loading times by reducing its initial size. Version 4.6.0 of webpack provides support to preload or prefetch chunks that are imported dynamically. Using this application as an example, the lodash method can be prefetched at browser idle time; when a user presses the button, there is no delay for the resource to be fetched.

Use the specific webpackPrefetch comment parameter within a dynamic import to prefetch a particular chunk. Here is how it would look with this particular application.

form.addEventListener("submit", e => {
  e.preventDefault()
  import(/* webpackPrefetch: true */ 'lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

Once the application is reloaded, webpack injects a prefetch tag for the resource into the head of the document. This can be seen in the Elements panel in DevTools.

Observing the requests in the Network panel also shows that this chunk is fetched with a low priority after all other resources have been requested.

Although prefetch makes more sense for this use case, webpack also provides support for preloading chunks that are dynamically imported.

import(/* webpackPreload: true */ 'module')

Conclusion #

With this codelab, you should have a solid understanding of how preloading or prefetching certain assets can improve the user experience of your site. It is important to mention that these techniques should not be used for every resource and using them incorrectly can harm performance. The best results are noticed by only preloading or prefetching selectively.

To summarize:

Use preload for resources that are discovered late but are critical to the current page.
Use prefetch for resources that are needed for a future navigation route or user action.

Not all browsers currently support both preload and prefetch. This means that not all users of your application may notice performance improvements.

If you would like more information about specific aspects of how preloading and prefetching can affect your web page, refer to these articles:

Serve modern code to modern browsers for faster page loads

2018-12-12T00:00:00Z

In this codelab, improve the performance of this simple application that allows users to rate random cats. Learn how to optimize the JavaScript bundle by minizming how much code is transpiled.

In the sample app, you can select a word or emoji to convey how much you like each cat. When you click a button, the app displays the button's value underneath the current cat image.

Measure #

It's always a good idea to begin by inspecting a website before adding any optimizations:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
Reload the app.

Over 80 KB is used for this application! Time to find out if parts of the bundle aren't being used:

Press Control+Shift+P (or Command+Shift+P on Mac) to open the Command menu.

Enter Show Coverage and hit Enter to display the Coverage tab.
In the Coverage tab, click Reload to reload the application while capturing coverage.
Take a look at how much code was used versus how much was loaded for the main bundle:

Over half the bundle (44 KB) is not even utilized. This is because a lot of the code within consists of polyfills to ensure that the application works in older browsers.

Use @babel/preset-env #

The syntax of the JavaScript language conforms to a standard known as ECMAScript, or ECMA-262. Newer versions of the specification are released every year and include new features that have passed the proposal process. Each major browser is always at a different stage of supporting these features.

The following ES2015 features are used in the application:

The following ES2017 feature is used as well:

Async functions

Feel free to dive into the source code in src/index.js to see how all of this is used.

All of these features are supported in the latest version of Chrome, but what about other browsers that don't support them? Babel, which is included in the application, is the most popular library used to compile code that contains newer syntax into code that older browsers and environments can understand. It does this in two ways:

Polyfills are included to emulate newer ES2015+ functions so that their APIs can be used even if it is not supported by the browser. Here is an example of a polyfill of the Array.includes method.
Plugins are used to transform ES2015 code (or later) into older ES5 syntax. Since these are syntax related changes (such as arrow functions), they cannot be emulated with polyfills.

Look at package.json to see which Babel libraries are included:

"dependencies": {
  "@babel/polyfill": "^7.0.0"
},
"devDependencies": {
  //...
  "babel-loader": "^8.0.2",
  "@babel/core": "^7.1.0",
  "@babel/preset-env": "^7.1.0",
  //...
}

@babel/core is the core Babel compiler. With this, all the Babel configurations are defined in a .babelrc at the root of the project.
babel-loader includes Babel in the webpack build process.

Now look at webpack.config.js to see how babel-loader is included as a rule:

module: {
  rules: [
    //...
    {
      test: /\.js$/,
      exclude: /node_modules/,
      loader: "babel-loader"
    }
  ]
},

@babel/polyfill provides all the necessary polyfills for any newer ECMAScript features so that they can work in environments that do not support them. It is already imported at the very top of src/index.js.

import "./style.css";
import "@babel/polyfill";

@babel/preset-env identifies which transforms and polyfills are necessary for any browsers or environments chosen as targets.

Take a look at the Babel configurations file, .babelrc, to see how it's included:

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "last 2 versions"
      }
    ]
  ]
}

This is a Babel and webpack setup. Learn how to include Babel in your application if you happen to use a different module bundler than webpack.

The targets attribute in .babelrc identifies which browsers are being targeted. @babel/preset-env integrates with browserslist, which means you can find a full list of compatible queries that can be used in this field in the browserlist documentation.

The "last 2 versions" value transpiles the code in the application for the last two versions of every browser.

Debugging #

To get a complete look at all the browser's Babel targets as well as all the transforms and polyfills that are included, add a debug field to .babelrc:

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "last 2 versions",
        "debug": true
      }
    ]
  ]
}

Click Tools.
Click Logs.

Reload the application and take a look at the Glitch status logs at the bottom of the editor.

Targeted browsers #

Babel logs a number of details to the console about the compilation process, including all the target environments that the code has been compiled for.

Notice how discontinued browsers, such as Internet Explorer, are included in this list. This is a problem because unsupported browsers won't have newer features added, and Babel continues to transpile specific syntax for them. This unnecessarily increases the size of your bundle if users are not using this browser to access your site.

Babel also logs a list of transform plugins used:

That's a pretty long list! These are all the plugins that Babel needs to use to transform any ES2015+ syntax to older syntax for all the targeted browsers.

However, Babel doesn't show any specific polyfills that are used:

This is because the entire @babel/polyfill is being imported directly.

Load polyfills individually #

By default, Babel includes every polyfill needed for a complete ES2015+ environment when @babel/polyfill is imported into a file. To import specific polyfills needed for the target browsers, add a useBuiltIns: 'entry' to the configuration.

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "last 2 versions",
        "debug": true
        "useBuiltIns": "entry"
      }
    ]
  ]
}

Reload the application. You can now see all the specific polyfills included:

Although only needed polyfills for "last 2 versions" is now included, it is still a super long list! This is because polyfills needed for the target browsers for every newer feature is still included. Change the value of the attribute to usage to only include those needed for features that are being used in the code.

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "last 2 versions",
        "debug": true,
        "useBuiltIns": "entry"
        "useBuiltIns": "usage"
      }
    ]
  ]
}

With this, polyfills are automatically included where needed. This means you can remove the @babel/polyfill import in src/index.js.

import "./style.css";
import "@babel/polyfill";

Now only the required polyfills needed for the application are included.

The application bundle size is reduced significantly.

Narrowing the list of supported browsers #

The number of browser targets included is still quite large, and not many users use discontinued browsers such as Internet Explorer. Update the configurations to the following:

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "last 2 versions",
        "targets": [">0.25%", "not ie 11"],
        "debug": true,
        "useBuiltIns": "usage",
      }
    ]
  ]
}

Take a look at the details for the fetched bundle.

Since the application is so small, there really isn't much of a difference with these changes. However, using a browser market share percentage (such as ">0.25%") along with excluding specific browsers that you are confident your users are not using is the recommended approach. Take a look at the "Last 2 versions" considered harmful article by James Kyle to learn more about this.

Use <script type="module"> #

There is still more room for improvement. Although a number of unused polyfills have been removed, there are many that are being shipped that are not needed for some browsers. By using modules, newer syntax can be written and shipped to browsers directly without the use of any unnecessary polyfills.

JavaScript modules are a relatively new feature supported in all major browsers. Modules can be created using a type="module" attribute to define scripts that import and export from other modules. For example:

// math.mjs
export const add = (x, y) => x + y;

<!-- index.html -->
<script type="module">
  import { add } from './math.mjs';

  add(5, 2); // 7
</script>

Many newer ECMAScript features are already supported in environments that support JavaScript modules (instead of needing Babel.) This means that the Babel config can be modified to send two different versions of your application to the browser:

A version that would work in newer browsers that support modules and that includes a module that is largely untranspiled but has a smaller file size
A version that includes a larger, transpiled script that would work in any legacy browser

Using ES Modules with Babel #

To have separate @babel/preset-env settings for the two versions of the application, remove the .babelrc file. Babel settings can be added to the webpack configuration by specifying two different compilation formats for each version of the application.

Begin by adding a configuration for the legacy script to webpack.config.js:

const legacyConfig = {
  entry,
  output: {
    path: path.resolve(__dirname, "public"),
    filename: "[name].bundle.js"
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: "babel-loader",
        options: {
          presets: [
            ["@babel/preset-env", {
              useBuiltIns: "usage",
              targets: {
                esmodules: false
              }
            }]
          ]
        }
      },
      cssRule
    ]
  },
  plugins
}

Notice that instead of using the targets value for "@babel/preset-env", esmodules with a value of false is used instead. This means that Babel includes all the necessary transforms and polyfills to target every browser that does not yet support ES modules.

Add entry, cssRule, and corePlugins objects to the beginning of the webpack.config.js file. These are all shared between both the module and legacy scripts served to the browser.

const entry = {
  main: "./src"
};

const cssRule = {
  test: /\.css$/,
  use: ExtractTextPlugin.extract({
    fallback: "style-loader",
    use: "css-loader"
  })
};

const plugins = [
  new ExtractTextPlugin({filename: "[name].css", allChunks: true}),
  new HtmlWebpackPlugin({template: "./src/index.html"})
];

Now similarly, create a config object for the module script below where legacyConfig is defined:

const moduleConfig = {
  entry,
  output: {
    path: path.resolve(__dirname, "public"),
    filename: "[name].mjs"
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: "babel-loader",
        options: {
          presets: [
            ["@babel/preset-env", {
              useBuiltIns: "usage",
              targets: {
                esmodules: true
              }
            }]
          ]
        }
      },
      cssRule
    ]
  },
  plugins
}

The main difference here is that a .mjs file extension is used for the output filename. The esmodules value is set to true here which means that the code that is outputted into this module is a smaller, less compiled script that does not go through any transformation in this example since all the features used are already supported in browsers that support modules.

At the very end of the file, export both configurations in a single array.

module.exports = [
  legacyConfig, moduleConfig
];

Now this builds both a smaller module for browsers that support it and a larger transpiled script for older browsers.

Browsers that support modules ignore scripts with a nomodule attribute. Conversely, browsers that do not support modules ignore script elements with type="module". This means you can include a module as well as a compiled fallback. Ideally, the two versions of the application should be in index.html like this:

<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js"></script>

Browsers that support modules fetch and execute main.mjs and ignore main.bundle.js. The browsers that do not support modules do the opposite.

It is important to note that unlike regular scripts, module scripts are always deferred by default. If you would like the equivalent nomodule script to also be deferred and only executed after parsing, then you'll need to add the defer attribute:

<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js" defer></script>

The last thing that needs to be done here is to add the module and nomodule attributes to the module and legacy script respectively, Import the ScriptExtHtmlWebpackPlugin at the very top of webpack.config.js:

const path = require("path");

const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const ScriptExtHtmlWebpackPlugin = require("script-ext-html-webpack-plugin");

Now update the plugins array in the configurations to include this plugin:

const plugins = [
  new ExtractTextPlugin({filename: "[name].css", allChunks: true}),
  new HtmlWebpackPlugin({template: "./src/index.html"}),
  new ScriptExtHtmlWebpackPlugin({
    module: /\.mjs$/,
    custom: [
      {
        test: /\.js$/,
        attribute: 'nomodule',
        value: ''
    },
    ]
  })
];

These plugin settings add a type="module" attribute for all .mjs script elements as well as a nomodule attribute for all .js script modules.

Serving modules in the HTML document #

The last thing that needs to be done is to output both the legacy and modern script elements to the HTML file. Unfortunately, the plugin that creates the final HTML file, HTMLWebpackPlugin, does not currently support the output of both the module and nomodule scripts. Although there are workarounds and separate plugins created to solve this problem, such as BabelMultiTargetPlugin and HTMLWebpackMultiBuildPlugin, a simpler approach of adding the module script element manually is used for the purpose of this tutorial.

Add the following to src/index.js at the end of the file:

    ...
    </form>
    <script type="module" src="main.mjs"></script>
  </body>
</html>

Now load the application in a browser that supports modules, such as the latest version of Chrome.

Only the module is fetched, with a much smaller bundle size due to it being largely untranspiled! The other script element is completely ignored by the browser.

If you load the application on an older browser, only the larger, transpiled script with all the needed polyfills and transforms are be fetched. Here is a screenshot for all the requests made on an older version of Chrome (version 38).

Conclusion #

You now understand how to use @babel/preset-env to provide only the necessary polyfills required for targeted browsers. You also know how JavaScript modules can improve performance further by shipping two different transpiled versions of an application. With a decent understanding of how both these techniques can cut your bundle size down significantly, go forth and optimize!

Remove unused code

2018-11-05T00:00:00Z

Registries like npm have transformed the JavaScript world for the better by allowing anyone to easily download and use over half a million public packages. But we often include libraries we're not fully utilizing. To fix this issue, analyze your bundle to detect unused code. Then remove unused and unnecessary libraries.

Impact on Core Web Vitals #

By removing unused code, you can improve your website's Core Web Vitals. Largest Contentful Paint, for example, can be affected by unused code by increased bandwidth contention caused by larger than necessary assets. LCP can also be affected if large JavaScript assets that render markup solely on the client contain references to LCP candidates by delaying when these resources can load.

Other metrics such as First Input Delay (FID) and Interaction to Next Paint (INP) can also be affected by unused code, because even unused JavaScript must be downloaded, parsed, compiled, and then executed. The unused code can introduce unnecessary delays in resource load time, memory usage, and main thread activity that contribute to poor page responsiveness.

This guide will help you get a handle on your project's unused code by showing you how to analyze your project's codebase, and offer strategies for pruning unused code from the JavaScript assets you ship to your users in production.

Analyze your bundle #

DevTools makes it easy to see the size of all network requests:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
Reload the page.

The Coverage tab in DevTools will also tell you how much CSS and JS code in your application is unused.

By specifying a full Lighthouse configuration through its Node CLI, an "Unused JavaScript" audit can also be used to trace how much unused code is being shipped with your application.

If you happen to be using webpack as your bundler, Webpack Bundle Analyzer will help you investigate what makes up the bundle. Include the plugin in your webpack configurations file like any other plugin:

module.exports = {
  //...
  plugins: [
    //...
    new BundleAnalyzerPlugin()
  ]
}

Although webpack is commonly used to build single-page applications, other bundlers, such as Parcel and Rollup, also have visualization tools that you can use to analyze your bundle.

Reloading the application with this plugin included shows a zoomable treemap of your entire bundle.

Using this visualization allows you to inspect which parts of your bundle are larger than others, as well as get a better idea of all the libraries that you're importing. This can help identify if you are using any unused or unnecessary libraries.

Remove unused libraries #

In the previous treemap image, there are quite a few packages within a single @firebase domain. If your website only needs the firebase database component, update the imports to fetch that library:

import firebase from 'firebase';
import firebase from 'firebase/app';
import 'firebase/database';

It is important to emphasize that this process is significantly more complex for larger applications.

For the mysterious looking package that you're quite sure is not being used anywhere, take a step back and see which of your top-level dependencies are using it. Try to find a way to only import the components that you need from it. If you aren't using a library, remove it. If the library isn't required for the initial page load, consider if it can be lazy loaded.

And in case you're using webpack, check out the list of plugins that automatically remove unused code from popular libraries.

Remove unnecessary libraries #

Not all libraries can be easily broken down into parts and selectively imported. In these scenarios, consider if the library could be removed entirely. Building a custom solution or leveraging a lighter alternative should always be options worth considering. However, it is important to weigh the complexity and effort required for either of these efforts before removing a library entirely from an application.

Reduce JavaScript payloads with code splitting

2018-11-05T00:00:00Z

Nobody likes waiting. Over 50% of users abandon a website if it takes longer than 3 seconds to load.

Sending large JavaScript payloads impacts the speed of your site significantly. Instead of shipping all the JavaScript to your user as soon as the first page of your application is loaded, split your bundle into multiple pieces and only send what's necessary at the very beginning.

Why is code splitting beneficial? #

Code splitting is a technique that seeks to minimize startup time. When we ship less JavaScript at startup, we can get applications to be interactive faster by minimizing main thread work during this critical period.

When it comes to Core Web Vitals, reducing JavaScript payloads downloaded at startup will contribute to better First Input Delay (FID) and Interaction to Next Paint (INP) times. The reasoning behind this is that, by freeing up the main thread, the application is able to respond to user inputs more quickly by reducing JavaScript parse, compile, and execution-related startup costs.

Depending on your website's architecture—particularly if your website relies heavily on client-side rendering—reducing the size of JavaScript payloads responsible for rendering markup may lead to improved Largest Contentful Paint (LCP) times. This can occur when the LCP resource is delayed in being discovered by the browser until after client-side markup is completed, or when the main thread is too busy to render that LCP element. Both scenarios can delay the LCP time for the page.

Measure #

Lighthouse displays a failed audit when a significant amount of time is taken to execute all the JavaScript on a page.

Split the JavaScript bundle to only send the code needed for the initial route when the user loads an application. This minimizes the amount of script that needs to be parsed and compiled, which results in faster page load times.

Popular module bundlers like webpack, Parcel, and Rollup allow you to split your bundles using dynamic imports. For example, consider the following code snippet that shows an example of a someFunction method that gets fired when a form is submitted.

import moduleA from "library";

form.addEventListener("submit", e => {
  e.preventDefault();
  someFunction();
});

const someFunction = () => {
  // uses moduleA
}

In here, someFunction uses a module imported from a particular library. If this module is not being used elsewhere, the code block can be modified to use a dynamic import to fetch it only when the form is submitted by the user.

form.addEventListener("submit", e => {
  e.preventDefault();
  import('library.moduleA')
    .then(module => module.default) // using the default export
    .then(() => someFunction())
    .catch(handleError());
});

const someFunction = () => {
    // uses moduleA
}

The code that makes up the module does not get included into the initial bundle and is now lazy loaded, or provided to the user only when it is needed after the form submission. To further improve page performance, preload critical chunks to prioritize and fetch them sooner.

Although the previous code snippet is a simple example, lazy loading third party dependencies is not a common pattern in larger applications. Usually, third party dependencies are split into a separate vendor bundle that can be cached since they don't update as often. You can read more about how the SplitChunksPlugin can help you do this.

Splitting on the route or component level when using a client-side framework is a simpler approach to lazy loading different parts of your application. Many popular frameworks that use webpack provide abstractions to make lazy loading easier than diving into the configurations yourself.

Apply instant loading with the PRPL pattern

2018-11-05T00:00:00Z

PRPL is an acronym that describes a pattern used to make web pages load and become interactive, faster:

Preload the most important resources.
Render the initial route as soon as possible.
Pre-cache remaining assets.
Lazy load other routes and non-critical assets.

In this guide, learn how each of these techniques fit together but still can be used independently to achieve performance results.

Audit your page with Lighthouse #

Run Lighthouse to identify opportunities for improvement aligned with the PRPL techniques:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Select the Performance and Progressive Web App checkboxes.
Click Run Audits to generate a report.

For more information, see Discover performance opportunities with Lighthouse.

Preload critical resources #

Lighthouse shows the following failed audit if a certain resource is parsed and fetched late:

Preload is a declarative fetch request that tells the browser to request a resource as soon as possible. Preload critical resources by adding a <link> tag with rel="preload" to the head of your HTML document:

<link rel="preload" as="style" href="css/style.css">

The browser sets a more appropriate priority level for the resource in order to try to download it sooner while not delaying the window.onload event.

For more information about preloading critical resources, refer to the Preload critical assets guide.

Render the initial route as soon as possible #

Lighthouse provides a warning if there are resources that delay First Paint, the moment when your site renders pixels to the screen:

To improve First Paint, Lighthouse recommends inlining critical JavaScript and deferring the rest using async, as well as inlining critical CSS used above-the-fold. This improves performance by eliminating round-trips to the server to fetch render-blocking assets. However, inline code is harder to maintain from a development perspective and cannot be cached separately by the browser.

Another approach to improve First Paint is to server-side render the initial HTML of your page. This displays content immediately to the user while scripts are still being fetched, parsed, and executed. However, this can increase the payload of the HTML file significantly, which can harm Time to Interactive, or the time it takes for your application to become interactive and can respond to user input.

There is no single correct solution to reduce the First Paint in your application, and you should only consider inlining styles and server-side rendering if the benefits outweigh the tradeoffs for your application. You can learn more about both of these concepts with the following resources.

Pre-cache assets #

By acting as a proxy, service workers can fetch assets directly from the cache rather than the server on repeat visits. This not only allows users to use your application when they are offline, but also results in faster page load times on repeat visits.

Use a third-party library to simplify the process of generating a service worker unless you have more complex caching requirements than what a library can provide. For example, Workbox provides a collection of tools that allow you to create and maintain a service worker to cache assets. For more information on service workers and offline reliability, refer to the service worker guide in the reliability learning path.

Lazy load #

Lighthouse displays a failed audit if you send too much data over the network.

This includes all asset types, but large JavaScript payloads are especially costly due to the time it takes the browser to parse and compile them. Lighthouse also provides a warning for this when appropriate.

To send a smaller JavaScript payload that contains only the code needed when a user initially loads your application, split the entire bundle and lazy load chunks on demand.

Once you've managed to split your bundle, preload the chunks that are more important (see the Preload critical assets guide). Preloading ensures more important resources are fetched and downloaded sooner by the browser.

Aside from splitting and loading different JavaScript chunks on demand, Lighthouse also provides an audit for lazy loading non-critical images.

If you load many images on your web page, defer all that are below the fold, or outside the device viewport, when a page is loaded (see Use lazysizes to lazyload images).

Next Steps #

Now that you understand some of the basic concepts behind the PRPL pattern, continue to the next guide in this section to learn more. It's important to remember that not all of the techniques need to be applied together. Any efforts made with any of the following will provide noticeable performance improvements.

Preload critical resources.
Render the initial route as soon as possible.
Pre-cache remaining assets.
Lazy load other routes and non-critical assets.

You can read up more about PRPL patterns.

Replace animated GIFs with video for faster page loads

2018-11-05T00:00:00Z

Have you ever seen an animated GIF on a service like Imgur or Gfycat, inspected it in your dev tools, only to find out that GIF was really a video? There's a good reason for that. Animated GIFs can be downright huge.

Thankfully, this is one of those areas of loading performance where you can do relatively little work to realize huge gains! By converting large GIFs to videos, you can save big on users' bandwidth.

Measure first #

Use Lighthouse to check your site for GIFs that can be converted to videos. In DevTools, click on the Audits tab and check the Performance checkbox. Then run Lighthouse and check the report. If you have any GIFs that can be converted, you should see a suggestion to "Use video formats for animated content":

Create MPEG videos #

There are a number of ways to convert GIFs to video, FFmpeg is the tool used in this guide. To use FFmpeg to convert the GIF, my-animation.gif to an MP4 video, run the following command in your console:

ffmpeg -i my-animation.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4

This tells FFmpeg to take my-animation.gif as the input, signified by the -i flag, and to convert it to a video called my-animation.mp4.

The libx264 encoder only works with files that have even dimensions, like 320px by 240px. If the input GIF has odd dimensions you can include a crop filter to avoid FFmpeg throwing a 'height/width not divisible by 2' error:

ffmpeg -i my-animation.gif -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2" -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4

Create WebM videos #

While MP4 has been around since 1999, WebM is a relatively new file format initially released in 2010. WebM videos are much smaller than MP4 videos, but not all browsers support WebM so it makes sense to generate both.

To use FFmpeg to convert my-animation.gif to a WebM video, run the following command in your console:

ffmpeg -i my-animation.gif -c vp9 -b:v 0 -crf 41 my-animation.webm

Compare the difference #

The cost savings between a GIF and a video can be pretty significant.

In this example, the initial GIF is 3.7 MB, compared to the MP4 version, which is 551 KB, and the WebM version, which is only 341 KB!

Replace the GIF img with a video #

Animated GIFs have three key traits that a video needs to replicate:

They play automatically.
They loop continuously (usually, but it is possible to prevent looping).
They're silent.

Luckily, you can recreate these behaviors using the <video> element.

<video autoplay loop muted playsinline></video>

A <video> element with these attributes plays automatically, loops endlessly, plays no audio, and plays inline (that is, not full screen), all the hallmark behaviors expected of animated GIFs! 🎉

Finally, the <video> element requires one or more <source> child elements pointing to different video files that the browser can choose from, depending on the browser's format support. Provide both WebM and MP4, so that if a browser doesn't support WebM, it can fall back to MP4.

<video autoplay loop muted playsinline>
  <source src="my-animation.webm" type="video/webm">
  <source src="my-animation.mp4" type="video/mp4">
</video>

Effect on Largest Contentful Paint (LCP) #

It should be noted that while <img> elements are candidates for LCP, <video> elements without a poster image are not LCP candidates. The solution in the case of emulating animated GIFs is not to add poster attribute to your <video> elements, because that image will go unused.

What does this mean for your website? The recommendation is to stick with using a <video> instead of an animated GIF, but with the understanding that such media will not be a candidate for LCP, and the next largest candidate will be used instead. As GIFs and <video>s are typically larger and so slower to download, moving to a different LCP candidate will likely even improve the site's LCP.

Preload critical assets to improve loading speed

2018-11-05T00:00:00Z

When you open a web page, the browser requests the HTML document from a server, parses its contents, and submits separate requests for any referenced resources. As a developer, you already know about all the resources your page needs and which of them are the most important. You can use that knowledge to request the critical resources ahead of time and speed up the loading process. This post explains how to achieve that with <link rel="preload">.

How preloading works #

Preloading is best suited for resources typically discovered late by the browser.

In this example, Pacifico font is defined in the stylesheet with a @font-face rule. The browser loads the font file only after it has finished downloading and parsing the stylesheet.

By preloading a certain resource, you are telling the browser that you would like to fetch it sooner than the browser would otherwise discover it because you are certain that it is important for the current page.

In this example, Pacifico font is preloaded, so the download happens in parallel with the stylesheet.

The critical request chain represents the order of resources that are prioritized and fetched by the browser. Lighthouse identifies assets that are on the third level of this chain as late-discovered. You can use the Preload key requests audit to identify which resources to preload.

You can preload resources by adding a <link> tag with rel="preload" to the head of your HTML document:

<link rel="preload" as="script" href="critical.js">

The browser caches preloaded resources so they are available immediately when needed. (It doesn't execute the scripts or apply the stylesheets.)

Resource hints, for example, preconnectand prefetch, are executed as the browser sees fit. The preload, on the other hand, is mandatory for the browser. Modern browsers are already pretty good at prioritizing resources, that's why it's important to use preload sparingly and only preload the most critical resources.

Unused preloads trigger a Console warning in Chrome, approximately 3 seconds after the load event.

Use cases #

Preloading resources defined in CSS #

Fonts defined with @font-face rules or background images defined in CSS files aren't discovered until the browser downloads and parses those CSS files. Preloading these resources ensures they are fetched before the CSS files have downloaded.

Preloading CSS files #

If you are using the critical CSS approach, you split your CSS into two parts. The critical CSS required for rendering the above-the-fold content is inlined in the <head> of the document and non-critical CSS is usually lazy-loaded with JavaScript. Waiting for JavaScript to execute before loading non-critical CSS can cause delays in rendering when users scroll, so it's a good idea to use <link rel="preload"> to initiate the download sooner.

Preloading JavaScript files #

Because browsers don't execute preloaded files, preloading is useful to separate fetching from execution which can improve metrics such as Time to Interactive. Preloading works best if you split your JavaScript bundles and only preload critical chunks.

How to implement rel=preload #

The simplest way to implement preload is to add a <link> tag to the <head> of the document:

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

Supplying the as attribute helps the browser set the priority of the prefetched resource according to its type, set the right headers, and determine whether the resource already exists in the cache. Accepted values for this attribute include: script, style, font, image, and others.

Some types of resources, such as fonts, are loaded in anonymous mode. For those you must set the crossorigin attribute with preload:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

<link> elements also accept a type attribute, which contains the MIME type of the linked resource. The browsers use the value of the type attribute to make sure that resources get preloaded only if their file type is supported. If a browser doesn't support the specified resource type, it will ignore the <link rel="preload">.

You can also preload any type of resource via the Link HTTP header:

Link: </css/style.css>; rel="preload"; as="style"

A benefit of specifying preload in the HTTP Header is that the browser doesn't need to parse the document to discover it, which can offer small improvements in some cases.

Preloading JavaScript modules with webpack #

If you are using a module bundler that creates build files of your application, you need to check if it supports the injection of preload tags. With webpack version 4.6.0 or later, preloading is supported through the use of magic comments inside import():

import(_/* webpackPreload: true */_ "CriticalChunk")

If you are using an older version of webpack, use a third-party plugin such as preload-webpack-plugin.

Effects of preloading on Core Web Vitals #

Preloading is a powerful performance optimization that has an effect on loading speed. Such optimizations can lead to changes in your site's Core Web Vitals, and it's important to be aware them.

Largest Contentful Paint (LCP) #

Preloading has a powerful effect on Largest Contentful Paint (LCP) when it comes to fonts and images, as both images and text nodes can be LCP candidates. Hero images and large runs of text that are rendered using web fonts can benefit significantly from a well-placed preload hint, and should be used when there are opportunities to deliver these important bits of content to the user faster.

However, you want to be careful when it comes to preloading—and other optimizations! In particular, avoid preloading too many resources. If too many resources are prioritized, effectively none of them are. The effects of excessive preload hints will be especially detrimental to those on slower networks where bandwidth contention will be more evident.

Instead, focus on a few high-value resources that you know will benefit from a well-placed preload. When preloading fonts, ensure that you're serving fonts in WOFF 2.0 format to reduce resource load time as much as possible. Since WOFF 2.0 has excellent browser support, using older formats such as WOFF 1.0 or TrueType (TTF) will delay your LCP if the LCP candidate is a text node.

When it comes to LCP and JavaScript, you'll want to ensure that you're sending complete markup from the server in order for the browser's preload scanner to work properly. If you're serving up an experience that relies entirely on JavaScript to render markup and can't send server-rendered HTML, it would be advantageous to step in where the browser preload scanner can't and preload resources that would only otherwise be discoverable when the JavaScript finishes loading and executing.

Cumulative Layout Shift (CLS) #

Cumulative Layout Shift (CLS) is an especially important metric where web fonts are concerned, and CLS has significant interplay with web fonts that use the font-display CSS property to manage how fonts are loaded. To minimize web font-related layout shifts, consider the following strategies:

Preload fonts while using the default block value for font-display. This is a delicate balance. Blocking the display of fonts without a fallback can be considered a user experience problem. On one hand, loading fonts with font-display: block; eliminates web font-related layout shifts. On the other hand, you still want to get those web fonts loaded as soon as possible if they're crucial to the user experience. Combining a preload with font-display: block; may be an acceptable compromise.
Preload fonts while using the fallback value for font-display. fallback is a compromise between swap and block, in that it has an extremely short blocking period.
Use the optional value for font-display without a preload. If a web font isn't crucial to the user experience, but it is still used to render a significant amount of page text, consider using the optional value. In adverse conditions, optional will display page text in a fallback font while it loads the font in the background for the next navigation. The net result in these conditions is improved CLS, as system fonts will render immediately, while subsequent page loads will load the font immediately without layout shifts.

CLS is a difficult metric to optimize for when it comes to web fonts. As always, experiment in the lab, but trust your field data to determine if your font loading strategies are improving CLS or making it worse.

Responsiveness metrics #

First Input Delay (FID) and Interaction to Next Paint are two metrics that gauge responsiveness to user input. Since the lion's share of interactivity on the web is driven by JavaScript, preloading JavaScript that powers important interactions may help to keep your FID and INP metrics as low as they can possibly be. However, be aware that FID is a load responsiveness metric and INP observes interactions throughout the entire page lifecycle—including during startup. Preloading too much JavaScript during startup can carry unintended negative consequences if too many resources are contending for bandwidth.

You'll also want to be careful about how you go about code splitting. Code splitting is an excellent optimization for reducing the amount of JavaScript loaded during startup, but interactions can be delayed if they rely on JavaScript loaded right at the start of the interaction. To compensate for this, you'll need to examine the user's intent, and inject a preload for the necessary chunk(s) of JavaScript before the interaction takes place. One example could be preloading JavaScript required for validating a form's contents when any of the fields in the form are focused.

Conclusion #

To improve page speed, preload important resources that are discovered late by the browser. Preloading everything would be counterproductive so use preload sparingly and measure the impact in the real-world.

Serve modern code to modern browsers for faster page loads

2018-11-05T00:00:00Z

Building websites that work well on all major browsers is a core tenet of an open web ecosystem. However, this means additional work of ensuring that all of the code you write is supported in each browser that you plan to target. If you want to use new JavaScript language features, you need to transpile these features to backwards-compatible formats for browsers that do not yet support them.

Babel is the most widely used tool to compile code that contains newer syntax into code that different browsers and environments (such as Node) can understand. This guide assumes you are using Babel, so you need to follow the setup instructions to include it into your application if you haven't already. Select webpack in Build Systems if you are using webpack as the module bundler in your app.

To use Babel to only transpile what is needed for your users, you need to:

Identify which browsers you want to target.
Use @babel/preset-env with appropriate browser targets.
Use <script type="module"> to stop sending transpiled code to browsers that don't need it.

Identify which browsers you want to target #

Before you begin to modify how the code in your application is transpiled, you need to identify which browsers access your application. Analyze which browsers your users are currently using as well as those that you plan to target to make an informed decision.

Use @babel/preset-env #

Transpiling code usually results in a file that is larger in file size than their original forms. By minimizing the amount of compilation that you do you can reduce the size of your bundles to improve the performance of a web page.

Instead of including specific plugins to selectively compile certain language features you are using, Babel provides a number of presets that bundles plugins together. Use @babel/preset-env to only include the transforms and polyfills needed for the browsers you plan on targeting.

Include @babel/preset-env within the presets array in your Babel configurations file, .babelrc:

{
 "presets": [
   [
     "@babel/preset-env",
     {
       "targets": ">0.25%"
     }
   ]
 ]
}

Use the targets field to specify which browser versions you want to include by adding an appropriate query to the browsers field. @babel/preset-env integrates with browserslist, an open-source configuration shared between different tools for targeting browsers. A full list of compatible queries is in the browserslist documentation. Another option is to use a .browserslistrc file to list the environments you wish to target.

The ">0.25%" value tells Babel to only include the transforms needed to support browsers that make up more than 0.25% of global usage. This ensures your bundle does not contain unnecessary transpiled code for browsers that are used by a very small percentage of users.

In most cases, this is a better approach than using the following configuration:

  "targets": "last 2 versions"

The "last 2 versions" value transpiles your code for the last two versions of every browser, which means support is provided for discontinued browsers such as Internet Explorer. This can unnecessarily increase the size of your bundle if you do not expect these browsers to be used to access your application.

Ultimately, you should select the appropriate combination of queries to only target browsers that fit your needs.

Enable modern bugfixes #

@babel/preset-env groups multiple JavaScript syntax features into collections and enables/disables them based on the target browsers specified. Although this works well, an entire collection of syntax features is transformed when a targeted browser contains a bug with just a single feature. This often results in more transformed code than is necessary.

Originally developed as a separate preset, the bugfixes option in @babel/preset-env solves this problem by converting modern syntax that is broken in some browsers to the closest equivalent syntax that is not broken in those browsers. The result is nearly identical modern code with a few small syntax tweaks that guarantee compatibility in all target browsers. To use this optimization, make sure you have @babel/preset-env 7.10 or later installed, then set the bugfixes property to true:

{
 "presets": [
   [
     "@babel/preset-env",
     {
       "bugfixes": true
     }
   ]
 ]
}

In Babel 8, the bugfixes option will be enabled by default.

Use `<script type="module">` #

JavaScript modules, or ES modules, are a relatively new feature supported in all major browsers. You can use modules to create scripts that can import and export from other modules, but you can also use them with @babel/preset-env to only target browsers that support them.

Instead of querying for specific browser versions or market share, consider specifying "esmodules" : true inside your .babelrc file's targets field.

{
   "presets":[
      [
         "@babel/preset-env",
         {
            "targets":{
               "esmodules": true
            }
         }
      ]
   ]
}

Many newer ECMAScript features compiled with Babel are already supported in environments that support JavaScript modules. So by doing this, you simplify the process of making sure that only transpiled code is used for browsers that actually need it.

Ideally, the two version scripts of an application are included like this:

  <script type="module" src="main.mjs"></script>
  <script nomodule src="compiled.js" defer></script>

Browsers that support modules fetch and execute main.mjs and ignore compiled.js. The browsers that do not support modules do the opposite.

If you use webpack, you can set different targets in your configurations for two separate versions of your application:

A version only for browsers that support modules.
A version that includes a compiled script which works in any legacy browser. This has a larger file size, since transpilation needs to support a wider range of browsers.

With thanks to Connor Clark and Jason Miller for their reviews.

Reduce JavaScript payloads with code splitting

2018-11-05T00:00:00Z

Most web pages and applications are made up of many different parts. Instead of sending all the JavaScript that makes up the application as soon as the first page is loaded, splitting the JavaScript into multiple chunks improves page performance.

This codelab shows how to use code splitting to improve the performance of a simple application that sorts three numbers.

Measure #

Like always, it's important to first measure how well a website performs before attempting to add any optimizations.

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
Reload the app.

71.2 KB worth of JavaScript just to sort a few numbers in a simple application. What gives?

In the source code (src/index.js), the lodash library is imported and used in this application. Lodash provides many useful utility functions, but only a single method from the package is being used here. Installing and importing entire third-party dependencies where only a small portion of it is being utilized is a common mistake.

Optimize #

There are a few ways the bundle size can be trimmed:

Write a custom sorting method instead of importing a third-party library
Use the built in Array.prototype.sort() method to sort numerically
Only import the sortBy method from lodash and not the entire library
Download the code for sorting only when the user clicks the button

Options 1 and 2 are perfectly appropriate methods to reduce the bundle size (and would probably make the most sense for a real application). However, those are not used in this tutorial for the sake of teaching 😈.

Both options 3 and 4 help improve the performance of this application. The next few sections of this codelab cover these steps. Like any coding tutorial, always try to write the code yourself instead of copy and pasting.

Only import what you need #

A few files need to be modified to only import the single method from lodash. To begin with, replace this dependency in package.json:

"lodash": "^4.7.0",

with this:

"lodash.sortby": "^4.7.0",

Now in src/index.js, import this specific module:

import "./style.css";
import _ from "lodash";
import sortBy from "lodash.sortby";

And update how the values are sorted::

form.addEventListener("submit", e => {
  e.preventDefault();
  const values = [input1.valueAsNumber, input2.valueAsNumber, input3.valueAsNumber];
  const sortedValues = _.sortBy(values);
  const sortedValues = sortBy(values);

  results.innerHTML = `
    <h2>
      ${sortedValues}
    </h2>
  `
});

Reload the application, open DevTools, and take a look at the Network panel once again.

For this application, the bundle size was reduced by over 4X with very little work, but there's still more room for improvement.

Code splitting #

webpack is one of the most popular open-source module bundlers used today. In short, it bundles all JavaScript modules (as well as other assets) that make up a web application into static files that can be read by the browser.

The single bundle used in this application can be split into two separate chunks:

One responsible for the code that makes up our initial route
A secondary chunk that contains our sorting code

With the use of dynamic imports, a secondary chunk can be lazy loaded, or loaded on demand. In this application, the code that makes up the chunk can be loaded only when the user presses the button.

Begin by removing the top-level import for the sort method in src/index.js:

import sortBy from "lodash.sortby";

And import it within the event listener that fires when the button is pressed:

form.addEventListener("submit", e => {
  e.preventDefault();
  import('lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

The import() feature is part of a proposal (currently at stage 3 of the TC39 process) to include the capability to dynamically import a module. webpack has already included support for this and follows the same syntax laid out by the proposal.

import() returns a promise and when it resolves, the selected module is provided which is split out into a separate chunk. After the module is returned, module.default is used to reference the default export provided by lodash. The promise is chained with another .then that calls a sortInput method to sort the three input values. At the end of the promise chain, .catch() is used to handle cases where the promise is rejected due to an error.

The last thing that needs to be done is to write the sortInput method at the end of the file. This needs to be a function that returns a function that takes in the imported method from lodash.sortBy. The nested function can then sort the three input values and update the DOM.

const sortInput = () => {
  return (sortBy) => {
    const values = [
      input1.valueAsNumber,
      input2.valueAsNumber,
      input3.valueAsNumber
    ];
    const sortedValues = sortBy(values);

    results.innerHTML = `
      <h2>
        ${sortedValues}
      </h2>
    `
  };
}

Monitor #

Reload the application one last time and keep a close eye on the Network panel again. Only a small initial bundle is downloaded as soon as the app loads.

After the button is pressed to sort the input numbers, the chunk that contains the sorting code gets fetched and executed.

Notice how the numbers still get sorted!

Conclusion #

Code splitting and lazy loading can be extremely useful techniques to trim down the initial bundle size of your application, and this can directly result in much faster page load times. However, there are some important things that need to be considered before including this optimization in your application.

Lazy loading UI #

When lazy loading specific modules of code, it's important to consider how the experience would be for users with weaker network connections. Splitting and loading a very large chunk of code when a user submits an action can make it seem like the application may have stopped working, so consider showing a loading indicator of some sort.

Lazy loading third-party node modules #

It is not always the best approach to lazy load third-party dependencies in your application and it depends on where you use them. Usually, third party dependencies are split into a separate vendor bundle that can be cached since they don't update as often. Read more about how the SplitChunksPlugin can help you do this.

Lazy loading with a JavaScript framework #

Many popular frameworks and libraries that use webpack provide abstractions to make lazy loading easier than using dynamic imports in the middle of your application.

Although it is useful to understand how dynamic imports work, always use the method recommended by your framework/library to lazy load specific modules.

Preloading and prefetching #

Where possible, take advantage of browser hints such as <link rel="preload"> or <link rel="prefetch"> to try and load critical modules even sooner. webpack supports both hints through the use of magic comments in import statements. This is explained in more detail in the Preload critical chunks guide.

Lazy loading more than code #

Images can make up a significant part of an application. Lazy loading those that are below the fold, or outside the device viewport, can speed up a website. Read more about this in the Lazysizes guide.

Remove unused code

2018-11-05T00:00:00Z

In this codelab, improve the performance of the following application by removing any unused and unneeded dependencies.

Measure #

It's always a good idea to first measure how well a website performs before adding optimizations.

To preview the site, press View App. Then press Fullscreen .

Go ahead and click on your favorite kitten! Firebase's Realtime Database is used in this application which is why the score updates in real-time and is synchronized with every other person using the application. 🐈

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
Reload the app.

Almost 1 MB worth of JavaScript is being shipped to load this simple application!

Take a look at the project warnings in DevTools.

Click on the Console tab.
Make sure that Warnings is enabled in the levels dropdown next to the Filter input.

Take a look at the displayed warning.

Firebase, which is one of the libraries used in this application, is being a good samaritan by providing a warning to let developers know to not import its entire package but only the components that are used. In other words, there are unused libraries that can be removed in this application to make it load faster.

There are also instances when a particular library is used, but where there may be a simpler alternative. The concept of removing unneeded libraries is explored later in this tutorial.

Analyzing the bundle #

There are two main dependencies in the application:

Firebase: a platform that provides a number of useful services for iOS, Android or web applications. Here its Realtime Database is used to store and sync the information for each kitten in real time.
Moment.js: a utility library that makes it easier to handle dates in JavaScript. The birth date of each kitten is stored in the Firebase database, and moment is used to calculate its age in weeks.

How can just two dependencies contribute to a bundle size of almost 1 MB? Well, one of the reasons is that any dependency can in turn have their own dependencies, so there are a lot more than just two if every depth/branch of the dependency "tree" is considered. It's easy for an application to become large relatively quickly if many dependencies are included.

Analyze the bundler to get a better idea of what is going. There are a number of different community-built tools that can help do this, such as webpack-bundle-analyzer.

The package for this tool is already included in the app as a devDependency.

"devDependencies": {
  //...
  "webpack-bundle-analyzer": "^2.13.1"
},

This means that it can be used directly in the webpack configuration file. Import it at the very beginning of webpack.config.js:

const path = require("path");

//...
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer")
  .BundleAnalyzerPlugin;

Now add it as a plugin at the very end of the file within the plugins array:

module.exports = {
  //...
  plugins: [
    //...
    new BundleAnalyzerPlugin()
  ]
};

When the application reloads, you should see a visualization of the entire bundle instead of the app itself.

Not as cute as seeing some kittens 🐱, but incredibly helpful nonetheless. Hovering over any of the packages shows its size represented in three different ways:

Stat size	Size before any minification or compression.
Parsed size	Size of actual package within the bundle after it has been compiled. Version 4 of webpack (which is used in this application) minifies the compiled files automatically which is why this is smaller than the stat size.
Gzipped size	Size of package after it has been compressed with gzip encoding. This topic is covered in a separate guide.

With the webpack-bundle-analyzer tool, it is easier to identify unused or unneeded packages that make up a large percentage of the bundle.

Removing unused packages #

The visualization shows that the firebase package consists of a lot more than just a database. It includes additional packages such as:

firestore
auth
storage
messaging
functions

These are all amazing services provided by Firebase (and refer to the documentation to learn more), but none of them are being used in the application, so there's no reason to have them all imported.

Revert the changes in webpack.config.js to see the application again:

Remove BundleAnalyzerPlugin in the list of plugins:

plugins: [
  //...
  new BundleAnalyzerPlugin()
];

And now remove the unused import from the top of the file:

const path = require("path");

//...
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

The application should load normally now. Modify src/index.js to update the Firebase imports.

import firebase from 'firebase';
import firebase from 'firebase/app';
import 'firebase/database';

Now when the app reloads, the DevTools warning does not show. Opening the DevTools Network panel also shows a nice reduction in bundle size:

More than half the bundle size was removed. Firebase provides many different services and gives developers the option to only include those that are actually needed. In this application, only firebase/database was used to store and sync all of the data. The firebase/app import, which sets up the API surface for each of the different services, is always required.

Many other popular libraries, such as lodash, also allow developers to selectively import different parts of their packages. Without doing much work, updating library imports in an application to only include what is being used can result in significant performance improvements.

Although the bundle size has been reduced by quite a bit, there's still more work to do! 😈

Removing unneeded packages #

Unlike Firebase, importing parts of the moment library cannot be done as easily, but maybe it can be removed entirely?

The birthday of each cute kitten is stored in Unix format (milliseconds) in the Firebase database.

This is a timestamp of a particular date and time represented by the number of milliseconds that have elapsed since January 1, 1970 00:00 UTC. If the current date and time can be calculated in the same format, a small function to find the age of each kitten in weeks can probably be constructed.

Like always, try not to copy and paste as you follow along here. Begin by removing moment from the imports in src/index.js.

import firebase from 'firebase/app';
import 'firebase/database';
import * as moment from 'moment';

There is a Firebase event listener that handles value changes in our database:

favoritesRef.on("value", (snapshot) => { ... })

Above this, add a small function to calculate the number of weeks from a given date:

const ageInWeeks = birthDate => {
  const WEEK_IN_MILLISECONDS = 1000 * 60 * 60 * 24 * 7;
  const diff = Math.abs((new Date).getTime() - birthDate);
  return Math.floor(diff / WEEK_IN_MILLISECONDS);
}

In this function, the difference in milliseconds between the current date and time (new Date).getTime() and the birth date (the birthDate argument, already in milliseconds) is calculated and divided by the number of milliseconds in a single week.

Finally, all instances of moment can be removed in the event listener by leveraging this function instead:

favoritesRef.on("value", (snapshot) => {
  const { kitties, favorites, names, birthDates } = snapshot.val();
  favoritesScores = favorites;

  kittiesList.innerHTML = kitties.map((kittiePic, index) => {
    const birthday = moment(birthDates[index]);

    return `
      <li>
        <img src=${kittiePic} onclick="favKittie(${index})">
        <div class="extra">
          <div class="details">
            <p class="name">${names[index]}</p>
            <p class="age">${moment().diff(birthday, 'weeks')} weeks old</p>
            <p class="age">${ageInWeeks(birthDates[index])} weeks old</p>
          </div>
          <p class="score">${favorites[index]} ❤</p>
        </div>
      </li>
    `})
});

Now reload the application and take a look at the Network panel once more.

The size of our bundle was reduced by more than half again!

Conclusion #

With this codelab, you should have a decent understanding of how to analyze a particular bundle and why it can be so useful to remove unused or unneeded packages. Before you begin optimizing an application with this technique, it's important to know that this can be significantly more complex in larger applications.

With regards to removing unused libraries, try to find out which parts of a bundle are being used and which parts are not. For a mysterious looking package that looks like it is not being used anywhere, take a step back and check which top-level dependencies might need it. Try to find a way to possibly decouple them from each other.

When it comes to removing unneeded libraries, things can be a little more complicated. It's important to work closely with your team and see if there is potential to simplify parts of the codebase. Removing moment in this application may look like it would be the right thing to do every time, but what if there were time zones and different locales that needed to be handled? Or what if there were more complicated date manipulations? Things can get very tricky when manipulating and parsing dates/times, and libraries like moment and date-fns simplify this significantly.

Everything is a tradeoff, and it's important to gauge whether it's even worth the complexity and effort to roll out a custom solution instead of relying on a third-party library.

Minify and compress network payloads

2018-11-05T00:00:00Z

There are two useful techniques that can be used to improve the performance of your web page:

Minification
Data compression

Incorporating both of these techniques reduces payload sizes and in turn improves page load times.

Measure #

Lighthouse displays a failed audit if it detects any CSS or JS resources on your page that can be minified.

It also audits for any uncompressed assets.

Minification #

Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file. Terser is a popular JavaScript compression tool and webpack v4 includes a plugin for this library by default to create minified build files.

If you're using webpack v4 or greater, you should be good to go without doing any additional work. 👍
If you are using an older version of webpack, install and include TerserWebpackPlugin into your webpack configuration settings. Follow the documentation to learn how.
If you are not using a module bundler, use Terser as a CLI tool or include it directly as a dependency to your application. The project documentation provides instructions.

Data compression #

Compression is the process of modifying data using a compression algorithm. Gzip is the most widely used compression format for server and client interactions. Brotli is a newer compression algorithm which can provide even better compression results than Gzip.

There are two different ways to compress files sent to a browser:

Dynamically
Statically

Both approaches have their own advantages and disadvantages which is covered in the next section. Use whichever works best for your application.

Dynamic compression #

This process involves compressing assets on-the-fly as they get requested by the browser. This can be simpler than compressing files manually or with a build process, but can cause delays if high compression levels are used.

Express is a popular web framework for Node and provides a compression middleware library. Use it to compress any asset as it gets requested. Here is an example of an entire server file that uses it correctly:

const express = require('express');
const compression = require('compression');

const app = express();

app.use(compression());

app.use(express.static('public'));

const listener = app.listen(process.env.PORT, function() {
	console.log('Your app is listening on port ' + listener.address().port);
});

This compresses your assets using gzip. If your web server supports it, consider using a separate module like shrink-ray to compress via Brotli to achieve better compression ratios.

Static compression #

Static compression involves compressing and saving assets ahead of time. This can make the build process take longer, especially if high compression levels are used, but ensures that no delays happen when the browser fetches the compressed resource.

If your web server supports Brotli, use a plugin like BrotliWebpackPlugin with webpack to compress your assets as part of your build step. Otherwise, use CompressionPlugin to compress your assets with gzip. It can be included just like any other plugin in the webpack configurations file:

module.exports = {
	//...
	plugins: [
		//...
		new CompressionPlugin()
	]
}

Once compressed files are part of the build folder, create a route in your server to handle all JS endpoints to serve the compressed files. Here is an example of how this can be done with Node and Express for gzipped assets.

const express = require('express');
const app = express();

app.get('*.js', (req, res, next) => {
	req.url = req.url + '.gz';
	res.set('Content-Encoding', 'gzip');
	next();
});

app.use(express.static('public'));

Minify and compress network payloads with gzip

2018-04-24T00:00:00Z

This codelab explores how both minifying and compressing the JavaScript bundle for the following application improves page performance by reducing the app's request size.

Measure #

Before diving in to add optimizations, it's always a good idea to first analyze the current state of the application.

To preview the site, press View App. Then press Fullscreen .

This app, which was also covered in the "Remove unused code" codelab, lets you vote for your favorite kitten. 🐈

Now take a look at how large this application is:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
Reload the app.

Although a lot of progress was made in the "Remove unused code" codelab to trim this bundle size down, 225 KB is still quite large.

Minification #

Consider the following block of code.

function soNice() {
  let counter = 0;

  while (counter < 100) {
    console.log('nice');
    counter++;
  }
}

If this function is saved in a file of its own, the file size is around 112 B (bytes).

If all whitespace is removed, the resulting code looks like this:

function soNice(){let counter=0;while(counter<100){console.log("nice");counter++;}}

The file size would now be around 83 B. If it gets further mangled by reducing the length of variable name and modifying some expressions, the final code may end up looking like this:

function soNice(){for(let i=0;i<100;)console.log("nice"),i++}

The file size now reaches 62 B.

With each step, the code is becoming harder to read. However, the browser's JavaScript engine interprets each of these in the exact same way. The benefit of obfuscating code in this manner can help achieve smaller file sizes. 112 B really was not much to begin with, but there was still a 50% reduction in size!

In this application, webpack version 4 is used as a module bundler. The specific version can be seen in package.json.

"devDependencies": {
  //...
  "webpack": "^4.16.4",
  //...
}

Version 4 already minifies the bundle by default during production mode. It uses TerserWebpackPlugin a plugin for Terser. Terser is a popular tool used to compress JavaScript code.

To get an idea of what the minified code looks like, go ahead and click main.bundle.js while still in the DevTools Network panel. Now click the Response tab.

The code in its final form, minified and mangled, is shown in the response body. To find out how large the bundle may have been if it was not minified, open webpack.config.js and update the mode configuration.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

Reload the application and take a look at the bundle size again through the DevTools Network panel

That's a pretty big difference! 😅

Make sure to revert the changes here before continuing.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

Including a process to minify code in your application depends on the tools that you use:

If webpack v4 or greater is used, no additional work needs to be done since code is minified by default in production mode. 👍
If an older version of webpack is used, install and include TerserWebpackPlugin into the webpack build process. The documentation explains this in detail.
Other minification plugins also exist and can be used instead, such as BabelMinifyWebpackPlugin and ClosureCompilerPlugin.
If a module bundler is not being used at all, use Terser as a CLI tool or include it directly as a dependency.

Compression #

Although the term "compression" is sometimes loosely used to explain how code is reduced during the minification process, it isn't actually compressed in the literal sense.

Compression usually refers to code that has been modified using a data compression algorithm. Unlike minification which ends up providing perfectly valid code, compressed code needs to be decompressed before being used.

With every HTTP request and response, browsers and web servers can add headers to include additional information about the asset being fetched or received. This can be seen in the Headers tab within the DevTools Network panel where three types are shown:

General represents general headers relevant to the entire request-response interaction.
Response Headers shows a list of headers specific to the actual response from the server.
Request Headers shows a list of headers attached to the request by the client.

Take a look at the accept-encoding header in the Request Headers.

accept-encoding is used by the browser to specify which content encoding formats, or compression algorithms, it supports. There are many text-compression algorithms out there, but there are only three that are supported here for the compression (and decompression) of HTTP network requests:

Gzip (gzip): The most widely used compression format for server and client interactions. It builds on top of the Deflate algorithm and is supported in all current browsers.
Deflate (deflate): Not commonly used.
Brotli (br): A newer compression algorithm that aims to further improve compression ratios, which can result in even faster page loads. It is supported in the latest versions of most browsers.

The sample application in this tutorial is identical to the app completed in the "Remove unused code" codelab except for the fact that Express is now used as a server framework. In the next few sections, both static and dynamic compression is explored.

Dynamic compression #

Dynamic compression involves compressing assets on-the-fly as they get requested by the browser.

Pros #

Creating and updating saved compressed versions of assets does not need to be done.
Compressing on-the-fly works especially well for web pages that are dynamically generated.

Cons #

Compressing files at higher levels to achieve better compression ratios takes longer. This can cause a performance hit as the user waits for assets to compress before they are sent by the server.

Dynamic compression with Node/Express #

The server.js file is responsible for setting up the Node server that hosts the application.

const express = require('express');

const app = express();

app.use(express.static('public'));

const listener = app.listen(process.env.PORT, function() {
  console.log('Your app is listening on port ' + listener.address().port);
});

All this currently does is import express and use the express.static middleware to load all the static HTML, JS and CSS files in the public/ directory (and those files are created by webpack with every build).

To make sure all of the assets are compressed every time they're requested, the compression middleware library can be used. Begin by adding it as a devDependency in package.json:

"devDependencies": {
  //...
  "compression": "^1.7.3"
},

And import it into the server file, server.js:

const express = require('express');
const compression = require('compression');

And add it as a middleware before express.static is mounted:

//...

const app = express();

app.use(compression());

app.use(express.static('public'));

//...

Now reload the app and take a look at the bundle size in the Network panel.

From 225 KB to 61.6 KB! In the Response Headers now, a content-encoding header shows that the server is sending down this file encoded with gzip.

Static compression #

The idea behind static compression is to have assets compressed and saved ahead of time.

Pros #

Latency due to high compression levels is not a concern anymore. Nothing needs to happen on-the-fly to compress files as they can now be fetched directly.

Cons #

Assets need to compressed with every build. Build times can increase significantly if high compression levels are used.

Static compression with Node/Express and webpack #

Since static compression involves compressing files ahead of time, webpack settings can be modified to compress assets as part of the build step. CompressionPlugin can be used for this.

Begin by adding it as a devDependency in package.json:

"devDependencies": {
  //...
  "compression-webpack-plugin": "^1.1.11"
},

Like any other webpack plugin, import it in the configurations file, webpack.config.js:

const path = require("path");

//...

const CompressionPlugin = require("compression-webpack-plugin");

And include it within the plugins array:

module.exports = {
  //...
  plugins: [
    //...
    new CompressionPlugin()
  ]
}

By default, the plugin compresses the build files using gzip. Take a look at the documentation to learn how to add options to use a different algorithm or include/exclude certain files.

When the app reloads and rebuilds, a compressed version of the main bundle is now created. Open the Glitch Console to take a look at what's inside the final public/ directory that's served by the Node server.

Click the Tools button.
Click the Console button.
In the console, run the following commands to change into the public directory and see all of its files:

cd public
ls

The gzipped version of the bundle, main.bundle.js.gz, is now saved here as well. CompressionPlugin also compresses index.html by default.

The next thing that needs to be done is tell the server to send these gzipped files whenever their original JS versions are being requested. This can be done by defining a new route in server.js before the files are served with express.static.

const express = require('express');
const app = express();

app.get('*.js', (req, res, next) => {
  req.url = req.url + '.gz';
  res.set('Content-Encoding', 'gzip');
  next();
});

app.use(express.static('public'));

//...

app.get is used to tell the server how to respond to a GET request for a specific endpoint. A callback function is then used to define how to handle this request. The route works like this:

Specifying '*.js' as the first argument means that this works for every endpoint that is fired to fetch a JS file.
Within the callback, .gz is attached to the URL of the request and the Content-Encoding response header is set to gzip.
Finally, next() ensures that the sequence continues to any callback that may be next.

Once the app reloads, take a look at the Network panel once more.

Just like before, a significant reduction in bundle size!

Conclusion #

This codelab covered the process of minifying and compressing source code. Both these techniques are becoming a default in many of the tools available today, so it's important to find out whether your toolchain already supports them or if you should begin applying both processes yourself.

Houssein Djirdeh on web.dev

Publish, ship, and install modern JavaScript for faster applications

Modern JavaScript #

Legacy JavaScript #

Modern JavaScript on npm #

Modern-only #

Modern with legacy fallback #

Modern with legacy fallback and ESM bundler optimizations #

Modern JavaScript in applications #

webpack #

Optimize Plugin #

BabelEsmPlugin #

Configure babel-loader to transpile node_modules #

Rollup #

@rollup/plugin-babel #

Additional build tools #

Optimize First Input Delay

Heavy JavaScript execution #

Break up Long Tasks #

Optimize your page for interaction readiness #

First-party script execution can delay interaction readiness #

Data-fetching can impact many aspects of interaction readiness #

Third-party script execution can delay interaction latency too #

Use a web worker #

Reduce JavaScript execution time #

Defer unused JavaScript #

Minimize unused polyfills #

Developer tools #

Improved Next.js and Gatsby page load performance with granular chunking

Introduction #

Improved Chunking #

More HTTP requests #

Size reductions with granular chunks #

Gatsby #

Conclusion #

Resolving Glitch issues

Project is suspended #

Exceeding disk usage #

Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fonts

Browser compatibility #

Font rendering #

Optional fonts #

Conclusion #

Advancing the web framework ecosystem

How do we make the web better? #

Contributions to web frameworks #

Angular #

Next.js #

Nuxt.js #

Babel #

What's next? #

How AMP can guarantee fastness in your Next.js app

What will you learn? #

How AMP guarantees fast page loads #

How you can use AMP in Next.js #

How to decide whether to use the Hybrid AMP or AMP-only approach #

Conclusion #

How to use AMP in Next.js

What will you learn? #

How to create Hybrid AMP pages #

How to conditionally serve AMP components #

How to create AMP-only pages #

Performance as a default with Next.js

What will you learn? #

How is Next.js different from React? #

Setting up #

What's next? #

Browser-level image lazy loading for the web

Browser compatibility #

Why browser-level lazy loading? #

The loading attribute #

Relationship between the loading attribute and fetch priority #

Distance-from-viewport thresholds #

Improved data-savings and distance-from-viewport thresholds #

Images should include dimension attributes #

Avoid lazy loading images that are in the first visible viewport #

Graceful degradation #

FAQ #

Are there plans to automatically lazy-load images in Chrome? #

Can I change how close an image needs to be before a load is triggered? #

The `loading` attribute #

Relationship between the `loading` attribute and fetch priority #

Can CSS background images take advantage of the `loading` attribute? #

How does the `loading` attribute work with images that are in the viewport but not immediately visible (for example: behind a carousel, or hidden by CSS for certain screen sizes)? #