Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06906.jsonl.gz/1140

Réduire la taille des pages pour améliorer la vitesse est une bonne chose. Transformer un point technique (mal compris) d’une RFC en injonction est stupide.
Origine de cette injonction
Depuis quelques jours, on voit passer des articles dont le titre ressemble plus ou moins à “Pourquoi votre site doit faire 14Ko?” ou “Pourquoi votre site se charge plus vite avec des pages de 14Ko” (en anglais surtout).
Dans ces articles, on vous explique rapidement qu’un sombre algorithme nommé “TCP Slow Start” vous oblige à envoyer un fichier de 14Ko maximum sous peine de ralentissement majeur.
Non, “TCP Slow Start” n’a pas pour vocation de vous ralentir, bien au contraire.
TCP Slow Start: mécanisme anti-congestion
Le principe du TCP Slow Start est définit dans la section 3.1 de la RFC 5681. Son objectif est de déterminer la taille maximum des blocs TCP échangeables entre un serveur et un client afin d’assurer la fluidité du trafic (et donc du chargement des fichiers) sur le réseau.
Algorithme de base
Dans cette section 3.1, on trouve ce petit algorithme:
1IW, the initial value of cwnd, MUST be set using the following
2 guidelines as an upper bound.
3
4 If SMSS > 2190 bytes:
5 IW = 2 * SMSS bytes and MUST NOT be more than 2 segments
6 If (SMSS > 1095 bytes) and (SMSS <= 2190 bytes):
7 IW = 3 * SMSS bytes and MUST NOT be more than 3 segments
8 if SMSS <= 1095 bytes:
9 IW = 4 * SMSS bytes and MUST NOT be more than 4 segments
Petit lexique
- cwnd: CONGESTION WINDOW. Il s’agit d’une variable d’état TCP qui limite la quantité d’informations à envoyer.
- SMSS: SENDER MAXIMUM SEGMENT SIZE. Définit la taille du plus grand paquet que l’émetteur peut envoyer. Sa valeur est basée sur un des éléments suivants:
- RMSS: Taille du plus grand paquet que le receveur peut accepter. Cette taille est définit dans l’option “MSS” lors de l’établissement de la connexion. Si l’option MSS n’est pas utilisée, cette taille est fixée à 536 octets (voir RFC1122).
Une fois le CWND calculé, celui-ci sera augmenté progressivement après chaque transmission réussie (jusqu’à atteindre un maximum ou dépasser les capactités du réseau ou du client).
Pourquoi 14Ko?
Ces articles font tous les deux mêmes postulats:
- la taille maximum d’un paquet TCP est de 1500 octets.
- le serveur envoie 10 paquets TCP la première fois.
Ensuite le calcul est simple: on retire les 40 octets d’entête TCP et on multiplie. On obtient donc
(1500-40) * 10 = 14600soit un peu plus de 14Ko.
Génial! On a une règle simple à comprendre et appliquer.
Sauf qu’elle est parfaitement incorrecte
Pourquoi ne pas de conformer à cette règle?
Le nombre de blocs est variable
En effet, cette RFC prévoit que le serveur augmente le nombre de blocs à chaque envoi réussi.
Donc si on voulait être cohérent, on devrait alors optimiser la taille des ressources en fonction de l’ordre de chargement, voir fusionner les ressources entre elles pour rentrer dans la limite calculée? Par exemple, si la page HTML pèse 10Ko et la CSS liée 3Ko, pourquoi ne pas intégrer la CSS dans le HTML afin d’obtenir une seule page de 13Ko?
On comprend vite que ce type d’optimisation va se transformer en enfer lors de chaque modification de contenu (je vous laisse imaginer le drame avec un contenu dynamique). De plus, on se focalisant sur la taille du premier fichier, on oublie le mécanisme de mise en cache du navigateur: celui-ci pourrait ne pas charger la page HTML car non expirée pour demander d’autres ressources.
La taille des blocs n’est pas 1500 octets
La taille maximum d’un paquet TCP n’est pas forcément 1500 octets. Si le client indique un MSS de 3000 octets et que le serveur accepte, le serveur pourra envoyer des paquets de 6000 octets avant d’augmenter la taille. Au contraire, si rien n’est précisé et que les options de calcul du SMSS ne sont pas probantes, on finit avec une taille initiale de 536 octets.
Ensuite, selon la taille du SMSS, le nombre initial de paquets varie de 2 à 4. On est loin des 10 et donc loin des 14Ko.
Finalement, la taille et le nombre de paquets varie au fur et à mesure de la transmission afin d’éviter les congestions du réseau. Il est aisé de comprendre qu’un client en liaison fibre et un autre en 3G loin de l’antenne la plus proche ne vont pas demander les mêmes tailles de blocs car ils n’ont pas les mêmes problèmes de congestion (le client fibre peut tenter de forcer le destin puisque demander un paquet manquant ne lui coûte rien. Le client 3G a intérêt à ne pas être gourmand par contre).
HTTP/2 et HTTP/3
Toujours dans le même type d’article, les auteurs se penchent sur HTTP/2 et 3 et laissent entendre de passer à HTTP/3 sinon de se rabattre sur HTTP/2 pour que l’optimisation “14Ko” porte ses fruits.
HTTP/2 n’apporte aucun changement dans la gestion de la congestion et donc cette règle idiote des 14Ko n’est toujours pas utile.
HTTP/3 (ou QUIC), par contre, propose des améliorations autour de la congestion. Dans le brouillon de la norme QUIC, on trouve au chapitre 6.8 des éléments de gestion du rythme d’envoi. On parle cette fois de la limite des 14Ko, non pas comme règle mais comme un minimum recommandé pour l’envoi de paquets lorsqu’on n’observe pas de délai entre les dits paquets.
Note: encore une fois, l’auteur “oublie” que tout le monde ne contrôle pas le serveur hébergeant son site et donc qu’on ne peut pas changer de version HTTP à sa guise.
Cas probable d’utilisation
Alors, avant de jeter le bébé avec l’eau du bain, on peut tout de même trouver au moins un cas pour lequel la connaissance du mécanisme “TCP Slow start” peut être utile: une application d’entreprise.
Dans ce contexte, vous maîtrisez l’ensemble de la configuration des PC, du réseau, du serveur Web et du code applicatif. Il pourrait, éventuellement, être utile d’aligner quelques paramètres pour améliorer le temps de chargement. Mais c’est à mon avis le dernier point à traiter.
Conclusion
Optimiser son site en réduisant la taille des pages et des ressources est une bonne pratique, c’est évident (même si c’est parfois compliqué). Se conformer à une injonction issue d’une observation est stupide. Il est impossible de connaître les conditions de transmission pour l’ensemble des clients et des réseaux rencontrés et, dès lors, tenter d’optimiser ses fichiers en fonction des algorithmes anti-congestion est au mieux une perte de temps et au pire contre-productif.