Measuring is extremely important, without numbers we don’t know about potential problems and we don’t have a base we can improve upon. Performance Budgets are a way to impose limits on metrics that may affect our app’s performance. In this lesson we’ll learn how to configure the Angular CLI to configure performance budgets, to monitor them and to alert us when we violate them.
Instructor: [0:00] One of the key goals goals when you want to build performant applications, or in general, when you want to improve something, you have to take measurements. Those measurements help you to understand how well you actually perform or how badly you perform.
[0:12] As well, you can see how you optimize over time. Now, one of those measurements can be the so-called performance budgets. Luckily, the Angular CLI has a way to specify budgets during the build time.
[0:24] For instance, if we go to our app here, which is a simple application which we have, and we go that Angular JSON, then we can go to our main application, which in this case here is our ng-perf. We scroll down, we go to the configuration, and we are actually interested here in that production section.
[0:44] What we want to do here is to specify so-called budgets. Budgets allow us to specify various sizes we don't want to exceed. For instance, let's take a look here. First of all, we specify here the type. Now, this is a JSON file, so we have respect that kind of syntax.
[1:02] What we want to do here is to type bundle. We want to address a specific bundle of our application. The name of that bundle is the main bundle. That's basically the one that contains the main application parts.
[1:14] Then we can specify here different kind of thresholds. For instance, we can say a maximum warning -- let's give it 350 kilobytes, just an example -- and then the maximum error. Here, let's say 500 kilobytes.
[1:28] What this does is whenever we exceed this kind of threshold, it will give us a warning during the compilation, while this here will actually make our build fail. This is extremely important, especially if you have a continuous integration environment.
[1:41] Now, let's give this a try. Let's save this. Let's run ng build --prod for the production build. Once the second build also finishes, you can already see here that we get a warning here. "Warning in budgets, maximum exceeded for main," which we specified before.
[1:59] That budget was specified to be 350 kilobytes and was exceeded by 72 kilobytes. You can already see that warning. You can now already take action. We'll, for now, ignore it. Now, let's artificially increase that size to get also the maximum error, which we specified.
[2:15] To do it, I open up the app component. You can see here at the very top, we have some import from RxJS. Now, these are already optimized. However, if we import an internal package here -- so from internal operators, rather than directly operators, as you should actually do -- we will artificially increase that bundle size of our application.
[2:37] Let's redo that build. Once the build finishes, you can now see that we get the warning, but you also get the error, which actually makes our build fail, because we exceeded our 500 kilobyte budget, which we have specified, by 44 kilobytes. That's actually exactly this main bundle, which we have specified before.
[2:56] Now, what we configured here is actually the main bundle. If you take a look here at this budgets definition, you have various types, what you can specify. For instance, all or script any, any script bundle, or the initial size.
[3:10] Now, if you want to know more, you can go to the main Angular.io documentation and go to that build section, where there's an entire section on how configure size budgets, as we just did. More further down here, there is exact definition of what the bundle means, what initial means, what allScript, etc.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!