Alors voilà, nous sommes arrivé à la question existentielle : quel est le poids idéal d’une page web pour être performante ? Car à l’instar du sumotori, le poids reste le premier point à améliorer pour être rapide à charger et ne pas dégrader l’UX. Donc même si tous les webmasters du monde se concentrent en ce moment sur les web vitals de Google, il n’en reste pas moins qu’ils devraient commencer par surveiller la masse pondérale de leurs kilo-octets… Cela dit, Alex Russel s’intéresse depuis longtemps à la web performance et a publié le 7 mars 2021 les résultats de ses études sur le poids idéal d’une page web. Résumons son propos…
Quel est le contexte référent ?
Quand il faut parler de web performance, il faut déjà déterminer le contexte. Le principe de base à retenir est le suivant :
Lorsque nous construisons le monde numérique
aux limites des meilleurs appareils,
nous en construisons un monde MOINS utilisable
pour plus de 80% des utilisateurs du monde .
Le message est clair, le poids idéal d’une page web ne peut se déterminer à l’aune du dernier smartphone ultrapuissant du marché.
En 2017, Android pas cher et 3G
En 2017, les conclusions d’Alex Russel, recommandait le contexte suivant :
- un modèle de téléphone Android à 200$,
- avec une connexion 3G lente (à 400kbps).
Ce type d’appareil présentait 4 à 8 cœurs (plutôt lents à faible cache), avec environ 2 Go de RAM et un stockage flash, comme le Moto G4. Bah !? Tiens, dis donc, c’est pile poil l’appareil simulé dans les tests LightHouse ! Ah oui mais j’ai oublié de vous dire, Alex Russel est ingénieur… chez Google. Et à priori, quand il écrit quelque chose cela peut avoir des répercussions.
En 2021, Android pas cher et 4G
Aujourd’hui, côté connexion, la donne a changé. La 4G est plutôt bien déployée et la 5G reste une utopie. Et cela le restera pendant au moins 5 ans, vu les choix divergeant des opérateurs et des performances qui dans un premier temps, risque d’être déceptif.
Côté appareils, c’est un peu plus compliqué. Les écarts de performance augmentent entre les appareils haut de gamme et bas de gamme. Et Alex Russel fustige les choix des appareils Android en comparant chaque catégorie d’appareil en termes d’années de retard sur les versions d’iPhone :
- Les Androïds haut de gamme de 2020 arborent les performances monocœur d’un iPhone 8, un téléphone sorti au 3ème trimestre 2017.
- En milieu de gamme, les Androïds sont légèrement plus rapides que l’iPhone 6 de 2014.
- Les Androïds bas de gamme ont finalement rattrapé l’iPhone 5 de 2012.
Du coup, l’appareil de référence reste un Android à environ 200$, comme le Moto E6, très proche matériellement du Moto G4.
Le poids idéal d’une page web pour un chargement en 5 secondes
A partir de ce contexte technique, l’objectif fixé par Alex Russel est un premier chargement en 5 secondes depuis 2017.
Le poids idéal d’une page web en 2017
En 2017, le poids idéal d’une page web était calculé comme ceci pour atteindre les 5 secondes :
- On réserve 1,6 seconde pour la recherche DNS et la négociation TLS, ce qui nous laisse 3,4 secondes pour travailler.
- Ensuite on calcule la donnée que l’on peut envoyer dans ce laps de temps avec une connexion 3G à 400 Kbps (soit 50 Ko par seconde).
- Résultat : 3,4 x 50 = 170 Ko.
Mais cela ne s’arrête pas là. Les pages web modernes étant constituées en grande partie de JS, le temps dont le JS a besoin pour s’exécuter doit être pris en compte.
170Ko de JS compressé deviennent environ 1Mo décompressé et prennent une seconde (si il y est bien optimisé sans travail sur le DOM trop coûteux) ! En extrapolant ces chiffres, notre ingénieur de Google en conclue qu’il faut limiter le JS à un poids de 130KB.
En rassemblant le tout, notre poids idéal d’une page web (CSS, JS, HTML et données) en 2017 était de :
- 170 Ko pour les sites sans beaucoup de JS,
- 130 Ko pour les sites construits avec des frameworks JS.
Le poids idéal d’une page web en 2021
En moyenne, avec le déploiement de la 4G (à 9000Kpbs soit 1125Ko/s), les temps de la connexion initiale pour la recherche DNS et la négociation TLS sont réduits de moitié. On passe de 1,6 s à 700 ms. Ce qui libère une marge de manœuvre plus importante pour transmettre plus de données dans la même fenêtre de temps !
Si on appliquait le même calcul que précédemment (4,3 secondes x 1125 Ko/s), on pourrait estimer le poids idéal à plus de 4 Mo… Mais, bah oui sinon ça serait trop simple et trop beau, deux facteurs sont désormais à prendre en compte :
- Au fur et à mesure que les réseaux se sont améliorés, le temps processeur côté client domine désormais le téléchargement des scripts, ajoutant une complexité supplémentaire. Car tous les scripts ne s’exécutent pas dans le même laps de temps pour la même taille.
- Avec HTTP/2 vous pouvez multiplier les connexions, mais chaque connexion à un coût temps / Ko pour atteindre l’objectif de 5 secondes.
Essayez ce graphique interactif pour voir l’impact du nombre de connexions sur la Web Performance.
Dès lors, pour faire court, Alex Russel en détermine le nouveau poids idéal :
- environ 100 Ko (gzippé) de HTML / CSS / polices,
- et entre 300 à 350Ko de JavaScript sur le fil (compressé).
Soit environ 500 Ko la page web et l’ensemble de ses ressources. A titre d’information, la médiane du poids d’une page web est de 1,9 Mo sur mobile selon les chiffres de Web Almanac 2020.
Un message pour les développeurs front-end
J’en vois certains faire de gros yeux. Mais c’est quand même de 2 à 4 fois plus que la base précédente. En fait, il faut modérer cette “recommandation”. Tout d’abord si votre contenu est purement constitué d’HTML, de CSS et d’images, vous pouvez vous permettre un poids plus élevé. Le point le plus délicat reste le JavaScript. Et personne, de manière réaliste, ne peut prédire la quantité de travail exécuté dans le thread principal qu’une quantité de code JavaScript entraînera. Il n’y pas de ratio X Ko de JS équivalent à X secondes d’exécution.
Alex Russel déplore une situation où trop de sites web ne correspondent pas à la réalité du marché et des utilisateurs. C’est pour lui un jour sans fin où défilent constamment des sites conçus sur le modèle Framework + Bundler + SPA, échouant à tenir l’objectif. Et il va falloir encore quelques années avant que les appareils et les réseaux dépassent les excès extrêmes et déraisonnables des années 2010 dus à l’accroissement de JavaScript initié par les développeurs JS eux-mêmes.
Le langouëtien à tendance écolo que je suis irait même un peu plus loin. En favorisant les appareils les plus avancés, les concepteurs de sites web favorisent un taux croissant de renouvellement des appareils. De fait, ils participent ainsi à une surconsommation en créant le besoin d’une UX confortable laissant croire aux utilisateurs que leur appareils moins avancés ne seraient pas capable de la leur fournir. On est loin de l’éco-conception.
En attendant, les résultats d’Alex Russel pourrait impacter les outils de mesure Google qui aujourd’hui utilise encore le MOTO G4. Cela pourrait avoir un léger impact en mieux sur nos notes de web performance.
Source : Merci à notre confrère Jean-Pierre Vincent pour le Tweet, à propos de cet article The Mobile Performance Inequality Gap, 2021.
Photo par Bob Fisher via Unsplash.
