Discussion :

[Bill Fassinou]

Les sites Web ne sont pas beaucoup plus rapides qu'ils ne l'étaient il y a 10 ans malgré une augmentation de la vitesse d'Internet,
selon un rapport de HTTP Archive

Malgré une augmentation de la vitesse d'Internet, la vitesse des pages Web ne s'est pas améliorée avec le temps. C'est la conclusion d'un rapport de HTTP Archive qui a, au cours des 10 dernières années, enregistré les temps de chargement des pages pour 6 millions de sites Web populaires. Les résultats de cette enquête ne sont pas vraiment encourageants. Pour les pages Web visitées depuis un ordinateur de bureau, le temps de chargement médian ne s'est pas amélioré. Les sites Web d'aujourd'hui ne sont pas beaucoup plus rapides qu'ils ne l'étaient il y a 10 ans.

Vous vous demandez peut-être si les gens ne remarquent tout simplement pas à quel point les sites d'aujourd'hui sont plus rapides, car leurs attentes ont augmenté au fil du temps. S'il est vrai que les estimations des gens sur les temps d'attente sont parfois exagérées, dans ce cas, il ne s'agit pas seulement de perceptions déformées. Le temps de chargement médian des pages suivi par HTTP Archive est resté à peu près le même au cours des 10 dernières années, tandis que, au cours de la même période, la vitesse moyenne d'Internet pour les utilisateurs a régulièrement augmenté.

L'histoire sur mobile est encore pire - les vitesses de connexion se sont améliorées à coup sûr, mais, au cours des 10 dernières années, les temps de chargement des pages mobiles suivis par HTTP Archive ont en fait augmenté. L'augmentation de la vitesse d'Internet n'a manifestement pas résolu le problème de la lenteur des sites web. Bien sûr, la vitesse du réseau n'est pas le seul facteur qui influe sur les performances, il n'est donc pas raisonnable de s'attendre à ce que les vitesses aient complètement suivi le rythme de la connectivité du réseau. Mais il semble qu'une augmentation considérable de la vitesse du réseau devrait rendre la navigation sur le web au moins un peu plus rapide.

Les données de HTTP Archive ont été recueillies selon la même approche pendant toute la décennie, ce qui permet une comparaison longitudinale. Ces données suggèrent fortement que les sites web que les gens visitent aujourd'hui ne sont pas beaucoup plus rapides qu'il y a dix ans. Le rapport de HTTP Archive ne donne pas une idée précise des causes de cette lenteur. Toutefois, la manière dont les sites Web sont conçus pourrait bien en être pour quelque chose. En effet, 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és à 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.

Aussi, certains tiennent pour responsable JavaScript qui a fortement contribué à développer le Web 2.0 que ça soit à travers les technologies Ajax, Angular et bien d’autres. C'est le cas de Steve Souders, qui travaille chez SpeedCurve sur l’interaction entre la performance et le design. Il s’est basé sur la requête du nombre de médian de demande JS par les 1res et tierce parties depuis 2010 pour tirer certaines conclusions. 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 tierce 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.

Source : HTTP Archive

Et vous ?

Quel est votre avis sur le sujet ?
Êtes-vous ou pas du même avis que HTTP Archive ? Pourquoi ?
Selon vous, qu'est-ce qui justifie la lenteur des sites Web alors que la vitesse d'Internet ne cesse d'augmenter ?

Voir aussi

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

L'historique de JavaScript : Brendan Eich l'a écrit en seulement 10 jours et c'est ainsi qu'il a changé le monde pour toujours

Mozilla a décidé de procéder au licenciement d'environ 70 personnes et évoque la lenteur du déploiement des nouveaux produits générateurs de revenus

Le langage JavaScript devrait-il être renommé ? Oui, selon Kieran Potts, un développeur JavaScript qui souligne quelques ambiguïtés liées au nom actuel du langage

[Invité]

Malgré une augmentation de la vitesse d'Internet, la vitesse des pages Web ne s'est pas améliorée avec le temps.
...
L'histoire sur mobile est encore pire - les vitesses de connexion se sont améliorées à coup sûr, mais, au cours des 10 dernières années, les temps de chargement des pages mobiles suivis par HTTP Archive ont en fait augmenté.

Oui bon, on avait dit que ce serait rapide avec l'adsl et la 3G puis la 4G et ça n'a pas marché. Mais avec la fibre et la 5G, ce sera rapide, alors achetez-les...

Aussi, certains tiennent pour responsable JavaScript qui a fortement contribué à développer le Web 2.0 que ça soit à travers les technologies Ajax, Angular et bien d’autres. C'est le cas de Steve Souders, qui travaille chez SpeedCurve sur l’interaction entre la performance et le design. Il 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. 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.

C'est donc la faute au design en JavaScript ? Et les pubs, analytics, trackers, etc, ça ne ralentit pas ?

[transgohan]

C'est donc la faute au design en JavaScript ? Et les pubs, analytics, trackers, etc, ça ne ralentit pas ?

Je pense que c'est ce qui est derrière les "tierces parties".
Donc au contraire il est indiqué que cela a octuplé contre doublé pour les scripts internes.

[BugFactory]

Combien de fois avez vous obtenu un budget pour travailler sur les performances? Moi une seule fois en 16 ans. Là j'ai une base de données où il manque des indexes et ça ne gêne que moi. C'est pour ça et pas à cause d'une technologie quelconque que les sites sont lents.

[Anselme45]

Quand les voies de circulation d'une grande ville sont ralenties par les bouchons quotidiens, on peut doubler le nombre de voies de circulation. Les automobilistes voient une amélioration qui dure... 6 mois!

Après? Retour des bouchons!

Pourquoi? Parce que l'offre crée la demande!!!

Il en va de même pour "l'autoroute de l'information" nommée internet!

On peut ajouter de la 5G, de la 10G ou 20G... Ce sera toujours lent!

Pendant que l'on augmentait les capacités des réseaux, on a généralisé les services cloud: Le streaming vidéo (Netflix et autres), les jeux en lignes qui se transforment aujourd'hui en plateformes de jeux virtuelles, les logiciels pro (style ERP, CRM, compta et autre) qui deviennent des services en ligne, etc...

Et on ne parle pas bien sûr du web transformé en poubelle avec tous les couillons qui se voient obligé de faire une chaîne Youtube pour présenter leur état d'âme et présenter tous les aspects de leur vie: de leur poisson rouge qui fait une dépression au premier rôt du petit dernier!

[PomFritz]

C'est pas très constructif, mais je me marre Le dév web, ça part dans tous les sens. Une usine à gaz éparpillée et non structurée. Des couches, des appels externes, des interpréteurs, de partout. C'est difficile d'avoir la même techno qui réponde, à la fois, aux amateurs et aux exigences des pros. On traine un historique, où on voulait une techno accessible par chacun.

[Zefling]

C'est pas très constructif, mais je me marre Le dév web, ça part dans tous les sens. Une usine à gaz éparpillée et non structurée. Des couches, des appels externes, des interpréteurs, de partout. C'est difficile d'avoir la même techno qui réponde, à la fois, aux amateurs et aux exigences des pros. On traine un historique, où on voulait une techno accessible par chacun.

On traîne aussi le support d'IE11. Je peux te dire que ça grève largement la façon de faire et les perfs. Quand tu sais que tu pourrais avoir toutes les amélioration de ES2020, et qu'au final on continue de faire du ES5 (2009). On a aussi du DOM bien lourd parce que dernière règles CSS qui permettre de réduire sont pas utilisable.

[air-dex]

Oui les débits sont plus rapides. Mais :

• On bourre les pages Web de trucs plus gourmands : images plus grosses, JavaScript usine à gaz...
• L'amélioration des perfs des navigateurs a désormais une limite. On n'est plus au carrefour des années 2000 et 2010 où les améliorations de performances pouvaient être notables et où ça se battait à coups de SunSpider pour dire "mon navigateur c'est le meilleur il est le plus rapide". Ils sont désormais à peu près tous bons et performants.

Du coup ça compense.

[amosdesable]

C'est normal, on dispose pas les mêmes outils qu'il ya 10ans, c'est comme les ordinateurs des années 60, ceux qui en possédaient était heureux et ils faisaient le boulot pour lequel ils étaient conçu. Il ya 10 on avait angular, reactjs et des tonnes de technos? Avec tout ces Framework et CMS souvent mal codés , cette situation est loin d’être fini.

[Deforel]

Je me souviens dans mes débuts que l'image apparaissant sur la page web ne devait excéder 12-15 ko alors que maintenant on met directement cette même image dans son format réel (ex. 1.2 Mo) en la rapetissant au format voulu pour l'insérer dans la page.
Pas la peine d'en dire plus je pense.

[pemmore]

quand Leboncoin a commencé c'était pour moi un site de tests tellement c'était facile à ouvrir , passer les pages, un p2 pouvait suffire.
Maintenant c'est quasiment inutilisable, bourré de trucs inutiles, ça pompe tellement la ram quand je cherche une chose que ça arrive à en planter le pc, dommage il n'y a pas de concurrent de ce niveau.

[tes49]

Salut

En effet ! Personnellement, j'ai contacté Leboncoin pour deux problèmes agaçant, dont celui-ci, ils font les sourds sur ce sujet ! Et on a beau avoir, en effet, du matériel suffisamment costaud, que ça suffit à peine... Un ami cherche du boulot et comme il le dit clairement, il ne peut aller tous les jours sur Leboncoin, pour cause de temps...

(le deuxième sujet que je leur ai évoqué, mais rien a voir avec ce fil. C'est l'avertissement du matériel utilisé pour se connecter... J'ai eu une réponse... Si l'on supprime régulièrement les cookies du site, un émail est envoyé à chaque nouvelle connexions aux sites ! Pire que des spams, même Google ne fait pas ça ! La réponse disait qu'ils étudieraient la chose, ce n'est pas encore chose faite...)

[Mathis Lucas]

L'encombrement des sites Web modernes conduit certains d'entre eux à charger jusqu'à 21 Mo de données pour une seule page
ils ont parfois des performances médiocres sur les appareils bas de gamme

Une étude publiée récemment révèle que la complexité et l'encombrement des sites Web moderne ont un impact négatif sur l'expérience utilisateur et les propriétaires d'appareils plus anciens ou de faible puissance. Par exemple, en raison de l'encombrement des sites Web modernes, Wix nécessite le téléchargement de 21 Mo de donnée pour une seule page, tandis que Patreon et Threads téléchargent 13 Mo pour une seule page. Les téléphones d'entrée de gamme ne peuvent pas faire fonctionner certaines pages Web simples. L'analyse révèle qu'un des appareils testés peut jouer à PUBG, un jeu vidéo à 40 images par seconde, mais n'est pas en mesure de charger Quora.

Bien qu'attrayants, les sites Web modernes sont de plus en plus surchargés et complexes. Au début du mois, le programmeur Dan Lu a publié une étude sur l'état actuel des pages Web non optimisées et des performances des applications Web. Le rapport, intitulé "How web bloat impacts users with slow devices", indique que les sites Web modernes non optimisés et surchargés ne se traduisent pas seulement par des temps de chargement lents ; ils peuvent aussi ne pas fonctionner du tout sur certains appareils bas de gamme. Les résultats des tests sur certains appareils bas de gamme montrent l'ampleur de ce problème.

Le rapport met en évidence le fait que les performances du processeur pour les applications Web n'ont pas évolué aussi rapidement que la bande passante au cours des dernières années, ce qui signifie qu'une plus grande partie du Web devient inaccessible aux utilisateurs d'appareils bas de gamme ou de faible puissance, même s'ils disposent de connexions haut de gamme. Pour l'analyse, il a relevé l'indicateur Largest Contentful Paint (LCP) pour plusieurs appareils. Il s'agit du temps qui s'écoule entre le moment où un utilisateur lance le chargement d'une page et le moment où la page affiche le contenu principal.

How web bloat impacts users with slow devices:https://t.co/O6Cb4u1KoW pic.twitter.com/0eri7AmVdT

— Dan Luu (@danluu) March 16, 2024

La quantité de bande passante demandée par chaque site est également indiquée. Les tests portent sur les puissants processeurs Apple M3 Max, M3 et M1 Pro, ainsi que sur les appareils bas de gamme Intel P32 et Tecno S8C. L'auteur a constaté que le simple chargement d'une page Web peut même bloquer un appareil bas de gamme capable de faire tourner le jeu populaire PUBG. Le rapport indique que parmi les sites testés, le plus gourmand est Wix, avec un chargement de 21 Mo de données pour une page. Les sites Patreon et Threads ont tous deux chargé 13 Mo, tandis que Twitter a chargé 11 Mo et Discourse 10 Mo.

Cela peut se traduire par des temps de chargement lents pouvant atteindre 33 secondes ou, dans certains cas, par l'impossibilité de charger la page. Comme vous pouvez le voir dans le tableau des résultats, les sites Web les plus gourmands en ressources incluent pratiquement toutes les grandes plateformes de médias sociaux, dont Quora. Les nouvelles plateformes de production de contenu comme Squarespace et les nouvelles plateformes de forum comme Discourse ont également des performances nettement inférieures à celles de leurs homologues plus anciens, souvent au point d'être inutilisables sur certains appareils.

En d'autres termes, le rapport indique que les sites qui utilisent des techniques modernes, comme le chargement partiel de la page et le chargement dynamique du reste, dont Discourse, Reddit et Substack, ont tendance à être moins utilisables que ne l'indiquent les scores du tableau. En théorie, c'est une bonne chose, mais en pratique, les sites qui utilisent le chargement dynamique ont tendance à être suffisamment complexes pour être extrêmement difficiles à utiliser sur les appareils bas de gamme. Le rapport a suscité de vives réactions sur la toile, dont en voici une :

Je construis des sites Web et des applications Web depuis 24 ans maintenant et ce que nous avons aujourd'hui aurait fait virer les gens sur le champ à l'époque. Des générations entières qui ne connaissent rien d'autre que des configurations VDOM encombrées et qui les utilisent pour construire les sites Web les plus triviaux. Vous avez des pages encombrées avec des images en résolution d'impression et des widgets inutiles de "gestion du consentement", des traqueurs inutiles et des services qui chargent plusieurs mots simplement pour afficher du texte et un bouton.

Mais encore, vous faites également face à des décideurs incapables de distinguer un client d'un serveur et qui n'ont jamais vu une seule ligne de HTML de toute leur vie. Vous rencontrez des sites Web qui chargent 10 fois le système d'exploitation complet d'un ordinateur Amiga avant même de pouvoir afficher un seul pixel. C'est un désastre complet et un énorme gâchis. Et c'est l'une des raisons pour lesquelles je change de carrière en ce moment même. Il y a trop de gens qui n'ont aucune idée de ce qu'il faut faire. C'est trop frustrant.

Le Tecno S8C, l'un des appareils d'entrée de gamme les plus répandus sur les marchés émergents, est un appareil de test particulièrement convaincant. Les résultats montrent que l'appareil est en fait assez impressionnant à certains égards, notamment sa capacité à faire tourner PUBG à 40 FPS, mais le même appareil ne peut même pas afficher Quora et subit un décalage inutilisable lorsqu'il fait défiler des pages de médias sociaux. Quora est un site Web de questions-réponses et selon les critiques, il n'y a absolument aucune raison pour que l'un de ces sites Web soit plus difficile à faire fonctionner qu'un jeu Battle Royale.

Cet exemple est probablement le meilleur résumé de l'idée générale, à savoir que la conception des sites et des applications Web modernes ruine l'expérience utilisateur, dégrade la qualité et réduit les performances Web. Dans les commentaires, les critiques rejettent la faute sur les médias (images, vidéos, etc.), les frameworks, les CMS et le JavaScript de tiers. À en croire certaines études, les images sont très souvent le facteur qui contribue le plus à l'encombrement des pages. La vidéo a également connu une croissance fulgurante, ce qui peut un impact important sur des indicateurs ou des métriques comme le LCP.

Le JavaScript est l'un des termes qui reviennent le plus souvent dans les débats sur la lenteur et la dégradation de la qualité des sites Web. Une page peut s'appuyer sur un fichier JavaScript de petite taille, mais souffrir de problèmes de performance liés à ce dernier. Plus il y a de scripts sur la page, plus le risque est grand. Selon certains critiques, le CSS pourrait également causer des problèmes de performance aux sites Web, notamment lorsque les feuilles de style sont mal exécutées. D'autres éléments peuvent également être à l'origine des mauvaises performances des sites Web.

Par ailleurs, d'autres commentaires estiment que l'étude n'est pas complète, car il manquerait d'autres métriques importantes comme l'impact des bloqueurs de publicités sur les sites Web surchargés. L'un d'eux suggère : « une bonne étude sur l'encombrement des sites Web indiquerait également la quantité de bande passante économisée par les bloqueurs de publicité. En comparant les différents bloqueurs de publicité, on obtiendrait une bonne mesure de leur efficacité. Il faudrait également mesurer les données de téléchargement, en particulier avec et sans bloqueurs de publicité ».

Source : billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des résultats de l'étude sur l'encombrement du Web ?
Selon vous, qu'est-ce qui est à l'origine de l'encombrement du Web moderne ?
Que pensez-vous des sites et applications Web modernes ? Partagez votre expérience.
Quels sont les impacts de la conception des sites et applications modernes sur le Web ?

Voir aussi

Sommes-nous en train d'assister à la mort d'Internet ? ARPANET à l'IA : les défis de l'authenticité sur l'Internet moderne, perspectives sur l'évolution et les aspirations pour l'avenir

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

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

[RenarddeFeu]

Le web est un énorme troll en soi, puisqu'il faut maîtriser 3 langages minimum pour pondre une seule page web. Pour rendre encore plus simple le tout, on mélange les langages à markup et ceux à accolades.

Bien entendu, il est fort difficile d'en optimiser l'exécution et on se retrouve avec des absurdités du genre une seule page web qui est plus volumineuse que l'intégrale de Proust.

[dragonofmercy]

A l'époque il y avais pas Angular, React JS, etc. depuis que ces framework existe la plupar du temps c'est une catastrophe côté client.
Par exemple, Facebook marchait très bien il y 15 ans quand il avait pas encore leur framework côté client.
Je vais passer pour un vieux con mais bon, le système client / serveur avec par exemple PHP marche très bien et peut être tout aussi dynamique pour autant que l'on fasse les choses correctement.
Par exemple pour ma boîte, j'ai développé un système complet de gestion d'hébergement pour mes clients (gestion des domaines, explorateur de fichier, etc.), une page charge aux maximum 2 Mo qui seront mis en cache pour la prochaine page.

[marc.collin]

Par exemple pour ma boîte, j'ai développé un système complet de gestion d'hébergement pour mes clients (gestion des domaines, explorateur de fichier, etc.), une page charge aux maximum 2 Mo qui seront mis en cache pour la prochaine page.

tu peux éviter de charger toute la page via htmx, unpoly, alpine
c'est ce que j'ai sur plusieurs projet

[seb.49]

La vitesse du réseau et des machines font que depuis longtemps les développeurs ne cherchent plus à optimiser quoique ce soit.

Aujourd'hui on nous parle de numérique responsable, exactement ce qui se faisait quand on avait un processeur 486 à 25 Mhz avec 4Mo de RAM et un disque dur de 800 Mo (dans les années 1995), et un réseau à 56K (ah le doux bruit des modems de l'époque)....

[smarties]

C'est certain que côté optimisation, on peut faire beaucoup de choses sans forcer :
- utiliser localStorage à la place des cookies et sessions pour des échanges de token après identification
- réduire drastiquement la publicité (vidéos, bannières, trackers, ...) et la mesure d'audience via des tiers. Les logs serveurs peuvent donner facilement les IP et pages visitées... mais il peut manquer la provenance et il faut peut être avoir des outils disponible via des moteur de recherche ou faire des sondages sur 2-3 questions max
- utiliser des sprites plutôt que de nombreuses images : 1 seule requête avec une image souvent moins grosse que la somme de toutes, moins de RAM utilisée côté client
- dimensionner correctement les images, ça ne sert à rien d'avoir des icônes en 256x256 alors que du 48x48 suffit dans la majorité des cas

[BugFactory]

Quelle est la dernière fois que vous avez eu un budget pour optimiser les performances ?
Quelle est la dernière fois où on vous a donné des délais trop serrés pour optimiser les performances ?
Le problème n'est pas la technologie. Le problème c'est que le boss s'en fout.

[vanquish]

A l'époque il y avais pas Angular, React JS, etc. depuis que ces framework existe la plupar du temps c'est une catastrophe côté client.

Même en téléchargeant 4 framework de 500 ko (ce qui est beaucoup) on reste très loin des 21 Mo.
Gros a parier que le volume vient des médias - probablement de la pub et pas des framework et les requêtes ajax propres à l'application elle même.