Secrets for Making Ultra-Responsive Angular Apps

Let us cover tips and tricks relating to best practices involved in making smaller bundles and responsive UIs. In other words, how do we build an application and distribute it to the users and it runs very efficiently for our users, that is, we want to ship something small and fast for our users?


So if you are using Angular CLI, you will see for all the code you have written that has been boiled down to small bits ready to be shipped down to the user. So basically that is our intention over here. If you access the flame chart through Chrome you will be able to access the timeline that shows which portions of running an application contribute most to the initiation time (shown below).


As you will be able to see, any application made through Angular, the most time is consumed by the parsing of Javascript. So making smaller bundles allows you to build faster applications for the users. The article follows through uncompressed bundle sizes so don’t worry if a size seems too large for its purpose.

Lets dive into the details for the optimizations:

Tip # 1: Measure Your Bundle


Source Map Explorer is the easiest and effective for this purpose. In order to install it, you can simply use the npm command along with –sm­.


This allows you to look at the original code and then maps to the bundles they are being shipped as. It uses the same technology that we use for throwing errors using Source Maps. Considering the Hello World example, you can measure the bundle and see which part of the application contributes most to the size of the bundle.


So here’s a small experiment. Currently, the size of the module rests at ~300KB. So I add a couple of lines to the code by importing RxJS, MaterialModule and AngularFireModule and it shoots up the size of the bundle to 1.15MB. That is too big. So using the Source Explorer you can examine your modules and see what is adding most to the size of the application.

Tip # 2: Ahead of Time Compile (AOT)


Ahead of Time Compile or AOT is something the CLI does automatically for you, although a lot of applications are being shipped down to users that do not do ahead of time compilation.


So consider an application of about 100KB and here you can see that the compiler itself takes up most of the space in it. So you don’t really want to ship the whole compiler like that. What is done alternatively is that NG Factory files are shipped instead that contains the scripts in the form of templates so the browser is able to run them more efficiently by making them compile Ahead of Time or AOT.

Tip # 3: Stay Up to Date


That is a tip that is preached over and over again and we will emphasize more on it here that it is very important to keep your applications updated. So on the launch of Angular 4, many users stormed twitter with their appreciation tweets on how the newer version made the bundle size faster and also smaller by about 25-49%. And that is a big deal and it can be taken advantage of by keeping your software up to date.


Here is a short story about a fellow, Igor. He was frustrated about bundle sizes and then came up with a creative solution. He extracted the generated bundles from the CLI and by hand went through it and crossed off pieces that seem too big and not necessary for the bundle itself. He pulled them out manually and then wrote a web pack bundle that allowed to automatically pull out these bigger chunks from your bundles. This web pack is not out yet but stay tuned and up to date and you will be able to make great use of it in the optimization of your bundle.

Tip # 4: Import Carefully


So import carefully basically points towards the fact that if you import incorrectly, you will turn a fairly reasonable package into an unreasonable and larger package of your bundle. So here is an example all the community working on Angular can relate to.


Importing RxJS is fundamental yet the whole bundle is not used entirely and just adds up about 11KB to the application which is a lot especially if you are barely making use of RxJS operators. So to make this more optimum as per your application requirements, what you can do is switch from import RxJS to only importing observables and then selectively add-on operators to that.


Similarly, previously you could import the components of the module but what it did was import the whole component which was not completely used by the application and just added size to the application itself. This makes tree-shaking even harder. So instead if you can point towards the desired components yourself, then it makes it a lot easier to do tree shaking.


For instance, materials library has about ~300KB worth of components and as much as all of these components are worth the size, if you are not using all of them, it is better to only include the ones you use.

So a key point to remember to make this happen is that if a library is too large, see if it offers smaller imports so you can simply just import the components that you really need. So you can either figure out smaller imports are available and then use them and in case they are not, you can simply request to have that smaller portion be made importable to minimize the size of your application.

So tree shaking is considered to be very useful if you are using advanced options of optimizations and therefore, not so handy if you are dealing simpler everyday tasks. Yet, as the technology is evolving and learning to adapt to more realistic problems of the world, tree shaking will most definitely be useful in the long-term. So as mentioned in the example before, if you can manually pull out the parts of the bundles that are not being used, then you can ideally create an application that can run faster and smoother.

Tip #5: Lazy Loading


A lot of people don’t realize how easy it is to lazy-load and don’t appreciate or accept until they are shown how it is done. A cool idea would be to take the sample or generated code from CLI and switch to lazy loading so that everyone is lazy loading out of the box. It is recommended. So how does it really work? Well, in lazy loading instead of having to load your module and all its dependencies synchronously by referring to them in your routes, you can simply refer to it by a string, by the name of the module you want to load and then name of the component followed by a pound sign (#). People on showing find it a lot easier to do. So now coming down to what you really want to lazy load, here is a list of things you can:

  • Lazy load your home screen:

This is useful mainly because in the home screen, especially on a website, that is the first interaction with the user and therefore, if your home screen loads slowly, your user loses their interest there and then. So in order to boost it up, you can figure out what modules are actually needed to be loaded and only choose to lazy load those and leave out all the complex code allowing the browser to load the website page faster because it doesn’t normally require a lot of functionality.

  • Lazy load your admin section:

Since the admin panel usually consists of forms and other forms of interactivity, it is best to lazy load the admin section.

  • Lazy load the content section:

Not all users want to pay the time cost up front by viewing all the contents at once. Some have a more specific requirement from the website, so lazy loading the content views will save a lot of time


In short, lazy loading everything is a good catch. Since it saves all the efforts to pull in extra dependencies and all that may not be required by the application or the user up front. Like for instance, consider a website of a conference where there are tickets and sponsors and such stuff present. So the simplified code will look something like calling an empty string and that matches it off to the main module and then match any string to the main module and then lastly the admin string that goes off in the admin module. So this makes the application faster and only loads the portion for the users that they really need.

Tip # 6: Poly-fill Responsibly:


So poly-fill can be really hard when you are reaching out to a number of users. The best way to make this effective is to go through your user database and their demographics then decide your application or web page should be supported by which browsers. Then go through our angular generated poly-fill file since this file has made it a lot easily configurable.


The file currently is 90% comments which serve as an integrated guide to help you choose which browsers to support and allow you to make the website compatible with the older versions. So if you are doing AOT then you do not require es6 or es7 reflect as it is present in the file, so you can simply comment them out at the time of using this file.


Since they will not work with any git components or applications or web pages that do not follow the guidelines of angular presented earlier in the talk. So simply it cuts down the size that is not really required, making it smaller and faster for the user.

So these are some of things we have learnt which make our applications faster and more responsive. Do you have any other suggestions? Please do share in the comments!