🙌🏼 🤴 🗿 Le prix des frameworks JavaScript 💶 👩🏽‍🤝‍👨🏼 🧑🏻‍🤝‍🧑🏻

Il n'y a pas de moyen plus rapide de ralentir un site (un jeu de mots) que d'utiliser un tas de code JavaScript dessus. Lorsque vous utilisez JavaScript, vous devez payer cela avec les performances du projet au moins quatre fois. Voici comment le code JavaScript du site charge les systèmes utilisateur:

Téléchargez un fichier sur le réseau.
Analyse et compilation du code source décompressé après le chargement.
Exécution de code JavaScript.
Consommation de mémoire.

Cette combinaison est très chère . Et nous incluons de plus en plus de code JS dans nos projets. Alors que les organisations évoluent vers des sites basés sur des frameworks et des bibliothèques comme React, Vue, etc., nous rendons les fonctionnalités principales des sites très dépendantes 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 viennent à moi précisément parce qu'elles rencontrent des problèmes complexes dans le domaine de la performance des sites Web. En conséquence, je suis devenu curieux de savoir à quel point ce problème est répandu et quel type d '«amendes» nous payons lorsque nous sélectionnons l'un ou l'autre cadre comme base pour un certain site.

Le projet HTTP Archive m'a aidé à comprendre cela .

Les données

Le projet HTTP Archive, au total, assure le suivi de 4 308 655 liens vers des sites réguliers dédiés aux appareils de bureau et 5 484 239 liens vers des sites mobiles. Parmi les nombreux indicateurs associés à ces liens, il y a une liste de technologies trouvées sur les sites respectifs. Cela signifie que nous pouvons créer un échantillon de milliers de sites qui utilisent divers cadres et bibliothèques, et savoir combien de code ils envoient aux clients, et combien de charge les systèmes utilisateur créent ce code.

J'ai collecté des données pour mars 2020, ce sont les dernières données auxquelles j'ai eu accès.

J'ai décidé de comparer les données agrégées des archives HTTP pour tous les sites avec les données des sites où React, Vue et Angular ont été détectés, bien que j'envisage d'utiliser d'autres sources.

Pour le rendre plus intéressant - j'ai également ajouté des sites qui utilisent jQuery au jeu de données source. Cette bibliothèque est toujours très populaire. Il fournit également une approche de développement de site Web qui diffère du modèle SPA (Single Page Application) proposé par React, Vue et Angular.

Liens dans l'archive HTTP représentant des sites qui ont détecté l'utilisation de technologies d'intérêt

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 voudrais 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 donner certains avantages concrets aux utilisateurs ordinaires travaillant avec nos sites. La performance n'est qu'un de ces avantages. Ici, l'accessibilité et la sécurité viennent encore à l'esprit. Mais ce n'est que le plus important.

Ainsi, dans un monde idéal, un certain framework devrait faciliter la création d'un site performant. Cela devrait être fait soit parce que le cadre donne au développeur une base décente sur laquelle construire le 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 s'avère lent.

Les meilleurs cadres devraient faire les deux: donner une bonne base et imposer des restrictions sur le travail, permettant d'obtenir un résultat décent.

L'analyse des valeurs médianes des données ne nous donnera pas les informations nécessaires. Et, en fait, une telle approche laisse beaucoup d’importance au-delà de notre attention . Au lieu de cela, j'ai déduit de mes données des indicateurs exprimés en centiles. Il s'agit de 10, 25, 50 (médiane), 75, 90 centiles.

Je suis particulièrement intéressé par les 10e et 90e centiles. Le 10e centile représente la meilleure performance (ou au moins plus ou moins proche de la meilleure) pour un cadre particulier. En d'autres termes, cela signifie que seulement 10% des sites utilisant un framework particulier atteignent ce niveau, ou à un niveau supérieur. Le 90e centile, d'autre part, est le revers de la médaille - il nous montre à quel point les choses peuvent être mauvaises. Le 90e centile correspond aux sites de tissage - ces 10% des sites qui se caractérisent par les volumes de code JS les plus importants ou le temps le plus long requis pour traiter leur code dans le flux principal.

Volumes de code JavaScript

Pour commencer, il est logique d'analyser la taille du code JavaScript transmis par différents sites sur le réseau.

La quantité de code JavaScript (Ko) transférée sur les appareils mobiles

	10	25	50	75	90
	93.4	196.6	413.5	746.8	1201.6
jQuery-	110.3	219.8	430.4	748.6	1162.3
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	10	25	50	75	90
	105.5	226.6	450.4	808.8	1267.3
jQuery-	121.7	242.2	458.3	803.4	1235.3
Vue-	248.0	420.1	718.0	1122.5	1643.1
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	308.6	469.0	841.9	1472.2	2197.8

La quantité de code JavaScript transmis aux appareils de bureau

Si nous parlons uniquement de la taille du code JS envoyé par les sites aux appareils, alors tout ressemble à ce que vous attendez. À savoir, si l'un des cadres est utilisé, cela signifie que même dans une situation idéale, le volume du code JavaScript du site augmentera. Cela n'est pas surprenant - vous ne pouvez pas faire du framework JavaScript la base du site et vous attendre à ce que le volume du code JS du projet soit très faible.

Il est à noter dans ces données que certains cadres et bibliothèques peuvent être considérés comme un point de départ plus réussi du projet que d'autres. Les sites 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 versions mobiles - 18% de plus. (Je dois admettre qu'ici, vous pouvez observer une certaine distorsion des données. Le fait est que jQuery est présent sur de nombreux sites, il est donc naturel que ces sites soient plus proches que d'autres du nombre total de sites. Cependant, cela n'affecte pas la manière les données source sont affichées pour chaque framework.)

Bien qu'une augmentation de 15 à 18% du volume de code soit un chiffre notable, en le comparant à d'autres frameworks et bibliothèques, nous pouvons conclure que la «taxe» facturée par jQuery est très faible. Les sites situés dans l'angle du 10e centile envoient 344% de données en plus aux appareils de bureau que tous les sites, et aux mobiles - 377% de plus. Les sites React, les prochains en termes de gravité, envoient 193% de code de plus aux appareils de bureau que tous les sites, et 270% de plus aux appareils mobiles.

J'ai déjà mentionné que, bien que l'utilisation du cadre signifie qu'une certaine quantité de code sera incluse dans le projet, au tout début des travaux, j'espère que le cadre est en mesure de limiter 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'au niveau du 10e centile, ils soient légèrement plus lourds que tous les sites (15 à 18%), ils sont, au niveau du 90e centile, légèrement plus légers que tous - d'environ 3% dans les versions de bureau et mobiles. Cela ne peut pas être considéré comme un avantage très important, mais on peut dire que les sites jQuery au moins ne diffèrent pas par la taille énorme du code JavaScript, même dans leurs plus grandes versions.

Mais on ne peut pas en dire autant des autres cadres.

Comme pour le 10e centile, les sites du 90e centile sur Angular et React sont différents des autres sites, mais malheureusement ils diffèrent pour le pire.

Au 90e centile, les sites angulaires envoient 141% plus de données aux appareils mobiles que tous les sites et 159% de plus aux ordinateurs de bureau. Les sites React envoient 73% de plus aux appareils de bureau que tous les sites et 58% de plus aux mobiles. La taille de code des sites React au 90e centile est de 2197,8 Ko. Cela signifie que ces sites envoient 322,9 Ko de données en plus aux appareils mobiles que leurs concurrents les plus proches, selon Vue. L'écart entre les sites de bureau basés sur Angular et React, et entre les autres sites, est encore plus grand. Par exemple, les sites React de bureau envoient 554,7 Ko de code JS en plus aux appareils que les sites Vue similaires.

Temps consacré au traitement du code JavaScript dans le fil principal

Les données ci-dessus indiquent clairement que les sites utilisant les frameworks et bibliothèques étudiés 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 en état de fonctionnement. En particulier, de nombreux problèmes sont causés par les actions qui doivent être effectuées avec le code dans le flux principal du navigateur. Le thread principal est responsable du traitement des actions des utilisateurs, du calcul des styles, de la construction et de l'affichage de la mise en page. Si vous remplissez le flux principal avec JavaScript-Affairs, il ne sera pas en mesure de résoudre d'autres 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 le temps nécessaire pour traiter le 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 divers sites.

Temps CPU (en millisecondes) lié au traitement des scripts sur les appareils mobiles

Percentiles	dix	25	cinquante	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
Sites de vue	1130,0	2087,9	4100,4	7676.1	12849.4
Sites 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 CPU lié au traitement de script sur les appareils mobiles

Temps CPU (en millisecondes) relatif au traitement de script sur les appareils de bureau

Percentiles	dix	25	cinquante	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
Vue-	350.4	650.8	1280.7	2388.5	4010.8
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	508.0	1045.6	2121.1	4235.1	7444.3

Temps CPU 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 sur le traitement JavaScript dans le thread principal que les autres. Au 10e centile, par rapport à tous les sites, les sites jQuery sur les appareils mobiles passent 61% plus de temps à traiter le code JS dans le thread principal. Dans le cas des sites jQuery de bureau, le temps de traitement est augmenté de 37%. Au niveau du 90e centile, les métriques du site jQuery sont très proches des métriques agrégées. À savoir, les sites jQuery sur les appareils mobiles passent 1,3% moins de temps dans le thread principal que tous les sites, et sur les appareils de bureau - 0,7% moins de temps.

De l'autre côté de notre évaluation, il existe des cadres qui se caractérisent par la plus grande charge sur le fil principal. Ceci, encore une fois, est angulaire et réagit. La seule différence entre eux est que, bien que les sites angulaires envoient de plus grandes quantités de code aux navigateurs que les sites React, le traitement du code des sites angulaires prend moins de temps au processeur. Beaucoup moins.

Au 10e centile, les sites Angular de bureau passent 230% de temps de thread principal de plus à traiter le code JS que tous les sites. Pour les sites mobiles, ce chiffre est de 313%. Les sites React ont les pires performances. Sur les appareils de bureau, ils consacrent 248% plus de temps au traitement de code que tous les sites, et sur les appareils mobiles - 658% de plus. 658% n'est pas une faute de frappe. Au 10e centile, les sites React passent 2,7 secondes du temps du thread principal pour traiter le code dont ils disposent.

Le 90e centile, comparé à ces chiffres énormes, semble au moins légèrement meilleur. Les projets angulaires par rapport à tous les sites passent 29% plus de temps sur les appareils de bureau dans le thread principal et 27% de plus sur les appareils mobiles. Dans le cas des sites React, des indicateurs similaires semblent 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 assez effrayants. Disons - 20,8 secondes dans le flux principal d'un appareil mobile pour un site construit sur React. (Je crois que l'histoire de ce qui se passe réellement pendant cette période mérite un article séparé).

Il y a une difficulté potentielle (merciJeremy pour avoir attiré mon attention sur cette fonctionnalité et pour 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 de nombreux sites qui utilisent jQuery avec React ou Vue, car ces sites migrent de jQuery vers d'autres frameworks ou bibliothèques. En conséquence, je me suis de nouveau tourné vers la base de données, en choisissant cette fois uniquement les liens qui correspondent à des sites qui n'utilisent que React, jQuery, Angular ou Vue, mais pas une combinaison d'entre eux. C'est ce que j'ai fait.

Temps CPU (en millisecondes) lié au traitement des scripts sur les appareils mobiles dans une situation où les sites n'utilisent qu'une seule infrastructure ou une seule bibliothèque

Percentiles	dix	25	cinquante	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

Temps CPU lié au traitement des scripts sur les appareils mobiles dans une situation où un seul framework est utilisé sur les sites, ou une seule bibliothèque

Au début, cela n'est pas surprenant: quand un seul framework ou une bibliothèque est utilisé sur un site, les performances d'un tel site sont plus souvent s'améliorer que de ne pas s'améliorer. Les indicateurs pour chaque instrument semblent meilleurs à 10 et 25 centiles. Ca a du sens. Un site créé à l'aide d'un cadre doit être plus productif qu'un site créé à l'aide de deux cadres ou bibliothèques ou plus.

En fait, les indicateurs pour chaque instrument frontal étudié sont plus beaux dans tous les cas, sauf une curieuse exception. J'ai été surpris qu'au niveau du 50e centile et plus, les sites utilisant React aient de moins bonnes performances si React est la seule bibliothèque utilisée sur eux. C'est d'ailleurs la raison pour laquelle j'apporte ici ces données.

C'est un peu étrange, mais j'essaie toujours de chercher une explication à cette bizarrerie.

Si un projet utilise à la fois React et jQuery, ce projet est très probablement à mi-chemin de la transition de jQuery à React. Peut-être qu'il a une base de code dans laquelle ces bibliothèques sont mélangées. Comme nous avons déjà vu que les sites jQuery passent moins de temps dans le thread principal que les sites React, cela peut nous dire que l'implémentation de certaines fonctionnalités sur jQuery aide à améliorer légèrement les performances du site.

Mais comme le projet, passant de jQuery à React, s'appuie davantage sur React, la situation change. Si le site est fait de très haute qualité et que les développeurs du site utilisent React avec prudence, alors avec ce site tout ira bien. Mais pour le site React moyen, l'utilisation répandue de React signifie que le fil principal est soumis à une charge accrue.

L'écart entre les appareils mobiles et de bureau

Un autre point de vue à partir duquel j'ai examiné les données à l'étude était d'étudier l'ampleur de l'écart entre travailler 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échargé, mais il n'y a pas beaucoup de différence dans les volumes de code mobile et de bureau.

Mais si vous analysez le temps requis pour traiter le code, vous remarquerez un très grand écart entre les appareils mobiles et de bureau.

L'augmentation du temps (en pourcentage) liée au traitement des scripts sur les appareils mobiles par rapport au bureau

Percentiles	dix	25	cinquante	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
Sites de vue	222,5	220,8	220,2	221,4	220,4
Sites 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'une certaine différence dans la vitesse de traitement du code entre le téléphone et l'ordinateur portable soit très attendue, de si grands nombres me disent que les cadres modernes ne sont pas suffisamment axés sur les appareils à faible puissance et sur le désir de combler l'écart. Même au 10e centile, les sites React passent 431,5% plus de temps dans le flux principal d'appareils mobiles que dans le flux principal d'appareils de bureau. L'écart le plus faible est observé dans jQuery, mais même ici, l'indicateur correspondant est de 188,2%. Lorsque les développeurs de sites Web réalisent leurs projets de sorte qu'il faut plus de temps au processeur pour les traiter (et cela se produit, et avec le temps, tout empire), les propriétaires d'appareils à faible puissance doivent payer pour cela.

Sommaire

De bons cadres devraient fournir aux développeurs une base de haute qualité pour créer des projets Web (en termes de sécurité, d'accessibilité, de performances), ou devraient avoir des restrictions intégrées qui rendent difficile la création de quelque chose qui viole ces restrictions.

Cela ne semble pas s'appliquer à la performance des projets Web (et, apparemment, à leur disponibilité ).

Il convient de noter que le fait que les sites React ou Angular consacrent plus de temps CPU à la préparation du code que d'autres ne signifie pas nécessairement que React-sites au cours du travail charge plus le processeur que Vue-sites. En fait, les données que nous avons examinées en disent très peu sur les performances des frameworks et des bibliothèques. Ils parlent davantage d'approches de développement auxquelles, consciemment ou non, ces cadres peuvent pousser les programmeurs. Nous parlons de documentation pour les frameworks, de leur écosystème, de techniques de développement communes.

Il convient de mentionner que nous ne l'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 que dès qu'une application d'une seule page est chargée dans le navigateur, l'utilisateur pourra théoriquement ouvrir rapidement les pages du site. Ma propre expérience me dit que c'est loin d'être un fait. Mais nous ne disposons pas de données pour clarifier ce problème.

Il est clair que si vous utilisez un framework ou une bibliothèque pour créer un site, vous compromettez en termes de chargement initial du projet et de le préparer au travail. Cela s'applique même aux scénarios les plus positifs.

Dans des situations appropriées, il est tout à fait possible de faire des compromis, mais il est important que les développeurs fassent des compromis conscients.

Mais nous avons des raisons d'être optimistes. Je suis encouragé par la façon dont les développeurs Chrome interagissent étroitement avec certains des outils frontaux que nous avons examinés dans le but d'améliorer les performances de ces outils.

Cependant, je suis une personne pragmatique. Les nouvelles architectures créent aussi souvent des problèmes de performances qu’elles les résolvent. Et il faut du temps pour corriger les défauts. Tout comme nous ne devons pas nous attendre à ce que les nouvelles technologies de réseau résolvent tous les problèmes de performances, nous ne devons pas nous attendre à cela des nouvelles versions de nos frameworks préférés.

Si vous souhaitez utiliser l'un des outils frontaux abordés dans ce document, cela signifie que vous devrez faire des efforts supplémentaires pour vous assurer, dans l'intervalle, de ne pas nuire à la productivité de votre projet. Voici quelques considérations à considérer avant de commencer à utiliser le nouveau framework:

Testez-vous en termes de bon sens. Avez-vous vraiment besoin d'utiliser le framework choisi? Le JavaScript pur est capable de beaucoup de choses aujourd'hui.
Existe-t-il une alternative plus simple au framework choisi (comme Preact, Svelte ou autre) qui peut vous donner 90% des capacités de ce framework?
Si vous utilisez déjà une sorte de framework, demandez-vous s'il existe quelque chose qui offre des options standard meilleures et plus conservatrices (par exemple, Nuxt.js au lieu de Vue, Next.js au lieu de React, etc.).
Quel sera votre budget de performance JavaScript?
Comment pouvez-vous limiter le processus de développement afin de compliquer la mise en œuvre d'une quantité de code JavaScript plus importante que nécessaire?
Si vous utilisez le framework pour la commodité du développement, déterminez si vous devez envoyer le code du framework à vos clients. Peut-être que vous pouvez résoudre tous les problèmes sur le serveur?

Habituellement, ces idées valent le coup d'œil, peu importe ce que vous avez choisi exactement pour développer l'interface. Mais ils sont particulièrement importants lorsque vous travaillez sur un projet qui, dès le début, manque de productivité.

Chers lecteurs! Comment voyez-vous le cadre JavaScript parfait?