Discussion :

[Bill Fassinou]

Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui
selon un expert

JavaScript a fortement contribué à développer le Web 2.0 que ça soit à travers les technologies Ajax, Angular et bien d’autres. Il se développe très rapidement et a permis de mettre sur pied des applications avec des performances remarquables. Il a également induit le développement très accéléré de rich Internet application (RIA). Une RIA ou application Internet riche, est une application Web qui offre des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. La dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces applications web. Elles comportent la plupart du temps des annonces publicitaires et des trackers par exemple, la majorité basée sur des scripts JavaScript de tierce partie.

Le code de première partie est ce que vous écrivez vous-même. Celui de tiers est un code menant vers une ressource extérieure écrit et hébergé par le fournisseur de cette ressource. Un bouton ‘’LIKE’’ de Facebook sur votre site par exemple. En octobre 2000, le poids moyen d’une page web était de 89 Ko (images et scripts compris). En 2015, le poids moyen arrivait déjà à 2,6 Mo, soit une multiplication par trente en quinze ans. Le nombre de requêtes a quant à lui été multiplié par 10. La course aux KPI (un acronyme pour Key Performance Indicator traduit en français par indicateur clé de performance) nous a amené à installer toute sorte de traqueurs et widgets, ce qui dégrade fortement les performances. Les Indicateurs clés de performance sont des indicateurs mesurables d’aide décisionnelle. Ils s’inscrivent dans une démarche de progrès et permettent le pilotage et le suivi de l’activité. Ils sont “reportés” et analysés sur une base hebdomadaire, mensuelle ou trimestrielle.

Notre usage du web quant à lui, est de plus en plus mobile. Les connexions sont donc moins stables (elles sont soumises à la qualité du réseau et de notre situation géographique). Les exigences des internautes sont-elles de plus en plus élevées ? Après 3 secondes d’attente, 57 % des internautes quittent un site et 80 % d’entre eux n’y reviendront jamais. Depuis 2011, la vitesse de croissance de requête JavaScript de première et tierce partie a connu une forte augmentation. Bien que les spécialistes du web imputent la lenteur des sites web au code JavaScript et principalement à celui de tierce partie, l’usage du JavaScript a quand-même augmenté d’environ 50 % pour la première partie et presque 140 % pour la tierce partie.

Steve Souders, qui travaille chez SpeedCurve sur l’interaction entre la performance et le design, s’est basé sur la requête du nombre de médian de demande JS par les 1ère et tierce parties depuis 2010 pour tirer certaines conclusions. Sur l’image ci-dessous, on peut constater qu'en termes de nombre de requêtes JavaScript, la première partie a augmenté de 50 %, passant de 4 à 6 requêtes, tandis que la tierce partie a augmenté de 140 %, passant de 5 à 12 requêtes. La croissance de codes JS de terce partie en termes de taille de JavaScript est plus alarmante. Le code JavaScript de la première partie a doublé, passant de 53 ko à 106 ko. Le code JavaScript de tierce partie est octuplé de 32 Ko à 258 Ko.
En regardant la quantité de code JavaScript utilisée aujourd'hui, les codes JS de tierces parties sont responsables de deux fois plus de demandes (12 contre 6) et environ deux fois et demie plus de kilo-octets (258 Ko contre 106 Ko).

Le code JavaScript de tierce partie apporte plus d’interactions avec le client et lui permet d’avoir une expérience enrichie. Il permet de charger des ressources externes et passe donc par un nom de domaine différent à celui de votre site, ce qui entraînera souvent une résolution DNS, suivie de l’établissement d’une nouvelle connexion TCP. On peut se poser la question de la localisation du serveur fournissant la ressource : si ce dernier ne s'appuie pas sur un CDN (Content Delivery Network), vos internautes peuvent être confrontés à une latence importante (délai minimum pour la transmission des données entre l’internaute et le serveur, due à la distance les séparant). Quand vous avez un public national sur un site web ce problème ne se pose pas pour vos propres ressources. Il est cependant fréquent d’utiliser de code JS de fournisseurs étrangers, et donc de faire face à cette contrainte.

Si la requête utilise du HTTPS, alors vous allez encore rajouter un délai supplémentaire, puisque ce protocole implique des échanges additionnels pour établir la connexion sécurisée. Enfin, vous serez dépendant du temps de réponse du serveur du parti tiers, ainsi que de son débit sortant. Sur la base des statistiques précédentes, Steve Souders estime qu’effectivement le JavaScript de tierce partie est une partie importante des sites web actuels. Il propose cependant, pour surveiller l’utilisation de code code JS de tierce partie sur votre site, qu’il vous faut impérativement configurer ce qu’on appelle des ‘’budgets de performance’’. Un budget de performance consiste à définir le seuil de performance que l’on ne souhaite pas dépasser. Il s’exprime en métrique poids des pages ou encore nombre de fichiers. Ce budget de performance va ainsi permettre de maintenir un site rapide et de détecter toutes régressions. Ainsi, un constructeur de site web s’assure de ne jamais oublier ce critère de performance et d’en faire un point de vigilance majeur.

Certains internautes ne comprennent pas pourquoi on accuse le langage d’être à l’origine de la lenteur des pages web. Ils estiment que ce n’est en rien la faute du langage et qu’il y a longtemps nous même avons décidé que les documents et les liens simples ne suffisaient plus. Nous voulions des applications web riches avec d’énormes images ainsi qu’un nombre de milliards d’annonces. Pourquoi est-ce maintenant la faute à JS ? S’interrogent-ils. Ils recommandent d’optimiser les sites web pour la mise en cache lors de première visite pour rendre le site rapide les prochaines fois. Un autre, toujours pour défendre JS, rejette la faute sur les entreprises de marketing et les médias et leurs logiciels qui sont souvent insérés dans les pages web pour faire de la publicité.

Source : Billet de blog

Et vous ?

Qu'en pensez-vous ?
Selon vous, le langage JS devrait-il être tenu responsable de la lenteur des sites Web ? Pourquoi ?

Voir aussi

The State Of JavaScript 2018 : l'enquête révèle que JavaScript est en pleine évolution, voici une vue macro des technologies JS utilisées

Les tendances dans les métiers de la technologie en France en 2017, une enquête réalisée par CodinGame

The State Of JavaScript : participez à l'édition 2018 de l'enquête qui permet d'avoir une vue macro des technologies utilisées dans le monde JS

Mithril : un framework JavaScript moderne, simple, rapide et léger comparé à React ou Angular pour ceux qui privilégient la facilité d'intégration

[SpaceFrog]

Cela démontre juste que les mauvaise pratiques de développement web prennent le dessus avec l'abus de frameworks et autre fioritures.
De plus en plus les développeurs empilent des frameworks et des plugins par méconnaissances ou sois-disant gains de temps de développement.
Il en résulte des appels grossissant et redondants à des scripts externes ou a de grosses librairies dont les fonctions sont dans la majorité des cas à peine utilisées à 5% dans le site.
Certains travaillent désormais sur des bibliothèques javascript présentant la possibilité de n'embarquer que le strict nécessaire...

[Cincinnatus]

La dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces applications web. Elles comportent la plupart du temps des annonces publicitaires et des trackers par exemple, la majorité basée sur des scripts JavaScript de tierce partie.

Ces deux phrases me semblent contradictoires. La vitesse d'exécution est forcément réduite par les publicités et trackers.

Par ailleurs, un article (de 2016) pointe la taille démesurée de librairies Javascript : https://medium.com/s/silicon-satire/...t-b89f63d21558
En particulier le fait que :
- Express nécessite l'installation de 291 modules node.js, notamment l'un qui "like" un compte twitter publicitaire à chaque téléchargement,
- Ember.js inclut dans un sous-module l'Encyclopedia Brittanica...
- Babel charge un fichier image sans utilité...

[xarkam]

Cela démontre juste que les mauvaise pratiques de développement web prennent le dessus avec l'abus de frameworks et autre fioritures.
De plus en plus les développeurs empilent des frameworks et des plugins par méconnaissances ou sois-disant gains de temps de développement.
Il en résulte des appels grossissant et redondants à des scripts externes ou a de grosses librairies dont les fonctions sont dans la majorité des cas à peine utilisées à 5% dans le site.

C'est plus fin que cela. C'est aussi lié aux temps de développement défini par les responsables.
Pour être concurrentiel, il faut produire vite et bien. C'est donc plus simple de prendre un truc qui embarque tout quitte à effectivement n'en utiliser qu'une infime partie.


Il faut livrer le produit au plus vite pour prendre l'argent et passer au suivant.

C'est rare d'avoir des entreprises qui ont compris que le développement c'est un peu comme de l’orfèvrerie, ca demande du temps et de la technicité pour bien faire les choses.

[Sodium]

Cela démontre juste que les mauvaise pratiques de développement web prennent le dessus avec l'abus de frameworks et autre fioritures.

Il n'est actuellement pas envisageable de faire du JavaScript à un niveau professionnel sans utiliser de Framework.
Certains prétendent y arriver : ils sont incompétents.

[Eric80]

je ne suis pas expert du dev web, mais en tant qu utilisateur, j ai l impression que le Web est gangrené par les scripts publicitaires (on est envahi par la pub!), de social media (liens Fb, Twitter and co sur chq page), et parfois aussi de scripts d analyses (GoogleAnalytics partout).
Cad que les pages web sont d abord ralentis par ce qui est autour du réel contenu.
AMHA, les choix technologiques (langage des scripts, framework utilisés, impact du développement) ont finalement peu d'impact face à ce "sur contenu".

J utilise depuis tjs des plugins ad-blocker et limiteurs de scripts sur mes navigateurs, et qd je dois naviguer sans, c est vraiment peu agréable.

[SpaceFrog]

@Sodium: Un jugement à l'emporte-pièces.
Je connais de nombreux professionnels qui se sont montés leur propre framework modulaire qui n'embarque que le strict minimum nécessaire en fonction du site.

C'est en effet la solution de facilité pour de nombreux développeurs à l'heure actuelle que de s'en remettre aux frameworks disponibles afin de répondre aux exigences immédiates imposées par la hiérarchie ou la compétitivité.
Chaque framewok ayant sa propre orientation, on en arrive même parfois à des utilisations combinées de plusieurs frameworks afin de couvrir tous les besoins...

Je suis souvent attristé de voir les annonces des offres d'emploi qui exigent des connaissances sur tel ou tel framework parfois exotique...

[Sodium]

@Sodium: Un jugement à l'emporte-pièces.
Je connais de nombreux professionnels qui se sont montés leur propre framework modulaire qui n'embarque que le strict minimum nécessaire en fonction du site.

J'en connais aussi beaucoup. Des gens parfaitement incompétents qui ont choisit de refaire ce qui existait déjà en moins propre, moins efficace, moins fiable et n'offrant que peu de perspective d'avenir puisqu'ils acquièrent une expertise sur un système propriétaire qui ne leur servira jamais à rien ailleurs.

C'est en effet la solution de facilité pour de nombreux développeurs à l'heure actuelle que de s'en remettre aux frameworks disponibles afin de répondre aux exigences immédiates imposées par la hiérarchie ou la compétitivité.

Ne pas confondre solution de facilité et solution raisonnée.
Un framework (un vrai, comme Symfony ou Angular, pas comme cette merde de ReactJS) permet de répondre à un besoin partagé par le plus grand nombre tout en forçant à une certaine rigueur et uniformité au sein d'une équipe, ce qui permet d'intégrer plus facilement de nouveaux arrivants tout en permettant de conserver plus facilement un code maintenable sur la durée.

[Vaidormir]

React.js ?

[Shepard]

Il n'est actuellement pas envisageable de faire du JavaScript à un niveau professionnel sans utiliser de Framework.
Certains prétendent y arriver : ils sont incompétents.

JavaScript est un bon langage, c'est un peu pénible cette croyance selon laquelle il est tellement pourri qu'on ne peut rien faire de bien sans utiliser de framework ...

Arrêtez de dire que JavaScript c'est de la merde, c'est vraiment énervant.

Merci ...

[SpaceFrog]

un vrai, comme Symfony ou Angular

Là pour le coup on est en plein dans ce qui est dénoncé en particulier pour angular qui n'est qu'une surcouche pour porter l'architecture 3/3 en Javascript.

[micka132]

RIP Flash...
C'est toujours les meilleurs qui partent en premier .

[Sodium]

JavaScript est un bon langage, c'est un peu pénible cette croyance selon laquelle il est tellement pourri qu'on ne peut rien faire de bien sans utiliser de framework ...

Arrêtez de dire que JavaScript c'est de la merde, c'est vraiment énervant.

Merci ...

On en a déjà assez débattu sur ce fil : non, JavaScript n'est pas un bon langage. C'est même tout le contraire d'un bon langage, et c'est pourquoi il existe autant de frameworks et de librairies pour combler ses manques et essayer de standardiser un minimum son usage.

Là pour le coup on est en plein dans ce qui est dénoncé en particulier pour angular qui n'est qu'une surcouche pour porter l'architecture 3/3 en Javascript.

On ne peut absolument pas parler de surcouche pour Angular, c'est un framework complet et une façon totalement différente (et meilleure) de travailler.

[walfrat]

L'article à oublier un point essentiel quand à l'évolution du Javascript : l'évolution des applications en pages ou le Javascript était dispersé ici et là et l'apparition aussi des SPA.

Beaucoup des "gros frameworks" actuels sont parfaitement compensés de part le fait qu'ils permettent la construction de ce type de site, oui le premier chargement est forcément un peu lent, le reste en revanche que du dit framework dépend bien plus de la compétence des développeurs du projet (et de l'organisation, les délais tout ça tout ça) que du dit framework.
Il est clair que si a chaque page PHP de developpez.net on rechargerai l'entièreté d’Angular ou un autre framework ce serait un problème, mais il viendrait pas d'Angular en soi mais des personnes qui ont fait les choix.

S'il y a une seule chose que je peux reprocher parfois aux framework, c'est d'être parfois tellement bon que des personnes qui comprenne pas la moitié des choix techniques qu'ils font appliques arrive à faire quelque chose qui "marche" "rapidement" (le temps de réalisation hein, pas l'autre) et parfois de nous contraindre à leur niveau.

[imperio]

J'en connais aussi beaucoup. Des gens parfaitement incompétents qui ont choisit de refaire ce qui existait déjà en moins propre, moins efficace, moins fiable et n'offrant que peu de perspective d'avenir puisqu'ils acquièrent une expertise sur un système propriétaire qui ne leur servira jamais à rien ailleurs.

Je présume donc que les créateurs de Angular, EmberJS, ReactJS et autres frameworks correspondent à cette description. Ou alors on a affaire au troll du mois ?

Ne pas confondre solution de facilité et solution raisonnée.
Un framework (un vrai, comme Symfony ou Angular, pas comme cette merde de ReactJS) permet de répondre à un besoin partagé par le plus grand nombre tout en forçant à une certaine rigueur et uniformité au sein d'une équipe, ce qui permet d'intégrer plus facilement de nouveaux arrivants tout en permettant de conserver plus facilement un code maintenable sur la durée.

Je vais faire une citation plus précise :

Un framework (un vrai, comme Symfony ou Angular, pas comme cette merde de ReactJS)

Oui c'est bien le troll du mois. C'est bien la première fois que j'entends quelqu'un dire du bien de Angular. Comme quoi... La vérité sort de la bouche des trolls !

[Sodium]

Je présume donc que les créateurs de Angular, EmberJS, ReactJS et autres frameworks correspondent à cette description. Ou alors on a affaire au troll du mois ?

Je ne vois pas comment tu peux comparer des individus et de grande équipes venant de Facebook ou Google.

Oui c'est bien le troll du mois. C'est bien la première fois que j'entends quelqu'un dire du bien de Angular. Comme quoi... La vérité sort de la bouche des trolls !

C'est marrant, pratiquement toutes les vidéos ou post de blogs comparant Angluar à React que j'ai consultés aboutissent plus ou moins à la même conclusion : si l'on veut un code propre et maintenable, une uniformité dans le travail d'équipe et un framework répondant à la majorité des besoins out of the box, Angular est le grand gagnant.

Ils émettent régulièrement des réserves sur l'utilisation de TypeScript en admettant qu'il est bien meilleur que JavaScript mais qu'il faut un petit peu de temps pour se former dessus... sauf que pour quelqu'un qui a fait du JavaScript et un autre langage comme Java ou C++, ça peut être bouclé en moins d'une heure.

[Mograine]

Ces deux phrases me semblent contradictoires. La vitesse d'exécution est forcément réduite par les publicités et trackers.

Par ailleurs, un article (de 2016) pointe la taille démesurée de librairies Javascript : https://medium.com/s/silicon-satire/...t-b89f63d21558
En particulier le fait que :
- Express nécessite l'installation de 291 modules node.js, notamment l'un qui "like" un compte twitter publicitaire à chaque téléchargement,
- Ember.js inclut dans un sous-module l'Encyclopedia Brittanica...
- Babel charge un fichier image sans utilité...

Juste pour info, cet article est un troll pour ouvrir les yeux des développeurs quant au fait qu'ils ne savent absolument pas ce qui se passe dans les modules qu'ils importent, ces trois points sont totalement faux

Sinon concernant l'article : "multiplication (du poid de JS) par trente en quinze ans", sachant qu'on est passé du 56k au 20mo (et je ne prend même pas en compte la fibre pas assez généralisée), c'est une multiplication par 350 des débits moyens, et je vous épargne le % de progression concernant les performances des processeurs, il faut donc relativiser les chiffres qui sont ici présentés

Cela dit, le JS déroule exactement le même tracé que le PHP avec un simple décalage temporel : Un mauvais langage développé trop rapidement, mais qui massivement adopté s’enrichit donc petit à petit et finira par devenir bon. PHP a déjà passé ce cap, principalement avec l'arrivée des classes en 5.x et les nombreuses améliorations de la 7.x (même si sa réputation et le fait que de nombreux débutants commencent avec lui font que d'un point de vue extérieur cela n'en donne pas l'impression), JS y arrivera aussi, même si étant coté client la bascule prendra plus de temps.

[Lcf.vs]

Je vous invite à tester mon anticore

Aussi simple qu'un jQuery, entièrement modulaire (201 modules), au plus proche du natif, système AJAX unique et innovant, aucun module inutile dans votre dist, open source, déjà utilisé par plus de 36000 utilisateurs, malgré l'absence de site promotionnel, ...

Enjoy

[Kikuts]

@Sodium, tu as un avis bien tranché sur Angular/react, j'aimerai bien ton avis et qq liens qui vont dans le sens de ton argumentaire

(je préfère Angular à React mais j'avoue parfois manquer d'argument quand on me demande pourquoi )

[Sodium]

@Sodium, tu as un avis bien tranché sur Angular/react, j'aimerai bien ton avis et qq liens qui vont dans le sens de ton argumentaire

Pas le temps de chercher des sources là tout de suite, mais voilà ce qui m'a fait abandonner l'idée d'apprendre React, même s'il est plus populaire qu'Angular :

- Peu d'outils standards. À la différence d'Angular qui est un framework permettant de faire un projet de A à Z, React n'est qu'une librairie qui doit être complétée par des packages externes. Cela mène inévitablement à plus de problème de maintenabilité et si l'on engage 10 développeurs Reacts, on risque d'avoir 10 personnes habituées à utiliser des outils différents, ce qui est très mauvais pour la cohésion de l'équipe
- L'utilisation de JSX, un outil de templating (foireux) plutôt que d'enrichir le HTML existant
- React reste du simple JavaScript. L'utiliser avec du TypeScript ne doit pas être bien compliqué mais il n'a pas été prévu pour ça à la base, ce qui signifie qu'une majorité de la documentation sera en JavaScript. Et faire encore du JavaScript sur un projet de grande ampleur en 2018... ben juste non quoi. Ils sont bien gentils d'avoir ajouté des classes, mais JS a encore des années de retard avant de devenir un vrai langage fréquentable.