Audit de performance web : le guide complet

Un site lent perd sur les deux tableaux : Google le classe moins bien, et les visiteurs qui arrivent malgré tout repartent avant d'avoir converti. Les études convergent depuis des années — chaque seconde de chargement supplémentaire fait chuter le taux de conversion, particulièrement sur mobile.

Le problème : « mon site est rapide » est une impression, pas une mesure. Il charge vite chez vous, sur votre machine, avec votre cache rempli et votre fibre. L'audit de performance remplace cette impression par des métriques objectives. Voici lesquelles, et comment les interpréter.

Performance et SEO : le lien direct

Depuis la mise à jour Page Experience de 2021, Google intègre officiellement les Core Web Vitals dans son algorithme de classement. Ce n'est pas le facteur dominant — la pertinence du contenu prime — mais à contenu équivalent, la page la plus performante gagne. Et l'indexation étant mobile-first, c'est la performance mobile qui compte, généralement bien plus mauvaise que la version desktop.

Au-delà du classement, la performance conditionne le comportement : plus de la moitié des visites mobiles sont abandonnées quand le chargement dépasse 3 secondes.

Les trois métriques qui comptent : LCP, INP, CLS

LCP — Largest Contentful Paint

Le LCP mesure le temps d'affichage du plus gros élément visible de la page (image héro, titre principal, bloc de texte). C'est la métrique qui correspond le mieux à la perception « la page est chargée ».

• 🟢 Bon : < 2,5 s — 🟠 À améliorer : 2,5–4 s — 🔴 Mauvais : > 4 s

Coupables habituels : image héro non optimisée, serveur lent, CSS bloquant, polices web chargées en cascade.

INP — Interaction to Next Paint

L'INP a remplacé le FID en mars 2024 comme Core Web Vital officiel. Il mesure la réactivité : le délai entre une interaction (clic, saisie) et la mise à jour visuelle de la page. Un site peut s'afficher vite mais réagir mal — typiquement quand un excès de JavaScript monopolise le thread principal.

• 🟢 Bon : < 200 ms — 🟠 À améliorer : 200–500 ms — 🔴 Mauvais : > 500 ms

En laboratoire, le TBT (Total Blocking Time) sert d'approximation : il cumule le temps pendant lequel le thread principal est bloqué et ne peut pas répondre.

CLS — Cumulative Layout Shift

Le CLS mesure la stabilité visuelle : ces sauts de mise en page exaspérants où le bouton se dérobe sous votre doigt parce qu'une publicité vient de s'insérer au-dessus.

• 🟢 Bon : < 0,1 — 🟠 À améliorer : 0,1–0,25 — 🔴 Mauvais : > 0,25

Causes classiques : images sans dimensions déclarées, polices qui changent la taille du texte en arrivant, bannières et embeds injectés tardivement.

FCP et Speed Index : les indicateurs complémentaires

• FCP (First Contentful Paint) : le délai avant le premier élément affiché — le moment où l'utilisateur sait que « quelque chose se passe ». Un FCP au-delà de 1,8 s installe le doute.
• Speed Index : la vitesse à laquelle le contenu visible se remplit progressivement. Deux pages peuvent finir de charger en même temps, mais celle qui affiche 80 % de son contenu dès la première seconde paraît deux fois plus rapide.

Ces métriques ne sont pas des facteurs de classement directs, mais elles localisent les problèmes : un FCP lent pointe vers le serveur ou le CSS bloquant ; un Speed Index dégradé avec un bon FCP pointe vers le chargement progressif.

TTFB : le serveur, premier coupable

Le TTFB (Time To First Byte) mesure le délai entre la requête et le premier octet de réponse du serveur. Tout le reste attend derrière lui : un TTFB de 1,5 s rend mathématiquement impossible un LCP à 2,5 s.

Un TTFB sain est inférieur à 800 ms, idéalement sous 200 ms. Au-delà, cherchez du côté de :

• l'hébergement mutualisé saturé ;
• l'absence de cache serveur (chaque visite régénère la page depuis la base de données — le grand classique WordPress) ;
• l'absence de CDN pour les visiteurs éloignés du serveur ;
• les redirections en chaîne qui multiplient les allers-retours.

Comment corriger : cache et TTFB

# Cache navigateur : 6 mois pour les ressources statiques
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 6 months"
  ExpiresByType text/css "access plus 6 months"
  ExpiresByType application/javascript "access plus 6 months"
</IfModule>

# Cache navigateur : 6 mois pour les ressources statiques
location ~* \.(css|js|webp|avif|jpg|png|woff2)$ {
  expires 6M;
  add_header Cache-Control "public, immutable";
}

L'analyse des assets : poids, images, scripts

L'audit décompose le poids total de la page par type de ressource :

• Poids total : une page médiane pèse environ 2 Mo ; au-delà de 3–4 Mo, l'expérience mobile en réseau réel se dégrade nettement.
• Images : premier poste de poids dans la plupart des cas. Formats modernes (WebP/AVIF, 25–50 % plus légers que JPEG), dimensions adaptées à l'affichage réel, lazy loading pour ce qui est hors écran.
• JavaScript : chaque kilooctet de JS coûte double — téléchargement puis exécution. C'est le principal responsable des mauvais INP.
• CSS : les feuilles de style bloquent le rendu tant qu'elles ne sont pas chargées. Le CSS critique peut être injecté en ligne, le reste différé.
• Polices : chaque variante de police est un fichier à télécharger. Deux familles en trois graisses = six fichiers, souvent chargés depuis un domaine tiers.

Comment corriger : les images

HTTP/2, compression et ressources tierces

Protocole

HTTP/2 (et HTTP/3) permettent de charger plusieurs ressources en parallèle sur une seule connexion. Un site encore servi en HTTP/1.1 paye une taxe de latence sur chaque fichier — la mise à niveau se joue généralement dans la configuration de l'hébergeur.

Compression

Les fichiers texte (HTML, CSS, JS) doivent être compressés en gzip ou, mieux, en Brotli — des réductions de 60 à 80 % du transfert pour une ligne de configuration serveur. L'audit détecte les ressources servies non compressées.

Comment corriger : activer la compression

# Compression gzip des fichiers texte
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>

# Compression gzip des fichiers texte
gzip on;
gzip_types text/css text/javascript application/javascript application/json image/svg+xml;
gzip_min_length 1024;

Ressources tierces

Analytics, pixels publicitaires, chats, widgets sociaux, vidéos intégrées : chaque service tiers ajoute des requêtes DNS, du JavaScript et des dépendances hors de votre contrôle. Il n'est pas rare que les tiers représentent la moitié du temps de blocage d'une page. L'audit en dresse l'inventaire avec leur coût réel — c'est souvent la liste des services qu'on a « ajoutés pour essayer » et jamais retirés.

Comment interpréter un score PageSpeed Insights

Le score Lighthouse (0–100) agrège les métriques pondérées. Trois pièges d'interprétation :

1. Données labo vs données terrain. Le score est calculé en environnement simulé (réseau et CPU bridés). Les données terrain (CrUX), quand elles existent, reflètent vos vrais visiteurs — c'est sur elles que Google s'appuie pour le classement. Un écart entre les deux est normal et instructif.
2. Le score varie entre deux exécutions. ±5 points est du bruit de mesure, pas une régression.
3. Ne poursuivez pas le 100/100. Passer de 45 à 75 transforme l'expérience utilisateur ; passer de 90 à 100 est un exercice de style. Les seuils Google sont : 90+ bon, 50–89 à améliorer, < 50 mauvais.

Le score est un thermomètre, pas un diagnostic : ce sont les recommandations associées, hiérarchisées par impact, qui constituent le plan d'action.

Les familles de contrôles d'un audit complet

Mesurez avant d'optimiser

L'erreur classique en performance est d'optimiser au hasard — minifier du CSS quand le problème est une image héro de 3 Mo, changer d'hébergeur quand le coupable est un script tiers. FlashScanr analyse vos pages avec Lighthouse et PageSpeed Insights, mesure l'ensemble de ces métriques et vous remet un rapport qui hiérarchise les corrections par impact réel sur votre temps de chargement.

Testez les performances de votre site →