Surveillez la taille de vos bundles au fil du temps pour vous assurer que votre application reste rapide.
Il est important d'optimiser une application Angular, mais comment s'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 du code.
Une métrique importante est la taille du code JavaScript envoyé avec votre application. En introduisant un budget de performances que vous surveillez à chaque build ou demande d'extraction, vous pouvez vous assurer que vos optimisations seront conservées dans le 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 charger, en fonction du délai avant interactivité que vous visez.
Configurer un budget de performances dans la CLI Angular
Une fois que vous disposez d'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.
Vous constaterez que 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 groupe JavaScript appelé
main
. - Si le bundle
main
dépasse 170 Ko, la CLI Angular affiche un avertissement dans la console lorsque vous compilez l'application. - Si le bundle
main
dépasse 250 Ko, la compilation échoue.
Essayez à présent de compiler l'application en exécutant ng build --prod
.
L'erreur suivante doit 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 n'est pas censée être utilisée par les utilisateurs de rxjs
. Cela augmente considérablement la taille du lot ! Si vous effectuez la mise à jour vers l'importation appropriée (rxjs/operators
) et exécutez à nouveau la compilation, vous constaterez que la vérification du budget a réussi.
Notez que le chargement différentiel étant 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 conduit à des groupes plus petits.
- Build pour les navigateurs plus anciens non compatibles avec ECMAScript 2015. L'ancienne syntaxe est moins expressive et nécessite plus de polyfills, ce qui donne lieu à des bundles de plus grande taille.
Le fichier index.html
de l'application exemple fait référence aux deux versions afin que les navigateurs récents puissent exploiter le build ECMAScript 2015, plus petit, et que les navigateurs plus anciens puissent revenir au build ECMAScript 5.
Appliquez votre budget dans le cadre d'une intégration continue
L'intégration continue (CI) est un moyen pratique de surveiller le budget de votre application au fil du temps. Heureusement, le moyen le plus rapide de configurer votre application est de compiler votre application à l'aide de la CLI Angular. Aucune étape supplémentaire n'est nécessaire. Chaque fois que le groupe 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 Lighthouse. La principale différence entre les budgets de performances dans la CLI Angular et dans Lighthouse est le moment où les vérifications sont effectuées. La CLI Angular effectue les vérifications au moment de la compilation, en examinant les éléments de production et en vérifiant leur taille. En revanche, Lighthouse ouvre la version déployée de l'application et mesure la taille de l'élément. Les deux approches ont leurs avantages et leurs 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 de disque unique. En revanche, LightWallet de Lighthouse peut effectuer un contrôle très précis en tenant compte des ressources chargées dynamiquement, mais il doit déployer et ouvrir l'application chaque fois qu'elle 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 du test directement dans l'interface utilisateur de GitHub.
Conclusion
Établissez des budgets de performances à l'aide de la CLI Angular pour vous assurer que les performances de votre application Angular n'évoluent 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.
- Configurez des budgets pour la taille dans
angular.json
sousprojects.[PROJECT-NAME].architect.build.configurations.production.budgets
- Les budgets seront automatiquement appliqués à chaque build à l'aide de la CLI Angular.
- Envisagez de mettre en place la surveillance du budget dans le cadre de l'intégration continue (qui peut également être réalisée à l'aide de la CLI Angular).