Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels sont les coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ?
Une analyse des sites utilisant React, Vue.js ou Angular

Le , par Michael Guilloux

235PARTAGES

15  0 
Quels sont les coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ? Cette question a certainement plusieurs fois été abordée, et dans la plupart des cas, les avis les plus partagés semblent pointer du doigt les frameworks JavaScript comme étant responsables de la lenteur des sites Web. Il est en effet fréquent d'entendre que les performances du Web auraient baissé ces dernières années à cause de l’avènement des frameworks Web, comme React et Vue.js, et les applications Web monopage ou SPA (single-page application) qui privilégient les développeurs à l’expérience utilisateur.

S'invitant dans le débat, Tim Kadlec, un développeur qui aide les organisations à améliorer les performances de leurs sites, estime pour sa part qu'il n'y a « pas de moyen plus rapide de ralentir un site que d'utiliser un tas de JavaScript », et c'est justement ce que font les frameworks JavaScript : utilisez beaucoup plus de JavaScript. Mais « le truc avec JavaScript », poursuit-il, « c'est que vous finissez par payer une taxe sur les performances pas moins de quatre fois », dit-il. Les quatre taxes auxquelles il fait allusion sont :

  • le coût de téléchargement du fichier sur le réseau ;
  • le coût de l'analyse et de la compilation du fichier non compressé une fois téléchargé ;
  • le coût d'exécution du JavaScript ; et
  • le coût de la mémoire.

« La combinaison [de ces quatre taxes] est très coûteuse. Et nous utilisons de plus en plus de JavaScript sur le Net. Nous rendons les fonctionnalités de base de nos sites de plus en plus dépendantes de JavaScript à mesure que les organisations évoluent vers des sites propulsés par des frameworks tels que React, Vue.js et al », dit-il. Ce ne sont toutefois pas des propos non fondés puisqu'il le montre en se basant sur une analyse effectuée grâce aux données du site HTTP Archive.

HTTP Archive suit plus de 4 millions d'URL de bureau et plus de 5 millions d'URL mobiles. Parmi les nombreux points de données collectés par HTTP Archive, on peut citer la liste des technologies détectées pour chaque site suivi. Cela signifie que vous pouvez sélectionner des milliers de sites utilisant divers frameworks et voir la taille de code JavaScript qu'ils transmettent et ce que cela coûte au processeur ; ce à quoi Tim Kadlec s'est intéressé.

Il a décidé de comparer les données agrégées de HTTP Archive pour l'ensemble des sites Web enregistrés et les comparer aux données spécifiques aux sites utilisant React, Vue.js et Angular. Il a aussi ajouté jQuery, qui reste une bibliothèque très populaire et qui représente également une approche de développement JavaScript différente de l'approche SPA fournie par React, Vue.js et Angular.


Nombre d'URL suivies par HTTP Archive pour lesquelles les frameworks ciblés ont été détectés

Pour Tim Kadlec, dans un monde idéal, un framework ne devrait pas se concentrer sur l'expérience développeur uniquement, mais fournir une bonne expérience aux personnes utilisant leurs sites. Ils ne devraient donc pas négliger la performance qui est un élément essentiel, ce pour quoi M. Kadlec a voulu regarder le temps de démarrage/chargement des sites Web, mais aussi le temps de traitement du code JavaScript de ces sites.

Taille du code JavaScript servi sur les appareils mobiles et desktop

Pour analyser le temps de démarrage des sites Web, Tim Kadlec a trouvé logique de regarder la quantité de JavaScript transmise sur le réseau.


Quantité de JavaScript servi sur les appareils mobiles


Quantité de JavaScript servi sur les appareils desktop

Si l'un de ces frameworks est utilisé, il y a sans surprise plus de JavaScript, même dans les situations idéales. Vous ne pouvez pas en effet utiliser un framework JavaScript et vous attendre à charger moins de JavaScript dès le départ. Ce qui est remarquable cependant, c'est la différence entre les frameworks. Les sites avec jQuery sont les meilleurs du lot sur les appareils de bureau et sur mobile. Viennent ensuite les sites utilisant Vue.js et React. Les sites avec Angular sont les pires du groupe.

Temps de travail du thread principal

Il ressort clairement des données de HTTP Archive que les sites dotés de ces frameworks ont tendance à payer une lourde pénalité en termes d'octets JavaScript transmis sur le réseau. Mais ce n'est qu'une partie de l'équation. Une fois que le code JavaScript est chargé, il doit se mettre au travail, et tout travail qui se produit sur le thread principal du navigateur est particulièrement crucial. Le thread principal est en effet responsable de la gestion des entrées utilisateur et de la mise en page, entre autres. Si nous le surchargeons avec beaucoup de travail, le thread principal n'a aucune chance de faire ces choses dans de bons délais, ce qui entraîne donc des retards.

Comme HTTP Archive enregistre le temps de travail du thread principal de V8, Tim Kadlec a pu interroger le site pour voir pendant combien de temps ce thread principal travaille sur le code JavaScript chargé.


Temps de traitement CPU (en millisecondes) des scripts pour les appareils mobiles


Temps de traitement CPU (en millisecondes) des scripts pour les appareils desktop

Le constat est que pour les sites sur lesquels jQuery a été détecté, le temps de traitement du code JavaScript est beaucoup plus court que pour les trois autres frameworks analysés. Les frameworks Angular et React sont encore à la queue. La seule différence est que même si les sites Angular ont chargé plus de JavaScript que les sites React, en termes de temps de traitement, ils utilisent beaucoup moins le processeur.

Tim Kadlec a refait son analyse en ne considérant que des URL pour lesquels un seul framework (React, jQuery, Angular ou Vue.js) était détecté. Sans surprise, quand un seul framework est utilisé, les performances s'améliorent beaucoup plus souvent. Il estime que c'est bien logique : un site bien construit avec un seul framework devrait être plus performant qu'un site bien construit avec deux frameworks ou plus.


Temps de traitement CPU des scripts (en millisecondes) pour les appareils mobiles où un seul des frameworks est détecté

Notre analyste insiste toutefois sur un fait : le fait que les sites utilisant React ou Angular enregistrent un temps de traitement CPU plus élevé que les autres ne veut pas nécessairement dire qu'ils sont plus gourmands en ressources CPU que Vue.js. Cela en dit très peu sur la performance des frameworks de base, mais beaucoup plus sur l'approche de développement encouragée par ces frameworks (intentionnellement ou non).

L'écart mobile vs bureau

Tim Kadlec voulait aussi savoir s'il y avait un grand écart entre l'expérience mobile et l'expérience de bureau. En analysant les données du point de vue des octets JavaScript transmis sur le réseau au démarrage, il n'a constaté aucune différence significative. Mais en ce qui concerne le temps de traitement, l'écart est important au détriment des appareils mobiles. « Bien qu'une certaine différence soit attendue entre mobile et desktop, le fait de constater un écart important nous indique que ces frameworks ne font pas assez pour prioriser les appareils moins puissants et aider à combler cet écart », dit-il.

Ce qu'il est important de retenir, c'est que jQuery se comporte aussi bien que l'ensemble des sites. Mais lorsqu'on passe aux frameworks JavaScript, en particulier Angular, Vue.js et React, il y a un lourd tribut à payer en termes de performance.

Source : Tim Kadlec

Et vous ?

Quel est votre avis sur le sujet ?
Les frameworks JavaScript, un mal nécessaire pour le développement Web ?
Ou le problème serait-il plutôt JavaScript lui-même ou les développeurs ?
Si le problème vient de JavaScript lui-même, par quel langage faut-il le remplacer, quand cela est possible, pour avoir des sites Web plus rapides ?

Voir aussi :

Les frameworks Web détruisent-ils vraiment les performances du Web ou l'expérience utilisateur ? Ils placeraient la satisfaction des développeurs au-dessus des utilisateurs
Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui selon un expert
Google veut financer le développement de fonctionnalités liées aux performances dans les frameworks JavaScript à hauteur de 200 000 USD

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Alexandre T
Membre chevronné https://www.developpez.com
Le 29/05/2020 à 22:49
En 1990, j'attendais devant une page blanche que mon modem se connecte et qu'il charge la page HTML.
En 2000, j'attendais devant une page presque blanche que tout le tableau HTML soit chargé pour qu'il apparaisse (vous vous souvenez de cette manie de mettre toute la page dans une balise <table> pour gérer les menus latéraux ?)
En 2010, j'attendais devant une page blanche que les librairies jQuery & cie se chargent
En 2020, j'attends devant une page blanche que le framework Vue/React/Angular se charge, puis devant un joli "spinning-icon" que le backend répondent au Front-end.

8  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 20/05/2020 à 12:09
C'est délicat de comparer des applicatifs utilisant jquery à des applicatifs utilisant angular/react (vue ca peut encore passer). Ce n'est en général pas la même chose.

Concernant angular les résultats sont sans doute un peu biaisés puisque les dernières versions ont apporté beaucoup d'améliorations sur la taille des applicatifs. Pas certains qu'un majorité des url testées soient en version 9.

Et oui effectivement quand on utilise un framework on rajoute de la complexité et donc du poids à une application , mais c'est vrai dans tous les langages.
6  2 
Avatar de sboudes
Futur Membre du Club https://www.developpez.com
Le 20/05/2020 à 14:11
Je trouve le contenu du billet de Tim Kadlec bien trop réducteur. Il est donné ici l'impression que seul le premier chargement de page compte sur l'expérience client. Même si cela compte, c'est clairement pas suffisant.

Je suis assez vieux dans le métier pour avoir vécu la bascule de beaucoup de sites d'un mode server side vers un mode client side. Certes le premier chargement est long car lié à la récupération de ressources statiques et l'exécution des JS. Mais le reste de la navigation est bien plus fluide. C'était un objectif majeur de cette bascule :
* éviter l'effet page blanche lorsqu'une page devait récupérer dans le SI des données qui mettaient du temps à venir.
* Paralléliser le chargement des différents blocs HTML pour éviter que la page n'attendent que toutes les données du SI soient récupérer avant d'afficher quelque chose, ...

Au final, pas sur que les SPA consomment plus que des applis server side. entre chaque page, seules les éléments qui ont changés sont récupérer alors que sur du server side, on récupère le contenu entier.

Est ce qu'il ne faudrait pas plutot chercher le coupable sur l'ergonomie des sites. SPA a justement fait apparaitre de nouvelles façons de naviguer plus rapidement et d'afficher du contenu au fil de l'eau (voir à quoi sert le page speed index). Cette facilité a entrainé, je crois, une augmentation terrible du nombre d'infos qu'on cherche à afficher au sein d'une page dont notamment plein de jolies images bien lourdes qui ralentissent automatiquement le chargement
6  2 
Avatar de erwan21a
Membre à l'essai https://www.developpez.com
Le 20/05/2020 à 17:39
Il est improbable de comparer des sites utilisant React/Vue/Angular avec ceux utilisant JQuery sans prendre en compte leurs contextes ?
C'est comme comparer un camion et une moto, aucun n'est intrinsèquement mieux que l'autre, ce n'est juste pas du tout le même usage.

On peut aujourd'hui supposer qu'un site utilisant uniquement JQuery/Vanilla a un cœur de métier privilégiant le back-office. Donc forcément l'investissement n'est pas placé au même endroit que pour une site nécessitant un socle front solide en terme d'UX/UI.

De plus, le ressentie de vélocité pour l'utilisateur final n'est peut-être pas du tout corrélé avec la technologie Javascript utilisé.
Un site React/Vue/Angular peut être lourd au premier chargement et consommateur de CPU par la suite mais proposer une UX bien orchestrée et s'appuyer sur un back-office simplement efficace.
A contrario un site JQuery/Vanilla peut avoir chargement de ressources front léger tout en semblant lourd en raison d'une UX succincte et de requêtes longues en raison d'un back-office trop complexe.

Bref, sans contexte, les statistiques citées sont tout simplement aberrantes.
7  3 
Avatar de xhe11662
Membre du Club https://www.developpez.com
Le 20/05/2020 à 22:31
Citation Envoyé par blasted Voir le message
React et Vue sont bien des frameworks.
Bon, je viens de voir que le site de Vue.js ce declare etre un "progressiv framework" ... donc ca va etre difficile de défendre mon point de vue ^^'

Selon moi JQuery à permis d'accélérer dans manquements au standard et de mettre a plat les disparités entre browser :
- la standardisation des selector standardisé en querySelector,
- la notion de promesse avec leurs .done()/.fail() standardisé en .then()/.catch() de Promise
- le $.ajax standardisé en fetch()
et j'en oublie.

Et je vois chez Vue une démarche similaire qui est:
- Unifier la création d'un composant (car l'API CustomElement n'est hélas pas encore 100% supportée)
- Rendre ce composant réactif (c'est a dire, en gros, garder le JS(model) et le HTML(vue) synchrone)
Et c'est tout... pas de validation de formulaire, pas de fetch, pas de routage, pas de TS forcé, pas de syntaxe JSX/TSX a apprendre.

J'ai déjà fait dans plusieurs sites pro sans buildflow en Vue (pas de TS / NPM / Sass / Node / Cancer.js ...)
Et ca a tres bien marché et ca marchera dans 15 ans (on ne peu pas en dire autant des projets angular impossible a recompiler du premier coup 2 ans plus tard).

Bref tout ca pour dire que les 2 jouent dans la catégorie "boites a outils" :

Code : Sélectionner tout
1
2
3
4
5
6
7
<script src="https://unpkg.com/vue@2"></script>
Vue:<button id=a @click=i++>{{i}}</button>
<script>new Vue({el:'#a',data:{i:0}})</script>
 
<script src="https://unpkg.com/jquery"></script>
Jquery:<button id=b>0</button>
<script>$('#b').click(ev => $(ev.target).text(++j));j=0</script>
3  0 
Avatar de admadama
Membre à l'essai https://www.developpez.com
Le 21/05/2020 à 0:55
Faudrait aussi qu'il fasse un benchmark des système de templating server side.

La compilation des templates twig par exemple, pour un peu qu'on utilise ses features (include, macros, blocks, extensions) couplé à un ORM (coucou doctrine) est aussi assez violent, cette fois pour le système de fichier et le CPU du serveur.

L'argument développé plus haut est vrai, l'approche stateless a elle aussi un coût: booter un kernel de framework backend avec sa flopée de composant à chaque requête n'est pas gratuit.

Je veux bien me passer de React mais il va falloir me donner une alternative qui me permette de proposer aux utilisateurs une UX décente avec un code aussi clean. Vanilla JS c'est bien joli mais ça peut vite devenir une galère à maintenir.
3  0 
Avatar de fodger
Membre habitué https://www.developpez.com
Le 25/05/2020 à 15:47
L'énergie déployée pour faire de malheureux boutons me semble parfois surréaliste.

A l'heure où le secteur se doit de mieux exploiter les machines pour réduire son empreinte énergénique, il convient de veiller au ratio coût / services rendus de chaque lib, framework, pseudo-framework ...

D'ailleurs très souvent les sites, services web sont difficilement exploitables sur mobile, tablettes ou petits micros : quand ce n'est pas le chargement distant de la lib qui fout la merde, c'est la sur utilisation du JS qui prend le relais.
3  0 
Avatar de xhe11662
Membre du Club https://www.developpez.com
Le 20/05/2020 à 12:48
à cause de l’avènement des frameworks Web, comme React et Vue.js
Dommage, react et vue ne sont pas de framework mais des lib ...
Au même titre que jquery d’ailleurs : ce sont juste des boites a outils qui ne cadre en rien la structurations du projet.
2  0 
Avatar de marc.collin
Membre éprouvé https://www.developpez.com
Le 21/05/2020 à 0:17
Citation Envoyé par sboudes Voir le message
Au final, pas sur que les SPA consomment plus que des applis server side. entre chaque page, seules les éléments qui ont changés sont récupérer alors que sur du server side, on récupère le contenu entier.
tu peux très bien avec par exemple thymeleaf découpé tes pages en fragment... et faire un appel serveur pour en chercher un...
2  0 
Avatar de eagle777
Candidat au Club https://www.developpez.com
Le 01/06/2020 à 22:17
La machine est un outils , son objectif est de permettre à l'homme d'augmenter son confort ou sa commodité de vie .
Ici nous avons trois acteurs le client , le développeur et la machine. Moi en tant que développeur je n'accepterais jamais de diminuer mon confort de développement
pour que la machine soit alaise désolé .
On ne développe par pour des machines mais pour des hommes , l'informatique c'est pas pour les machines c'est pour les hommes.
Donc si mon application ou mon site est facile à manipuler par l'utilisateur et que j'ai pris moins de temps et plus de plaisir à développer grâce à vuejs/Angular/React,
je ne vois pas où est le problème ?
Si le serveur dois travailler plus et bien qu'il travaille plus, de toute façon c'est lui l' outils et un serveur c'est fait pour ça :chauffer.
Nous ne sommes plus en 80-90 ou les ressources était insuffisantes donc il fallait les gérer. Maintenant la ressource ce n'est plus le problème.
En réalité la plupart des critiqueurs des framework java-script sont les développeur séniors qui n'ont pas effectués correctement leur transitions technologiques .
Beaucoup ont du mal a accepter que ce qui était si difficile et fastidieux à leur temps est aussi facile et accessible avec les nouveaux paradigmes aujourd'hui.
Alors pour se consoler il cherchent la petite bête dans toutes les nouvelles technos avec des argument qui ne sont pas concrets.
LA MACHINE RESTE LA MACHINE .
3  1