Speedy angular.

Optimizing Angular

Optimizing primarily for snappy user experience. We’ll take a look at what types of lazy loading we can do and how to measure our results while optimizing Angular.

Update 7 June ’19: After a question from PairedPrototype and a bit of research it turns out that a part of the article is incorrect. More precisely the part that talks about Shared Module bucket near the end of the article. See the question and response for details. In short, the Angular production build tree shakes away unused components.

We are going to be optimizing primarily for snappy user experience. That means smaller bundles and not downloading code that is not required. We want to ship the bytes that user needs and nothing more. That way our users will see a snappy and quick to react site which is what they’ve come to expect.

Disclaimer: No server-side rendering will be discussed here. We’ll try to optimize the javascript that gets delivered and evaluated in the browser.

We’ll take a look at what types of lazy loading we can do and how to measure our results while optimizing Angular.

Here is the plan: We’ll measure first. We’ll create hypotheses. Then we’ll apply some optimization, measure and see if the hypothesis is correct or not.

I’ve created a small example app to exercise the optimizations. Find it at https://github.com/gparlakov/optimizing-angular

Measurement:

We’ll use these tools:

Webpack bundle analyzer. It’s a tool that takes the output from a ng build --stats-json command, namely dist/stats.json and presents it in a very nice graphical interface. We can see how many bundles we produce, what goes where and the size of them (Stat — raw, Parsed — processed [ like after minification] and Gzipped). Here’s an example: