How to load single-page app faster

October 3, 2017

Yet another research about ways to slightly reduce size and loading time of the frontend applications.

We work on apps with a lot of JavaScript code, styles. We have the endless process of adding new features, pages, elements everyday. Gradually we have a problem when size and loading time of the our bundled code increases.

It seems like present frontend development has some challenges for us. Many users work with our apps using low-end smartphones. Much code with business logic is located on client instead of backend.

Herewith many of us don’t think about the optimal use/ship of resouces. Our apps have an enormous trees of external dependencies whose authors also don’t think about size of their packages.

What can we do?

Use of the following modern techniques will help us to ship smaller bundles to browsers.

Tree shaking

This feature is used for dead code elimination. Tree shacking was implimented in many actual bundle tools like webpack or rollup for ES2015 modules.

If we have an entry point and imported module with some unused exports, we can reduce bundle size out of the box.

We see that the second export is declared but not used. So its will not be in final bundle.

This technique works only for ES2015 modules. We want eliminate dead code also for packages whose use commonjs exports. First we can try to automate it with plugins such a webpack-common-shake or rollup-plugin-commonjs.

In the second place when using big external libraries, lodash for example, we can initially avoid inclusion to bundle. If we import something as follows, whole lodash code will be included:

import {omit} from 'lodash'

It happens because libraries were preliminarily transpiled to ES5 syntax with require imports. To reduce the import of such libraries, you should request only things you need:

import omit from 'lodash/omit'

Code splitting

This feature is used for split our code into many chunks instead of one bundle. It allows manage the priority of loading chunks and load their in parallel or lazily. Code splitting is currently supported by webpack, but isn’t still implemented in rollup.

Caching

After reducing the size of our bundle, we should directly think about loading it with browser. If we have single bundle, user browser will be forced to load it again after each code change. To avoid this, we can use browser technique called caching. Browser caching allows you speed up loading recources by saving files locally.

We laid a good basis to cache our code applying the tree shaking, splitting and extracting. After splitting, we have few small chunks. Each of them can be cached. With tools like webpack, we can easy configure caching.

Building this project will get chunks with chunk-specific hashes in filenames:

dist
|- app.e2a5ac13d7b26742f4d7.js
|- utils.e646121558170aeedd91.js

Now when we modify code in one module, building this project update only one chunk containing this module with new hash. User browser will have to load again only this updated chunk. Other ones will be taken from browser cache.

One more thing we can apply to build is a manual extracting vendor modules and lock their versions. External libraries are updated us less often than own code. So we should minimize the force loading of a chunk containing this libraries.

Wrapping up

That’s all. We’ve learned few useful methods to speed up loading of our resources. If you have a slow loaded app with a big bundle for shipping, try to apply all those techniques to your building process.

Research what you can do to reduce the loading time more. Here are some other approaches to help you optimize this more: