How production-friendly and ready is your Angular app?
There’s probably a lot of dead code in your Angular app — you know, the unnecessary bits and pieces that ends up adding kilobytes to the final deployment. Dead code is parts of the program that gets executed but is never actually used.
Dead code wastes time, space and memory — and Angular by nature is very fat and heavy. We’re talking MB sized kind of heavy. Unlike React and Vue, Angular has a whole host of libraries that it uses, which ends up contributing to the overall beefed up result that we see in a development environment.
Take the screenshot below as an example.
3.9MB just for the bare bones. What happens when you start adding in images, components, additional external libraries, CSS and API calls? That number is sure to go up, if not significantly. 3.9MB is pretty huge when Medium’s homepage, for example and in comparison, transfers about 3.6MB — images are inclusive.
Unlike Angular 1, which was more library like and lightweight in comparison, Angular 2 admits that deploying straight from a development environment to a production space without pruning is not the best idea. It’s possible but just don’t do it.
Although deploying directly from the development environment works, it’s far from optimal. — Angular 2
So how, exactly, does one optimize from a local development environment to a manageable and bandwidth friendly size deployment?
Build your applications with
The easiest way to significantly reduce the size of your Angular application is to use the
--prod meta flag when you use
ng build in the CLI. In theory, you could just copy and paste all the files as-is into your web server and it will still work, but you’ll run into the issue of overall size, which we are trying to reduce.
In Angular, you can use
--prod so it looks something like this:
ng build --prod
The major difference between them is that dev has a source map while prod doesn’t. Source maps are useful for mapping the compressed code back into its original source code — something which in a production environment doesn’t require.
--prod flag shrank the entire starter app to 330KB for a combined total of 7 files with 262KB of that being main.js— a massive difference from 3.9MB that was running on the dev environment.
It achieves this size by bundling your app, inlining your code and produce an uglified and minified version of everything that’s needed. This code doesn’t care about human readability, formatting or anything that is remotely human readable. The process only cares about how much ‘dead code’ it can shave off while maintaining the app’s functionality.
ng build --prod is what most people do when it comes to down sizing their apps. However, there is also another size control feature that’s not commonly talked about in beginner’s circle of Angular and it’s called budgets. This allows you to set thresholds that will alert you if your app grows physically too big.
Angular Budgets — what, why and how
Over time, your application’s growth will increase over time. This often mean more features and therefore more code. As a result, your single page application balloons in size that becomes unpractical to your needs. Angular’s budgets mechanism will give you warnings or errors once your application reaches a certain size during the build process.
The overall size of your application matters because your users are paying for a large application with time (and potentially, limited mobile data). Budgets helps you become aware of your sizes and when it reaches the maximum limit, it just won’t build and tell you off for bloating up your application.
If you’ve managed to reach the threshold that you’ve set, then it’s time to go back and trim out any unused library or pollyfill supports you’ve got.
So how do you set budgets for your production output in Angular, and what does it look like?
- Go to your
angular.jsonfile and scroll down the
- There is already a default of maximum warning set at 2MB and for the build process to error out and refuse to produce a build at 5MB.
3. Think about what is reasonable for the context of your application. Production build does all the code shaving for you to give a final and true size of your application. It’s already made it ugly and employed methods that allows the final produced code to be as small as possible.
4. Your final result is too big and can’t figure out why? If you use the
--stats-json flag with your build command, it will generate a
stats.json file which you can use with Webpack’s bundle analyzer.
To install, use
npm i -D webpack-bundle-analyzer and then inside your packages.json file, add
“stats”: “webpack-bundle-analyzer dist/[change your path name to match]/stats.json” under
npm stats and it will boot up a localhost that will allow you to zoom in and out to see visually where all the KBs are being used. This is helpful because it can let you identify bloats in your application and potential space hungry libraries, components or application parts that can be replaced or excluded.
A trim application matters. Deploying a size optimized application can make or break that extra second that a user feels whilst waiting for your Angular app to load. Not everyone will have access to super fast Internet and research shows that, on average, a user will leave if it doesn’t communicate your value proposition within 10 seconds.
If 5 seconds of that time spent loading a page, then you have 5 seconds less with your potential returning user. Also note that 10 seconds is also an average, meaning that there are also people who sit on the lesser side of that number. 10 seconds doesn’t seem like very long but if you were to observe your own behavior, how long will you be willing to stay for a website you’ve never visited before?
Speed matters and one way to achieve it is by reducing your production’s file sizes.