L’impact du bloat web sur les utilisateurs d’appareils lents

• Depuis 2017, la hausse de la bande passante a, dans une certaine mesure, devancé l’augmentation de la taille transférée des sites ordinaires, mais les exigences CPU des applications web ont augmenté plus vite que les performances des appareils d’entrée de gamme, dégradant l’accessibilité du web même avec une connexion rapide
• Même avec une connexion 1Gbps, un Tecno Spark 8C subit des crashs du navigateur sur les forums Discourse, tandis que sur un Itel P32, des sites comme Discourse, Reddit, Shopify, Substack, Wix, Mastodon et Bluesky sont en FAIL ou pratiquement inutilisables
• Les mesures ont comparé le LCP* et le temps CPU du thread principal sur M3 Max, M1 Pro, Chrome avec throttling CPU 10x, Tecno Spark 8C et Itel P32; les scores PageSpeed Insights étaient faiblement corrélés à la vitesse réellement perçue
• Les sites simples ou anciens comme MyBB, phpBB, les anciens WordPress, HN et danluu.com fonctionnaient relativement bien même sur mobile d’entrée de gamme, tandis que les sites à chargement dynamique intensif comme Discourse, Medium, Reddit et Substack montraient de forts ralentissements au défilement, à la recherche et au tap
• Les utilisateurs d’appareils d’entrée de gamme dans des régions comme le Nigeria, l’Inde et l’Amérique latine sont de vrais utilisateurs du web; construire le web uniquement autour d’iOS et d’une connexion rapide exclut aussi bien les utilisateurs moins aisés que ceux disposant de PC peu puissants

---

Quand le CPU devient le goulot d’étranglement du web, plus que la bande passante

• En 2017, le bloat web nuisait fortement à l’utilisabilité sur les connexions lentes, puis la bande passante des connexions haut de gamme a rapidement augmenté, d’environ 50% par an selon Nielsen
• De nombreux utilisateurs ont encore une connexion lente et une grande partie du web moderne reste difficile à utiliser sur ces connexions, mais pour les sites ordinaires, la hausse de la bande passante a dans une certaine mesure dépassé l’augmentation des tailles transférées
• À l’inverse, les exigences de performance CPU des applications web ne se sont pas améliorées aussi vite que la bande passante, ce qui rend le web difficile à utiliser sur des appareils peu puissants même avec une bonne connexion Internet
• Un forum “moderne” basé sur Discourse peut même faire crasher le navigateur sur un Tecno Spark 8C, et sa réactivité entre deux crashs a été mesurée comme pire que l’utilisation d’un BBS avec un 286 à 8 MHz et un modem 1200 baud
• La charge utile compressée qui récupère les titres de messages dans Discourse est de 2.6 MB, soit environ 1000x plus de données transférées que par le passé, mais cela reste relativement léger sur une connexion 1Gbps
• Côté CPU, même un Tecno Spark 8C doté de 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) ne parvient pas à gérer Discourse, alors que ce CPU est environ 100000x plus rapide qu’un 286

Cibles de mesure et indicateurs

• Les appareils de test sont un M3 Max Macbook (14-core), un M1 Pro Macbook (8-core), un M3 Max avec throttling 10x dans Chrome DevTools, un Tecno Spark 8C et un Itel P32
• Pour avantager les appareils, le réseau utilise une connexion Internet 1Gbps et un routeur WiFi benchmarké avec une faible latence sous charge
• Les comparaisons incluent des blogs et microblogs, des forums et des plateformes pour petites entreprises
  • Blogs et microblogs: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
  • Forums: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
  • Plateformes pour petites entreprises: Wix, Squarespace, Shopify, WordPress
• Les principaux indicateurs sont la taille compressée transférée (wire), la taille décompressée (raw), le LCP* et le temps CPU du thread principal
• Le LCP* n’est pas le Largest Contentful Paint mesuré par Chrome; lorsque une grosse mise à jour visuelle n’est pas utile à l’utilisateur, il se base sur le moment où le contenu réellement utile apparaît
• Le temps CPU n’est pas un Core Web Vital, mais il est utilisé comme indicateur simple fortement lié à l’utilisabilité ressentie par les utilisateurs sur des appareils lents

L’écart d’utilisabilité révélé par le tableau

• danluu.com et HN fonctionnent rapidement sur tous les appareils testés
  • danluu.com: 6kB wire / 18kB raw, 0.4s LCP* / 0.3s CPU sur Tecno Spark 8C
  • HN: 11kB wire / 50kB raw, 0.5s LCP* / 0.5s CPU sur Tecno Spark 8C
• Les anciens forums basés sur PHP étaient bien meilleurs que les forums modernes sur les appareils lents
  • MyBB: 0.8s LCP* / 0.8s CPU sur Tecno Spark 8C
  • phpBB: 1.7s LCP* / 1.5s CPU
  • vBulletin: 4.4s LCP* / 4.8s CPU
  • Discourse: 15s LCP* / 26s CPU, et FAIL sur Itel P32
• Parmi les plateformes de blog, les anciens thèmes WordPress sont également bien plus rapides que Medium et Substack sur les appareils peu puissants
  • WordPress(old): 0.7s LCP* / 1.7s CPU sur Tecno Spark 8C
  • Medium: 2.8s LCP* / 33s CPU
  • Substack: 14s LCP* / 14s CPU
• Plusieurs sites modernes échouaient ou étaient pratiquement inutilisables sur Itel P32
  • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse et Reddit sont en FAIL
  • Threads: 28s LCP* / 66s CPU, Twitter: 24s LCP* / 43s CPU, Medium: 3.2s LCP* / 63s CPU
• Les pages qui consomment 10s+ CPU produisent une mauvaise expérience même après le chargement
  • Le défilement tombe à quelques FPS, et le délai des taps devient si long que l’utilisateur ne sait plus si son tap a été enregistré
  • S’il retape, le premier tap peut être enregistré tardivement, puis le second déclencher une action inattendue

Différence entre appareils réels et throttling CPU

• Le throttling CPU de Chrome DevTools est pratique, mais il n’approxime pas de façon cohérente les résultats obtenus sur de vrais appareils lents
• Dans la comparaison entre M3/10 et Tecno Spark 8C, les écarts variaient fortement selon les sites
  • danluu.com et Ghost étaient approximés de manière raisonnable
  • Medium, Substack et Twitter avaient un temps CPU environ 3x plus lent sur Tecno Spark 8C
  • Reddit et Discourse étaient environ 4x plus lents
  • Shopify affichait sur Tecno Spark 8C un résultat plus d’un ordre de grandeur plus rapide que sur M3/10
• Les pages lentes deviennent parfois plus lentes de manière superlinéaire à mesure que l’appareil ralentit, et la lenteur d’une page ne prédit pas bien celle d’une autre
• Discourse, Medium et Reddit ne semblent pas consommer beaucoup de CPU sur M3 et M1, mais figurent parmi les plus lents sur Tecno Spark 8C
• Reddit utilise ~90% CPU même lorsqu’on attend sans aucune interaction, ce qui fait afficher le CPU comme ∞

Les atouts des anciens sites et des pages simples

• Les anciens sites étaient généralement plus rapides que les sites récents, et ceux qui ont peu changé visuellement depuis 10 à 20 ans figurent parmi les plus rapides
• MyBB est 3.6x / 5x plus rapide que Discourse sur M3, et 19x / 33x plus rapide sur Tecno Spark 8C
• WordPress(old) a été mesuré 17.5x / 10x plus rapide que Medium sur M3 Max, et 4x / 19x plus rapide sur Tecno Spark 8C
• Ghost, bien que plateforme moderne sortie un an après Medium, constitue une exception avec des performances capables de rivaliser avec les anciennes plateformes
• NodeBB est aussi proche d’une exception parmi les forums modernes dans les tests en annexe
  • 0.3s / 0.4s sur M1
  • 3.4s / 7.2s sur Tecno Spark 8C
  • Il est bien plus rapide que Discourse, et le défilement comme les taps fonctionnent globalement après le chargement

Les pièges du chargement dynamique et de l’optimisation des métriques

• Les sites qui chargent d’abord une partie de la page puis récupèrent le reste dynamiquement, comme Discourse, Reddit et Substack, sont en pratique moins utilisables que ne le suggèrent les scores du tableau
• Sur les appareils lents, il est difficile de prévoir la distance de défilement, et faire défiler trop loin peut déclencher un chargement supplémentaire qui fige la page
• Les pages qui suppriment le contenu déjà parcouru deviennent pratiquement inutilisables sur les appareils lents
• Les pages à chargement dynamique peuvent difficilement utiliser telle quelle la recherche rapide Ctrl/Command+F du navigateur, et doivent implémenter leur propre recherche
  • La recherche de Google Docs se charge, depuis quelques mois ou environ un an, si tardivement qu’elle est difficilement utilisable juste après le chargement du document
  • La recherche de Discourse n’a jamais bien fonctionné sur des appareils lents ou même pas très rapides
• En théorie, du travail CPU initial pourrait accélérer les interactions ultérieures, mais les pages testées étaient lentes au chargement initial, aux chargements suivants et dans les interactions après chargement

La gamification du LCP

• Le LCP est à l’origine un indicateur visant à estimer le moment où l’utilisateur voit le contenu principal de la page, mais la mesure de Chrome se rapproche plutôt du moment où un grand élément est peint à l’écran
• Certains sites affichent rapidement un grand écran de chargement inutile pour l’utilisateur afin de réduire le LCP, puis fractionnent l’affichage du contenu réel en petites mises à jour pour qu’il ne soit plus compté comme LCP
• Discourse a publiquement introduit Discourse Splash et indique qu’un grand écran splash a fortement réduit le LCP lors des chargements lents
• La réponse officielle de Discourse allait dans le sens où une bannière de contenu réel plus grande que le splash serait défavorable au LCP
• Les cas où l’écart entre le LCP* basé sur le contenu utile et le LCP mesuré par Chrome est important sont Wix et Discourse
  • Wix: 6x sur M3, 12x sur M1, 3x sur Tecno Spark 8C
  • Discourse: 10x sur M3, 12x sur M1, 4x sur Tecno Spark 8C

Impact business de l’optimisation des performances

• Dans les grandes entreprises, l’amélioration des performances des sites et apps avait une valeur financière suffisamment importante pour être mesurée par A/B tests
• Même dans des holdbacks de longue durée, l’amélioration des performances apparaît comme une intervention ayant un effet relativement important sur la croissance et la rétention
• Chez Twitter, la latence p99 observée côté utilisateur était d’environ 60s non seulement en Inde et dans plusieurs pays africains, mais aussi aux États-Unis
• Dans chaque pays, il existe suffisamment d’utilisateurs avec des appareils ou connexions lents pour que le facteur limitant ressemble davantage à la patience des utilisateurs qu’à la distribution moyenne des appareils et connexions dans l’ensemble de la population
• Réduire de 60s à 50s sur des appareils lents peut aussi se traduire, pour les utilisateurs d’appareils haut de gamme, par un passage de 5s à 4.5s, avec un impact sur le chiffre d’affaires, la croissance et la rétention

Concevoir pour les appareils peu puissants

• Sur les appareils lents, ou avec une faible bande passante et des connexions instables, charger beaucoup de contenu d’un coup sous forme de page statique offre généralement la meilleure expérience
• Des attributs width, height et alt appropriés sur les images aident, mais le progressive JPEG n’a pas apporté de bénéfice particulièrement important
• Sur un appareil lent doté d’une connexion rapide, les pages statiques légères fonctionnent bien, et les pages dynamiques légères conçues avec la performance en tête peuvent aussi fonctionner
• Sur les pages lourdes, le chargement supplémentaire au défilement et l’interception de la recherche cassent les modèles d’interaction utilisables
• Substack peut avoir un LCP rapide pour un article sur iPhone 8, mais il existe des cas où il faut attendre 6s le chargement de la page suivante pour faire défiler sous l’en-tête, puis encore 1s~2s après cela
• À l’inverse, de grandes pages en HTML brut fonctionnent relativement bien même sur des appareils peu puissants
  • https://danluu.com/diseconomies-scale/: 0.1 MB wire / 0.4 MB raw
  • https://danluu.com/threads-faq/: 0.4 MB wire / 1.1 MB raw
  • Une page de texte de 1.1 MB fonctionne mieux sur appareils lents que la plupart des sites modernes
• La documentation de la bibliothèque standard Zig récupère tout le code source au départ et effectue le rendu localement, mais elle reste relativement réactive après 4.7s de CPU sur Tecno Spark 8C

Utilisateurs à faible revenu et accessibilité

• Le Tecno Spark 8C se trouve pour environ USD 50-60 au Nigeria et USD 100-110 en Inde, mais rapporté au revenu médian des ménages de ces régions, il représente une part bien plus importante qu’un iPhone de génération actuelle aux États-Unis
• À l’échelle mondiale, le Tecno Spark 8C est loin d’être proche des appareils les moins chers, et l’Itel P32 se situe également au-dessus des appareils les moins puissants réellement utilisés
• Selon Alex Russell, la part d’iOS est de 7% en Inde et de 6% en Amérique latine
• D’après la télémétrie Windows, la plupart des utilisateurs de laptops et desktops utilisent probablement des appareils peu puissants, plus lents qu’un iPhone récent
• Les téléphones “lifeline” fournis aux personnes sous surveillance correctionnelle peuvent être des iPhone 6 ou iPhone 8, mais beaucoup d’appareils sont moins puissants qu’un Itel P32, et leurs faibles plafonds de données peuvent, une fois épuisés, rendre difficiles la recherche d’emploi, le remplissage de formulaires d’aide sociale ou l’utilisation de Maps
• Les apps mobiles peuvent être téléchargées à l’avance lorsqu’une bonne connexion est disponible, mais si une application web doit télécharger plusieurs MB de JavaScript compressé à chaque visite, elle devient inutilisable sur une connexion limitée

Conditions expérimentales et limites

• Chaque site a été mesuré en cherchant l’expérience la plus “basique” possible
  • WordPress utilise la démo du thème par défaut actuel twentytwentyfour
  • Shopify utilise le premier thème affiché dans la liste des thèmes
  • Discourse, vBulletin, XenForo, phpBB et MyBB utilisent les pages trouvées comme forums officiels
• Ce travail a été mené comme un court projet de collecte et d’analyse de données en moins d’une journée, et ne reflète donc pas forcément les thèmes les plus fréquents ni la distribution des personnalisations réelles des utilisateurs
• Les laptops ont été testés avec environ 60% de batterie, débranchés, dans une pièce à 20°C, après les avoir laissés proches de l’équilibre thermique
• Les mobiles ont été testés avec une charge d’environ 100%, branchés, sans autres apps ni onglets
• En pratique, la plupart des utilisateurs verront probablement de pires performances sur les mêmes appareils à cause d’un plus grand nombre d’apps et de tâches en arrière-plan
• Les tailles ont été mesurées sur mobile; lorsque mobile et desktop reçoivent des assets différents, elles reflètent donc la taille des assets mobiles
• Le CPU a été mesuré comme le temps CPU du thread principal; le temps des autres threads a été enregistré, mais n’a pas été utilisé dans l’indicateur

Cas notables par site

• Wix ne stabilise pas correctement le défilement sur Tecno Spark 8C, et échoue de manière non déterministe sur Itel P32
• Les performances de défilement de Patreon sont pires que ne le suggèrent les chiffres du chargement initial, au point qu’il est pénible de retrouver d’anciens posts et qu’un index séparé des posts Patreon est maintenu
• Discourse gamifie fortement le LCP; même sur une connexion 1Gbps avec un M3 Max, le LCP mesuré par Chrome était de 115ms, mais le contenu réel se chargeait en 1.1s
• Bluesky affiche un écran vide sur Itel P32
• Les deux premiers cas réels d’utilisation de Shopify examinés étaient tous deux bien plus lents que la page de démo testée
• Tumblr produit une erreur JavaScript sur Itel P32, mais cela permet à la page de se charger plus vite, et le défilement ainsi que les clics sur les liens fonctionnaient
• MyBB ne propose pas de version mobile, ce qui peut le pénaliser auprès de Google, mais sur mobile lent, le défilement et les taps fonctionnent réellement bien
• Woo Commerce a été exclu du tableau, car il est difficile de le comparer à Shopify sur la seule performance du chargement initial; une comparaison distincte incluant les vrais parcours comme le panier et le checkout serait nécessaire

[GN⁺]

Commentaires Hacker News

• J’ai récemment utilisé un téléphone Android relativement lent, et même des pages web qui semblaient ne contenir que du texte et des images pouvaient être vraiment pénibles à charger.
  Le vrai goulet d’étranglement n’est pas tant le réseau que les traqueurs, les publicités et l’obésité du JavaScript.
  Sur un vieux téléphone lent, un navigateur complet comme Firefox mobile est lui-même trop lourd, ce qui pousse à utiliser un navigateur léger comme Firefox Focus ; mais comme on ne peut pas y installer d’extensions, on ne peut pas utiliser uBlock Origin, et l’expérience web se dégrade encore.
  Certains sites se plaignent si l’on n’utilise pas un navigateur « standard » et deviennent inutilisables, tandis que les entreprises poussent à installer leur application à la place.
  Il existait autrefois des versions simplifiées pour les appareils et connexions lents, mais elles disparaissent peu à peu, sans doute parce qu’il est difficile de faire tourner la publicité et les réseaux de pistage sans cette obésité JavaScript.

  • C’est un véritable dilemme : sans bloqueur de publicités, le web moderne est inutilisable.
    C’est encore pire sur les pages à défilement infini remplies de publicités aléatoires.
  • Même avec un navigateur standard, certaines entreprises sabotent volontairement leur site web pour pousser à utiliser leur application.
    Exemple récent : la boutique en ligne de Nike affichait une erreur inutile pendant le paiement, et le support s’est contenté de répondre « essayez l’application ».
    Les sites de réservation des compagnies aériennes européennes sont aussi des exemples typiques de sites de grandes entreprises qui tombent souvent en panne.
    En 2024, il est étrange de penser qu’être incapable de faire un site web fonctionnel malgré des ressources presque illimitées n’a pas d’impact négatif sur une marque.
  • Et dans neuf cas sur dix, ces applications sont probablement de simples coquilles de navigateur embarquant une copie partiellement hors ligne du site.
  • Il y a 10 ans, quand j’écrivais le code du site principal de nokia.com, nous détections de plusieurs façons si le chargement des ressources était lent, afin de définir un flag qui désactivait des fonctionnalités supplémentaires.
    Le site devait fonctionner dans tous les pays, et une bonne partie des téléphones les plus lents étaient fabriqués par cette entreprise.
  • J’ai encore un MacBook Pro de 2013, que j’ai gardé parce que c’est le meilleur clavier jamais fabriqué par Apple.
    Il n’est pas rapide, mais je n’ai pas de difficulté à utiliser les sites web ; ce n’est simplement pas aussi instantané que du matériel récent, tout en restant parfaitement utilisable.
    J’utilise toutefois uBlock Origin.
    Je me demande si ces appareils Android sont vraiment plus faibles, en pratique, qu’un MacBook d’entrée de gamme vieux de 11 ans.

• Je suis tout à fait d’accord avec l’idée de Dan selon laquelle il faut être conscient du niveau d’inégalités dans le monde, mais il faut aussi inclure les pays à revenu intermédiaire comme ceux d’Amérique latine et d’Asie du Sud-Est.
  Par exemple, certains utilisateurs ont un forfait de données mensuel limité à quelques Go et de la RAM/CPU au niveau d’un flagship américain d’il y a 10 ans.
  Discourse n’est pas totalement inutilisable pour eux, mais l’expérience risque d’être désagréablement lente.
  À mon avis, c’est surtout pour ce type d’utilisateurs que Dan considère que les améliorations progressives du CPU, de la RAM et du disque augmentent la participation de façon mesurable.
  Le graphique de Dan montre que les utilisateurs d’appareils ultra bon marché comme l’Itel P32 tirent peu de bénéfices des optimisations progressives.
  Ce qui pourrait aider, c’est une architecture de client complètement différente, sacrifiant fonctionnalités et raffinement pour fournir le code le plus léger possible : en gros, un mode lite/basique alternatif.
  Cela dit, cette approche a rarement bien fonctionné, car le problème d’empathie réapparaît : les développeurs américains jugent mal ce qu’il faut garder ou supprimer au nom des performances.

  • Je ne vois pas pourquoi cela devrait être une option « alternative ».
    Je me demande ce que Discourse apporte aujourd’hui par rapport à PhpBB ou aux forums DLang.
    À part un design adapté au mobile, dans un monde normal quelques lignes de CSS responsive devraient suffire.
  • Je vis dans un pays pauvre d’Asie du Sud-Est, et les gens qui ont de petits forfaits de données ne les économisent pas grâce à des sites web efficaces : ils utilisent le Wi-Fi, qui est partout.
    30 Go de données par mois coûtent 3,64 $, soit environ 4 à 6 heures de travail au salaire minimum.
    Le plus important, c’est que les gens n’utilisent pas les données de façon débridée comme en Occident.
    Il y a du Wi-Fi gratuit dans chaque café, restaurant, supermarché et centre commercial, et la plupart des gens demandent le mot de passe Wi-Fi avant même le menu.
    Je n’ai jamais vu ni entendu dire que des sites web consommaient les données trop rapidement.
    Cela ressemble à une inquiétude inventée par des gens qui n’ont jamais réellement vécu dans un pays en développement.
    Ici, quand les gens épuisent leurs données, c’est parce qu’ils regardent des vidéos sur TikTok, Instagram ou Facebook, pas à cause de l’obésité des sites web.
  • Si tous les sites étaient plus efficaces, cela pourrait aussi prolonger la durée de vie des ordinateurs portables et des PC, en retardant le moment où les utilisateurs non spécialistes se disent « mon ordinateur est devenu lent, je dois en acheter un nouveau ».
    Il en va de même pour les bloatwares installés avec les ordinateurs.
    J’ai récemment acheté un nouvel ordinateur portable et on m’a proposé une « optimisation » à 50 $.
    Imaginez qu’un concessionnaire automobile propose la même chose pour une voiture neuve : ce serait étrange.
  • Même sur un iPhone de la génération précédente, certains de ces sites sont vraiment à la limite du supportable.
    Dans une zone où le signal est mauvais, le problème est multiplié par 10.
    Je ne parle pas d’interfaces complexes où l’on ne voit qu’un tiers de l’écran à cause des en-têtes fixes et des publicités, mais de la taille même de sites assemblés n’importe comment jusqu’à ressembler à leur maquette de design.
    Même correctement réalisés, ces sites auraient déjà été lourds ; sur une connexion Internet lente, ils deviennent inutilisables, sans même parler du matériel lent.
    Il est difficile d’imaginer ce que cela fait d’utiliser Internet dans les conditions décrites, et j’espère seulement que ces personnes utilisent des sites locaux adaptés à leur bande passante et à leurs appareils, plutôt que de subir les déchets obèses auxquels nous avons droit.
  • Je vis au Canada, mon forfait de données était lui aussi limité à quelques Go, et je viens tout juste de remplacer un flagship vieux de près de 10 ans.
    La plupart des sites web sont proches de la torture.

• Il est intéressant de voir que la plupart des gens ne font que rejeter la faute sur leur chef ou sur de grandes entreprises effrayantes.
  Les développeurs n’admettent pas qu’il existe aussi un grand groupe de programmeurs web peu compétents, qui comprennent mal l’efficacité et ne semblent pas vouloir s’y intéresser.
  Autant que les chefs ou les dirigeants d’entreprise qui les ont forcés à créer de mauvais logiciels, eux aussi portent une part de responsabilité dans le triste monde des logiciels web.

  • J’ai déjà travaillé avec ce genre de personnes.
    Quand on leur demandait des détails concrets sur le « résultat » produit, à savoir HTML, CSS, JS, ils vous regardaient comme si vous parliez une autre langue.
    Ils venaient du monde des frameworks JavaScript et n’avaient pas vraiment réfléchi au résultat généré en dessous.
    Ma philosophie est presque exactement inverse : je me demande quel est le minimum de code maintenable nécessaire pour produire un résultat équivalent à un site web HTML+CSS+JS bien écrit à la main.
    En général, le résultat est plus petit de plusieurs ordres de grandeur.
    Quand ils m’ont demandé comment j’avais fait pour filtrer en temps réel 1 000 lignes de tableau tout en gardant un chargement rapide et un bon fonctionnement sur mobile, j’ai répondu que j’envoyais simplement toutes les données dès la première requête, puis que je masquais dynamiquement celles qui ne correspondaient pas au filtre.
    Le serveur web n’a qu’à envoyer les mêmes données mises en cache à tout le monde, et c’est aussi tout ce que fait le JavaScript exécuté sur le site ; pour eux, cela paraissait étrangement rapide.
    Dans leur solution basée sur un framework, quand on regardait le HTML de lignes de tableau similaires, 80 % était du boilerplate inutilisé.
    Le développement web s’est trop figé, et beaucoup de gens se sont beaucoup trop éloignés de l’essence des technologies web.
  • Il y a environ 5 ans, j’ai postulé dans une entreprise qui aidait des habitants de zones rurales africaines à vendre plus facilement ce qu’ils produisaient.
    Si les utilisateurs visés étaient principalement aux États-Unis ou dans l’UE, ne pas optimiser à l’excès pour du matériel peu puissant et des connexions instables, à faible bande passante et forte latence, pourrait se défendre.
    Mais si la cible est l’Afrique rurale, une optimisation agressive semble aller de soi.
    Pourtant, la page d’accueil chargeait une énorme image de 2 Mo réduite en CSS à 500×1000 pixels, et la suite était pire.
    Je ne me souviens pas de la taille exacte du payload JS, mais elle était de plusieurs Mo, et même si l’ensemble ressemblait surtout à une application backend traditionnelle à base de templates, le frontend était extrêmement lourd.
    Le concept était bon, donc j’ai postulé, mais la technique était épouvantable.
    Comme je n’ai même pas passé la première étape d’entretien, je ne sais pas pourquoi c’était ainsi, mais j’ai du mal à imaginer autre chose que des développeurs d’Europe de l’Ouest qui ne réalisaient pas vraiment ce qu’ils faisaient sur cet aspect.
  • Pour avoir travaillé dans une de ces « grandes entreprises effrayantes », la responsabilité leur revient à 100 %.
    Le point de départ, ce ne sont pas les développeurs, c’est le budget.
    Si la hiérarchie n’est pas à l’aise avec la technique ou n’a pas de culture d’ingénierie, elle prévoit généralement un budget pour les nouvelles fonctionnalités, mais sous-finance, voire ne finance pas du tout, la maintenance et la réduction de la dette technique.
    Même lorsqu’il existe un budget de maintenance, il est presque entièrement confié à une équipe de maintenance offshore moins chère.
    Une équipe produit développe une fonctionnalité pendant 6 mois, fait une « session KT » d’une heure avec l’équipe de maintenance offshore, puis lui transmet le code.
    L’équipe offshore dispose de quelques informations sur la fonctionnalité, mais pas assez pour gérer la dette technique existante ; elle se contente de faire en sorte que rien ne prenne feu.
    Quand ce cycle se répète 100 à 1 000 fois dans une organisation, on arrive vite à un frontend qui aurait dû faire au maximum 250 000 lignes et qui en fait 2 millions.
    Même si les meilleurs ingénieurs rejoignent une nouvelle équipe fonctionnalité, ils doivent travailler dans la boîte déjà construite.
    Si les maquettes et les éléments ne correspondent pas, c’est peut-être que la maquette est incorrecte, que le kit UI a été mis à niveau ou qu’il faut refactorer le kit UI existant, mais il n’y a pas de budget pour cela.
    On demande donc à l’équipe de copier le composant et de le modifier pour l’adapter à sa fonctionnalité.
    Au moment de le transmettre à l’équipe de maintenance, la nouvelle équipe ne veut pas toucher au travail sur les fonctionnalités existantes, donc elle laisse tel quel.
    Les dirigeants non techniques ne voient pas la différence, et après des années d’équipes qui copient-collent pour faire rentrer de nouvelles fonctionnalités, la base de code se retrouve avec plus de 50 composants appelés « Button ».
  • Ce n’est pas juste.
    Si l’équipe compte des développeurs expérimentés qui valorisent l’efficacité, et qu’ils poussent pour un site plus efficace ou le conçoivent ainsi dès le départ, la page peut s’améliorer.
    Mais la plupart du temps, c’est un problème d’incitations.
    Si la direction ne s’en soucie pas, les programmeurs préféreront probablement faire quelque chose qui fonctionne en deux fois moins de temps et vider le backlog plutôt que de passer du temps à améliorer l’efficacité.
  • En général, les mauvais logiciels web vont de pair avec de mauvais contenus.
    Les appareils lents sont donc un excellent filtre pour éviter les déchets.

• Je viens seulement de passer d’un flagship LG vieux de 6 ans à un nouveau Galaxy, et l’écart de performances était énorme.
  Cela ne devrait pas arriver.
  C’était un appareil très haut de gamme à sa sortie, il n’est pas si vieux et il fonctionne encore comme neuf.
  Le fait que des Galaxy S9 utilisés pour les tests rencontrent les mêmes difficultés montre que le problème ne vient pas seulement de mon téléphone.
  J’aurais aimé qu’Amazon fasse partie des tests.
  D’après mon expérience, le site web d’Amazon fait partie des pires du pire sur les appareils mobiles de plus de 4 ans.
  Même sur du matériel mobile haut de gamme relativement récent, c’était le seul site que je consultais régulièrement qui était quasiment inutilisable.

  • Après avoir utilisé deux appareils Snapdragon 835 vieux de 7 ans, j’ai constaté que la RAM et une version récente d’Android font une grande différence.
    J’utilise au quotidien un OnePlus 5 sous Android 14 via LineageOS, et l’expérience utilisateur pour les tâches hors jeu est tout à fait correcte.
    Ce téléphone a 6 Go de RAM, ce qui le rapproche encore des modèles milieu de gamme actuels.
    Mon seul reproche est qu’il a fallu remplacer la batterie et que démonter le téléphone est pénible.
    En revanche, un Galaxy S8 avec le même SoC, 4 Go de mémoire et Android 9 stock modifié par Samsung saccade sans arrêt.
    Les 2 Go de mémoire d’écart peuvent jouer, mais la différence entre les deux téléphones est le jour et la nuit.
    Je ne sais pas si la gestion mémoire d’Android 14 est bien meilleure que celle d’Android 9, ou si les logiciels lents et boursouflés de Samsung tirent l’appareil vers le bas.
    Quoi qu’il en soit, il est agaçant de voir que beaucoup d’entreprises ne testent pas sur des appareils anciens ou bas de gamme.
    Si l’on s’adresse à des utilisateurs du monde entier, il faut constater que la majorité de la planète n’utilise pas le dernier flagship.
  • Je me demande si vous avez essayé de désactiver JavaScript sur Amazon.
    En réalité, ça ne fonctionne pas si mal.
    Bien sûr, je suis d’accord qu’on ne devrait pas avoir à faire ça.
  • Je suis allé récemment au Brésil, on m’a arraché mon nouveau téléphone des mains, et j’utilise maintenant un téléphone de secours vieux de 4 ans ; honnêtement, je ne vois pas la différence.
    Cela dit, j’utilise Firefox avec tous les bloqueurs de publicité, donc ça doit aider.
  • J’ai un Palm Phone, et à ce stade je considère que la navigation web y est quasiment impossible.
  • Sur un iPhone 8 avec la dernière version d’iOS 16, Amazon ne pose aucun problème

• La technologie d’aujourd’hui est trop indifférente même aux personnes peu à l’aise avec la technologie
  Les smartphones en sont, à mon avis, l’exemple le plus représentatif
  J’ai vu énormément de gens qui savent à peine utiliser leur appareil, voire pas du tout, et pour eux tout cela ressemble à de la magie noire
  Le plus gros problème est la dépendance excessive à la navigation par gestes, qui est invisible et donc comme inexistante
  Sur l’iPhone, on peut tant bien que mal découvrir la barre de gestes, mais il n’y a aucune notion de centre de notifications ou de centre de contrôle
  Ces gens ne sont pas stupides, et ils peuvent être bien meilleurs que moi dans d’autres domaines
  En technologie, le problème n’est pas le manque d’effort, mais le manque d’interfaces intuitives

  • Le fait qu’un nouvel iPhone ne soit accompagné d’aucune documentation n’aide pas
    Pour voir la vraie documentation, il faut aller jusqu’à la page de documentation du site d’Apple, et en fouillant un peu plus on tombe sur une page qui montre vaguement seulement quelques gestes possibles
    Sur quand et quel geste utiliser, il n’y a guère plus qu’un exemple en une phrase
    Et cela ne concerne que le système d’exploitation
    Je me demande combien d’apps fournissent avec elles une documentation expliquant comment les gestes sont utilisés dans leur propre application
    https://support.apple.com/guide/iphone/learn-basic-gestures-...
  • J’ai déjà vu des personnes d’âge moyen ou plus âgées qui n’auraient sans doute pas su utiliser un lecteur de cassettes et auraient trouvé une machine à écrire difficile
    Elles ont pourtant clairement grandi entourées de ce genre d’appareils
    Je ne pense donc pas que ce soit uniquement la faute de la technologie moderne
  • Vu de l’extérieur, au moins pour les interfaces des produits tape-à-l’œil, tout semble conçu selon une approche taille unique pour tout le monde
    Au lieu de laisser les utilisateurs choisir un design et des interactions qui leur conviennent, les designers ou les responsables produit agissent comme s’ils savaient ce qui est le mieux pour tous les utilisateurs
  • Le problème de dépendance excessive à la navigation par gestes n’est pas un problème des smartphones, mais un problème propre à l’iPhone
    C’était l’un de mes plus gros griefs après être passé depuis Android
    Où est le bouton retour, où est le bouton accueil, et où sont les boutons tout court ?
    Je déteste vraiment l’obsession d’Apple pour le minimalisme, et quand ce téléphone rendra l’âme, je retournerai sur Android

• Cet article est, par défaut, difficile à lire pour moi, qui ai 48 ans, sur desktop
  En ajoutant ce qui suit au body dans les outils de développement, il devient lisible
  font-size: 18px;
line-height: 1.5em;
max-width: 38rem;
  On voit alors à quel point c’est plus lisible et plus beau
  Je lis beaucoup d’articles de Dan Luu, mais je dois les modifier comme ça à chaque fois
  Sérieusement, les techniciens : rendre une page plus lisible ne coûte que 64 octets de plus

  • J’ai 53 ans et j’ai dépassé d’au moins cinq ans le moment où j’aurais dû me faire prescrire des lunettes ; même maintenant, mes lunettes sont posées au bout du nez et je dois parfois en ajuster l’angle
    Cette page était à peu près correcte, il suffisait de zoomer avec CTRL +
    La page est presque du texte brut et il y a très peu d’interactions
    Vous avez une solution adaptée à votre cas d’usage, et moi j’ai la mienne
    Un lecteur malvoyant peut aussi y accéder avec sa propre solution
    Comme la source est simple, les solutions d’accessibilité restent raisonnablement simples elles aussi
    À mon avis, Dan sait comment communiquer efficacement
    Il garde les choses simples et ne part pas du principe qu’elles seront forcément lues visuellement
    On peut facilement modifier soi-même l’affichage selon ses besoins
    Si ce mode d’affichage ne vous plaît pas, vous pouvez le reformater vous-même avant de lire
    En somme, Dan fournit son message sous forme de flux de texte simple et facile à manipuler
  • Je pense que la correction proposée est raisonnable, mais si Dan Luu avait lui-même ajouté ces règles CSS, il y aurait eu ici des réactions déplorant la faible densité et les « marges excessives »
    Le lectorat de Luu préfère probablement, dans l’ensemble, une approche relativement sans style
  • Je ne suis pas d’accord
    Les utilisateurs peuvent changer la taille de la fenêtre, la taille de la police, les couleurs, etc., selon leurs préférences
    Ils ne devraient pas avoir à le faire fichier par fichier à chaque fois, et il devrait être permis d’ajouter et d’utiliser un fichier CSS utilisateur applicable à plusieurs fichiers
  • Si la police est trop petite, on peut modifier la taille de police par défaut du navigateur
    C’est dans la page des paramètres par défaut de Firefox
    Si un site force font-size: 18px;, le texte peut au contraire devenir plus petit pour les utilisateurs qui ont choisi une police plus grande dans leur navigateur
  • Je suis d’accord sur le fait qu’il faudrait ajouter un minimum de CSS
    Cela dit, on peut aussi utiliser le mode lecture du navigateur : au lieu de passer par plusieurs étapes dans les outils de développement, il suffit d’un clic

• À titre de référence, Raspberry Pi 3 ne permet pas d’utiliser YouTube
  C’est devenu comme ça au cours de l’année écoulée ; auparavant, on pouvait « regarder » des vidéos à environ 10–15 FPS, ce qui suffisait pour voir des vidéos de réparation dans l’atelier
  Quand le Raspberry Pi Model B, c’est-à-dire le tout premier modèle, est sorti, on pouvait lire des vidéos 1080p depuis le stockage, regarder YouTube et même jouer
  Je ne sais pas ce que fait YouTube, ni ce que font les autres services
  Si l’on prend au sérieux la crise climatique et le changement climatique, il faudrait examiner très strictement ce genre de manœuvres de Google et Meta
  Brûler des cycles CPU au nom du profit — à vue de nez, à cause de l’adtech — au point de casser YouTube sur des appareils basse consommation devrait être vivement critiqué dans la presse, et il faudrait utiliser des services plus efficaces même si l’expérience utilisateur globale est moins bonne

  • Ça pourrait être dû à l’absence de décodage vidéo matériel, non ?
    Le Pi3 dispose d’une accélération matérielle x264, mais YouTube a commencé depuis un moment à utiliser d’autres codecs
  • YouTube devient clairement de plus en plus lourd
    Même sur un MacBook Air Intel de début 2021, des vidéos se figent aléatoirement sous charge moyenne, ce qui n’arrivait pas avant
  • Toutes les données indiquent que la consommation d’énergie des appareils clients est proche d’une erreur d’arrondi en matière de contribution au changement climatique
    S’attaquer à ce point pour résoudre le changement climatique a aussi peu de sens que d’interdire les pailles en plastique ou les sacs en plastique
  • Pour parcourir le site, j’utilise Invidious, et pour les vidéos elles-mêmes, un script qui désobfusque afin d’obtenir l’URL réelle du flux puis la transmet à VLC
    Autre point de comparaison : le YouTube d’il y a 10 ans aurait été parfaitement utilisable sur ce matériel
    Le coupable, c’est l’enflure générale du Web, et plus précisément les monstres d’abstraction devenus courants en JS
    Même à quelqu’un qui ne croit pas du tout à la « crise climatique », on peut dire qu’avec le temps, le savoir-faire et la qualité ont disparu, ce qui a créé ce chaos
    C’est pourquoi je pense que c’est un sujet sur lequel tout le spectre politique peut s’accorder
  • Il faudrait un organisme de surveillance qui suive le poids des pages par site et par utilisateur, et qui rende les noms publics pour leur faire honte
    Ça pourrait fonctionner à la manière de Consumer Reports, ou être un add-on qui se comporte comme les audiences Nielsen

• La personne de chez Discourse est un cas typique de quelqu’un qui conçoit un produit en fonction du monde dans lequel elle aimerait exister, et non du monde réel dans lequel nous vivons
  Il existe des milliards d’appareils équipés de SoC Qualcomm, ils continueront d’exister et d’être fabriqués et vendus
  Aucune plainte n’y changera quoi que ce soit
  Il faut l’accepter et optimiser pour ces appareils
  Les utilisateurs de ces appareils se fichent des plaintes des développeurs ; si le logiciel plante, ils penseront simplement que ce sont des développeurs incompétents

  • Ou bien on peut choisir la voie du « ce n’est pas fait pour vous »

• D’ordinaire, j’aime les articles de Dan Luu, mais celui-ci m’a semblé à côté de la plaque
  Le tableau LCP/CPU était bon, mais ensuite ça dérive vers de la psychologie de comptoir
  À partir de quelques commentaires aléatoires du fondateur de Discourse, il demande au lecteur d’imaginer l’attitude des ingénieurs logiciels
  Il va jusqu’à tirer Knuth vers le bas à partir de ses propos sur les performances mono-cœur contre multi-cœur et sur Itanium, alors que ce sont de vieux points de débat académiques
  J’ai trouvé l’article trop mou, et trop dépendant de querelles Internet pour vraiment tenir debout

  • Mais ce genre d’attitude existe bel et bien, non ?
    Les propos du fondateur de Discourse sont simplement très révélateurs
    Si vous avez utilisé le Web récemment, il est devenu d’une lourdeur inimaginable, au point que Google en est maintenant à dire qu’un Largest Contentful Paint de 2,4 s est rapide : https://blog.chromium.org/2020/05/the-science-behind-web-vit...
    Cette donnée date d’il y a 4 ans, donc la situation est probablement pire aujourd’hui
    Pas besoin de chercher bien loin : YouTube charge 2,5 Mo de CSS sur desktop, et le fondateur de Vercel a présenté comme ultra-rapide un site qui met 20 secondes à charger dès qu’on impose une légère limitation : https://x.com/dmitriid/status/1735338533303259571
  • J’ai rarement vu des entreprises prendre la performance au sérieux
    Personne ne se moque d’un simple service API pour le frontend qui répond en 500 ms
    Je me demande aussi combien d’ingénieurs savent combien leur coûte leur cloud et s’en préoccupent vraiment
  • Je pense que Knuth a raison dans une certaine mesure
    La parallélisation actuelle n’est pas utilisée dans 90 % des logiciels, sauf pour des cas d’usage spécialisés ou lorsqu’on exécute le même programme monothread sur plusieurs éléments de données
    Les langages de programmation comme le matériel prennent mal en charge le parallélisme fin, et rendre un logiciel classique plus rapide avec une approche parallèle est très difficile
  • Je ne vois pas où est la polémique
    Luu a même écrit de façon plutôt indulgente
    Knuth se plaignait surtout de la fin d’un repas gratuit qui avait duré des décennies
  • Je trouve que le résumé est plutôt réussi
    Jeff Atwood n’est qu’un exemple choisi
    Des penseurs célèbres du développement Web, avec beaucoup de followers, continuent de déverser des points de vue similaires, et beaucoup de leurs followers les acceptent tels quels

• Toutes les entreprises ont cessé de s’en soucier, en particulier celles qui étaient autrefois à l’avant-garde des standards et des bonnes pratiques de conception web, comme Google et Apple
  Google a récemment mis fin à HTML Gmail, qui fonctionnait encore rapidement et correctement sur un téléphone Android de 2008 avec 256 Mo de RAM et sur de vieilles versions de Firefox
  Sans surprise, la nouvelle version obèse en JavaScript fait planter le navigateur
  C’est un exemple extrême, mais les téléphones d’entrée de gamme ont 2 Go de RAM, et il est désormais difficile d’attendre des performances raisonnables en naviguant sur le web avec ce genre d’appareils
  Le web mobile est lamentable, et c’est voulu pour pousser les utilisateurs vers des apps “natives”
  Parce qu’il devient plus facile pour des entreprises comme Apple et Google de collecter des données et d’afficher des publicités

  • C’est certainement en partie vrai, mais je ne sais pas quoi penser d’Amazon ou de Decathlon, la grande chaîne européenne de sport et d’outdoor
    Leurs sites sont horribles sur mobile, et celui de Decathlon est aussi horrible sur un ordinateur de bureau qui n’est pas très performant
    Pourtant, ils ne mettent même pas vraiment leur app en avant, donc il faut sans doute y voir simplement de l’incompétence
    On dirait que les développeurs ne testent tout que sur des machines haut de gamme branchées directement au backbone
  • Jeudi, Google a mis fin au seul “produit” utilisable
    RIP Google
    Le nouveau Reddit est inutilisable, et old Reddit est trop vieux
    Twitch est à peine utilisable à cause des problèmes de chat et de flux vidéo
    La liste est longue
    Quand on possède déjà la formule finale, tout changement devient un mauvais changement destiné à garantir des emplois
    Un jour, les singes sur cette motte de terre comprendront que les emplois et l’argent n’existent pas, mais il sera alors trop tard
    Non, c’est maintenant
    RIP Humans