Surveillez les tailles de vos bundles au fil du temps pour vous assurer que votre application reste rapide.
Optimiser une application Angular est important, mais comment vous assurer que ses performances ne régressent pas au fil du temps ? En introduisant des métriques de performances et en les surveillant à chaque modification de code.
La taille du code JavaScript fourni avec votre application est une métrique importante. En introduisant un budget de performances que vous surveillez pour chaque demande de compilation ou d'extraction, vous pouvez vous assurer que vos optimisations sont conservées au fil du temps.
Calculer votre budget de performances
Vous pouvez utiliser ce calculateur de budget en ligne pour estimer la quantité de code JavaScript que votre application peut se permettre de charger, en fonction du temps de chargement que vous visez.
Configurer un budget de performances dans la CLI Angular
Une fois que vous avez défini un budget JavaScript cible, vous pouvez l'appliquer à l'aide de l'interface de ligne de commande (CLI) Angular. Pour en savoir plus, consultez cet exemple d'application sur GitHub.
Le budget suivant a été configuré dans angular.json
:
"budgets": [{
"type": "bundle",
"name": "main",
"maximumWarning": "170kb",
"maximumError": "250kb"
}]
Voici un récapitulatif des informations spécifiées :
- Un budget est défini pour un bundle JavaScript appelé
main
. - Si le bundle
main
dépasse 170 ko, la CLI Angular affiche un avertissement dans la console lorsque vous créez l'application. - Si le bundle
main
dépasse 250 Ko, la compilation échoue.
Essayez maintenant de créer l'application en exécutant ng build --prod
.
L'erreur suivante devrait s'afficher dans la console :
Pour corriger l'erreur de compilation, examinez app.component.ts
, qui inclut une importation à partir de rxjs/internal/operators
. Il s'agit d'une importation privée qui ne doit pas être utilisée par les consommateurs de rxjs
. Cela augmente considérablement la taille du groupe. Lorsque vous effectuez la mise à jour vers la bonne importation (rxjs/operators
) et exécutez à nouveau la compilation, vous constatez qu'elle a réussi la vérification du budget.
Notez que, comme le chargement différentiel est activé par défaut dans la CLI Angular, la commande ng build
génère deux builds de l'application :
- Build pour les navigateurs compatibles avec ECMAScript 2015 Cette version inclut moins de polyfills et une syntaxe JavaScript plus moderne. Cette syntaxe est plus expressive, ce qui permet de créer des bundles plus petits.
- Compilation pour les navigateurs plus anciens non compatibles avec ECMAScript 2015. L'ancienne syntaxe est moins expressive et nécessite davantage de polyfills, ce qui entraîne des bundles plus volumineux.
Le fichier index.html
de l'application exemple fait référence aux deux builds afin que les navigateurs modernes puissent profiter du build ECMAScript 2015 plus petit et que les navigateurs plus anciens puissent revenir au build ECMAScript 5.
Appliquer votre budget dans le cadre de l'intégration continue
L'intégration continue (CI) vous permet de surveiller facilement le budget de votre application au fil du temps. Heureusement, le moyen le plus rapide de configurer cela est de compiler votre application avec la CLI Angular. Aucune étape supplémentaire n'est requise ! Chaque fois que le bundle JavaScript dépasse le budget, le processus se termine avec le code 1 et la compilation échoue.
Si vous préférez, vous pouvez également appliquer un budget de performances à l'aide de bundlesize et de Lighthouse. Dans la CLI Angular et dans Lighthouse, la principale différence entre les budgets de performances réside dans le moment où les vérifications sont effectuées. La CLI Angular effectue les vérifications au moment de la compilation, en examinant les composants de production et en vérifiant leurs tailles. Lighthouse, en revanche, ouvre la version déployée de l'application et mesure la taille de l'élément. Les deux approches présentent des avantages et des inconvénients. La vérification effectuée par la CLI Angular est moins robuste, mais beaucoup plus rapide, car il s'agit d'une recherche sur un seul disque. En revanche, LightWallet de Lighthouse peut effectuer une vérification très précise en tenant compte des ressources chargées dynamiquement, mais il doit déployer et ouvrir l'application à chaque fois qu'il s'exécute.
bundlesize est assez semblable à la vérification du budget de la CLI Angular. La principale différence est que bundlesize peut afficher les résultats de la vérification directement dans l'interface utilisateur de GitHub.
Conclusion
Définissez des budgets de performances avec la CLI Angular pour vous assurer que les performances de votre application Angular ne régressent pas au fil du temps :
- Définissez une référence pour la taille des ressources à l'aide d'un simulateur de budget ou en suivant les pratiques de votre organisation.
- Configurer des budgets de taille dans
angular.json
sousprojects.[PROJECT-NAME].architect.build.configurations.production.budgets
- Les budgets seront automatiquement appliqués à chaque compilation avec la CLI Angular.
- Envisagez d'introduire la surveillance du budget dans le cadre de l'intégration continue (ce qui peut également être réalisé avec la CLI Angular).