Angular

Performances &

Best Practices

. Sommaire

1) Build

2) Load

3) Run

 

 

 

 

 

 

1) Build

. JIT vs AOT:

  . Compilation au lancement de l'application VS en amont

  . Taille du livrable différente

  . Performances au lancement de l'application

 

 

 

1) Build

. Avec Angular 5 :

  . ng build --prod = ?

 

 

 

ng build --env=prod ... --aot --build-optimizer

Bientôt possible de développer en AOT?

. ng serve --aot with ng 4.4 and CLI 1.4 : ~4000-8000ms

. ng serve --aot with ng 5.0 and CLI 1.7 : ~1500-3400ms

1) Build

. ng eject :

  . Extraction de la config webpack de la CLI Angular.

  . Possibilité d'ajouts de plugins, etc...

 

 

 

. Angular CLI :

  . Aspect "boîte noire"

  . Complexe à customiser...

 

 

 

1) Build

. Attention aux imports non maîtrisés...

 

 

 

Build                           Output size                  build duration

_                                   4,836M                         5389ms                   

rxjs/add/op/map       5,523M                         5950ms                   

rxjs/Rx                         6,878M                         7345ms                   

1) Build

. Best practice: un fichier d'import unique rxjs-imports.ts

. Et ajouter le set de rules rxjs-tslint-rules

 

 

 

1) Build

. npm i -g source-map-explorer

. ng build --prod -sm

. source-map-explorer ./dist/main*.js

 

2) Load

. Lazy Loading :

  . A utiliser à bon escient.

  . Chargement des modules peut être conditionné par un guard (canLoad).

  . Différentes preloading Strategies :

 

 

 

 

 

    - Au chargement des routes correspondantes.

    - PreloadAllModules

    - CustomPreloadingStrategy

3) Run

. Angular change detection :

 

 

 

 

 

3) Run

. computed values in templates :

  . Réévaluées à chaque change detection cycle (potentiellement de nombreuses fois en Default).

  . Pas de gros traitements/calculs.

 

 

 

 

 

 

 

 

 

. Solutions :

    . Ajout d'une propriété calculée une fois.

    . Utilisation de pures pipes

3) Run

. onPush :

  . changeDetectionStrategy.Default... Un peu trop "magic"?

 

  . Permet de contrôler précisément quand et comment sont     déclenchés les cycles de rafraichissement de vos composants :

   

 

 

 

 

 

 

 

    - A chaque réaffectation d'un @Input()

    - A chaque appel explicite de changeDetector.markForCheck()

3) Run

. Interrompre la change Detection :

  . Dans les cas où elle se déclenche trop souvent (flux continu d'events, etc...), il est possible de "détacher" le change detector du composant.

 

 

 

 

 

3) Run

. trackBy :

  . Optimisation des boucles *ngFor

  . Pourquoi re-render un élément qui n'a pas changé?

  . Préciser l'identifiant de chaque élément (id? index?).

 

 

 

 

 

 

Questions?

Angular performances & best practices

By Laurent WROBLEWSKI

Angular performances & best practices

  • 392