Des chiffres à vous rendre malade

La taille des pages a plus que triplé en 5 ans, passant de 90Ko à 310Ko. Dans le même temps on a aussi doublé le nombre de composants externes par page (de 25 à 50). Cette progression ne faiblit pas, bien au contraire. Attention, je bourre le reste de l’article de chiffres, et certains font peur.

Pour les utilisateurs bas débit c’est une horreur. Le point positif c’est que pendant ce temps nos débits ont explosé et la latence des connexions a diminué. Bref, au final le temps moyen de chargement des pages des utilisateurs haut débit a légèrement baissé, mais c’est au prix d’un enfer pour tous les autres (le chiffre US est de 40% de RTC, en France il est plus faible mais non négligeable). A t’on bien fait ? pas certain.

Qu’y a t’on gagné ?

Si on y a gagné ces dernières années quand on surf ce n’est pas en performances mais en richesse et en qualité. Ou pas d’ailleurs. C’est ce que sous entend l’étude mais je ne peux m’empêcher de faire le parallèle avec nos micro-ordinateurs et nos logiciels. La puissance a vraiment explosé mais ce n’a pas tellement été pour faire les tâches plus rapidement. On s’est retrouvés avec de véritables monstres logiciels qui ont mangé chaque année la puissance gagnée. C’est au point où il est presque plus agréable de faire du traitement de texte sur un vieil ordinateur que sur la toute dernière bête de course associée aux derniers logiciels.

J’exagère mais l’esprit est là et je me demande si sur le web ce n’est pas la même chose. Peut être qu’on n’y a pas vraiment gagné en qualité mais que les développeurs font simplement moins attention. La seule exception que je vois c’est pour les vidéos, où là il y a vraiment eu un gain sensible pour le visiteur.

Des chiffres…

L’étude me donne ne fait à moitié raison, sans le dire. En 2006 les statistiques font état d’une page moyenne de 280 balises HTML pour 1440 pixels de haut. C’est beaucoup tout ça pour … 500 mots en moyenne. Ca fait deux mots par balise. Le rapport signal/bruit est agaçant. Pour des lignes de 15 mots on a environ un tiers de la hauteur seulement occupée par le contenu texte, c’est peu. Je ne vous propose pas de vous rassurer parce que entre 2006 et 2007, si le nombre de pages en tableau a été divisée par deux, le nombre de balise a suivi le chemin inverse : on passe à presque 600 balises par page en moyenne. Personnellement je n’ai pas eu l’impression que ça s’est traduit par plus de contenu dans les pages donc on doit être à plus d’une balise par mot en moyenne. De quoi donner des vertiges.

Mais ce n’est pas tout parce que sur nos 300Ko de page web on compte en moyenne 50ko sur 7 javascript (compressé), 10ko sur deux fichiers de style, plus les images, qui représentent 75% des requêtes (donc pour ceux qui suivent, à peu près 30 images par page).

Une saturation

J’hésite à continuer. Nous sommes des vrais malades.

Et si nous nous arrétions là ? je ne parle pas des chiffres de l’étude mais des délires des concepteurs web. Il est temps que nos machines ultrapuissantes connectés avec 1500 fois le débit que j’avais en 97, commencent à être plus rapides qu’à l’époque non ? Commençons à faire de la qualité et du contenu ou lieu de nous vautrer dans toute cette puissance pour faire quelque chose d’à peine mieux.

Un espoir

On peut toujours voir les choses sous plusieurs angles, alors voilà le bon : si réellement on a encore en moyenne deux feuilles de style, sept fichiers javascript et tant d’images, alors il y a une très bonne marge de progression côté performance pour un investissement très minime : concaténation des fichiers css, des fichiers javascript, et sprites pour les images.

Simple à mettre en oeuvre… en attendant de mettre fin au reste des délires.

Publié par edaspet

Plus d'informations sur mon profil en ligne

7 réponses sur « Des chiffres à vous rendre malade »

  1. J’ai l’impression que la problématique que tu pose vraiment très bien ici va bientôt arrivée comme une véritable problématique qui sera obligatoirement à prendre en compte, dans un avenir proche, pour les entreprises du domaine.

    C’est un peu une suite logique. On a appris à en faire des masses… Maintenant il faut apprendre à organiser tout cela et optimiser (Et peut être en faire parfois un poil moins car ça peut être plus gagnant).

  2. En fait, le gain en terme de puissance machine est bénéfique pour le développeur avant l’utilisateur.
    En tant que développeur, je peux plus facilement et plus rapidement faire une application fonctionnelle, qui ne sera pas une angoisse à mettre à jour ou débugger.
    Il est un temps pas si lointain ou performance rimait avec « bas niveau », voire « assembleur ».
    On en est loin aujourd’hui.
    Le souci, c’est qu’on se préoccupe de fait beaucoup moins des problèmes de performance qu’il y a quelques années. Certes, les compilateurs font un travail d’optimisation remarquable, n’empêche qu’un compilateur ne corrigera jamais une lourdeur dans le code…
    Plus jeunes, je pensais que les applications seraient instantanées sur nos prochaines machines et qu’on bénéficierait d’un allumage instantané. Aujourd’hui, je me rends compte à quel point c’est peu susceptible de se produire.

    Pour en revenir aux pages web, elles enflent, c’est sûr.
    Là, on peut distinguer les pages de contenu à proprement parler, et les applications web.
    Dans les applications, fatalement, pour dessiner l’interface, on risque d’avoir une belle soupe de balises, sans compter la grosse machinerie Javascript qui tâchera de faire fonctionner tout ça. Dans ce cas, on ne peut qu’essayer d’optimiser au mieux l’existant, et compter sur les prochains moteur de traitement de Javascript (Tamarin, V8 et consorts) qui promettent une exécution bien plus rapide.

    Pour les pages de contenu, la situation est plus critique. En effet, lorsqu’elles font appel à une ou plusieurs librairies javascript, c’est souvent pour des effets visuels futiles. Lorsqu’elles sont surchargés de balises imbriquées à n’en plus finir, c’est pour achever un effet particulier (coins arrondis, ombres etc.) qu’on ne peut pas traiter de manière facile actuellement.
    Bref, on se focalise sur la forme, qui prend énormément de place, et non sur le contenu.
    Finalement, c’est la même problématique que pour les médias papiers : un journal sera imprimé en noir sur papier recyclé pourri, avec le contenu mis en avant au maximum, alors qu’un magazine ferait part belle à l’image, aux couleurs, aux effets de style.
    Pas la cible, pas les mêmes moyens.

  3. Bonjour,

    Voilà un article qui m’a diablement surpris ! Curieusement, je le lis dans un contexte où mes collègues direct, usant massivement de YUI et autre Prototype ou JQuery, (re)découvrent la compression GZip 🙂

    En fait évidemment pas trop de doutes sur la taille globale des documents qui explose. Par contre, j’étais assez persuadé que la généralisation des mises en page par CSS auraient provoqué des HTML vraiment de moins en moins lourds… Encore en mémoire les html de plus de 100Ko vers 2000… contre quelques Ko aujourd’hui pour réaliser la même chose voire bien mieux !

    Alors je pensais plus que la faute revenait aux inclusions de CSS, JavaScript et d’images toujours plus nombreuses… Considérant qu’il ne s’agissait pas d’un simple déplacement de prb (les ressources externes sont mutualisées et ainsi mis en cache, compressables plus facilement) je pensais que l’impact de cette escalade de poids des documents était en fait en quelques sorte un moindre mal.

    L’article que vous citez indique quand même que lors de l’étude de 2007, plus de 60% des sites utilisent encore de la mise en page en tableaux…
    Aussi j’ai du mal à trouver le bon compromis entre les chiffres que vous évoquez et le point de vue qui était mien. Bref à avoir une vision réelle pour des « bons artisans » qui travaillent autant que possible avec les bonnes techniques.

    Enfin, concernant les RTC, j’ai aussi eu une surprise la semaine dernière en lisant cet article sur ZDNet :
    Plus de 10,5 millions de box ADSL en France
    . Il semble en effet indiquer qu’il n’y aurait plus que 7% environ de RTC en France : « 93,6 % des foyers ayant accès à internet ont choisi le haut débit » (!!)

  4. Tout d’abord merci pour le chiffre des RTC. Je l’air cherché et je ne l’avais pas trouvé. 7% c’est encore non négligeable ceci dit. Je connais peu de commerciaux prêts à s’aliéner 7% de leur marcher. Surtout qu’à ceux ci il faut ajouter ceux qui ont une bande passante d’entreprise trop petite, ceux qui ont un wifi en limite de portée, ceux qui ont un mobile ou un pda, etc.

    Pour l’utilisation des CSS, ça prend doucement, mais malheureusement je pense que même leur chiffre est faux. J’évalue personnellement les mises en page par tableau plus proche des 80% que des 60%, même dans les nouveaux développements. Mais même avec CSS, une grande partie des développeurs ne comprennent pas ce qu’ils manipulent et remplacent simplement leurs tableaux et leur balises font par plein de div et de span inutiles et surnuméraires. Au final parfois le poids du HTML ne diminue pas du tout.

    il y a aussi surtout que si la compresion, les proxy et les caches étaient des données connues de n’importe quel bon igénieur web, maintenant c’est presque un pôle d’expertise. Quand tu dis que certains collègues (re)découvrent la compression gzip, je ne peux m’empêcher de penser qu’il y a un problème de compétence, de formation, et surtout de culture technique dans le milieu (donc pas forcément la faute des personnes en question, mais de la profession dans son ensemble).

    Bref, le poids des pages continue à grossir, et en plus on double le nombre et le poids des ressources jointes comme les javascript et les CSS. On prend le pire des deux. On ne déplace pas le problème, on l’ajoute.

    Enfin, rien à voir mais c’est aussi pour ça qu’on a créé Paris Web. On a un gros déficit de formation et de culture technique, et on finit par avoir n’importe quoi.

  5. @Eric

    Les compétences…

    Dans mon commentaire précédent j’avais hésité à évoquer le problème du manque terrible d’intégrateurs HTML/CSS qualifiés, c’est quelques chose que je ressent très directement (je précise : en tant que développeur d’applications Web)
    Car si le Web s’est vraiment industrialisé côté infrastructure (admin) et logiciel (dev) comme marketing, rédactionnel etc, au final le html/css/js produit est encore très rarement réalisé par de vrais spécialistes…

    Mais vous avez raison, il n’y a pas que cela : le cache, les tests de montée en charge, … (…) beaucoup d’étapes de conception indispensables passent par Joe la débrouille ou carrément à la trappe, alors qu’on aurait besoin de personnes connaissant tout cela sur le bout des doigts.

    Manque de compétences ? Je crois surtout déficit de volonté !
    Depuis les débuts « artisanaux », les choses évoluent bien doucement… Mais il est vrai aussi que les projets Web nécessitent de faire travailler un grand nombre de compétences différentes qui n’ont pas forcément l’habitude de cohabiter aussi directement ! Cela complique quand même les choses…

  6. Merci pour ce billet très pertinent.

    J’aimerai apporter un autre axe de réfléxion, étant moi même « ingénieur web », j’ai remarqué une tendance génante du point de vue de la formation :

    Le développement web au sens large n’a pas la cotte.

    Les compétences existent, un tas de gens très pointus sur un ou plusieurs domaines attenant au web sortent d’école chaque année, mais voila, ils préfèrent en grande partie aller travailler pour Apple, Microsoft, Google, VMWare, dans des boites de sécurité etc… (No offense, il est tout à fait compréhensible que des étudiants souhaitent s’orienter vers des grand comptes, il ne s’agit que d’un constat).

    Au final, dans ma promotion, en proportion peu de gens qualifiés se sont dirigés vers des métier de production sur le web, la plupart n’y voyant pas d’interet majeurs.

    Je ne suis pas sorti de l’école depuis bien longtemps et j’y exerce toujours une activité de formation, et il semble que la tendance soit pire sur les promotion à venir.

    Une des solutions ne serait-elle pas de revaloriser les métiers du web ?

Les commentaires sont fermés.