La vitesse d'un site internet

Par Aurélie Ducasteaux · mis à jour le 30 août 2026

Les trois signaux web essentiels

Google publie trois indicateurs, appelés signaux web essentiels, avec des seuils explicites. Ils portent chacun sur un aspect différent de l'expérience réelle.

Ces seuils s'apprécient au 75e centile des chargements de page, mesurés séparément sur mobile et sur ordinateur. Autrement dit, il ne s'agit pas de la moyenne : trois chargements sur quatre doivent respecter le seuil. C'est une exigence plus dure qu'une moyenne, et elle a une raison : la moyenne masque les visiteurs sur connexion faible, qui sont précisément ceux qui abandonnent.

Ces valeurs et cette méthode sont publiées par Google sur son site consacré aux performances web, consulté le 30 août 2026.

Comment mesurer, sans se tromper d'outil

Deux familles de mesures, qui ne disent pas la même chose.

Les données de laboratoire. Un outil charge la page dans des conditions simulées, souvent avec une connexion et un appareil bridés. Cela donne un score et des recommandations. C'est reproductible, c'est utile pour comparer avant et après une correction, et cela ne dit rien de vos visiteurs réels.

Les données de terrain. Les mesures collectées sur les chargements réels des visiteurs. C'est ce que Google utilise. Elles sont visibles dans son outil de suivi pour les sites qui reçoivent assez de trafic, et dans les rapports d'expérience utilisateur.

L'erreur la plus courante consiste à traiter le score de laboratoire comme un objectif. Un score de 100 sur un outil de test ne signifie pas que les visiteurs ont une bonne expérience, et un score de 70 avec de bonnes données de terrain vaut mieux que l'inverse.

Une troisième mesure, gratuite et sous-estimée : ouvrir les outils de développement du navigateur, onglet réseau, et regarder le poids total transféré et le nombre de requêtes. Ces deux nombres expliquent la plupart des problèmes.

Ce qui ralentit réellement un site

Classé par fréquence sur les sites que j'ai vus.

1. Les images. Trop lourdes, aux mauvaises dimensions, dans un format ancien, chargées toutes en même temps. C'est le premier poste dans une écrasante majorité des cas.

2. Les scripts tiers. Outils de mesure, widgets de réseaux sociaux, chat en ligne, bandeaux de consentement, polices externes, cartes. Chacun ajoute des connexions vers d'autres domaines et du code à exécuter. C'est aussi la première cause de mauvais INP.

3. Le thème et les extensions. Un thème polyvalent charge des fonctions inutilisées. Une extension mal conçue charge son code sur toutes les pages, y compris celles qui ne s'en servent pas.

4. L'hébergement. Un serveur mutualisé saturé allonge le temps de réponse initial. C'est réel, mais c'est rarement le premier problème, contrairement à ce qu'on entend.

5. L'absence de cache. Chaque visiteur retélécharge tout, et le serveur recalcule chaque page.

6. Les polices. Cinq graisses chargées depuis un service externe retardent l'affichage du texte et provoquent un saut visuel au moment de leur arrivée.

Les corrections, classées par gain

Les cinq premières lignes se traitent en une journée sur un site courant et suffisent souvent à faire passer les trois signaux au vert.

Le cas du décalage visuel

Le CLS est le signal le plus facile à corriger et le plus négligé, alors qu'il correspond à l'agacement le plus concret : le bouton qui se dérobe au moment où l'on clique.

Ses causes sont peu nombreuses :

• une image ou une vidéo sans dimensions déclarées, qui pousse le contenu quand elle arrive ;
• un bandeau, une publicité ou un message inséré au-dessus du contenu après le chargement ;
• une police externe qui remplace la police de secours et modifie la hauteur du texte ;
• une animation qui déplace des éléments au lieu de les transformer ;
• un contenu injecté par un script après affichage.

Toutes se corrigent en réservant la place à l'avance. C'est du travail d'intégration, pas de l'optimisation avancée.

Ce que la vitesse change vraiment

Il faut être précis ici, parce que le sujet est saturé de chiffres invérifiables.

Pour le référencement. Google indique utiliser l'expérience de la page, dont font partie les signaux web essentiels, parmi ses nombreux critères. Ce n'est pas le critère dominant : un site rapide au contenu inexistant ne se positionne pas. La vitesse agit à la marge, entre des pages de pertinence comparable.

Pour les visiteurs. L'effet est direct et se constate sur ses propres données : quand une page met plusieurs secondes à afficher quelque chose, une partie des visiteurs part avant. Les chiffres précis d'abandon varient énormément selon les secteurs et les sources, et ceux qui circulent sont rarement traçables jusqu'à une étude publiée. Le seul chiffre fiable est le vôtre, mesuré avant et après une amélioration.

Pour les appareils anciens. Un site lourd est un site que les téléphones de plus de cinq ans peinent à afficher. C'est aussi le lien avec la page écoconception web : l'essentiel de l'empreinte du numérique se joue sur les terminaux.

Un objectif réaliste pour un site vitrine

Pour un site d'entreprise sans fonctions particulières, ces valeurs sont atteignables sans expertise rare :

• poids total de la page d'accueil : moins de 800 kilooctets, idéalement moins de 500 ;
• nombre de requêtes : moins de 40 ;
• LCP sur mobile : moins de 2,5 secondes en données de terrain ;
• CLS : moins de 0,1, ce qui doit être systématique ;
• INP : moins de 200 millisecondes, facile sans script lourd.

Un site vitrine qui n'y arrive pas a presque toujours un problème identifiable en dix minutes : une image de plusieurs mégaoctets, une vidéo de fond, ou une accumulation de scripts tiers.

La méthode en une demi-journée

Sur un site existant, cet ordre donne le maximum de résultat pour le minimum de temps. Il ne demande aucune compétence rare, seulement un navigateur et un accès au site.

Première heure, l'état des lieux. Ouvrir la page d'accueil et une page intérieure dans un navigateur, outils de développement ouverts, onglet réseau, cache vidé. Relever le poids total transféré, le nombre de requêtes, et la liste des dix ressources les plus lourdes. Refaire la même chose en simulant une connexion lente. Noter les valeurs et la date.

Deuxième heure, les images. Dans la liste des dix ressources les plus lourdes, les images occupent presque toujours les premières places. Pour chacune : quelle taille est réellement affichée à l'écran, et quelle taille est envoyée. L'écart désigne le travail à faire. La conversion dans un format récent et le redimensionnement se font par lot.

Troisième heure, les tiers. Lister tous les domaines contactés par la page, visibles dans le même onglet réseau. Chaque domaine étranger est un service tiers. Pour chacun : à quoi il sert, qui lit ses données, et depuis quand il est là. Un site de PME contacte souvent huit à quinze domaines externes, dont la moitié sont des reliquats.

Quatrième heure, les corrections faciles. Déclarer les dimensions des images, activer le chargement différé, réserver la place des bandeaux, activer le cache. Puis remesurer, et comparer aux valeurs de la première heure.

Ce protocole a un mérite qui dépasse la technique : il produit des chiffres avant et après. Ces chiffres permettent de discuter avec un prestataire sur des faits, et de savoir si une prestation d'optimisation facturée a produit quelque chose.

Ce qui rate

• L'optimisation menée sur le score d'un outil de laboratoire, sans jamais regarder les données de terrain.
• Une extension de cache installée sur un site dont les images pèsent 4 Mo. Le cache accélère la livraison de ce qui est lourd, il ne l'allège pas.
• La police externe chargée en cinq graisses pour deux utilisées.
• Le bandeau de consentement qui bloque l'affichage et pénalise les trois signaux à la fois.
• L'image de bannière servie en 3 000 pixels de large à un téléphone.
• Le carrousel d'accueil, qui charge plusieurs grandes images dont une seule est vue.
• L'hébergement changé en premier, alors que le temps de réponse serveur n'était pas le problème.

Le cas des bandeaux de consentement

Ils méritent une mention à part, parce qu'ils pénalisent les trois signaux à la fois et qu'on les traite rarement comme un sujet de performance.

Un bandeau de gestion des traceurs mal intégré produit trois effets simultanés. Il s'affiche par-dessus le contenu, ce qui retarde ou perturbe la mesure du plus grand élément visible. Il pousse le contenu vers le bas quand il apparaît, ce qui dégrade la stabilité visuelle. Et il exécute du code au moment le plus chargé du démarrage de la page, ce qui allonge le délai de réponse aux premières interactions.

Ce qui se corrige, sans toucher à la conformité :

• Réserver la place du bandeau dans la mise en page, pour qu'il n'en déplace aucun élément à son arrivée.
• Charger la solution en local plutôt que depuis un domaine externe, ce qui supprime une connexion et une attente.
• N'exécuter les scripts tiers qu'après acceptation, ce qui est de toute façon ce que la réglementation impose pour les traceurs non essentiels, et ce qui allège considérablement les pages vues par ceux qui refusent.
• Vérifier que le bandeau est utilisable au clavier, ce qui relève de l'accessibilité et se teste en dix secondes.

Le point important : les règles applicables aux traceurs relèvent de la CNIL, qui publie sa doctrine et ses recommandations. La performance ne justifie aucune entorse à ces règles. En revanche, une intégration soignée permet de tenir les deux exigences en même temps.

Sources

• Seuils des signaux web essentiels, LCP 2,5 s, INP 200 ms, CLS 0,1, mesurés au 75e centile : web.dev, article de référence sur les Web Vitals, consulté le 30 août 2026.
• Utilisation de l'expérience de la page dans le classement : documentation Google Search Central.
• Répartition de l'empreinte du numérique entre terminaux, centres de données et réseaux : étude ADEME-Arcep, volet prospectif publié en mars 2023.