PC & Mobile

Dans quelle mesure votre application Angular est-elle conviviale et prête à l'emploi?

Dans quelle mesure votre application Angular est-elle conviviale et prête à l'emploi?


Run angulaire! Courir! Aussi vite que tu peux!

Parce que Angular est gros. Comme, vraiment gros.

Il y a probablement beaucoup de code mort dans votre application Angular - vous savez, les éléments inutiles qui finissent par l’ajout de kilo-octets au déploiement final. Le code mort est surtout une partie du programme qui est exécuté mais qui n’est jamais réellement utilisé.

Le code mort gaspille du temps, de l’espace et de la mémoire - et Angular est par nature très gros et lourd. Nous parlons de MB assez lourd. Contrairement à React et Vue, Angular utilise une multitude de bibliothèques qu’il utilise, ce qui contribue en définitive à l’amélioration du résultat global obtenu dans un environnement de développement.

Prenez la capture d'écran ci-dessous à titre d'exemple.

Dans quelle mesure votre application Angular est elle conviviale et prête à l39emploi - Dans quelle mesure votre application Angular est-elle conviviale et prête à l'emploi?
Nouvelle application angulaire générée par la CLI

3.9MB juste pour les os nus. Que se passe-t-il lorsque vous commencez à ajouter des images, des composants, des bibliothèques externes supplémentaires, des appels CSS et API? Ce nombre est sûr d'augmenter, si ce n'est pas de manière significative. 3,9 Mo est assez énorme lorsque la page d’accueil de Medium, par exemple, et en comparaison, transfère environ 3,6 Mo - les images sont inclusives.

Contrairement à Angular 1, qui ressemblait davantage à une bibliothèque et plus léger en comparaison, Angular 2 admet que déployer directement d'un environnement de développement vers un espace de production sans élagage n'est pas la meilleure idée. C’est possible mais ne le faites pas.

Bien que le déploiement direct depuis l’environnement de développement fonctionne, il est loin d’être optimal. - angulaire 2

Alors, comment optimiser exactement un environnement de développement local vers un déploiement de taille gérable et adaptée à la bande passante?

Construisez vos applications avec --prod méta-drapeau

Le moyen le plus simple de réduire considérablement la taille de votre application angulaire consiste à utiliser le --prod meta flag lorsque vous utilisez ng construire dans la CLI. En théorie, vous pouvez simplement copier et coller tous les fichiers tels quels dans votre serveur Web et le système fonctionnera toujours, mais vous rencontrerez un problème de taille globale que nous essayons de réduire.

Dans Angular, vous pouvez utiliser --dev ou --prod donc ça ressemble à quelque chose comme ça:

ng build --prod

La principale différence entre eux est que dev a une carte source alors que prod n'en a pas. Les mappages sources sont utiles pour reconstituer le code compressé dans son code source d'origine, ce qui n'est pas nécessaire dans un environnement de production.

Lancer le --prod flag a réduit l'ensemble de l'application de démarrage à 330 Ko, pour un total combiné de 7 fichiers, dont 262 Ko étaient main.js, une différence énorme par rapport aux 3,9 Mo actuellement en cours d'exécution sur l'environnement de développement.

Il atteint cette taille en regroupant votre application, en alignant votre code et en produisant une version simplifiée et simplifiée de tout ce dont vous avez besoin. Ce code ne s’intéresse pas à la lisibilité humaine, au formatage ou à tout ce qui est lisible à distance. Le processus ne s'intéresse qu'à la quantité de "code mort" qu'il peut éliminer tout en maintenant les fonctionnalités de l'application.

ng build --prod C’est ce que la plupart des gens font quand il s’agit de réduire la taille de leurs applications. Cependant, il existe également une autre fonctionnalité de contrôle de taille dont on ne parle pas couramment dans le cercle des débutants d’Angular, appelée budgets. Cela vous permet de définir des seuils qui vous alerteront si votre application devient trop grosse physiquement.

Budgets angulaires - quoi, pourquoi et comment

Au fil du temps, la croissance de votre application augmentera avec le temps. Cela signifie souvent plus de fonctionnalités et donc plus de code. En conséquence, la taille de votre application simple page devient insatisfaisante pour vos besoins. Le mécanisme des budgets d’Anngular vous avertit ou vous prévient des erreurs lorsque votre application atteint une certaine taille pendant le processus de construction.

La taille globale de votre application est importante car vos utilisateurs paient pour une application volumineuse avec du temps (et potentiellement des données mobiles limitées). Budgets vous aide à prendre conscience de votre taille et qu’elle atteigne la limite maximale, elle ne se construit plus et ne vous blâme pas pour gonfler votre application.

Si vous avez réussi à atteindre le seuil que vous avez défini, il est temps de revenir en arrière et de supprimer toute bibliothèque non utilisée ou toute assistance pollyfill que vous avez.

Alors, comment définissez-vous les budgets pour votre production en Angular, et à quoi cela ressemble-t-il?

  1. Aller à votre angular.json fichier et faites défiler la production section de des configurations
  2. Il y a déjà un défaut d'avertissement maximum défini à 2 Mo et le processus de génération peut générer une erreur et refuser de générer une génération à 5 Mo.
Exemple de code de angular.json

3. Réfléchissez à ce qui est raisonnable pour le contexte de votre application. Production Build effectue tout le code nécessaire pour donner une taille finale et exacte à votre application. Il est déjà très laid et utilise des méthodes qui permettent au code produit final d’être aussi petit que possible.

4. Votre résultat final est trop grand et vous ne savez pas pourquoi? Si vous utilisez le --stats-json drapeau avec votre commande de construction, il générera un stats.json fichier que vous pouvez utiliser avec l’analyseur de lots de Webpack.

Pour installer, utilisez npm i -D analyseur de packs de sites Web puis dans votre fichier packages.json, ajoutez «Stats»: «webpack-bundle-analyzer dist /[change your path name to match]/stats.json ” sous des scripts.

Puis courir npm stats et il démarrera un hôte local qui vous permettra d'effectuer un zoom avant et arrière pour voir visuellement où toutes les bases de connaissances sont utilisées. Ceci est utile car il peut vous permettre d'identifier des problèmes dans votre application et des bibliothèques, composants ou composants d'application gourmands en espace pouvant être remplacés ou exclus.

Mots finaux

Une application de rognage compte. Le déploiement d'une application optimisée en taille peut faire gagner ou réduire cette seconde supplémentaire qu'un utilisateur ressent en attendant le chargement de votre application Angular. Tout le monde n’a pas accès à l’Internet ultrarapide et les recherches montrent qu’en moyenne, un utilisateur partira s’il ne communique pas votre proposition de valeur dans les 10 secondes.

Si 5 secondes de ce temps ont été consacrées au chargement d'une page, vous disposez de 5 secondes de moins avec votre utilisateur potentiel. Notez également que 10 secondes est également une moyenne, ce qui signifie qu'il y a aussi des personnes qui siègent du côté inférieur de ce nombre. 10 secondes ne vous semblent pas très longues, mais si vous observiez votre propre comportement, combien de temps seriez-vous prêt à rester pour un site Web que vous n'avez jamais visité auparavant?

La rapidité compte et l’un des moyens pour y parvenir consiste à réduire la taille des fichiers de votre production.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close