Une page de 14 kB peut se charger bien plus vite qu’une page de 15 kB (2022)

• Maintenir la taille d’un site web sous les 14 kB peut réduire fortement le temps de chargement par rapport à 15 kB
• Ce phénomène est causé par l’algorithme de slow start de TCP, qui crée une différence de vitesse perceptible à cause de la limite de données envoyées lors de la première transmission
• 14 kB correspondent à la capacité des 10 paquets TCP que la plupart des serveurs envoient au départ
• Dans des environnements à forte latence comme l’internet par satellite, un aller-retour supplémentaire (RTT) peut entraîner plus de 612 ms de délai
• En pratique, il est efficace pour l’optimisation des performances web de garder le contenu principal sous les 14 kB, ou de placer les ressources critiques dans les 14 premiers kB

---

Vue d’ensemble et principe clé

• Il est bien connu que plus un site web est petit, plus il se charge vite
• En revanche, le fait qu’un passage de 14 kB à 15 kB provoque une différence majeure sur le temps de première réponse est moins intuitif
• La différence de vitesse entre une page de 15 kB et de 16 kB est minime, mais entre 14 kB et 15 kB, l’écart peut atteindre 612 ms

Qu’est-ce que TCP

• Le Transmission Control Protocol (TCP) fonctionne au-dessus d’IP (Internet Protocol) et garantit la fiabilité des paquets
• Lors d’une requête HTTP, le navigateur web envoie plusieurs paquets TCP
• Avec IP seul, il est impossible de savoir si les paquets sont bien arrivés, donc TCP fournit un mécanisme d’accusé de réception des paquets (ACK)
• Le serveur envoie d’abord une petite quantité de paquets, puis transmet des paquets supplémentaires après réception d’un ACK du navigateur
• En l’absence d’ACK, une procédure de retransmission des paquets est déclenchée

Qu’est-ce que le slow start de TCP

• Le slow start de TCP est un algorithme dans lequel le serveur augmente progressivement la quantité de paquets envoyés afin d’évaluer la qualité de la connexion réseau (bande passante)
• Au début de la connexion, le serveur n’envoie qu’un petit nombre de paquets (généralement 10)
• Si l’ordinateur du visiteur renvoie correctement les ACK, le volume d’envoi de paquets est doublé
• Si des ACK manquent, les paquets sont ensuite envoyés à une vitesse plus lente
• L’algorithme réel varie dans ses détails selon les implémentations, mais le principe reste le même

Pourquoi la limite de 14 kB

• La plupart des serveurs envoient 10 paquets TCP d’un coup pendant le slow start
• La taille maximale d’un paquet TCP est de 1500 octets, mais après retrait de l’en-tête (40 octets), il reste 1460 octets de données utiles
• Donc 10 x 1460 = 14600 octets (environ 14 kB), soit la limite maximale du premier envoi
• Si un site web ou une ressource critique tient sous les 14 kB (ou quelques dizaines de kB de données source avant compression), il peut s’afficher sans délai d’aller-retour supplémentaire au démarrage

À quel point un aller-retour peut-il ajouter du délai

Exemple de l’internet par satellite

• Un exemple représentatif d’environnement à forte latence est celui des utilisateurs de l’internet par satellite (plateformes pétrolières, paquebots de croisière, etc.)
• Lorsqu’un téléphone demande une page d’accueil, le trajet routeur → antenne satellite → satellite en orbite → station au sol → serveur prend de plusieurs dizaines à plusieurs centaines de ms sur chaque segment
• L’aller-retour complet inclut deux trajets dans l’espace, le passage par les segments réseau et le traitement côté serveur, ce qui ajoute environ 612 ms de délai
• Avec HTTPS, cela peut monter jusqu’à 1836 ms à cause des handshakes supplémentaires

Latence sur les réseaux terrestres

• Des latences de 100 à 1000 ms peuvent aussi apparaître sur les réseaux mobiles comme la 2G ou la 3G
• Des délais supplémentaires peuvent être causés par la congestion, la surcharge du serveur, la perte de paquets et d’autres conditions réseau

Stratégies d’optimisation web avec la règle des 14 kB

• L’essentiel est de rendre le site web ou la page aussi léger que possible
• L’idéal est de concevoir chaque page pour que son volume transféré compressé reste sous les 14 kB
  • Avec compression, le contenu réel peut aller jusqu’à ~50 kB
• Réduire les vidéos en lecture automatique, les pop-ups, les trackers, le JS/CSS inutile et la plupart des éléments superflus permet généralement d’atteindre cet objectif
• Si faire tenir toute la page dans 14 kB est difficile, il est important de placer en priorité les ressources critiques et le contenu principal (CSS, JS, texte principal, etc.) dans les 14 premiers kB
• Les en-têtes HTTP (non compressibles) et les images (chargement strictement nécessaire / uniquement dans la zone visible ou avec placeholders) comptent aussi dans ces 14 kB

Exceptions à la règle des 14 kB et enjeux des protocoles récents

• La règle des 14 kB n’est pas une simplification excessive, mais il existe quelques exceptions
  • Certains serveurs étendent la fenêtre initiale à 30 paquets
  • Le handshake TLS peut permettre une fenêtre plus grande
  • Le nombre de paquets transmissibles peut être mis en cache selon la route, ce qui permet d’en envoyer davantage lors d’une connexion suivante
• Même avec HTTP/2, la pratique qui consiste à démarrer à 10 paquets via le slow start de TCP change peu dans l’ensemble
• Avec HTTP/3 et QUIC aussi, la règle des 14 kB reste officiellement recommandée

Résumé et ressources de référence

• Les fondements techniques et des explications supplémentaires peuvent être consultés via les différents liens
• Première publication : 2022-08-25, dernière modification : 2022-08-26, auteur : Nathaniel, tags associés : performance web, HTTP, TCP

Liens de référence

• Structure des trames Ethernet et des en-têtes TCP, documents complémentaires sur la latence et la bande passante, spécifications TCP/QUIC, etc.

[GN⁺]

Avis sur Hacker News

• Les développeurs logiciel devraient s’intéresser un peu plus à la couche média ; j’ai surtout trouvé très pertinent ce que l’auteur souligne sur la fiabilité et la latence de la 3G/5G. Les radios impliquent presque toujours des retransmissions, et dans la plupart des communications HTTP, les paquets doivent arriver dans l’ordre pour que l’UI se mette à jour. En pratique, même une seule requête REST n’est réellement traitée en un seul paquet que si la requête et la réponse font moins de 1400 octets. Au-delà, cette requête « unique » est en réalité fragmentée en plusieurs paquets. Si l’un d’eux a un problème, l’écran ne peut se rafraîchir correctement que lorsque tous les paquets arrivent dans l’ordre. Si vous voulez tester, activez le mode 3G et la perte de paquets dans les outils de développement de Chrome : vous verrez qu’une toute petite optimisation peut déjà fortement améliorer la réactivité de l’UI. C’est donc un argument convaincant pour garder l’API et l’UI aussi petites que possible

• Le poids transféré de ma page d’accueil est de 7,0 kB une fois compressé

  • /
  • main.css
  • favicon.png
  • total 7,0 kB La liste du blog et l’ensemble du site sont générés avec mon générateur de site statique maison (open source : site.lisp, en Common Lisp). Pour les articles de maths, j’utilise KaTeX en rendu côté client, ce qui ajoute alors 347,5 kB
  • katex.min.css 23,6 kB
  • katex.min.js 277,0 kB
  • auto-render.min.js 3,7 kB
  • KaTeX_Main-Regular.woff2 26,5 kB
  • KaTeX_Main-Italic.woff2 16,7 kB
  • ajout total 347,5 kB Je réfléchis à passer KaTeX en rendu côté serveur un jour. Ce blog est mon projet passion depuis l’époque de l’internat universitaire. J’ai écrit moi-même tout le HTML, les templates et le CSS, et je compose toujours chaque page avec soin pour n’y mettre que les éléments strictement nécessaires, afin de conserver un poids réduit
  • Ma page d’accueil
  • Collection d’articles de maths
    • Je ne dis pas qu’il ne faut pas utiliser une meilleure approche, mais la latence générée par le rendu côté client quand des composants dynamiques comme les expressions LaTeX se chargent est à peine perceptible — voire pas du tout — pour l’utilisateur moyen. L’optimisation excessive est aussi un problème. Toute cette recherche de performance motivée par le SEO apporte peu de bénéfices au regard du temps investi, sauf si l’on exploite un service avec des millions de vues. C’est comme piloter un bateau sans équipage avec les marées en mer tout en se préoccupant de son aérodynamique. Quand les ressources sont limitées, il faut regarder le coût et le bénéfice globaux : l’optimisation n’est pas toujours le meilleur choix
    • S’il y a peu de contenu mathématique mais que vous utilisez quand même KaTeX, cela vaut peut-être la peine d’envisager MathML(mathml-core) comme alternative
    • Je ne comprends pas pourquoi il faudrait absolument rendre les formules mathématiques ou les expressions LaTeX avec du JS côté client. Pourquoi ne pas les convertir à l’avance en HTML/CSS et les intégrer déjà pré-rendues ?
    • Une autre idée serait de charger les bibliothèques lourdes après le rendu initial de la page, ou de ne charger les graphismes des formules en SVG que lorsqu’ils entrent dans le viewport. C’est mon avis

• L’objectif des 14 kB est assez ambitieux, mais l’idée de rester dans les 10 paquets initiaux est intéressante aussi. Il existe un projet comme 512kb.club qui se concentre, comme moi, sur le poids des sites web. On y compare la taille des sites comme un score de golf. Mon site (anderegg.ca) totalisait 71 kB toutes ressources confondues avant inscription. Grâce à ce projet, j’ai aussi découvert Cloudflare Radar, qui propose un bon outil pour analyser les sites et mesurer le poids des pages. Son but principal est d’être un tableau de bord global d’Internet, mais il inclut aussi un outil d’analyse de taille de page

  • J’aimerais poser la question du point de vue utilisateur : à quoi servent les 500 kB restants ? Personnellement, 90 % de ce dont j’ai besoin, c’est du texte, et pour le reste des graphiques vectoriels suffisent. On peut déjà mettre pas mal de texte et de graphismes dans 14 kB, alors à quoi servent les 500 restants ?
  • 512 kB est un seuil réaliste. Je l’applique aussi à mon site web. Un site au niveau des 14 kB a déjà dépassé les standards du web
  • Pour un site personnel, 512 kB est tout à fait atteignable. Ma prochaine cible est 99 kB (moins de 100 kB). Avec quelques week-ends de travail, c’est faisable sans difficulté. Mon site est classé Orange sur le seuil 512 kB

• Si vous voulez faire une expérience plus amusante avec ça, la taille de la fenêtre initiale (IW) peut être définie côté serveur. Par exemple, on peut l’ajuster comme ceci

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 En cherchant un peu, on voit qu’aujourd’hui certains CDN donnent une fenêtre initiale allant jusqu’à 30 paquets (45 kB)
  • Il y a 13 ans, même 10 paquets étaient considérés comme de la « triche ». Voir à ce sujet ici et le blog de Ben Strong (archive)
  • Je serais curieux de voir une source qui confirme que la fenêtre initiale des CDN est de 30 paquets
  • On peut aussi la régler à 1000 paquets, comme un « mauvais citoyen »... mais l’inconvénient, c’est que cela peut créer un goulot d’étranglement pour quelqu’un sur une connexion dial-up ou affectée par le bufferbloat

• Cela s’applique aussi à ce qui est expliqué dans le billet suivant : Blog Cloudflare - le phénomène où des FAI russes n’autorisent que les 16 premiers KB, rendant la plupart du web inutilisable. Selon l’analyse de Cloudflare, des FAI russes limitent le trafic de leurs utilisateurs nationaux, de sorte que seuls les 16 premiers kB de chaque ressource web se chargent

• L’intersection entre les gens qui ne savent pas ce qu’est TCP Slow Start et ceux qui s’intéressent suffisamment au sujet pour se préoccuper jusqu’aux moindres retards de chargement d’un site web est très faible. Une startup doit d’abord se concentrer sur le fait d’être une startup, et seules les grandes entreprises ont les moyens de s’obséder avec ce type d’optimisation

  • Si on adopte une approche du type « on se concentre d’abord sur l’essentiel, donc on n’a pas le temps de s’occuper de l’optimisation des performances », alors on ne s’en occupera jamais. C’est pour ça que la majorité des applis et des sites actuels sont lents et médiocres
  • Si c’était vrai, alors les logiciels de Microsoft devraient toujours fonctionner de manière parfaitement optimale et avec l’efficacité maximale
  • Conceptuellement, cela paraît juste. Mais si Evan Wallace de Figma ne s’était pas obsédé pour les performances, Figma ne serait pas ce qu’il est aujourd’hui. Parfois, la « performance » elle-même devient une fonctionnalité majeure du produit
  • Ce n’est pas forcément un choix : on peut aussi faire en sorte que cela arrive par défaut. J’utilise datastar pour ma démo à 1 milliard de cellules et pour [1] les cases à cocher, et tout tient à un peu plus de 10 kB. La différence est énorme sur réseau mobile et en 3G. Dans mes tests, au-delà de 14 kB, il fallait 3 secondes de plus sur une connexion de mauvaise qualité. Comme le mainteneur de datastar a même pris en compte TCP slow start, j’en profite sans effort particulier
    • checkboxes.andersmurphy.com
  • Je ne pense pas que la taille de l’entreprise ait grand-chose à voir avec l’optimisation des performances. Au contraire, les grandes entreprises sont souvent plus lentes

• Ma page d’accueil fait 17,2 KB ! (hors dépendances) Pour une page personnelle, j’ai vraiment travaillé l’optimisation à fond et j’ai même obtenu un score parfait de 100 à Lighthouse. Je pensais que ce serait impossible avant d’y arriver. Au fait, c’est fait avec Rails. Ce type d’optimisation vaut vraiment le coup. L’expérience d’une page qui apparaît à la vitesse de l’éclair, sans aucune sensation de latence, est en soi très satisfaisante

  • Le fait que news.ycombinator.com se charge instantanément procure aussi un énorme confort psychologique ; du coup, on l’ouvre presque automatiquement à chaque pause
  • J’ai énormément optimisé le code d’un template utilisé par des milliers de sites, et j’ai obtenu 100/100/100/100 à Lighthouse. Même sur mobile, c’est un 100 parfait. Le chargement initial est bien plus lourd que 17,2 kB, autour de 120 kB, mais le secret, c’est d’éliminer toutes les requêtes HTTP inutiles, de n’exécuter le JS que pour la zone "above-the-fold", et de retarder au maximum tout le reste via lazy eval, defer, etc. Le JS/CSS est inline, et même les widgets tiers sont traités en mode « façade » avec une simple icône de popup, en repoussant les vraies requêtes. Le backend SSR aide beaucoup aussi. J’avais même 100 avec une vidéo d’arrière-plan Vimeo, mais c’est impossible avec Youtube. La manière d’obtenir un score parfait a consisté à réinterpréter les résultats Lighthouse puis à refondre complètement la codebase. Résultat : toutes les plaintes clients liées à la vitesse ont disparu, et cela donne aussi un gros avantage en SEO comme dans les scores eux-mêmes
  • Rails n’a pas de lien direct avec l’optimisation du rendu. Félicitations pour le score Lighthouse parfait

• Je pense que l’article a deux faiblesses logiques

  1. Il y a une formule qui affirme qu’en communication satellite, l’envoi d’un paquet prend environ 1600 ms, mais cela ne suffit pas à justifier la règle des 14 kB. Il n’y a aucune comparaison avec un gros site web, donc on ne montre pas que 10 paquets ≠ 16 secondes
  2. Il est dit que les images d’une page web entrent aussi dans la règle des 14 kB, mais dans combien de cas les images sont-elles chargées inline au départ ? En pratique, c’est un cas exceptionnel très rare, donc il faudrait dire plus clairement que cela ne s’applique pas dans 99,9 % des cas - « <i>Des images inline ?</i> » Par exemple, on peut afficher au départ de petites miniatures basse définition avec un flou CSS, puis faire apparaître en fondu la vraie image plus tard, de manière asynchrone. Si c’est bien fait, cela ne consomme qu’environ 100 à 200 octets de plus. Je l’ai mis sur mon blog, et des plateformes comme Wordpress ou Medium l’utilisent aussi beaucoup. C’est surtout une astuce d’hyper-optimisation pour des frontends commerciaux - Je ne suis pas non plus d’accord avec l’hypothèse implicite selon laquelle la majorité des utilisateurs seraient sur des connexions satellite à faible latence, ni avec l’idée que seule ma page ne tiendrait pas le coup alors que la réalité, c’est que presque tous les sites pèsent plusieurs Mo

• La génération actuelle a tendance à créer même les sites statiques simples avec des frameworks comme Next.js. Je trouve cela dommage, comme si l’époque HTML+CSS+js touchait à sa fin

  • D’accord. J’ai moi aussi fait des sites avec ressources minimales, optimisation JS à la main et règle des 14 kB, mais cette approche finit par imposer des contraintes de conception et d’architecture. Quand les fonctionnalités augmentent, toutes ces décisions de « minimisation » deviennent de la dette technique. La plupart des gens idéalisent le « web pur sans framework », puis finissent par découvrir que c’est encore plus pénible. Alors qu’avec un framework JS isomorphe, on peut commencer par une page statique, l’optimiser raisonnablement, puis basculer vers un client JS plus riche si nécessaire
  • En réalité, la tendance est déjà en train de repartir dans l’autre sens. La plupart des frameworks actuels prennent très bien en charge les sites statiques. Astro, par exemple, est né précisément pour les sites statiques
  • J’ai envie de dire : tu t’en rends compte seulement maintenant ? En fait, c’est comme ça depuis bien avant l’explosion de popularité de jQuery vers 2010
  • Next.js optimise très agressivement le code de bundle, ce qui le rend adapté aux lambdas ou aux petits déploiements serveur. Même les sites statiques faits avec Next peuvent produire des bundles très légers

• Au-delà de la latence, réduire au minimum la consommation de ressources est une condition indispensable pour un avenir durable. L’impact environnemental du réseau est loin d’être négligeable. Je trouve dommage que le ton des commentaires soit un peu sarcastique. Cette optimisation n’est pas l’ultime solution, mais j’aurais aimé qu’on insiste davantage sur la baisse de consommation d’énergie

  • La majorité du trafic Internet, c’est du streaming vidéo. Optimiser de quelques mégaoctets une page web ne se voit quasiment pas. Cela dit, la question de l’efficacité mérite d’être discutée, mais chercher à tout optimiser peut finir par consommer des ressources qui seraient plus utiles dans les domaines où l’optimisation est vraiment nécessaire
  • Ce n’est même pas un fruit à portée de main. Pendant qu’on optimise une page pour économiser 1 à 2 mWh, une seule requête à un moteur de recherche consomme 100 fois plus, et une interaction avec un chatbot 10 000 fois plus. Le caching et le lazy loading atténuent déjà une bonne partie du problème
  • Se soucier de réduire la taille des pages est presque une perte de temps. Même en multipliant par 10, par prudence, l’électricité consommée par une année de navigation web reste très inférieure à l’énergie nécessaire pour fabriquer un seul hamburger. D’un point de vue environnemental, il vaudrait presque mieux qu’un développeur mange une salade pendant une semaine au lieu d’optimiser
  • Tout à fait d’accord. J’ai été choqué autrefois en passant à la BBC de voir qu’un petit article texte pouvait stocker 120 MB dans le cache. Cela encourage une culture du gaspillage et une dépense d’énergie inutile. J’essaie moi aussi de garder mon site aussi minimal que possible, et quand j’upload sur YouTube, je reste en 1080P au lieu de la 4K. La 4K et la 8K n’ont pas vraiment besoin d’exister. On parle souvent d’ajouter quelques MW de solaire, mais il faudrait aussi imaginer à quel point il serait bénéfique de simplement « produire moins ». La taille réduite du web à l’époque des modems 56K me manque ; il y avait sûrement un point d’équilibre quelque part, mais aujourd’hui on l’a largement dépassé
  • Les gens ne commencent vraiment à s’en soucier que lorsque cela a un impact direct sur eux. Pour ma part, je prends aussi la question environnementale au sérieux. Certains rétorquent que l’IA est pire, mais en réalité l’IA crawl elle aussi ces pages lourdes. Et la cible des 14 kB représente toujours moins de 1 % de la charge utile moyenne d’une page mobile