Il n'y a pas de moyen plus rapide de ralentir un site Web (jeu de mots) que d'utiliser un tas de code JavaScript dessus. Lorsque vous utilisez JavaScript, vous devez le payer avec la performance des projets pas moins de quatre fois. Voici comment le code JavaScript du site charge les systèmes des utilisateurs :
- Téléchargement d'un fichier sur le réseau.
- Analyse et compilation du code source décompressé après le téléchargement.
- Exécution de code JavaScript.
- Consommation de mémoire.
Cette combinaison s'avère .
Et nous incluons de plus en plus de code JS dans nos projets. Alors que les organisations se tournent vers des sites alimentés par des frameworks et des bibliothèques comme React, Vue et autres, nous rendons la fonctionnalité de base des sites très fortement dépendante de JavaScript.
J'ai vu beaucoup de sites très lourds utilisant des frameworks JavaScript. Mais ma vision de la question est très biaisée. Le fait est que les entreprises avec lesquelles je travaille se tournent vers moi précisément parce qu'elles sont confrontées à des problématiques complexes dans le domaine de la performance des sites. En conséquence, je suis devenu curieux de savoir à quel point ce problème est courant et de savoir quel type de "pénalités" nous payons lorsque nous choisissons l'un ou l'autre cadre comme base pour un certain site.
Le projet m'a aidé à comprendre cela. .
Données
Le projet HTTP Archive suit un total de 4308655 5484239 XNUMX liens vers des sites de bureau classiques et XNUMX XNUMX XNUMX liens vers des sites mobiles. Parmi les nombreuses mesures associées à ces liens figure une liste de technologies trouvées sur les sites respectifs. Cela signifie que nous pouvons échantillonner des milliers de sites qui utilisent divers frameworks et bibliothèques et découvrir la quantité de code qu'ils envoient aux clients et la charge que ce code crée sur les systèmes des utilisateurs.
J'ai collecté les données de mars 2020, qui étaient les données les plus récentes auxquelles j'avais accès.
J'ai décidé de comparer les données agrégées HTTP Archive sur tous les sites avec les données des sites trouvés à l'aide de React, Vue et Angular, même si j'ai également envisagé d'utiliser d'autres sources.
Pour le rendre plus intéressant, j'ai également ajouté des sites qui utilisent jQuery à l'ensemble de données source. Cette bibliothèque est toujours très populaire. Il introduit également une approche différente du développement Web que le modèle d'application à page unique (SPA) proposé par React, Vue et Angular.
Liens dans l'archive HTTP représentant des sites qui se sont avérés utiliser des technologies intéressantes
Framework ou bibliothèque
Liens vers des sites mobiles
Liens vers des sites réguliers
jQuery
4615474
3714643
Réagir
489827
241023
Vue
85649
43691
Angulaire
19423
18088
Espoirs et rêves
Avant de passer à l'analyse des données, je veux parler de ce que j'aimerais espérer.
Je pense que dans un monde idéal, les frameworks devraient aller au-delà de la satisfaction des besoins des développeurs et offrir des avantages spécifiques à l'utilisateur moyen qui travaille avec nos sites. La performance n'est qu'un de ces avantages. C'est là que l'accessibilité et la sécurité entrent en jeu. Mais ce n'est que le plus important.
Ainsi, dans un monde idéal, une sorte de framework devrait faciliter la création d'un site performant. Cela devrait être fait soit parce que le framework donne au développeur une base décente sur laquelle construire un projet, soit parce qu'il impose des restrictions au développement, met en avant des exigences qui compliquent le développement de quelque chose qui tourne être lent.
Les meilleurs cadres doivent faire les deux : donner une bonne base et imposer des restrictions sur le travail, vous permettant d'obtenir un résultat décent.
L'analyse des valeurs médianes des données ne nous donnera pas les informations dont nous avons besoin. Et, en fait, cette approche laisse de côté notre attention . Au lieu de cela, j'ai dérivé des pourcentages à partir des données que j'avais. Ce sont 10, 25, 50 (médiane), 75, 90 centiles.
Je m'intéresse particulièrement aux 10e et 90e centiles. Le 10e centile représente les meilleures performances (ou du moins plus ou moins proches des meilleures) pour un framework particulier. En d'autres termes, cela signifie que seuls 10 % des sites utilisant un framework particulier atteignent ce niveau, voire plus. Le 90e centile, en revanche, est le revers de la médaille - il nous montre à quel point les choses peuvent mal tourner. Le 90e centile correspond aux sites à la traîne : les 10 % de sites inférieurs qui ont le plus de code JS ou le plus de temps pour traiter leur code sur le thread principal.
Volumes de code JavaScript
Pour commencer, il est logique d'analyser la taille du code JavaScript transmis par les différents sites sur le réseau.
La quantité de code JavaScript (Ko) transféré sur les appareils mobiles
Centiles
10
25
50
75
90
Tous les sites
93.4
196.6
413.5
746.8
1201.6
sites jquery
110.3
219.8
430.4
748.6
1162.3
Voir les sites
244.7
409.3
692.1
1065.5
1570.7
Chantiers angulaires
445.1
675.6
1066.4
1761.5
2893.2
Sites de réaction
345.8
441.6
690.3
1238.5
1893.6
Quantité de code JavaScript envoyé aux appareils mobiles
Quantité de code JavaScript (Ko) transféré sur les appareils de bureau
Centiles
10
25
50
75
90
Tous les sites
105.5
226.6
450.4
808.8
1267.3
sites jquery
121.7
242.2
458.3
803.4
1235.3
Voir les sites
248.0
420.1
718.0
1122.5
1643.1
Chantiers angulaires
468.8
716.9
1144.2
1930.0
3283.1
Sites de réaction
308.6
469.0
841.9
1472.2
2197.8
Quantité de code JavaScript envoyé aux appareils de bureau
Si nous ne parlons que de la taille du code JS que les sites envoient aux appareils, alors tout se passe comme prévu. A savoir, si l'un des frameworks est utilisé, cela signifie que même dans une situation idéale, le volume de code JavaScript du site va augmenter. Ce n'est pas surprenant - vous ne pouvez pas faire d'un framework JavaScript la base d'un site et vous attendre à ce que le volume de code JS du projet soit très faible.
Ce qui est remarquable à propos de ces données, c'est que certains frameworks et bibliothèques peuvent être considérés comme un meilleur point de départ pour un projet que d'autres. Les sites avec jQuery sont les meilleurs. Sur les versions de bureau des sites, ils contiennent 15 % de JavaScript en plus que tous les sites, et sur les mobiles, ils en contiennent 18 % de plus. (Certes, il y a une certaine corruption de données ici. Le fait est que jQuery est présent sur de nombreux sites, il est donc naturel que ces sites soient plus étroitement associés que d'autres au nombre total de sites. Cependant, cela n'affecte pas la façon dont les données sont générées pour chaque cadre.)
Bien que l'augmentation de 15 à 18 % du volume de code soit un chiffre notable, en le comparant à d'autres frameworks et bibliothèques, on peut conclure que la "taxe" prélevée par jQuery est très faible. Les sites angulaires du 10e centile envoient 344 % de données en plus sur les ordinateurs de bureau que tous les sites, et 377 % de plus sur les mobiles. Les sites React sont les suivants les plus lourds, envoyant 193% de code en plus sur le bureau que tous les sites et 270% de plus sur le mobile.
Plus tôt, j'ai mentionné que même si l'utilisation d'un framework signifie qu'une certaine quantité de code sera incluse dans le projet, au tout début du travail, j'espère que le framework est capable de limiter d'une manière ou d'une autre le développeur. En particulier, nous parlons de limiter la quantité maximale de code.
Fait intéressant, les sites jQuery suivent cette idée. Bien qu'ils soient légèrement plus lourds que tous les sites au 10e centile (de 15 à 18 %), ils sont légèrement plus légers au 90e centile à environ 3 % sur ordinateur et sur mobile. Cela ne veut pas dire que c'est un avantage très important, mais on peut dire que les sites jQuery, au moins, n'ont pas d'énormes tailles de code JavaScript, même dans leurs plus grandes versions.
Mais on ne peut pas en dire autant des autres frameworks.
Tout comme dans le cas du 10e centile, les sites du 90e centile sur Angular et React diffèrent des autres sites, mais ils diffèrent, malheureusement, pour le pire.
Au 90e centile, les sites angulaires envoient 141 % de données en plus au mobile que tous les sites, et 159 % de plus au bureau. Les sites React envoient 73 % de plus sur ordinateur que tous les sites et 58 % de plus sur mobile. La taille du code des sites React au 90e centile est de 2197.8 Ko. Cela signifie que ces sites envoient 322.9 Ko de données de plus aux appareils mobiles que leurs concurrents les plus proches basés sur Vue. L'écart entre les sites de bureau basés sur Angular et React et les autres sites est encore plus grand. Par exemple, les sites React de bureau envoient 554.7 Ko de code JS de plus aux appareils que les sites Vue équivalents.
Temps nécessaire pour traiter le code JavaScript dans le thread principal
Les données ci-dessus indiquent clairement que les sites utilisant les frameworks et les bibliothèques à l'étude contiennent de grandes quantités de code JavaScript. Mais bien sûr, ce n'est qu'une partie de notre équation.
Une fois que le code JavaScript est arrivé dans le navigateur, il doit être mis dans un état fonctionnel. En particulier, de nombreux problèmes sont causés par les actions qui doivent être effectuées avec le code dans le thread principal du navigateur. Le thread principal est responsable du traitement des actions de l'utilisateur, du calcul des styles, de la construction et de l'affichage de la mise en page. Si vous submergez le thread principal avec des tâches JavaScript, il n'aura pas la possibilité de terminer le reste des tâches à temps. Cela entraîne des retards et des "freins" dans le travail des pages.
La base de données HTTP Archive contient des informations sur la durée de traitement du code JavaScript dans le thread principal du moteur V8. Cela signifie que nous pouvons collecter ces données et savoir combien de temps le thread principal prend pour traiter le JavaScript de différents sites.
Temps processeur (en millisecondes) lié au traitement des scripts sur les appareils mobiles
Centiles
10
25
50
75
90
Tous les sites
356.4
959.7
2372.1
5367.3
10485.8
sites jquery
575.3
1147.4
2555.9
5511.0
10349.4
Voir les sites
1130.0
2087.9
4100.4
7676.1
12849.4
Chantiers angulaires
1471.3
2380.1
4118.6
7450.8
13296.4
Sites de réaction
2700.1
5090.3
9287.6
14509.6
20813.3
Temps processeur lié au traitement des scripts sur les appareils mobiles
Temps processeur (en millisecondes) lié au traitement des scripts sur les appareils de bureau
Centiles
10
25
50
75
90
Tous les sites
146.0
351.8
831.0
1739.8
3236.8
sites jquery
199.6
399.2
877.5
1779.9
3215.5
Voir les sites
350.4
650.8
1280.7
2388.5
4010.8
Chantiers angulaires
482.2
777.9
1365.5
2400.6
4171.8
Sites de réaction
508.0
1045.6
2121.1
4235.1
7444.3
Temps processeur lié au traitement des scripts sur les appareils de bureau
Ici, vous pouvez voir quelque chose de très familier.
Pour commencer, les sites avec jQuery dépensent beaucoup moins en traitement JavaScript sur le thread principal que les autres sites. Au 10e centile, par rapport à tous les sites, les sites jQuery sur mobile passent 61 % de temps en plus à traiter le code JS sur le thread principal. Dans le cas des sites jQuery de bureau, le temps de traitement augmente de 37 %. Au 90e centile, les sites jQuery obtiennent un score très proche des scores agrégés. Plus précisément, les sites jQuery sur les appareils mobiles passent 1.3 % de temps en moins sur le thread principal que tous les sites, et 0.7 % de temps en moins sur les appareils de bureau.
De l'autre côté de notre note se trouvent les cadres qui se caractérisent par la charge la plus élevée sur le fil principal. C'est, encore une fois, Angular et React. La seule différence entre les deux est que si les sites Angular envoient plus de code aux navigateurs que les sites React, les sites Angular prennent moins de temps CPU pour traiter le code. Beaucoup moins.
Au 10e centile, les sites Angular de bureau passent 230 % de temps en plus sur le thread principal traitant le code JS que tous les sites. Pour les sites mobiles, ce chiffre est de 313 %. Les sites React sont les moins performants. Sur ordinateur, ils passent 248 % de temps en plus à traiter du code que tous les sites, et 658 % de plus sur mobile. 658% n'est pas une faute de frappe. Au 10e centile, les sites React passent 2.7 secondes de temps de thread principal à traiter leur code.
Le 90e centile, comparé à ces chiffres énormes, semble au moins un peu mieux. Par rapport à tous les sites, les projets Angular passent 29 % de temps en plus sur les appareils de bureau dans le thread principal et 27 % de temps en plus sur les appareils mobiles. Dans le cas des sites React, les mêmes chiffres ressemblent respectivement à 130% et 98%.
Les écarts en pourcentage pour le 90e centile semblent meilleurs que les valeurs similaires pour le 10e centile. Mais ici, il convient de rappeler que les chiffres indiquant l'heure semblent plutôt effrayants. Disons 20.8 secondes sur le fil mobile principal pour un site Web construit avec React. (Je pense que l'histoire de ce qui se passe réellement pendant cette période mérite un article séparé).
Il y a une complication potentielle ici (merci d'avoir attiré mon attention sur cette caractéristique et d'avoir soigneusement examiné les données de ce point de vue). Le fait est que de nombreux sites utilisent plusieurs outils frontaux. En particulier, j'ai vu beaucoup de sites utiliser jQuery aux côtés de React ou Vue, car ces sites migrent de jQuery vers d'autres frameworks ou bibliothèques. En conséquence, j'ai de nouveau frappé la base de données, cette fois en sélectionnant uniquement les liens qui correspondent aux sites qui n'utilisent que React, jQuery, Angular ou Vue, mais pas n'importe quelle combinaison d'entre eux. Voici ce que j'ai.
Temps processeur (en millisecondes) lié au traitement des scripts sur les appareils mobiles dans une situation où les sites n'utilisent qu'un seul framework ou qu'une seule bibliothèque
Centiles
10
25
50
75
90
Sites qui n'utilisent que jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Sites qui n'utilisent que Vue
944.0
1716.3
3194.7
5959.6
9843.8
Sites qui utilisent uniquement Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sites qui n'utilisent que React
2443.2
4620.5
10061.4
17074.3
24956.3
Temps processeur lié au traitement des scripts sur les appareils mobiles dans une situation où les sites n'utilisent qu'un seul framework, ou qu'une seule bibliothèque
Tout d'abord, chose qui n'a rien d'étonnant : lorsqu'un site n'utilise qu'un seul framework ou qu'une seule bibliothèque, les performances d'un tel site s'améliorent le plus souvent. Chaque instrument est plus performant aux 10e et 25e centiles. Ca a du sens. Un site créé à l'aide d'un framework devrait être plus performant qu'un site créé à l'aide de deux frameworks ou bibliothèques ou plus.
En fait, les performances de chaque outil frontal étudié semblent meilleures dans tous les cas, à une curieuse exception près. Ce qui m'a surpris, c'est qu'au 50e centile et au-dessus, les sites utilisant React fonctionnent moins bien lorsque React est la seule bibliothèque qu'ils utilisent. C'est d'ailleurs la raison pour laquelle je présente ici ces données.
C'est un peu étrange, mais je vais quand même essayer de chercher une explication à cette étrangeté.
Si un projet utilise à la fois React et jQuery, alors ce projet est probablement quelque part à mi-chemin de la transition de jQuery à React. Peut-être qu'il a une base de code où ces bibliothèques sont mélangées. Comme nous avons déjà vu que les sites jQuery passent moins de temps sur le thread principal que les sites React, cela pourrait nous dire que l'implémentation de certaines fonctionnalités dans jQuery aide le site à fonctionner un peu mieux.
Mais à mesure que le projet passe de jQuery à React et s'appuie davantage sur React, les choses changent. Si le site est vraiment de haute qualité et que les développeurs du site utilisent React avec précaution, alors tout ira bien avec un tel site. Mais pour le site React moyen, l'utilisation intensive de React signifie que le thread principal est soumis à une forte charge.
L'écart entre les appareils mobiles et les ordinateurs de bureau
Un autre point de vue à partir duquel j'ai examiné les données recherchées était d'étudier l'ampleur de l'écart entre le travail avec des sites sur des appareils mobiles et de bureau. Si nous parlons de comparer les volumes de code JavaScript, une telle comparaison ne révèle rien de terrible. Bien sûr, ce serait bien de voir de plus petites quantités de code téléchargeable, mais il n'y a pas beaucoup de différence dans la quantité de code mobile et de bureau.
Mais si nous analysons le temps nécessaire pour traiter le code, un très grand écart entre les appareils mobiles et de bureau devient perceptible.
Augmentation du temps (pourcentage) lié au traitement des scripts sur les appareils mobiles par rapport au bureau
Centiles
10
25
50
75
90
Tous les sites
144.1
172.8
185.5
208.5
224.0
sites jquery
188.2
187.4
191.3
209.6
221.9
Voir les sites
222.5
220.8
220.2
221.4
220.4
Chantiers angulaires
205.1
206.0
201.6
210.4
218.7
Sites de réaction
431.5
386.8
337.9
242.6
179.6
Bien qu'il faille s'attendre à une certaine différence de vitesse de traitement du code entre un téléphone et un ordinateur portable, des nombres aussi importants me disent que les frameworks modernes ne sont pas suffisamment ciblés sur les appareils à faible puissance et qu'ils s'efforcent de combler l'écart qu'ils ont découvert. Même au 10e centile, les sites React passent 431.5 % de temps en plus sur le thread principal mobile que sur le thread principal de bureau. jQuery a le plus petit écart, mais même ici, le chiffre correspondant est de 188.2 %. Lorsque les développeurs de sites Web réalisent leurs projets de telle sorte que leur traitement nécessite plus de temps processeur (et cela arrive, et cela ne fait qu'empirer avec le temps), les propriétaires d'appareils à faible puissance doivent payer pour cela.
Les résultats de
De bons frameworks devraient donner aux développeurs une bonne base pour la construction de projets Web (en termes de sécurité, d'accessibilité, de performances), ou ils devraient avoir des restrictions intégrées qui rendent difficile la construction de quelque chose qui viole ces restrictions.
Cela ne semble pas s'appliquer à la performance des projets Web (et probablement pas à leur ).
Il convient de noter que ce n'est pas parce que les sites React ou Angular consacrent plus de temps CPU à la préparation du code que d'autres que les sites React sont plus gourmands en CPU que les sites Vue lors de leur exécution. En fait, les données que nous avons examinées en disent très peu sur les performances opérationnelles des frameworks et des bibliothèques. Ils parlent davantage des approches de développement que, consciemment ou non, ces frameworks peuvent pousser les programmeurs. Nous parlons de la documentation des frameworks, de leur écosystème, des techniques de développement courantes.
Il convient également de mentionner quelque chose que nous n'avons pas analysé ici, à savoir le temps que l'appareil passe à exécuter du code JavaScript lors de la navigation entre les pages du site. L'argument en faveur de SPA est qu'une fois l'application monopage chargée dans le navigateur, l'utilisateur pourra théoriquement ouvrir les pages du site plus rapidement. Ma propre expérience me dit que c'est loin d'être un fait. Mais nous n'avons pas de données pour clarifier cette question.
Ce qui est clair, c'est que si vous utilisez un framework ou une bibliothèque pour créer un site Web, vous faites un compromis en termes de chargement initial du projet et de préparation. Cela s'applique même aux scénarios les plus positifs.
Il est parfaitement possible de faire des compromis dans des situations appropriées, mais il est important que les développeurs fassent consciemment de tels compromis.
Mais nous avons aussi des raisons d'être optimistes. Je suis ravi de voir à quel point les développeurs de Chrome travaillent en étroite collaboration avec les développeurs de certains des outils frontaux que nous avons examinés dans le but d'améliorer les performances de ces outils.
Cependant, je suis quelqu'un de pragmatique. Les nouvelles architectures créent des problèmes de performance aussi souvent qu'elles les résolvent. Et il faut du temps pour corriger les bugs. Tout comme il ne faut pas s'attendre résoudra tous les problèmes de performances, vous ne devriez pas vous attendre à cela des nouvelles versions de nos frameworks préférés.
Si vous souhaitez utiliser l'un des outils frontaux abordés dans cet article, cela signifie que vous devrez faire des efforts supplémentaires pour ne pas nuire aux performances de votre projet entre-temps. Voici quelques considérations à prendre en compte avant de commencer un nouveau framework :
- Testez-vous avec bon sens. Avez-vous vraiment besoin d'utiliser le framework choisi ? Le JavaScript pur est aujourd'hui capable de beaucoup.
- Existe-t-il une alternative plus légère au framework choisi (comme Preact, Svelte ou autre) qui puisse vous donner 90% des capacités de ce framework ?
- Si vous utilisez déjà un framework, demandez-vous s'il existe quelque chose qui offre de meilleures options standard plus conservatrices (par exemple, Nuxt.js au lieu de Vue, Next.js au lieu de React, etc.).
- Quel sera votre Performances JavaScript ?
- Comment peux-tu un processus de développement pour rendre plus difficile l'injection de plus de code JavaScript dans un projet que ce qui est absolument nécessaire ?
- Si vous utilisez un framework pour faciliter le développement, pensez à envoyer le code de cadre aux clients. Peut-être pouvez-vous résoudre tous les problèmes sur le serveur ?
Habituellement, ces idées valent la peine d'être examinées, quel que soit exactement ce que vous avez choisi pour le développement frontal. Mais ils sont particulièrement importants lorsque vous travaillez sur un projet qui manque de performances dès le début.
Chers lecteurs, Comment voyez-vous le framework JavaScript idéal ?
Source: habr.com