Lesson 10

Bundle Size & Lazy Loading

Increase boot time by decreasing the bundle size and lazy loading

PRO

Lesson Outline

Bundle Size & Lazy Loading

In this lesson, we are going to be covering two concepts that are relevant to the boot time of an application: bundle size and lazy loading.

In the lesson on network requests we have talked a little about some of these concepts already, but we are going to go into a little more detail now. The goal here is to get our application booting as quickly as possible, which means optimising those initial network requests that are required to get to our Largest Contentful Paint.

Bundle Size

The bundle size of your application is the size of your application after it has been built and minified. When you perform a build of your application you will see that various files are generated which will consist of the following:

  • common.js - contains code that is used by multiple different modules (e.g. shared services/providers)
  • runtime.js - webpack utilities
  • main.js - the main application code
  • polyfills.js - enables Angular to run properly in supported browsers
  • styles.css - contains the application styles

As well as these core files, you will also have a bunch of individual "chunks" that webpack generates that enable lazy loading:

  • 1.js
  • 2.js
  • 3.js
  • and so on...

Rather than having our entire application loaded up front in a single file, it is split up into "chunks" that can be loaded on demand. Each of these file names will also have a bunch of random numbers/letters attached to it for the sake of cache-busting in a production build (i.e. when a new version of our application is deployed we don't want to accidentally serve an old cached version).

The resulting size of these files have a lot to do with the code we write and the resources we include in our application. The smaller we can get this bundle size, the faster our application can load.

Aside from the obvious step of removing any files, components, providers, plugins, or libraries from our application that we don't need, we can also investigate a little further with the help of a particularly useful tool.

There are a lot of different files that go into building our final bundle, so it can be quite difficult to try and figure out what is taking up space. To help us with this, we can use a tool called Source Map Explorer.

This tool will give us a visual representation of what is taking up space in our bundle, and it is super easy to use. It can be installed globally (meaning it is installed on your computer in general, not your application specifically) with the following command:

npm install -g source-map-explorer

You can use this tool on your minified source files and source map files to create a visualisation of where space is being used in that file.

Make sure to create a build first that includes source maps by running:

ionic build --prod --source-map

and then all you need to do is run the following command (assuming you are in the root directory of your project):

source-map-explorer www/*.js
PRO

Thanks for checking out the preview of this lesson!

You do not have the appropriate membership to view the full lesson. If you would like full access to this module you can view membership options (or log in if you are already have an appropriate membership).