Beginning with version 1.3.0-rc.0, the Angular CLI makes use of the Angular Build Optimizer. This is a nifty tool that transforms the emitted JavaScript code to make tree shaking more efficient. This can result in huge improvements regarding bundle size. In this post Im describing some simple scenarios that show the potential of this newly introduced tool. If you want to reproduce these scenarios, you find the source code used in my GitHub repository.
Scenario 1
To demonstrate the power of the Angular Build Optimizer, Im using a simple Angular Application Ive created with the Angular CLI. After scaffolding, Ive added the MdButtonModule and the MdCheckboxModule from Angular Material as well as Angulars NoopAnimationsModule and FormsModule:
import { BrowserModule } from @angular/platform-browser;
import { NgModule } from @angular/core;
import { AppComponent } from ./app.component;
import { MdButtonModule, MdCheckboxModule } from @angular/material;
import { NoopAnimationsModule } from @angular/platform-browser/animations;
import { FormsModule } from "@angular/forms";
@NgModule({
declarations: [
AppComponent
],
imports: [
BrowserModule,
FormsModule,
NoopAnimationsModule,
MdButtonModule,
MdCheckboxModule
],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }
Please note that Im using none of the added modules. Ive just added them to find out how good the CLI/ webpack is in combination with the Angular Build Optimizer when it comes to shake them off.
After this, Ive created a production build without using the Build Optimizer and another one using it. For the latter one, Ive leveraged the new -bo command line option:
ng build --prod -bo
The results of this are amazing:
As this figure shows, using the Angular Build Optimizer the bundle size after tree shaking is about the half. This fits to my observations Ive written down here some months ago: There are situations that prevent tree shaking implementations from doing their job as well as they can. The Build Optimizer seems to compensate this.
Scenario 2
After this, Ive added one component from each of the two included Angular Material modules to find out whether this is influencing tree shaking:
<!-- app.component.html -->
<button md-raised-button (click)="doIt()">Raised button</button>
<md-checkbox class="example-margin" [(ngModel)]="checked">Checked</md-checkbox>
This led to the following results:
Of course, both bundles are bigger, because now Im using more parts of the bundles included. But, as before, using the Angular Build Optimizer our Bundles are about half as big.
Scenario 3
Perhaps you are wondering whats the overhead introduced by the two Angular Material modules in the scenarios above. To find this out, Ive removed referenced to their Angular Modules and created two more build -- one with and one without the Angular Bundle Optimizer:
Compared to Scenario 1 this shows that when using the Build Optimizer, it is possible to shake off most parts of the Material Design Modules when they are imported but not used.
Conclusion
The Angular Build Optimizer removed the issues that prevented tree shaking tools to do their job. This can result in a drastic reduction of bundle sizes.