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...

[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.

[Mat.M]

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

je partage évidemment cet avis à 200% tout est dit et cette argumentaton je ne cesse de la tenir sur ce forum.
Bref plus on utilise des frameworks de manière abusive plus le risque est de construire des usines à gaz qui évidemment risquent de tourner au ralenti.

Logiquement un projet informatique ne devrait pas être dépendant de plus de 2-3 technos

L'intérêt principal des classes (ou des autres formes d'objet) est de séparer un code complexe en petits composants très simples et idéalement réutilisables.
.

c'est exact mais encore faut-il concevoir ces petits composants de manière efficiente c'est là la difficulté du design des objets.
Autrement on risque de produire du code "lasagne"

Tout cela mérite des discussions conceptuelles qui vont bien au delà de la question du sujet.
Le concept de classe est discutable en soi et son intuitivité tout autant

voui c'est bien pour ça que chacun a sa propre vision et conception des choses.
Si je te parle d'un objet en particulier tu ne le vois pas de la même manière que je le vois.
Et pour conceptualiser cet objet sous forme de code informatique et donc de données qui le décrivent il y aura quasiment autant d'appréciations de cet objet qu'il n'existe d'individus, histoire de compliquer les choses

[Sodium]

je partage évidemment cet avis à 200% tout est dit et cette argumentaton je ne cesse de la tenir sur ce forum.
Bref plus on utilise des frameworks de manière abusive plus le risque est de construire des usines à gaz qui évidemment risquent de tourner au ralenti.

Logiquement un projet informatique ne devrait pas être dépendant de plus de 2-3 technos

C'est super intéressant dis-moi ça, tu tiens ça d'où, la grande Bible des 100 chiffres à retenir en informatique ?

Quand on fait du web, on se retrouve à faire systématiquement face aux mêmes problématiques. Si on est un peu organisé, on va commencer à développer des librairies. Et si l'on est réellement organisé, on finira par regrouper ces librairies en un framework.

Alors, faire son propre framework, c'est très bien pour monter en compétence, mais on finira forcément par rencontrer l'un ou plusieurs des problèmes suivant :
- Mieux vaut avoir sacrément bien bossé la doc et la tenir à jour en permanence si l'on ne veut pas devenir la personne du bureau qui ne peut jamais prendre un congé parce qu'au moindre pépin, elle devra intervenir
- C'est beaucoup plus compliqué de recruter de nouveau collaborateurs et de les évaluer s'ils ne sont pas déjà formés à la techno utilisée dans l'entreprise
- Beaucoup de clients sont réticents à acheter du développement 100% maison car ils veulent pouvoir changer de prestataire si le besoin se fait sentir
- Et surtout, probablement le point le plus important, même une équipe de quelques génies ne pourra jamais faire un travail du niveau d'un projet open-source avec des milliers de contributeurs et quelques fois des gens de Google ou Facebook dessus

À la limite, la seule "bonne" raison de s'acharner a maintenir son propre truc, c'est que pour les employés de la boîte ne montent pas en compétence sur une techno qui améliorerait leur employabilité ailleurs

[Mat.M]

CAlors, faire son propre framework, c'est très bien pour monter en compétence

tu as raison cependant comme dans toute chose il y a des inconvénients ou des inconvénients ça c'est comme utiliser un ERP ou non...
Si tu utilises tel ou tel framework en particulier dans un projet le problème c'est que tu vas utiliser tout un ensemble de modules mais dont tu n'utiliseras qu'une partie sur la totalité.
Bref c'est selon et faut voir ça dépend des cas.
Mais avant d'utiliser un framework peut-être que quelques lignes de codes suffisent faut voir.

Maintenant je le répète ce n'est pas l'utilisation de frameworks qui confère forcément à un projet sa réussite contrairement à ce que beaucoup de personnes pensent.
Bref les frameworks ça ne fait pas tout.
Si la conception est bancale et mal faite eh bien le projet dans son entièreté sera bancal...

Heureusement que je ne suis pas une porte ouverte sinon j'aurais vraiment peur de me faire enfoncer.

mais bien sûr tout est évidence ! Et la majorité des membres de ce forum écrivent des lieux communs.

Et puisque tout coule de source et que tout est évident , pourquoi il y a des tas de projets informatiques souvent avec un gros budget qui patinent voire frise l'échec ?

[Invité]

tu as raison cependant comme dans toute chose il y a des inconvénients ou des inconvénients ça c'est comme utiliser un ERP ou non...
Si tu utilises tel ou tel framework en particulier dans un projet le problème c'est que tu vas utiliser tout un ensemble de modules mais dont tu n'utiliseras qu'une partie sur la totalité.
Bref c'est selon et faut voir ça dépend des cas.
Mais avant d'utiliser un framework peut-être que quelques lignes de codes suffisent faut voir.

Maintenant je le répète ce n'est pas l'utilisation de frameworks qui confère forcément à un projet sa réussite contrairement à ce que beaucoup de personnes pensent.
Bref les frameworks ça ne fait pas tout.
Si la conception est bancale et mal faite eh bien le projet dans son entièreté sera bancal...

Au temps pour moi, c'est vrai que ce sont là des informations totalement inédites. Mon cerveau est au bord de l'AVC face à cette masse d'informations originales.

[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é...

[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]

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

Je voulais tout de même réagir sur ce point : on s'en contrefiche, de l'augmentation de bande passante, de l'augmentation de puissance de calcul de nos appareils... ce n'est pas une raison valable pour ne pas optimiser ses sites et applications !

La raison ? la consommation électrique engendrée par tout cela, d'autant plus à notre époque, avec la multiplication des utilisateurs, des services tournant en continu et en temps réel, ... c'est juste criminel, de ne s'en soucier.

[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.

[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.

[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.

[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

[sirthie]

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.

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.

Donc, si je comprends bien, toute autre solution autre que déjà existante et éprouvée est une idiotie ? Heureusement qu'on n'a pas dit ça au(x) créateur(s) du premier framework.

[Sodium]

Donc, si je comprends bien, toute autre solution autre que déjà existante et éprouvée est une idiotie ? Heureusement qu'on n'a pas dit ça au(x) créateur(s) du premier framework.

Dans tous les domaines, il y a des centaines milliers de gens qui se prennent pour des génies qui vont révolutionner le monde. Une poignée d'entre eux ont raison. Les autres se vautreront pour la plupart lamentablement.
Quand on a plus de 10 ans d'expérience dans une techno, qu'on est reconnu comme expert (pas autoproclamé) et qu'on a identifié un problème ainsi qu'une manière élégante de le résoudre, ça vaut le coup de se lancer.
Si c'est pour refaire ce que font déjà des projets open source à plusieurs milliers de contributeurs ou produits par des ingénieurs de chez Google/Facebook/Microsoft en moins bien, juste pour le plaisir d'avoir SA techno, autant éviter de se tirer directement une balle dans le pied.

[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.