Anaïs Sparesotto : « On a habitué les internautes à des centaines de fonctionnalités inutiles »

Questionner le besoin

Anaïs Sparesotto : « On a habitué les internautes à des centaines de fonctionnalités inutiles »

Comment expliquer que le poids des logiciels et pages web s’est démultiplié à mesure que les performances du matériel numérique augmentaient ? Comment écoconcevoir des services numériques ? Dans le cinquième épisode d’Écosystème, Anaïs Sparesotto décrypte les enjeux environnementaux du développement logiciel et web.

Le 23 juillet 2025 à 17h22

Commentaires (39)

votre avatar
Je trouve que la fonctionnalité est une bonne excuse, mais en pratique il y a de vrais sujets d'optimisation techniques.
Je crois que c'est ici-même que j'avais lu un article qui analysait le poids de certaines pages d'accueil connues pour lesquelles il y avait 0 optimisation : des images de qualité bien trop grandes par rapport au besoin, des JS à n'en plus finir pour la floppée de régies pubs et d'outils de metrics qui doivent être consultés tous les 3 ans...

On a surtout pris l'habitude qu'un code crade reste fluide parce qu'un appareil lambda peut largement encaisser la charge associée, et la connexion 8Gb-pour-aller-lire-lequipe aussi.

Mais aller grappiller un petit avatar (d'ailleurs je viens de voir que vous ne chargez plus la version HD désormais :smack:) quand TikTok précharge des dizaines de vidéos d'avance et qu'Instagram transforme une photo en vidéo pour son flux de Stories, c'est un peu comme mettre du sel bio dans les frites McDo.
votre avatar
A une époque (>10 ans), je m'étais amusé à chiffrer un peu le poids d'une page web
- avec un navigateur "à poil"
- avec le même navigateur + adblock
- avec le même navigateur + adblock + Noscript
Grosso modo, le poids d'une page web était divisé par presque 10 sans trop de difficulté sur bcp de sites. Il y avait une extension de FF qui indiquait d'ailleurs le poids des images, des scripts et des éléments HTML dans la barre d'information du bas (qui a disparu)

De nos jours, si on "inspecte" une page avec Firefox, et qu'on se rend dans "Réseau", on peut avoir une idée du poids d'une page et de son temps de téléchargement (et donc quantifier l'efficacité d'un bloqueur de pub).

Par exemple, chez clubic (qui n'est pas dans les pires, à mon avis) :
- avec un FF à poil : 4.34 Mo / 988 ko transféré et 1.9s de traitement
- avec un FF + Mublock (avec bcp de listes) et Adguard Home : 3.48 Mo / 684 ko et 1.9s de traitement
- avec un FF + Mublock (avec bcp de listes) et Adguard Home + Nocript (domaine principal autorisé) : 3.48 Mo / 684 ko et 1.45s de traitement

Les écarts peuvent être bien plus conséquents sur certains sites (là, c'est assez modéré, donc Clubic n'abuse pas, en tout cas en 2025)
votre avatar
Cette mesure n'a de sens que si on la met en perspective avec la consommation induite.

Le chargement d'une page de 4,34 Mo ne va pas consommer plus au niveau des infrastructures réseau modernes à être transportée - c'est pas forcément intuitif mais c'est vrai - elle ne va pas consommer plus à être affichée, le terminal et l'ensemble du matériel utilisé pour la servir sur toute la chaine est le même et ne s'use pas plus à servir 10 fois plus d'infos, et 4,43 Mo vont consommer environ 0,1W côté serveur pendant une seconde à être délivrés.

En gros, si vous n'allumez pas une heure un radiateur de 1 000 W l'hiver prochain, vous allez compenser l'ouverture de 36 millions de pages de 4,34 Mo.

Mettons que vous consultez 150 pages web par jour, ça nous donne 240 000 jours de compensés, soit 657 ans de vie. Pour une heure de chauffage d'une surface de 50m².

Est-ce qu'il n'y a pas des économies de ressources plus évidentes à aller chercher ?
Est-ce que ce sujet n'est-il pas un vaste abus à l'encontre des diptères ?

A l'inverse, quelles seraient les ressources nécessaires pour optimiser toutes nos ressources web ?
C'est très compliqué à calculer, mais si je devais parier quelque chose, je dirais que cet effort aurait un résultat net négatif pour la planète par rapport aux ressources économisées.
votre avatar
C'est vrai que l'optimisation peut paradoxalement se révéler coûteuse, même si c'est contre-intuitif. D'où l'intérêt de prendre en compte la problématique dès la conception, et pas uniquement en temps deux !
votre avatar
@Ferd

Hélas, c'est faux. Toute information traitée/manipulée par un système numérique induit des transistors qui vont changer d'état, et donc une consommation élémentaire, peu importe la nature du circuit. Pareil dans le transport de l'information. Alléger tes data de 80%, c'est donc alléger la consommation électrique de l'ensemble de la chaine d'un coefficient non négligeable (un peu moins de 80% car il y a des consommations constantes, mais généralement prévues pour être faibles).

L'impact sur les ressources est donc immédiat : si pour faire transiter la même information, il te faut 5x moins de ressources matérielles, tu peux te contenter de moins d'équipements, et donc pas besoin de les fabriquer.

Reste la consommation sur le terminal et le serveur aux deux bouts de la chaine : des données compressées peuvent nécessiter plus de ressources aux deux extrémités par exemple. Cependant, dans le cas de la pub, ne plus l'afficher, c'est gagner sur toute la chaine : plus d'émission depuis un serveur, plus de transport, et plus de traitement.

NB : l'exemple de clubic n'est pas le meilleur, car le gain est étonnement faible sur leur site (en tout cas, ils ont dû faire des efforts). Le ratio de 10% de poids utile pour 90% de trackers/pubs n'est pas tiré d'un mouchoir.
votre avatar
Les réseaux optiques sont déjà là, ils sont déjà capables de faire transiter énormément de données à un très faible coût énergétique.
Si on construisait tout de zéro aujourd'hui on pourrait en discuter (à la marge en vrai, si ça doit pouvoir transporter un film c'est pas la page à 4Mo qui fera la diff) mais en l'état c'est peine perdue.
Un réseau optique consomme à peu près la même chose qu'il soit utilisé à 0% ou à 100%.
votre avatar
ton calcule est extrêmement simpliste, le serveur il est dimensionné selon la consommation en heure de pointe et est actif 24h/24 que tu l'utilise ou non, il faut prendre en compte son refroidissement permanent, chaque requête vas passer par un certain nombre de routeur qui eux même communique en permanence entre eux et sont aussi dimensionné en nombre et en puissance selon les heures de pointes.

et il faut prendre en compte le réseaux électrique qui est dimensionné aussi pour pouvoir absorbé les pics de consommation, les pertes de transformation et je ne sais quoi d'autre.

Je ne suis pas spécialiste, je ne sais pas être plus précis, je remarque juste que ton calcule est biaisé et largement sous estimé.
votre avatar
Il se trouve que sans être un spécialiste de pointe, je connais un peu le sujet.
Nous opérons des serveurs, des réseaux optiques, et du transit, et c'est nous qui payons la facture d'élec à la fin.
Le calcul que je fais est globalement correct, je crois, il n'est évidemment pas précis, il est schématique, mais les ordres de grandeurs sont là.
Je pars du principe que la charge est parfaite sur le serveur, car si elle ne l'est pas, c'est encore pire, le serveur consomme à ne pas servir de données - ce qui ne va pas dans le sens de la nécessité d'optimiser les requêtes.
D'ailleurs, dans le cas d'une grosse portion de services web aujourd'hui, ce sont des VM derrière, ce qui est optimal en termes d'efficacité chez les gros CSP.
(Ce qui n'est pas optimal pour le client financièrement parlant, mais c'est un autre débat.)
votre avatar
Je pense que la divergence de vos constats est que vous ne partez pas de la même base.

De ton côté, tu parles en fonction des infra existantes. Un peu plus ou un peu moins de données ne change rien.

De l'autre côté, @neod ou @WarMachine, j'ai l'impression qu'ils prennent en compte l'influence de la consommation sur le dimensionnement de l'infrastructure. Une consommation de data moindre ne nécessiterait pas un réseau dimensionné comme il peut l'être aujourd'hui, ce qui induit donc une consommation supplémentaire car on pourrait se contenter de moins d'équipement.

Autrement dit, une infra pouvant supporter 10Go/s ou 100To/s ne va pas consommer la même chose rien que par le fait d'être allumé, et ceci, indépendamment du trafic qu'il peut y avoir à un instant T.
votre avatar
Oui, et non.

Déjà, les réseaux fibre en place suffiront pour des décennies, il fallait bien la déployer une fois cette infra - qui ne sert pas qu'à afficher des avatars, je le rappelle.

Je donne des chiffres précis en développant mon raisonnement, basé sur mon expérience professionnelle, de ce que consomment les infras en place sur la base de vrais chiffres.

On peut débattre de la façon de calculer l'empreinte, de la durée d'amortissement des matériels, mais la contradiction ici ne vient pas du calcul, elle vient plus d'une posture IMHO.

Je pense que la réalité exacte se situe - tous facteurs confondus - quelque part autour d'un facteur 10 de mon résultat.
En worst case, scenario, quand bien même on serait à 65 ans de vie de pages toutes à 4,34 Mo pour une heure de chauffage, est-ce que la conclusion n'est-elle pas la même ?
Si c'est un facteur 100, et qu'on parle d'une heure de chauffage tous les 6 ans et demi, pareil non ?

Mon point c'est qu'à chaque fois qu'on parle de sobriété de contenu (vidéos 4k, grosses pages web, sobriété logicielle...), on parle plus d'idées que de faits, et les infras sont d'une efficacité rarement retranscrite par des interlocuteurs qui sont souvent loin de la réalité opérationnelle (et cette efficacité va en s'améliorant, alors que l'usage tend globalement à se stabiliser).

Edit : je précise ici que je n'ai pas d'infos particulières sur la conso des réseaux cellulaires, on part sur un delivery full fibre jusqu'à l'abonné.
votre avatar
J'ai l'impression que tu parles principalement de la topologie du réseau (où la fibre arrive), pas de son dimensionnement (les équipements nécessaires pour le faire fonctionner).

Je suis d'accord avec toi sur la topologie, et d'autant plus que la fibre a une durée de vie extrêmement longue (sauf accident ou sabotage !).

Par contre, peut-on dire de même des équipements actifs tout autour ? Je ne suis pas spécialiste (tu l'es bien plus que moi à ce sujet ;) ), mais les répéteurs & co. ça consomment aussi et cela a aussi une durée de vie, que je dirais de bien moindre dans la mesure où il s'agit d'appareils électroniques.

Plus il y en a, plus cela consomme, et plus on changent / réparent. Je ne crois pas (mais tu m'arrêteras là dessus) que quand on a des liens à 100To/s par exemple, et qu'il faut mettre un répéteur, que tu vas mettre le même si le lien est un simple lien à 10Go/s. Je ne suis même pas certains qu'un seul puisse suffire, et qu'il faudra sans doute en agréger plusieurs. On aurait besoin de moins de débit (je ne parle pas de couverture, juste de débit), on pourrait peut être avoir moins d'équipements qui traitent le tout non ?

Après, c'est peut être mon parallèle foireux à la dimension d'une entreprise, mais quand on arrive aux limites de bande passante d'un switch, ben on en met un deuxième (ou un plus gros, mais qui consomme plus aussi).
Mon point c'est qu'à chaque fois qu'on parle de sobriété de contenu (vidéos 4k, grosses pages web, sobriété logicielle...), on parle plus d'idées que de faits, et les infras sont d'une efficacité rarement retranscrite par des interlocuteurs qui sont souvent loin de la réalité opérationnelle (et cette efficacité va en s'améliorant, alors que l'usage tend globalement à se stabiliser).
Je te rejoins là dessus. On peut entendre beaucoup de connerie sur le sujet. Non, 1h de Netflix ne va pas tuer la planète en tant que tel (je crois que c'est l'équivalent à 200m en voiture thermique de mémoire). Je préfère largement ne pas prendre ma voiture, j'ai un bien meilleur impact sur mon environnement ainsi ! (mais je regarde Netflix)

Mais ça, c'est pour une vision à l'échelle instantanée d'une personne. Si on prend un peu de recul, on voit bien que la consommation de data ne fait que croitre d'année en année, incitant toujours à investir plus dans les infra réseaux. Et là, si on commence à répercuter de manière comptable (= en parlant d'amortissement), en prenant en compte les équipements sur toute la chaine, alors non, je ne suis pas certains que le réseau soit toujours aussi négligeable que cela. Sauf qu'à l'échelle individuel, on n'a aucun impact là dessus. C'est dans le collectif que cela se joue...

Et encore faudrait-il aussi définir ce que l'on entend par infra. Est-ce juste le réseau ? Est-ce aussi les serveurs qui desservent les pages web ? etc. Car bon, faut pas se leurrer non plus, mais si tu as besoin de 5 serveurs pour ton site ou d'un seul, ce n'est clairement pas la même chose en terme d'impact, que ce soit d'un point de vue alimentation ou même fabrications des serveurs.

Je suis d'accord pour dire que ce n'est pas les avatars pour un site comme Vinted ou Le Bon Coin qui vont changer grand chose, fasse aux nombres de photos qu'ils doivent stocker pour les articles. Mais je pense que s'interroger sur ce qui est nécessaire ou pas, c'est quand même quelque chose d'important. Et là, pour le coup, perso, ce qui ne me parait pas nécessaire dans la grande majorité des cas, et que pourtant on est en train de nous foutre partout, c'est bien l'IA... Elle a même débarqué dans le bloc note. Dans le bloc note... :surenchere:
votre avatar
Alors, développons jusqu’au bout la partie power en détails.

On a trois postes de conso élec :

- Le datacenter
- Le transport backbone & last mile
- Le LAN

Il est entendu que les serveurs sont utilisés à fond, pour que l’optimisation du code soit synonyme de moins de ressources utilisées sinon ça ne sert à rien.
Également, nous tenons compte du fait que l’usage de l’infra en général est utilisée par des millions de services en parallèle, d’une façon relativement constante - comme c’est le cas dans la vraie vie.

Le datacenter, c’est la partie compliquée, on va dire que le site est hébergé sur un serveur de moins de 5 ans, que le PUE du site est de 1.5, que c’est un VPS avec plein de VMs, que le serveur crache 10 Gbps en moyenne pour 300W de conso (ça peut monter bien plus haut sur ce budget énergie, mais soyons conservateurs).
Ce serveur est relié à trois switchs successifs avant d’arriver sur le backbone, chaque switch consomme 400W en moyenne, mais il y a 48 machines sur le premier, 500 sur le second, et 4000 sur le core (restons sur des pizzabox pour faire simple).
400/48+400/500+400/4000=10W
Pour une ressource de 4,34 Mo, on a donc 4,34/10000x8x(300+10)/3600=0.000297222 Wh.
Si on tient compte du PUE, on arrive à 0.0004458 Wh pour une page servie.

Parlons backbone.
Imaginons que le datacenter est à 1 000 km de l’usager - ce qui est conservateur pour la France qui a globalement ses ressources en son centre, mais qui tient compte des quelques ressources hébergées en dehors de son territoire.
L’usager est client d’un des 4 gros opérateurs de FTTH, qui a ses propres backbones, avec de la charge.
Un équipement de transmission optique moderne crache plusieurs dizaines de Tbps de capa en OTN, mais imaginons que le backbone est très peu chargé, et qu’il n’envoie que 500 Gbps en moyenne.
On va consommer environ 300W tous les 100km, soit 3000W pour les 1000km, pour 500 Gbps.
On refait le calcul, 4.34/500000x8x3000/3600=0.00005786 Wh.
Des clopinettes, là encore.

LAN du client, relou, ça dépend d’énormément de paramètres.
Je le mets pudiquement de côté, pour ne faire le calcul que sur ce que l’usager ne voit pas, mais fantasme, les infras.
D'ailleurs, l'empreinte de la fabrication des terminaux est infiniment supérieure à celle des infras mutualisées - ce qui n'est pas particulièrement agréable à entendre si on aime se défausser de sa propre responsabilité sur le cloude, je le conçois. On est tous humains.

Revenons à nos agneaux, hors LAN, on a donc 0,000506 Wh pour la page web.

On prend les 1000 W du radiateur, on les divise par notre conso ridicule, on obtient un facteur 1 974 983.
On divise ce facteur par 150 pages web par jour, on arrive à 13 166 jours de navigation.
On divise par 365, ça fait 36 ans.

Les paramètres modifiés par rapport à tout à l’heure c’est qu’on n’envoie que 10G par serveur (au lieu de 100G initialement) et qu’on tient compte de la conso backbone et du PUE du DC.

Donc c’est 36 fois plus efficace de couper son radiateur une heure par an que d’écoconcevoir toutes les pages web de 4,34 Mo.
A noter, une page web en moyenne est de 2,5 Mo aujourd’hui. On est donc plutôt sur un facteur 62, dans l’hypothèse où on arrive à réduire la page à quelques ko.
Si on se dit qu’on fait seulement un -50%, on arrive à 124 années de pages à 2,5 Mo pour une heure de chauffage.

L’écoconception des pages web, c’est de la flute sur le plan environnemental, c’est au mieux plus fluide pour l’usager.

Ce raisonnement n'est pas valable pour tous les services IT, il est infiniment plus complexe sur le sujet de l'IA, et oui, le numérique a une empreinte réelle sur l'environnement.
Mais faut arrêter de raconter n'importe quoi.
votre avatar
Nan mais moi je voulais juste intervenir pour signifier ce qui me semblait être la source de votre mésentente sur le sujet, pas une démonstration magistrale :phiphi:

Parce que sur le fond, je suis entièrement d'accord avec toi. Il y a des choses bien plus utile et impactante que de simplement arrêter de mettre des avatars.

Là où perso je trouve la démarche utile, c'est qu'elle incite à se poser des questions ! Pas de bol, pour les avatars, c'est peanuts, mais cela ne veut pas toujours dire que c'est le cas. Est-ce qu'on a autant besoin des avatars partout que des IA partout ? La même question amène, toujours de mon point de vue, la même réponse. Par contre, l'impact sera radicalement différent.

Surtout que les fonctionnalités inutiles (l'IA, tousse tousse) incite à avoir des équipements toujours plus puissants, donc participe au renouvellement anticiper de terminaux tout à fait fonctionnel.


Mais sinon, un gros poutou pour toi pour cette démonstration :smack:

[edit] un ajout mineur juste pour éclaircir mon propos, quand je dis IA, c'est un énorme raccourci pour les LLM et les IA génératrices.
votre avatar
Sur les transferts les avatars sont minuscules mais lorsque l'utilisateur décide d'en envoyer un cela peut vite se gâter.

Il y a des portables qui ont 200 Mpixels ( https://www.frandroid.com/produits/smartphones/capteur-photo-200-mpx ). On peut franchement douter de la pertinence d'un tel capteur, un APN pro a moins de pixels et est déjà limité en finesse par son objectif pourtant haut de gamme. Toujours est t'il que cela fait 200 Mpixels 3 couleurs 8 bits/couleur = 600 Mo pour juste décompresser le jpeg avant de faire le redimensionnement en genre 120x120 !

Bien sûr un utilisateur avisé va redimensionner l'image sous Gimp ou autre. Une appli peut faire un redimensionnement local (enfin si elle est bien faite) mais si c'est en web et que l'utilisateur n'a pas conscience de cela (comme + de 95% de la population) bah, va bien falloir traiter l'image sur le serveur.
C'est 600 Mo. :windu:
votre avatar
Sans compter que si le dev fait tourner sa machine quelques heures supplémentaires pour "écoconcevoir" le site, suivant la visibilité du site, il peut consommer plus que tous les gains que ça va apporter au final…

La quantité de données transférée n'est pas le cœur du problème écologique, loin de là.
votre avatar
Bah si la page de Clubic faisait 400ko au lieu de 4mo, ils pourraient avoir des tuyaux de sortie internet plus petits, un serveur plus petit (ou mutualiser plus de sites sur la même machine).

La comparaison au chauffage me laisse dubitatif : le chauffage est essentiel (c-à-d on peut mourir de froid), les librairies JS complètes, et images HD pour faire une miniature, ou pour le cas de clubic la requête GraphQL toutes les minutes de 1,91Mo ! récupérant ad-nauseam les mêmes données en mode annule et remplace : ça n'apporte pas de fonctionnalités c'est simplement mal codé.

Le fait que le transport (en fibre) ne coûte plus grand chose, ne justifie pas de faire n'importe quoi. Tu raisonnes côté infra server (normal c'est ton boulot), mais tu sembles oublier le reste de la photo :
les CDN payent une partie de ta facture d'électricité à reservir le cache des ressources qui ne sortent qu'une fois de ton server,
sur les 5 millions de visiteurs uniques de Clubic :

- combien sont en cuivre ? (ADSL, ou cable), ou pire wireless (satellite, WiMax...)
- combien surconsomme leur box Wifi qui ne se met pas en veille à cause du "ping" toutes les min pour un onglet Clubic +/- oublié ?
- quid de la charge CPU du JS qui va toutes les minutes réclamer l’entièreté de la page, parser un GraphQL, et reconstruire le DOM.
- qui dit charge CPU, dit conso batterie et donc usure prématuré de la batterie du laptop...

Tout ça ce n'est pas grand chose... x5 millions, pour 1 seul onglet d'1 seul site...

Le pire dans tout ça c'est que Clubic n'est pas si mal codé...
votre avatar
Le calcul que j’ai fait est all included et si c’est du cdn c’est über optimisé en plus.
Vous pouvez faire toutes les circonvolutions intellectuelles que vous voulez, ces chiffres sont les plus proches de la réalité que nous ayons.

La comparaison avec le chauffage c’est que c’est simple d’éteindre le radiateur une fois dans une vie pendant une heure, alors qu’optimiser l’ensemble du web serait un effort considérable (évangélisation + optimisation).
votre avatar
Je n'ai pas l'impression que votre calcul prenne en compte (pour Clubic) l'auto refresh de 1.91Mo chaque minute pondérés aux 5millions d'utilisateurs uniques (qui n'ont pas tous un radiateur électrique à éteindre :-p )

Concernant l'évangélisation, je pense qu'il faut la faire : en formation informatique pour les techniques et en indicateur / reporting "green IT" obligatoire (voir taxe) côté décideur. Même si entre Trump et la folie tout-IA, j'ai peur que le green IT soit le cadet des soucis de nos décideurs... L'optimisation suivra avec la maintenance ou les refontes où ce sera demandé explicitement directement dans l'expression de besoins.
La comparaison avec le chauffage c’est que c’est simple d’éteindre le radiateur une fois dans une vie pendant une heure, alors qu’optimiser l’ensemble du web serait un effort considérable (évangélisation + optimisation).
Et je réponds que l'un n’empêche pas l'autre ;)

Il aurait été très simple que le dev de Clubic code un algo en delta qui n'aurait demandé que les nouveaux articles : ça n'aurait transporter / recalculer la page qu'en cas de nouveau contenu publié, la conso aurait été moindre à tout niveau, et l'usage parfaitement identique.
votre avatar
A mon avis il faudrait aussi regarder du côté des scripts tiers embarqués pour le marketing... Quand certains sites référencent 300 domaines il y a un problème
votre avatar
300, 300, tu exagères :santa_flock:

next.ink Next
votre avatar
Je suis désolé, mais je trouve cet argumentaire ridicule : on trouve depuis des décennies des sites web léger, avec des photos de profils et des tonnes de services. PHPbb date de 2000...

Non, les véritables sources de l'alourdissement, c'est :
1. L'abstraction. Sous des prétextes de facilitation de développements, les devs vont inclure une bibliothèque qui pèse son poids alors qu'ils utilisent 1 % de ses fonctions. Au lieu de développer un site à la main, ils vont utiliser Wordpress pour un site vitrine statique.
2. La multiplication des publicités et trackers. Si vous allez sur les sites de journaux par exemple, sans adblock, vous multiplier le nombre de requêtes par 10 et le poids par 5 (je viens de tester sur le figaro). L'ordre de grandeur avec/sans adblock sur le bon coin est plus ou moins le même.

Bref, les fonctionnalités ne sont pas la cause des problèmes, si problèmes il y a.
votre avatar
les devs vont inclure une bibliothèque qui pèse son poids alors qu'ils utilisent 1 % de ses fonctions.
C'est exactement ça, et cela me rappelle une expérience avec un ancien apprentis. Dans un formulaire, il devait vérifier le format des numéros de téléphone. Il a trouvé une bibliothèque qui faisait ça et qui était très lourde (> 1 Mo !). Ok, c'était une usine à gaz et qui était capable de gérer je ne sais combien de format internationaux, de préfix, etc.

Et là, je lui ai dit : notre application n'est pas internationale et n'a que des numéros français à 99,9%. Donc, tu me vires ça, et tu me fais une simple regex.
Au lieu de développer un site à la main, ils vont utiliser Wordpress pour un site vitrine statique.
Le truc, c'est que ces abstractions rendent aussi les technos accessibles. Un site vitrine statique avec Wordpress, quasiment n'importe qui peut le faire (surtout que bon nombres d'hébergeurs propose de l'installer pour toi). Un site vitrine statique sans Wordpress, c'est déjà beaucoup plus complexe et nécessite des compétences que tout le monde est loin d'avoir.
votre avatar
Clairement, l'argument est vraiment tout pourri, la personne qui fait cette conclusion devrait se pencher sur le développement d'un site internet au niveau technique + le bordel des trackers / publicités pas juste regarder la taille des avatars...(qui sont eux plutôt pratique et n'influent pas vraiment sur le chargement du site)
votre avatar
. Sous des prétextes de facilitation de développements, les devs vont inclure une bibliothèque qui pèse son poids alors qu'ils utilisent 1 % de ses fonctions.
C'est ce que j'observe aussi de ma fenêtre de non-dev. Lib qui fait papa-maman sous exploitée, et qui parfois va même redéfinir des fonctionnalités de base du navigateur en moins bien (scrolling chelou, saisie de texte pétée, boutons qui ne réagissent pas, etc.).

C'est fou le nombre d'éléments de composition qui reposent sur des tonnes de JS quant ils peuvent être faits avec quelques lignes de CSS et du HTML.
votre avatar
Perso, depuis j'ai découvert VanillaJS, je ne jure que par cette lib !! Et on peut tout faire avec, c'est dingue.:D

Et hautement configurable. On ne prend que ce dont on a besoin.
votre avatar
Le problème reste la quantité, comme toujours. Typiquement je vois Linkedin dans la liste de ceux qui l'utilisent, c'est clairement un dinosaure pataud et lourdingue ce site de brun.

Perso je sais pas dev en JS et ça m'intéresse pas. Mes sites web n'en contiennent pas, en dehors d'un fait viteuf à coup de chat bot pour afficher un feed mastodon on se basant sur le RSS (celui de Bluesky est un trouvé sur le Web).

Et j'ai quand même réussi à faire des éléments sympa genre un carousel sans JS. Bon, il bouge pas tout seul, mais en même temps, j'aime bien les trucs qui ne gigotent pas dans tous les sens :D
votre avatar
je vois cette dérive aussi sur des applications interne à l’entreprise. Le marketing n’est pas la seule cause à cette situation. On rajoute des fonctionnalités demandées par personne ou alors dont le retour sur investissement n’a pas été étudié mais les archis ou les dev ou leurs chefs trouvent sympas de le faire. Que ce soit sous l’angle de l’écologie ou financier, vivement que le pragmatisme et la rationalité revienne dans le monde de l’informatique !
votre avatar
Je crée moi même mes propres sites et j'essaie toujours qu'il soient léger et rapide.
Et à CHAQUE fois, le SEUL truc qui pète tout, que ça soit en terme de lourdeur, de compatibilité, de rapidité ou de sécurité, c'est ... LES PUBS GOOGLE ! (parce qu'il faut bien bouffer).
votre avatar
Si sur le fond je suis assez d’accord, je trouve que l’avatar est un exemple assez mal choisi. C’est un identificateur assez pratique, repérable rapidement dans les échanges, et généralement de taille assez réduite…
votre avatar
La bise à nodejs ! :smack:
votre avatar
Cette nana est bien gentille avec ses considérations sur les fonctions d'un services web qui devrait se "restreindre" au strict minimum... mais il suffit d'activer un bloqueur de pub pour constater que le poids d'une page est bien souvent majoritairement dominé par les services de tracking/pub.

Bref, s'il y a des efforts à faire, c'est d'abord de ce coté là, et personnellement cela fait des années que je bloque tous ces éléments, à la fois :
- par déontologie et respect de ma vie privée. Ce n'est pas parce que je n'ai rien à cacher que j'ai envie qu'on m'analyse comme une bête de foire
- par action citoyenne : tout ce qui sort de l'information utile d'une page, ce sont des octets qui transitent et sont traités par des machines. Ne pas avoir à traiter ce qui est inutile, c'est donc agir pour la nature car c'est limiter la consommation des machines sollicités (terminal, serveurs, switchs etc.)
- par économie personnelle : tout ce qui n'est pas traité sur MES machines, c'est de la batterie en moins de gaspillée pour les appareils mobiles, et autant de consommation électrique en moins.

En cela, cela fait donc des années que j'utilise des bloqueurs (mublock Origin et NoScript)... et désormais, c'est carrément un serveur DNS à la maison (installé sur ma domotique) qui vient compléter le travail pour tout ce qui n'est pas "navigateur". Bon, je pourrai me contenter de DNS4Euro, mais là, je peux bloquer très nettement davantage de choses : presque plus de pub, presque plus de tracking, sur TOUS les appareils.

EDIT : cependant, je rejoins les propos de Anaïs Sparesotto sur d'autres exemples qui me paraissent plus judicieux : le poids des applications (PC, smartphone). Désormais, un driver, ca peut peser plus lourd qu'un OS complet comme windows XP : est-ce raisonnable ? Ou bien, pour afficher une carte GPS, il faut une application qui pèse des centaines de Mo (je ne parle pas des datas en elles-mêmes) ??? Indirectement, c'est faire le jeu de l'obsolescence programmée, car on finit par saturer le stockage de certaines machines.
votre avatar
Les poids des applications a évolué en fonction des augmentations de résolution (image, icones et son). C'est un peu moins le cas aujourd'hui (ça plafonne).

Ce qui est plus gênant ce sont les applications mobile qui ne sont que des antichambres de navigateur. Je ne vois pas l'intérêt. Egalement dans les applications mobile (Android), avoir une icone pour plusieurs résolution d'écran ne m'a jamais semblé crédible. T'en mets une grande et on "resize" à la volée.

Pour le reste, il est vrai que le marketing est un poids atrocement élevé dans le web. Il n'y a que la vidéo qui soit plus consommatrice de bande passante (brute, hors proxys).

Bon maintenant, il y a les vendeurs de data center qui ne sont pas d'accord avec la miss. Et ces datacenter sont des infrastructures du marketing... Bref on a beau discuter ce sera une fin de non recevoir in fine.

Ces fameuses bonnes pratiques ne se retrouvent pas dans nos services public français. On pourrait même dire que c'est l'inverse en ce moment. Va montrer l'exemple avec ça.
votre avatar
Egalement dans les applications mobile (Android), avoir une icone pour plusieurs résolution d'écran ne m'a jamais semblé crédible. T'en mets une grande et on "resize" à la volée.
Je me permets de souligné un bon exemple de contre-optimisation : il y'a deux axes à prendre en compte la fréquence et le coût unitaire.
D'un côté on a une appli légèrement plus grosse (contenant une icône de chaque taille), dont le redimensionnement n'a été fait qu'une fois par le graphiste
De l'autre on a une une appli légèrement plus petite (ne contenant que la version grosse définition des icônes) pour laquelle le resize et fait à chaque affichage.

L'appli n'est installée (téléchargée) qu'environ une fois par utilisateur, par contre ses icônes seront affichées un nombre de fois incalculable pour chaque utilisateur: Je pense qu'il est plus rentable écologiquement de fournir une appli légèrement plus grosse (mais chargée une seule fois), qui contienne les icônes redimensionnées aux résolutions standards des périphériques, et qui n'aura pas besoin d'être redimensionner à chaque affichage.

En fait,la vrai raison est que les icônes ne sont pas qu'un resizing d'une même source: ça serait flou et illisible, elles sont en générale visuellement simplifiées par le graphiste pour rester lisible en basse résolution.
votre avatar
En fait si on compte tout je pense que le mieux c'est de "resizer".

1 Il y a le stockage sur la ou Les plateformes de distribution (Google Play, Apple, etc.). Ca coute du serveur mais aussi du temps de service pour la publication. Qui aime la Play console??? (nan répondez pas, on sait).


2 les transferts qui correspondent non seulement à la première installation mais aussi aux mises à jour que tout le monde met en automatique (vu que c'est proposé d'amblé ou même préconfiguré suivant le constructeur / opérateur). donc il n'y a pas qu'un seul transfert mais plein.

3A Prendre soin de la lisibilité sur ces résolutions est clairement négligeable tant ce sont des résolutions parfois supérieures au moniteur de base (ca va jusqu'à 8k quand même). Même pour des téléphones à petit budget on aura du mal à trouver moins que HD/FHD (supérieur / égal 1080p). Un RedMi contemporain s'inscrit dans ce cadre. Après les gout et le couleurs...


Mais aussi du fait que bien souvent on ne fait pas plusieurs icones visuellement différents. Temps, coût… autant utiliser les solutions en ligne et hop c'est réglé. Une recherche google "online Android app icon generator" plus tard et on fait ça dans l'heure.


3B C'est seulement pour l'app launcher. Les reste des icônes dans une application mobile sont souvent la même image mais redimensionnée dans le document. Et pour ne pas avoir de flou on prend les plus grandes résolutions (raisonnablement ou pas). Seules les grosses boites se prennent la tête à faire du multi résolution quand elles en ont envie. Ce n'est pas forcément possible dans tous les cadriciels non plus. Il faut maintenir tout ça aussi.

La consommation énergétique d'un "resizing" d'icone est complètement négligeable tellement l'accélération matérielle fait cela comme l'éclair. En fait de ne rien faire gaspille l'énergie. Un chip consomme (comme celui un pc) plus de courant en charge mais ne rien faire avec l'écran allumé est autant d'énergie perdue. Il y a toujours un minima de consommation. Celui-ci permet d'embarquer ces quelques traitements sans surplus de consommation visible.
votre avatar
Quand on voit des sites Prestashop qui demandent de régler la mémoire max de PHP à plus de 512Mo, parce que sinon l'administration plante, on se dit qu'en effet l'optimisation n'est pas au cœur des réflexions de certaine développements

Sérieux, 512mo c'était la taille d'un CD-ROM. On y mettait Encarta dessus, une encyclopédie avec des images...
votre avatar
Sérieux, 512mo c'était la taille d'un CD-ROM. On y mettait Encarta dessus, une encyclopédie avec des images...
Ben Prestashop c'est un site commercial avec des articles et des images :langue:
votre avatar
Je ne parle pas de la taille que prend le site sur le disque, mais de la taille de la mémoire nécessaire pour l'utiliser (tout particulièrement pour administrer le site, qui peut planter s'il n'a pas la dite mémoire, des fois juste pour éditer les produits !!!).
votre avatar
Des images ? des images pour des écrans 4/3 14" ? ou des 16/9 32" 4K ?
votre avatar
Rapport avec la mémoire nécessaire pour pouvoir administrer le site ? Le CD-ROM c'est pour donner un exemple de grandeur, rien à voir avec la taille du site sur le disque.

Anaïs Sparesotto : « On a habitué les internautes à des centaines de fonctionnalités inutiles »

  • Des fonctionnalités démultipliées

  • Revenir à l’essentiel

Fermer