La vitesse des pages est un signal de classement Google depuis 2018. En 2026, c'est l'un des rares facteurs que vous pouvez directement contrôler et mesurer. Ce guide couvre les métriques qu'AISeen vérifie, les seuils Google et les optimisations qui apportent le plus d'améliorations par effort.
Ce que mesure l'AISeen Speed Score
- Time to First Byte (TTFB) — Temps de réponse du serveur. Objectif : moins de 200 ms. Problèmes : hébergement lent, pas de CDN, requêtes de base de données non optimisées.
- Taille HTML — Taille du document non compressé. Un HTML volumineux indique souvent des problèmes de rendu côté serveur.
- Version HTTP — HTTP/2 et HTTP/3 permettent des requêtes multiplexées, réduisant significativement le temps de chargement.
- Compression — Brotli ou gzip doit être activé pour tous les assets texte. Le HTML/CSS/JS non compressé est l'une des corrections les moins coûteuses.
- En-têtes de cache — Les assets statiques doivent avoir des en-têtes
Cache-Controlde longue durée. - Indices de ressources — Les directives
<link rel="preload">,preconnectetprefetchréduisent le temps de chargement perçu.
Les plus grands tueurs de vitesse
Dans notre analyse de plus de 50 000 sites, trois problèmes apparaissent le plus fréquemment :
- Scripts bloquant le rendu — Les fichiers JavaScript chargés dans
<head>sansdeferouasyncbloquent l'analyse HTML. - Images non optimisées — Fichiers PNG où WebP ou AVIF réduirait la taille de 30 à 70% sans perte de qualité visible.
- Pas de CDN — Servir des assets statiques depuis un seul serveur d'origine ajoute 100 à 500 ms de latence pour les utilisateurs mondiaux.
Priorisation des corrections
Commencez par les changements au niveau serveur (TTFB, compression, HTTP/2) car ils affectent toutes les pages simultanément. Passez ensuite à l'optimisation des images et aux indices de ressources. Le report de JavaScript nécessite souvent des modifications de code et doit être abordé en dernier.