Minko Gechev on web.dev

How CommonJS is making your bundles larger

2020-05-08T00:00:00Z

In this post, we'll look into what CommonJS is and why it's making your JavaScript bundles larger than necessary.

Summary: To ensure the bundler can successfully optimize your application, avoid depending on CommonJS modules, and use ECMAScript module syntax in your entire application.

What's CommonJS? #

CommonJS is a standard from 2009 that established conventions for JavaScript modules. It was initially intended for use outside of the web browser, primarily for server-side applications.

With CommonJS you can define modules, export functionality from them, and import them in other modules. For example, the snippet below defines a module which exports five functions: add, subtract, multiply, divide, and max:

// utils.js
const { maxBy } = require('lodash-es');
const fns = {
  add: (a, b) => a + b,
  subtract: (a, b) => a - b,
  multiply: (a, b) => a * b,
  divide: (a, b) => a / b,
  max: arr => maxBy(arr)
};

Object.keys(fns).forEach(fnName => module.exports[fnName] = fns[fnName]);

Later on, another module can import and use some or all of these functions:

// index.js
const { add } = require('./utils.js');
console.log(add(1, 2));

Invoking index.js with node will output the number 3 in the console.

Because of the lack of a standardized module system in the browser in the early 2010s, CommonJS became a popular module format for JavaScript client-side libraries as well.

How does CommonJS affect your final bundle size? #

The size of your server-side JavaScript application is not as critical as in the browser, that's why CommonJS was not designed with reducing the production bundle size in mind. At the same time, analysis shows that the JavaScript bundle size is still the number one reason for making browser apps slower.

JavaScript bundlers and minifiers, such as webpack and terser, perform different optimizations to reduce the size of your app. Analyzing your application at build time, they try to remove as much as possible from the source code you're not using.

For example, in the snippet above, your final bundle should only include the add function since this is the only symbol from utils.js that you import in index.js.

Let's build the app using the following webpack configuration:

const path = require('path');
module.exports = {
  entry: 'index.js',
  output: {
    filename: 'out.js',
    path: path.resolve(__dirname, 'dist'),
  },
  mode: 'production',
};

Here we specify that we want to use production mode optimizations and use index.js as an entry point. After invoking webpack, if we explore the output size, we'll see something like this:

$ cd dist && ls -lah
625K Apr 13 13:04 out.js

Notice that the bundle is 625KB. If we look into the output, we'll find all the functions from utils.js plus a lot of modules from lodash. Although we do not use lodash in index.js it's part of the output, which adds a lot of extra weight to our production assets.

Now let us change the module format to ECMAScript modules and try again. This time, utils.js would look like this:

export const add = (a, b) => a + b;
export const subtract = (a, b) => a - b;
export const multiply = (a, b) => a * b;
export const divide = (a, b) => a / b;

import { maxBy } from 'lodash-es';

export const max = arr => maxBy(arr);

And index.js would import from utils.js using ECMAScript module syntax:

import { add } from './utils.js';

console.log(add(1, 2));

Using the same webpack configuration, we can build our application and open the output file. It is now 40 bytes with the following output:

(()=>{"use strict";console.log(1+2)})();

Notice that the final bundle does not contain any of the functions from utils.js that we don't use, and there's no trace from lodash! Even further, terser (the JavaScript minifier that webpack uses) inlined the add function in console.log.

A fair question you might ask is, why does using CommonJS cause the output bundle to be almost 16,000 times bigger? Of course, this is a toy example, in reality, the size difference might not be that large, but the chances are that CommonJS adds significant weight to your production build.

CommonJS modules are harder to optimize in the general case because they are much more dynamic than ES modules. To ensure your bundler and minifier can successfully optimize your application, avoid depending on CommonJS modules, and use ECMAScript module syntax in your entire application.

Notice that even if you're using ECMAScript modules in index.js, if the module you're consuming is a CommonJS module, your app's bundle size will suffer.

Why does CommonJS make your app larger? #

To answer this question, we'll look at the behavior of the ModuleConcatenationPlugin in webpack and, after that, discuss static analyzability. This plugin concatenates the scope of all your modules into one closure and allows for your code to have a faster execution time in the browser. Let's look at an example:

// utils.js
export const add = (a, b) => a + b;
export const subtract = (a, b) => a - b;

// index.js
import { add } from './utils.js';
const subtract = (a, b) => a - b;

console.log(add(1, 2));

Above, we have an ECMAScript module, which we import in index.js. We also define a subtract function. We can build the project using the same webpack configuration as above, but this time, we'll disable minimization:

const path = require('path');

module.exports = {
  entry: 'index.js',
  output: {
    filename: 'out.js',
    path: path.resolve(__dirname, 'dist'),
  },
  optimization: {
    minimize: false
  },
  mode: 'production',
};

Let us look at the produced output:

/******/ (() => { // webpackBootstrap
/******/ 	"use strict";

// CONCATENATED MODULE: ./utils.js**
const add = (a, b) => a + b;
const subtract = (a, b) => a - b;

// CONCATENATED MODULE: ./index.js**
const index_subtract = (a, b) => a - b;**
console.log(add(1, 2));**

/******/ })();

In the output above, all the functions are inside the same namespace. To prevent collisions, webpack renamed the subtract function in index.js to index_subtract.

If a minifier processes the source code above, it will:

Remove the unused functions subtract and index_subtract
Remove all the comments and redundant whitespace
Inline the body of the add function in the console.log call

Often developers refer to this removal of unused imports as tree-shaking. Tree-shaking was only possible because webpack was able to statically (at build time) understand which symbols we are importing from utils.js and what symbols it exports.

This behavior is enabled by default for ES modules because they are more statically analyzable, compared to CommonJS.

Let us look at the exact same example, but this time change utils.js to use CommonJS instead of ES modules:

// utils.js
const { maxBy } = require('lodash-es');

const fns = {
  add: (a, b) => a + b,
  subtract: (a, b) => a - b,
  multiply: (a, b) => a * b,
  divide: (a, b) => a / b,
  max: arr => maxBy(arr)
};

Object.keys(fns).forEach(fnName => module.exports[fnName] = fns[fnName]);

This small update will significantly change the output. Since it's too long to embed on this page, I've shared only a small portion of it:

...
(() => {

"use strict";
/* harmony import */ var _utils__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(288);
const subtract = (a, b) => a - b;
console.log((0,_utils__WEBPACK_IMPORTED_MODULE_0__/* .add */ .IH)(1, 2));

})();

Notice that the final bundle contains some webpack "runtime": injected code that is responsible for importing/exporting functionality from the bundled modules. This time, instead of placing all the symbols from utils.js and index.js under the same namespace, we require dynamically, at runtime, the add function using __webpack_require__.

This is necessary because with CommonJS we can get the export name from an arbitrary expression. For example, the code below is an absolutely valid construct:

module.exports[localStorage.getItem(Math.random())] = () => { … };

There's no way for the bundler to know at build-time what the name of the exported symbol is since this requires information that's only available at runtime, in the context of the user's browser.

This way, the minifier is incapable of understanding what exactly index.js uses from its dependencies so it can't tree-shake it away. We'll observe the exact same behavior for third-party modules as well. If we import a CommonJS module from node_modules, your build toolchain will not be able to optimize it properly.

Tree-shaking with CommonJS #

It's much harder to analyze CommonJS modules since they are dynamic by definition. For example, the import location in ES modules is always a string literal, compared to CommonJS, where it is an expression.

In some cases, if the library you're using follows specific conventions on how it uses CommonJS, it's possible to remove unused exports at build time using a third-party webpack plugin. Although this plugin adds support for tree-shaking, it does not cover all the different ways your dependencies could use CommonJS. This means that you're not getting the same guarantees as with ES modules. Additionally, it adds an extra cost as part of your build process on top of the default webpack behavior.

Conclusion #

To ensure the bundler can successfully optimize your application, avoid depending on CommonJS modules, and use ECMAScript module syntax in your entire application.

Here are a few actionable tips to verify you're on the optimal path:

Use Rollup.js's node-resolve plugin and set the modulesOnly flag to specify that you want to depend only on ECMAScript modules.
Use the package is-esm to verify that an npm package uses ECMAScript modules.
If you're using Angular, by default you'll get a warning if you depend on non-tree-shakeable modules.

Create a Progressive Web App with the Angular CLI

2019-08-15T00:00:00Z

In this post, you'll learn how to use the Angular command line interface (CLI) to make a Progressive Web App (PWA).

You can find the code sample from this guide on GitHub.

Create an installable PWA #

To make your Angular application a PWA, all you need to do is run a single command:

ng add @angular/pwa

This command will:

Create a service worker with a default caching configuration.
Create a manifest file, which tells the browser how your app should behave when installed on the user's device.
Add a link to the manifest file in index.html.
Add the theme-color <meta> tag to index.html.
Create app icons in the src/assets directory.

By default, your service worker should be registered within a few seconds of the first page load. If it isn't, consider modifying the registrationStrategy.

Customize your PWA #

The Precaching with the Angular service worker post explains how to configure the Angular service worker. There you can find how to specify which resources you want the service worker to cache and what strategy it should use to do so.

The manifest file of your app lets you specify your app's name, short name, icons, theme color, and other details. Read about the full set of properties you can set on the Add a web app manifest post.

Take a peek at the manifest file generated by the Angular CLI:

{
  "name": "manifest-web-dev",
  "short_name": "manifest-web-dev",
  "theme_color": "#1976d2",
  "background_color": "#fafafa",
  "display": "standalone",
  "scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "assets/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    …
    {
      "src": "assets/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

You can customize any of these properties by changing the relevant value in manifest.webmanifest.

A PWA references its manifest file with a link element in index.html. Once the browser finds the reference, it'll show the Add to Home screen prompt:

Since the ng-add schematics add everything needed to make your app installable, they generate some shortcut icons that are shown once the user adds the app to their desktop:

Make sure you customize the manifest properties and icons before you deploy your PWA to production!

Conclusion #

To make an installable Angular app:

Add @angular/pwa to your project using the Angular CLI.
Edit the options in the manifest.webmanifest file to suit your project.
Update the icons in the src/assets/icons directory to suit your project.
Optionally, edit the theme-color in index.html.

Optimize Angular's change detection

2019-07-09T00:00:00Z

Angular runs its change detection mechanism periodically so that changes to the data model are reflected in an app's view. Change detection can be triggered either manually or through an asynchronous event (for example, a user interaction or an XHR completion).

Change detection is a powerful tool, but if it's run very often, it can trigger a lot of computations and block the main browser thread.

In this post you'll learn how to control and optimize the change detection mechanism by skipping parts of your application and running change detection only when necessary.

Inside Angular's change detection #

To understand how Angular's change detection works, let's look at a sample app!

You can find the code for the app in this GitHub repository.

The app lists employees from two departments in a company—sales and R&D—and has two components:

AppComponent, which is the root component of the app, and
Two instances of EmployeeListComponent, one for sales and one for R&D.

You can see the two instances of EmployeeListComponent in the template for AppComponent:

<app-employee-list
  [data]="salesList"
  department="Sales"
  (add)="add(salesList, $event)"
  (remove)="remove(salesList, $event)"
></app-employee-list>

<app-employee-list
  [data]="rndList"
  department="R&D"
  (add)="add(rndList, $event)"
  (remove)="remove(rndList, $event)"
></app-employee-list>

For each employee there's a name and a numeric value. The app passes the employee's numeric value to a business calculation and visualizes the result on screen.

Now take a look at EmployeeListComponent:

const fibonacci = (num: number): number => {
  if (num === 1 || num === 2) {
    return 1;
  }
  return fibonacci(num - 1) + fibonacci(num - 2);
};

@Component(...)
export class EmployeeListComponent {
  @Input() data: EmployeeData[];
  @Input() department: string;
  @Output() remove = new EventEmitter<EmployeeData>();
  @Output() add = new EventEmitter<string>();

  label: string;

  handleKey(event: any) {
    if (event.keyCode === 13) {
      this.add.emit(this.label);
      this.label = '';
    }
  }

  calculate(num: number) {
    return fibonacci(num);
  }
}

EmployeeListComponent accepts a list of employees and a department name as inputs. When the user tries to remove or add an employee, the component triggers a corresponding output. The component also defines the calculate method, which implements the business calculation.

Here's the template for EmployeeListComponent:

<h1 title="Department">{{ department }}</h1>
<mat-form-field>
  <input placeholder="Enter name here" matInput type="text" [(ngModel)]="label" (keydown)="handleKey($event)">
</mat-form-field>
<mat-list>
  <mat-list-item *ngFor="let item of data">
    <h3 matLine title="Name">
      {{ item.label }}
    </h3>
    <md-chip title="Score" class="mat-chip mat-primary mat-chip-selected" color="primary" selected="true">
      {{ calculate(item.num) }}
    </md-chip>
  </mat-list-item>
</mat-list>

This code iterates over all the employees in the list and, for each one, renders a list item. It also includes an ngModel directive for two-way data binding between the input and the label property declared in EmployeeListComponent.

With the two instances of EmployeeListComponent, the app forms the following component tree:

AppComponent is the root component of the application. Its child components are the two instances of EmployeeListComponent. Each instance has a list of items (E₁, E₂, etc.) that represent the individual employees in the department.

When the user begins entering the name of a new employee in the input box in anEmployeeListComponent, Angular triggers change detection for the entire component tree starting from AppComponent. This means that while the user is typing in the text input, Angular is repeatedly recalculating the numeric values associated with each employee to verify that they haven't changed since the last check.

To see how slow this can be, open the non-optimized version of the project on StackBlitz and try entering an employee name.

You can verify that the slowdown comes from the fibonacci function by setting up the example project and opening the Performance tab of Chrome DevTools.

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

Now click Record (in the top-left corner of the Performance panel) and start typing in one of the text boxes in the app. In a few seconds, click Record again to stop recording. Once Chrome DevTools processes all the profiling data it collected, you'll see something like this:

If there are many employees in the list, this process may block the browser's UI thread and cause frame drops, which leads to a bad user experience.

Skipping component subtrees #

When the user is typing in the text input for the sales EmployeeListComponent you know that the data in the R&D department isn't changing—so there's no reason to run change detection on its component. To make sure the R&D instance doesn't trigger change detection, set the changeDetectionStrategy of EmployeeListComponent to OnPush:

import { ChangeDetectionStrategy, ... } from '@angular/core';

@Component({
  selector: 'app-employee-list',
  template: `...`,
  changeDetection: ChangeDetectionStrategy.OnPush,
  styleUrls: ['employee-list.component.css']
})
export class EmployeeListComponent {...}

Now when the user types in a text input, change detection is only triggered for the corresponding department:

You can find this optimization applied to the original application here.

You can read more about the OnPush change detection strategy in the official Angular documentation.

To see the effect of this optimization, enter a new employee in the application on StackBlitz.

Using pure pipes #

Even though the change detection strategy for the EmployeeListComponent is now set to OnPush, Angular still recalculates the numeric value for all employees in a department when the user types in the corresponding text input.

To improve this behavior you can take advantage of pure pipes. Both pure and impure pipes accept inputs and return results that can be used in a template. The difference between the two is that a pure pipe will recalculate its result only if it receives a different input from its previous invocation.

Remember that the app calculates a value to display based on the employee's numeric value, invoking the calculate method defined in EmployeeListComponent. If you move the calculation to a pure pipe, Angular will recalculate the pipe expression only when its arguments change. The framework will determine if the arguments of the pipe have changed by performing a reference check. This means that Angular won't perform any recalculations unless the numeric value for an employee is updated.

Here's how to move the business calculation to a pipe called CalculatePipe:

import { Pipe, PipeTransform } from '@angular/core';

const fibonacci = (num: number): number => {
  if (num === 1 || num === 2) {
    return 1;
  }
  return fibonacci(num - 1) + fibonacci(num - 2);
};

@Pipe({
  name: 'calculate'
})
export class CalculatePipe implements PipeTransform {
  transform(val: number) {
    return fibonacci(val);
  }
}

The transform method of the pipe invokes the fibonacci function. Notice that the pipe is pure. Angular will consider all pipes pure unless you specify otherwise.

Finally, update the expression inside of the template for EmployeeListComponent:

<mat-chip-list>
  <md-chip>
    {{ item.num | calculate }}
  </md-chip>
</mat-chip-list>

That's it! Now when the user types in the text input associated with any department, the app won't recalculate the numeric value for individual employees.

In the app below you can see how much smoother the typing is!

To see the effect of the last optimization try this example on StackBlitz.

The code with the pure pipe optimization of the original application is available here.

Conclusion #

When facing runtime slowdowns in an Angular app:

Profile the application with Chrome DevTools to see where the slowdowns are coming from.
Introduce the OnPush change detection strategy to prune a component's subtrees.
Move heavy computations to pure pipes to allow the framework to perform caching of the computed values.

Route preloading strategies in Angular

2019-07-09T00:00:00Z

Route-level code splitting can help you reduce the initial load time of an application by delaying the JavaScript associated with routes that aren't initially needed. This way, the Angular router waits until a user navigates to a given route before triggering a network request to download the associated JavaScript.

While this technique is great for initial page load, it can slow down navigation, depending on the users' network latency and bandwidth. One way to tackle this problem is route preloading. Using preloading, when the user is at a given route, you can download and cache JavaScript associated with routes that are likely to be needed next. The Angular router provides this functionality out of the box.

In this post, you'll learn how to speed up navigation when using route-level code splitting by taking advantage of JavaScript preloading in Angular.

Route preloading strategies in Angular #

The Angular router provides a configuration property called preloadingStrategy, which defines the logic for preloading and processing lazy-loaded Angular modules. We'll cover two possible strategies:

PreloadAllModules, which preloads all lazy-loaded routes, as the name implies
QuicklinkStrategy, which preloads only the routes associated with links on the current page.

The rest of this post refers to a sample Angular app. You can find the source code on GitHub.

Using the `PreloadAllModules` strategy #

The sample app has several lazy-loaded routes. To preload all of them using the PreloadAllModules strategy—which is built into Angular—specify it as the value for the preloadingStrategy property in the router configuration:

import { RouterModule, PreloadAllModules } from '@angular/router';
// …

RouterModule.forRoot([
  …
], {
  preloadingStrategy: PreloadAllModules
})
// …

Now serve the application and look at the Network panel in Chrome DevTools:

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

You should see that the router downloaded nyan-nyan-module.js and about-about-module.js in the background when you opened the application:

The PreloadAllModules strategy in action.

The router also registered the modules' route declarations so that when you navigate to a URL associated with any of the preloaded modules, the transition is instantaneous.

Using the Quicklink preloading strategy #

PreloadAllModules is useful in a lot of cases. When you have dozens of modules, however, its aggressive preloading can really increase network usage. Also, since the router needs to register the routes in all the preloaded modules, it can cause intensive computations in the UI thread and lead to sluggish user experience.

The quicklink library provides a better strategy for larger apps. It uses the IntersectionObserver API to preload only modules associated with links that are currently visible on the page.

You can add quicklink to an Angular app by using the ngx-quicklink package. Start by installing the package from npm:

npm install --save ngx-quicklink

Once it's available in your project, you can use QuicklinkStrategy by specifying the router's preloadingStrategy and importing the QuicklinkModule:

import {QuicklinkStrategy, QuicklinkModule} from 'ngx-quicklink';
…

@NgModule({
  …
  imports: [
    …
    QuicklinkModule,
    RouterModule.forRoot([…], {
      preloadingStrategy: QuicklinkStrategy
    })
  ],
  …
})
export class AppModule {}

Now when you open the application again, you'll notice that the router only preloads nyan-nyan-module.js since the button in the center of the page has a router link to it. And when you open the side navigation, you'll notice that the router then preloads the "About" route:

A demo of the quicklink preloading strategy.

Using the Quicklink preloading strategy across multiple lazy-loaded modules #

The above example will work for a basic application but if your application contains multiple lazy-loaded modules you will need to import the QuicklinkModule into a shared module, export it and then import the shared module into your lazy-loaded modules.

First import the QuicklinkModule from ngx-quicklink into your shared module and export it:

import { QuicklinkModule } from 'ngx-quicklink';
…

@NgModule({
  …
  imports: [
    QuicklinkModule
  ],
  exports: [
    QuicklinkModule
  ],
  …
})
export class SharedModule {}

Then import your SharedModule into all of your lazy-loaded modules:

import { SharedModule } from '@app/shared/shared.module';
…

@NgModule({
  …
  imports: [
      SharedModule
  ],
  …
});

Quicklinks will now be available in your lazy-loaded modules.

Going beyond basic preloading #

While selective preloading via quicklink can significantly speed up navigation, you can make your preloading strategy even more network efficient by using predictive preloading—which is implemented by Guess.js. By analyzing a report from Google Analytics or another analytics provider, Guess.js can predict a user's navigation journey and preload only the JavaScript chunks that are likely to be needed next.

You can learn how to use Guess.js with Angular on this page from the Guess.js site.

Conclusion #

To speed up navigation when using route-level code splitting:

Pick the right preloading strategy depending on the size of your application:
- Applications with few modules can use Angular's built-in PreloadAllModules strategy.
- Applications with many modules should use a custom preloading strategy, like Angular's quicklink, or predictive preloading, as implemented in Guess.js.
Configure the preloading strategy by setting the preloadStrategy property of the Angular router.

Faster web navigation with predictive prefetching

2019-07-08T00:00:00Z

In my Faster Web Navigation with Predictive Prefetching session at Google I/O 2019, I began by talking about optimizing web apps with code splitting and the potential performance implications for subsequent page navigation. In the second part of the talk, I discussed how to improve navigation speed by using Guess.js to set up predictive prefetching:

Code splitting for faster web apps #

Web apps are slow, and JavaScript is among the most expensive resources that you ship. Waiting for a slow web app to load can frustrate your users and decrease conversions.

Lazy loading is an efficient technique to reduce the bytes of JavaScript that you're transferring over the wire. You can use several techniques to lazy-load JavaScript, including:

Component-level code splitting
Route-level code splitting

With component-level code splitting, you can move individual components into separate JavaScript chunks. On particular events, you can load the relevant scripts and render the components.

With route-level code splitting, however, you move entire routes into independent chunks. When users transition from one route to another, they have to download the associated JavaScript and bootstrap the requested page. These operations can lead to significant delays, especially on slow networks.

Prefetching JavaScript #

Prefetching allows the browser to download and cache resources that the user is likely to need soon. The usual method is to use <link rel="prefetch">, but there are two common pitfalls:

Prefetching too many resources (overfetching) consumes a lot of data.
Some resources the user needs may never be prefetched.

Predictive prefetching solves these problems by using a report of users' navigational patterns to determine what assets to prefetch.

Predictive prefetching with Guess.js #

Guess.js is a JavaScript library that provides predictive prefetching functionality. Guess.js consumes a report from Google Analytics or another analytics provider to build a predictive model that can be used to smartly prefetch only what the user is likely to need.

Guess.js has integrations with Angular, Next.js, Nuxt.js, and Gatsby. To use it in your application, add these lines to your webpack configuration to specify a Google Analytics view ID:

const { GuessPlugin } = require('guess-webpack');

// ...
plugins: [
   // ...
   new GuessPlugin({ GA: 'XXXXXX' })
]
// ...

If you're not using Google Analytics, you can specify a reportProvider and download data from your favorite service.

Integration with frameworks #

To learn more about how to integrate Guess.js with your favorite framework check out these resources:

For a quick walkthrough on the integration with Angular, check out this video:

How does Guess.js work? #

Here's how Guess.js implements predictive prefetching:

It first extracts data for the user navigational patterns from your favorite analytics provider.
It then maps the URLs from the report to the JavaScript chunks produced by webpack.
Based on the extracted data, it creates a simple predictive model of which pages a user is likely to navigate to from any given page.
It invokes the model for each JavaScript chunk, predicting the other chunks that are likely to be needed next.
It adds prefetching instructions to each chunk.

When Guess.js is done, each chunk will contain prefetching instructions similar to:

__GUESS__.p(
  ['a.js', 0.2],
  ['b.js', 0.8]
)

This Guess.js-generated code is telling the browser to consider prefetching chunk a.js with probability 0.2 and chunk b.js with probability 0.8.

Once the browser executes the code, Guess.js will check the user's connection speed. If it's sufficient, Guess.js will insert two <link rel="prefetch"> tags in the header of the page, one for each chunk. If the user is on a high-speed network, Guess.js will prefetch both chunks. If the user has a poor network connection, Guess.js will only prefetch chunk b.js since it has a high probability of being needed.

Learn more #

To learn more about Guess.js, check out these resources:

Audit your Angular app's accessibility with codelyzer

2019-07-03T00:00:00Z

Making your app accessible means that all users, including those with special needs, can use it and understand the content. According to the World Health Report, more than a billion people—about 15% of the world's population—have some form of disability. So accessibility is a priority for any development project.

In this post you'll learn how to add codelyzer's accessibility checks to the build process for an Angular app. This approach lets you catch accessibility bugs directly in your text editor as you code.

Using codelyzer to detect inaccessible elements #

codelyzer is a tool that sits on top of TSLint and checks whether Angular TypeScript projects follow a set of linting rules. Projects set up with the Angular command line interface (CLI) include codelyzer by default.

codelyzer has over 50 rules for checking if an Angular application follows best practices. Of those, there are about 10 rules for enforcing accessibility criteria. To learn about the various accessibility checks provided by codelyzer and their rationales, see the New Accessibility rules in Codelyzer article.

Currently, all the accessibility rules are experimental and disabled by default. You can enable them by adding them to the TSLint configuration file (tslint.json):

{
  "rulesDirectory": [
    "codelyzer"
  ],
  "rules": {
    ...,
    "template-accessibility-alt-text": true,
    "template-accessibility-elements-content": true,
    "template-accessibility-label-for": true,
    "template-accessibility-tabindex-no-positive": true,
    "template-accessibility-table-scope": true,
    "template-accessibility-valid-aria": true,
    "template-click-events-have-key-events": true,
    "template-mouse-events-have-key-events": true,
    "template-no-autofocus": true,
    "template-no-distracting-elements": true
  }
}

TSLint works with all popular text editors and IDEs. To use it with VSCode, install the TSLint plugin. In WebStorm, TSLint is enabled by default. For other editors, check the TSLint README.

With codelyzer's accessibility checks set up, you get a popup showing accessibility errors in TypeScript files or inline templates as you code:

A codelyzer popup showing a form element labeling error.

To perform linting over the entire project (including external templates), use the ng lint command:

Supplementing codelyzer #

Lighthouse is another tool you can use to enforce accessibility practices in your Angular application. The main difference between codelyzer and Lighthouse is when their checks get performed. Codelyzer statically analyzes the application at development time, without running it. This means that during development you can get direct feedback in your text editor or in the terminal. By contrast, Lighthouse actually runs your application and performs a bunch of checks using dynamic analysis.

Both tools can be useful parts of your development flow. Lighthouse has better coverage given the checks it performs, while codelyzer allows you to iterate faster by getting constant feedback in your text editor.

Enforcing accessibility checks in your continuous integration #

Introducing static accessibility checks in your continuous integration (CI) can be a great enhancement for your development flow. With codelyzer you can easily enforce certain accessibility rules or other practices by running ng lint on each code modification (for example for each new pull request).

This way, even before you proceed to code review, your CI can tell you if there are any accessibility violations.

Conclusion #

To improve the accessibility of your Angular app:

Enable the experimental accessibility rules in codelyzer.
Perform accessibility linting over your entire project using the Angular CLI.
Fix all the accessibility problems reported by codelyzer.
Consider using Lighthouse for accessibility audits at runtime.

Performance budgets with the Angular CLI

2019-07-02T00:00:00Z

Optimizing an Angular application is important, but how do you make sure its performance doesn't regress over time? By introducing performance metrics and monitoring them on each code change!

One important metric is the size of the JavaScript shipped with your application. By introducing a performance budget that you monitor on each build or pull request, you can make sure your optimizations persist over time.

Calculate your performance budget #

You can use this online budget calculator to estimate how much JavaScript your app can afford to load, depending on the Time to Interactive you're aiming for.

Configure a performance budget in the Angular CLI #

Once you have a target JavaScript budget, you can enforce it using the Angular command line interface (CLI). To see how that works, check out this sample app on GitHub.

You'll see that the following budget has been configured in angular.json:

"budgets": [{
  "type": "bundle",
  "name": "main",
  "maximumWarning": "170kb",
  "maximumError": "250kb"
}]

Here's a summary of what's being specified:

There's a budget for a JavaScript bundle called main.
If the main bundle gets bigger than 170 KB, the Angular CLI will show a warning in the console when you build the app.
If the main bundle gets bigger than 250 KB, the build will fail.

Now try building the app by running ng build --prod.

You should see this error in the console:

To fix the build error, take a look at app.component.ts, which includes an import from rxjs/internal/operators. This is a private import that's not supposed to be used by consumers of rxjs. It increases the bundle size a lot! When you update to the correct import, rxjs/operators, and run the build again, you'll see that it passes the budget check successfully.

Note that, since differential loading is enabled by default in the Angular CLI, the ng build command produces two builds of the app:

A build for browsers with ECMAScript 2015 support. This build includes fewer polyfills and more modern JavaScript syntax. That syntax is more expressive, which leads to smaller bundles.
A build for older browsers without ECMAScript 2015 support. The older syntax is less expressive and requires more polyfills, which leads to larger bundles.

The index.html file of the sample app refers to both builds so that modern browsers can take advantage of the smaller ECMAScript 2015 build and older browsers can fall back to the ECMAScript 5 build.

Enforce your budget as part of continuous integration #

Continuous integration (CI) offers a convenient way to monitor the budget of your app over time. And, luckily, the quickest way to set that up is to build your app with the Angular CLI—no extra steps required! Whenever the JavaScript bundle exceeds the budget, the process will exit with code 1, and the build will fail.

If you prefer, you can also enforce a performance budget using bundlesize and Lighthouse. The main difference between performance budgets in the Angular CLI and Lighthouse is when the checks get performed. The Angular CLI performs the checks at build time, looking at the production assets and verifying their sizes. Lighthouse, however, opens the deployed version of the application and measures the asset size. Both approaches have their pros and cons. The check that Angular CLI performs is less robust but much faster since it's a single disk lookup. On the other hand, the LightWallet of Lighthouse can perform a very accurate check by considering dynamically loaded resources, but it needs to deploy and open the app each time it runs.

bundlesize is quite similar to the Angular CLI's budget check; the main difference is that bundlesize can show the check results directly in GitHub's user interface.

Conclusion #

Establish performance budgets with the Angular CLI to make sure your Angular app's performance doesn't regress over time:

Set a baseline for the resource size either by using a budget calculator or by following your organization's practices.
Configure size budgets in angular.json under projects.[PROJECT-NAME].architect.build.configurations.production.budgets
The budgets will be automatically enforced on each build with the Angular CLI.
Consider introducing budget monitoring as part of continuous integration (which can also be achieved with the Angular CLI).

Precaching with the Angular service worker

2019-07-02T00:00:00Z

Dealing with limited connectivity #

When users have limited network access—or none at all—web app functionality can significantly degrade and often fails. Using a service worker to provide precaching lets you intercept network requests and deliver responses directly from a local cache instead of retrieving them from the network. Once your app's assets have been cached, this approach can really speed up an app and make it work when the user is offline.

This post walks through how to set up precaching in an Angular app. It assumes you're already familiar with precaching and service workers in general. If you need a refresher, check out the Service workers and the Cache Storage API post.

Introducing the Angular service worker #

The Angular team offers a service worker module with precaching functionality that's well integrated with the framework and the Angular command line interface (CLI).

To add the service worker, run this command in the CLI:

ng add @angular/pwa

@angular/service-worker and @angular/pwa should now be installed in the app and should appear in package.json. The ng-add schematic also adds a file called ngsw-config.json to the project, which you can use to configure the service worker. (The file includes a default configuration that you'll customize a little later.)

Now build the project for production:

ng build --prod

Inside the dist/service-worker-web-dev directory you'll find a file called ngsw.json. This file tells the Angular service worker how to cache the assets in the app. The file is generated during the build process based on the configuration (ngsw-config.json) and the assets produced at build time.

Now start an HTTP server in the directory containing your app's production assets, open the public URL, and check out its network requests in Chrome DevTools:

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

Note that the network tab has a bunch of static assets directly downloaded in the background by the ngsw-worker.js script:

This is the Angular service worker precaching the static assets specified in the generated ngsw.json manifest file.

One important asset is missing though: nyan.png. To precache this image you need to add a pattern that includes it to ngsw-config.json, which lives in the root of the workspace:

{
  "$schema": "./node_modules/@angular/service-worker/config/schema.json",
  "index": "/index.html",
  "assetGroups": [
    {
      "name": "app",
      "installMode": "prefetch",
      "resources": {
      "files": [
        "/favicon.ico",
        "/index.html",
        "/*.css",
        "/*.js",
        "/assets/*.png"
        ]
      }
    },
    ...
}

This change adds all PNG images in the /assets folder to the app resource asset group. Since the installMode for this asset group is set to prefetch, the service worker will precache all the specified assets—which now include PNG images.

Specifying other assets to be precached is just as straightforward: update the patterns in the app resource asset group.

Conclusion #

Using a service worker for precaching can improve the performance of your apps by saving assets to a local cache, which makes them more reliable on poor networks. To use precaching with Angular and the Angular CLI:

Add the @angular/pwa package to your project.
Control what the service worker caches by editing ngsw-config.json.

Get started: optimize an Angular application

2019-06-24T00:00:00Z

What's Angular? #

Angular is a framework for building user interfaces. It provides building blocks to help you quickly set up a maintainable, scalable application. Angular empowers developers to create applications that live on the web, mobile, or the desktop.

What's in this collection? #

This collection focuses on five major areas for optimizing an Angular application:

Improving the performance of your application to increase user conversion and engagement
Improving your application's reliability on poor networks by precaching assets with the Angular service worker
Making your application discoverable for search engines and social media bots using prerendering and server-side rendering
Making your application installable to provide a user experience similar to an iOS/Android app's
Improving the accessibility of your application to make it usable and understandable for all users

Each post in the collection will describe techniques that you can directly apply to your own applications.

What's not in this collection? #

This collection assumes that you're already familiar with Angular and TypeScript. If you're not feeling confident with them yet, check out the TypeScript documentation and the Getting Started with Angular guide on angular.io.

Start a project #

The Angular command line interface (CLI) lets you quickly set up a simple client-side Angular application. This post has a short introduction to the CLI, while other posts in the collection show how to add more advanced features like server-side rendering and deployment support.

Set up the CLI #

To begin, install the CLI globally and verify that you have the latest version by running these commands:

npm i -g @angular/cli
ng --version

Make sure the last command outputs version 8.0.3 or newer.

Alternatively, if you don't want to install the CLI globally, you can install it locally and run it with the npx command:

npm i @angular/cli
npx ng --version

Create the project #

To create a new project run:

ng new my-app

This command will create the initial files and folder structure for your application and install the node modules it needs.

Once the setup process completes successfully, start your application by running:

cd my-app
ng serve

You should now be able to access your application at http://localhost:4200.

What's next? #

In the rest of this collection you'll learn how to improve the performance, accessibility, and SEO of your Angular application. Here's what's covered:

Route-Level code splitting in Angular
Performance Budgets with the Angular CLI
Route Prefetching Strategies in Angular
Change detection optimization in Angular
Virtualize large lists with the Angular CDK
Precaching with the Angular Service Worker
Pre-render routes with Angular CLI
Server-side rendering with Angular Universal
Add a web app manifest with Angular CLI
Accessibility auditing with codelyzer

Route-level code splitting in Angular

2019-06-24T00:00:00Z

This post explains how to set up route-level code splitting in an Angular application, which can reduce JavaScript bundle size and dramatically improve Time to Interactive.

You can find the code samples from this article on GitHub. The eager routing example is available in the eager branch. The route-level code splitting example is in the lazy branch.

Why code splitting matters #

The ever growing complexity of web applications has led to a significant increase in the amount of JavaScript shipped to users. Large JavaScript files can noticeably delay interactivity, so it can be a costly resource, especially on mobile.

The most efficient way to shrink JavaScript bundles without sacrificing features in your applications is to introduce aggressive code splitting.

Code splitting lets you divide the JavaScript of your application into multiple chunks associated with different routes or features. This approach only sends users the JavaScript they need during the initial application load, keeping load times low.

Code splitting techniques #

Code splitting can be done at two levels: the component level and the route level.

In component-level code splitting, you move components to their own JavaScript chunks and load them lazily when they are needed.
In route-level code splitting, you encapsulate the functionality of each route into a separate chunk. When users navigate your application they fetch the chunks associated with the individual routes and get the associated functionality when they need it.

This post focuses on setting up route-level splitting in Angular.

Sample application #

Before digging into how to use route level code splitting in Angular, let's look at a sample app:

Check out the implementation of the app's modules. Inside AppModule two routes are defined: the default route associated with HomeComponent and a nyan route associated with NyanComponent:

@NgModule({
  ...
  imports: [
    BrowserModule,
    RouterModule.forRoot([
      {
        path: '',
        component: HomeComponent,
        pathMatch: 'full'
      },
      {
        path: 'nyan',
        component: NyanComponent
      }
    ])
  ],
  ...
})
export class AppModule {}

Route-level code splitting #

To set up code splitting, the nyan eager route needs to be refactored.

Version 8.1.0 of the Angular CLI can do everything for you with this command:

ng g module nyan --module app --route nyan

This will generate:

A new routing module called NyanModule
A route in AppModule called nyan that will dynamically load the NyanModule
A default route in the NyanModule
A component called NyanComponent that will be rendered when the user hits the default route

Let's go through these steps manually so we get a better understanding of implementing code splitting with Angular!

When the user navigates to the nyan route, the router will render the NyanComponent in the router outlet.

To use route-level code splitting in Angular, set the loadChildren property of the route declaration and combine it with a dynamic import:

{
  path: 'nyan',
  loadChildren: () => import('./nyan/nyan.module').then(m => m.NyanModule)
}

There are a two key differences from the eager route:

You set loadChildren instead of component. When using route-level code splitting you need to point to dynamically loaded modules, instead of components.
In loadChildren, once the promise is resolved you return the NyanModule instead of pointing to the NyanComponent.

The snippet above specifies that when the user navigates to nyan, Angular should dynamically load nyan.module from the nyan directory and render the component associated with the default route declared in the module.

You can associate the default route with a component using this declaration:

import { NgModule } from '@angular/core';
import { NyanComponent } from './nyan.component';
import { RouterModule } from '@angular/router';

@NgModule({
  declarations: [NyanComponent],
  imports: [
    RouterModule.forChild([{
      path: '',
      pathMatch: 'full',
      component: NyanComponent
    }])
  ]
})
export class NyanModule {}

This code renders NyanComponent when the user navigates to https://example.com/nyan.

To check that the Angular router downloads the nyan.module lazily in your local environment:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Click NYAN in the sample app.
Note that the nyan-nyan-module.js file appears in the network tab.

Find this example on GitHub.

Show a spinner #

Right now, when the user clicks the NYAN button, the application doesn't indicate that it's loading JavaScript in the background. To give the user feedback while loading the script you'll probably want to add a spinner.

To do that, start by adding markup for the indicator inside the router-outlet element in app.component.html:

<router-outlet>
  <span class="loader" *ngIf="loading"></span>
</router-outlet>

Then add an AppComponent class to handle routing events. This class will set the loading flag to true when it hears the RouteConfigLoadStart event and set the flag to false when it hears the RouteConfigLoadEnd event.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  loading: boolean;
  constructor(router: Router) {
    this.loading = false;
    router.events.subscribe(
      (event: RouterEvent): void => {
        if (event instanceof NavigationStart) {
          this.loading = true;
        } else if (event instanceof NavigationEnd) {
          this.loading = false;
        }
      }
    );
  }
}

In the example below we've introduced an artificial 500 ms latency so that you can see the spinner in action.

Conclusion #

You can shrink the bundle size of your Angular applications by applying route-level code splitting:

Use the Angular CLI lazy-loaded module generator to automatically scaffold a dynamically loaded route.
Add a loading indicator when the user navigates to a lazy route to show there's an ongoing action.

Minko Gechev on web.dev

How CommonJS is making your bundles larger

What's CommonJS? #

How does CommonJS affect your final bundle size? #

Why does CommonJS make your app larger? #

Tree-shaking with CommonJS #

Conclusion #

Create a Progressive Web App with the Angular CLI

Create an installable PWA #

Customize your PWA #

Conclusion #

Optimize Angular's change detection

Inside Angular's change detection #

Skipping component subtrees #

Using pure pipes #

Conclusion #

Route preloading strategies in Angular

Route preloading strategies in Angular #

Using the PreloadAllModules strategy #

Using the Quicklink preloading strategy #

Using the Quicklink preloading strategy across multiple lazy-loaded modules #

Going beyond basic preloading #

Conclusion #

Faster web navigation with predictive prefetching

Code splitting for faster web apps #

Prefetching JavaScript #

Predictive prefetching with Guess.js #

Integration with frameworks #

How does Guess.js work? #

Learn more #

Audit your Angular app's accessibility with codelyzer

Using codelyzer to detect inaccessible elements #

Supplementing codelyzer #

Enforcing accessibility checks in your continuous integration #

Conclusion #

Performance budgets with the Angular CLI

Calculate your performance budget #

Configure a performance budget in the Angular CLI #

Enforce your budget as part of continuous integration #

Conclusion #

Precaching with the Angular service worker

Dealing with limited connectivity #

Introducing the Angular service worker #

Conclusion #

Get started: optimize an Angular application

What's Angular? #

What's in this collection? #

What's not in this collection? #

Start a project #

Set up the CLI #

Create the project #

What's next? #

Route-level code splitting in Angular

Why code splitting matters #

Code splitting techniques #

Sample application #

Route-level code splitting #

Show a spinner #

Conclusion #

Using the `PreloadAllModules` strategy #