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 
Envoyé par Sodium
Mais tout va bien hein 