les éléments essentiels du Web ne sont pas une astuce de référencement
dev · Oct 6, 2026 · 3 min read
Chaque site d'agence en Italie contient le mot "veloce" quelque part. rapide, moderne, optimisé. je n'en ai jamais vu mettre un chiffre à côté d'un mot, et après en avoir mesuré quelques-uns par curiosité je comprends pourquoi : les chiffres les gêneraient.
c'est donc le côté numéro du terrain. quels sont réellement les éléments essentiels du Web, comment je les mesure sur ce site et ce qu'ils valent lorsque quelqu'un vous cite un nouveau site Web.
ce qu'ils sont
trois mesures que Google prend sur des visites réelles :
- LCP — combien de temps avant que le contenu principal de la page soit visible. le bien dure moins de 2,5 secondes
- INP — combien de temps avant que la page réagisse lorsque vous appuyez sur quelque chose. le bien est inférieur à 200 millisecondes
- CLS — combien la mise en page saute pendant le chargement. bon est inférieur à 0,1, ce qui signifie en pratique : ça ne saute pas
ce ne sont pas un rituel de référencement. ils font la différence entre une page que quelqu’un attend et une page que quelqu’un lit. sur un téléphone, sur une mauvaise connexion, c'est le site rapide qui prend le contact.
comment je les mesure
deux outils, tous deux gratuits : des informations sur la vitesse de page pour les numéros de laboratoire et le rapport sur l'expérience utilisateur Chrome pour ce que les vrais visiteurs ont réellement vécu. le numéro du laboratoire est ce que vous pouvez corriger aujourd'hui ; le numéro de champ est la vérité qui arrive des mois plus tard. quiconque vous montre uniquement le numéro du laboratoire vous montre la moitié la plus facile.
ce que j'ai fait sur celui-ci
ce site est la première étude de cas, car je peux publier ses chiffres sans demander la permission à personne. mesuré aujourd'hui, en laboratoire, sur une charge froide :
- le document html fait 16 Ko, et il est complet avant l'exécution de tout javascript : la build pré-rend un document par itinéraire et par langue - le plan du site les compte à chaque build
- premier octet en 227 ms, page entièrement chargée en 658 ms
- décalages de disposition : zéro. rien sur la page ne bouge après son arrivée
- la construction elle-même échoue si une vérification de contraste échoue : 50 cas mesurés sur chaque construction, non promis dans un pdf
rien de tout cela n’est exotique. il s'agit d'une poignée de décisions prises une seule fois, au début : un prérendu au lieu d'un rendu client uniquement, une police variable au lieu de cinq, des images dimensionnées avant leur insertion. la rapidité d'un chantier se décide à la table de l'architecture, pas dans la phase "ottimizzazione" à la fin, qui est la phase qui n'existe pas car le budget est dépassé.
ce que cela signifie si vous achetez un site
quand quelqu'un vous cite un site internet et vous promet qu'il sera rapide, demandez trois chiffres : LCP, INP, CLS, mesurés sur le site fini, pas sur la démo. si la réponse est un sourire, vous avez votre réponse.
un site rapide n'est pas seulement un peu mieux classé. il convertit : chaque seconde d'attente, c'est quelqu'un qui ferme l'onglet avant de lire ce que vous faites. et le correctif est rarement une refonte - c'est la façon dont le site est construit, c'est pourquoi je le mesure dans la construction et publie le résultat, au lieu d'utiliser le mot "veloce" et en espérant que vous ne le demanderez pas.