Date de création : 2021/02/27 10:54

Votre application Web s'est-elle déjà plainte du temps de chargement trop long? Vous a-t-on déjà confié une tâche pour «optimiser les performances» de l'application lente? Il existe des tonnes de sujets sur l'amélioration des performances de votre application, tels que le chargement paresseux ou lazy loading , la détection des changements, le rendu côté serveur, etc. L'un des sujets dont je veux parler ici est l'optimisation de la taille du bundle angular. C'est extrêmement simple et utile.

Il est difficile de nier que le temps de chargement initial de la page est étroitement lié à la taille de votre bundle d'applications Angular. En exécutant, ng build –prod vous verrez la taille des lots des fichiers que le navigateur obtiendrait de votre serveur.

Habituellement, parmi ces 4 fichiers renvoye par cette commande , seul main.*.js est susceptible de devenir gros ou fou. J'ai vérifié de nombreuses applications créées avec Angular et j'ai le sentiment que la plupart des applications d'entreprise de taille moyenne devraient avoir un main.*.js de moins de 500 Ko, en moyenne 250 Ko. Si la taille de votre bundle dépasse largement ces chiffres, vous devrez peut-être en être conscient. Si la taille de votre bundle est inférieure à ce nombre, vous souhaiterez peut-être encore l'optimiser davantage.

De manière générale, le fichier gzippé n'a qu'environ 20% de la taille du fichier d'origine, ce qui peut considérablement réduire le temps de chargement initial de votre application. Pour vérifier si vous avez gzippé vos fichiers, ouvrez simplement l'onglet réseau de la console développeur. Dans les “Reponse Header”, si vous voyez “Content-Encoding: gzip”, vous êtes prêt à partir. Si vous ne voyez pas cet en-tête, votre navigateur chargera les fichiers d'origine. Par exemple, pour le bundle Angular, le navigateur chargera main.nombrealéatoire.js et coûtera 2,21 Mo de données. Cependant, si vous gzipez votre fichier, votre navigateur ne pourra charger que 495,13 Ko. Une telle réduction énorme de la taille du fichier réduira évidemment le temps de chargement initial de la page, en particulier lorsque l'utilisateur a une faible vitesse Internet.

Si vous hébergez votre application Angular sur la plupart des plates-formes cloud ou CDN, ne vous inquiétez pas de ce problème car ils l'ont probablement géré pour vous. Cependant, si vous avez votre propre serveur (tel que NodeJS + expressJS) servant votre application Angular, vérifiez définitivement si les fichiers sont gzippés. Voici un exemple pour gzip vos actifs statiques dans une application NodeJS + expressJS. Vous pouvez difficilement imaginer que cette simple «compression» middleware réduirait la taille de votre bundle de 2,21 Mo à 495,13 Ko.

Si la taille de votre bundle devient trop grande, vous voudrez peut-être analyser votre bundle car vous avez peut-être utilisé un package tiers de grande taille inapproprié ou vous avez oublié de supprimer un package si vous ne l'utilisez plus. Webpack a une fonctionnalité étonnante pour nous donner une idée visuelle de la composition d'un bundle webpack.

C'est super facile d'obtenir ce graphique.

1. npm install -g webpack-bundle-analyzer

2. Dans votre application Angular, exécutez

   ng build --stats-json

   (n'utilisez pas d'indicateur –prod). En activant,

   --stats-json

   vous obtiendrez un fichier supplémentaire stats.json

3. Enfin, exécutez

   webpack-bundle-analyzer path/to/your/stats.json

   et votre navigateur affichera la page à localhost:8888.

Vous pourriez être surpris,

• a) que vous avez oublié de supprimer certains paquets que vous n'utilisez plus et / ou
• b) que certains colis sont bien plus volumineux que prévu et pourraient être remplacés par un autre et / ou
• c) que vous avez mal importé certaines bibliothèques (par exemple, 80% de moment.js ne sont que des données locales qui ne sont probablement pas nécessaires) afin que vous ayez une direction pour chercher une réponse.

Dans Angular 7 et versions ultérieures, lorsque vous générez une nouvelle application avec ng new, dans angular.json, vous pouvez trouver une configuration comme:

"budgets": [
  {
    "type": "initial",
    "maximumWarning": "2mb",
    "maximumError": "5mb"
  }
]

Cela vous donnera un avertissement si vous créez Angular et que la taille du bundle dépasse 2 Mo et génère une erreur si la taille du bundle dépasse 5 Mo. Vous pouvez ajuster les nombres selon vos besoins.

Vous pouvez tirer parti de cette fonctionnalité dans votre pipeline CI / CD. Si vous voyez l'avertissement / l'erreur, vous voudrez peut-être rechercher ce qui ne va pas.

Vérifier si toutes les dépendences utilisées sont utilent.

Il faut utiliser le package depcheck ( il faut avoir Angular 10 ou plus).

npm install depcheck -g

ou

yarn global add depcheck

lancer dans le terminal : depcheck

puis une fois nettoyer il peut être bien de savoir si on utilise pas une trop vieille librairie. Pour cela il suffit d'installer npm-check.

npm install -g npm-check

puis pour lancer la vérification:

npm-check --skip-unused

–skip-unused sert juste a ne pas afficher les packages inutiliser.

pour lancer depcheck sans l'installer un simplie

ngx depcheck

Si la taille de votre bundle devient trop grande parce que votre application est aussi grande que Facebook, vous devriez vraiment utiliser le chargement paresseux . Ce sujet est largement couvert par la communauté Angular, je ne vais donc pas le diffuser ici.

Page dans la catégorie: