# Audit « 100 % de pages lentes » : pourquoi c'est souvent un faux positif (et comment le corriger)
**Auteur:** Sebastien Chaffer
**Publié:** 2026-06-10T08:21:38+02:00
**URL:** https://wordpress-freelance.com/articles/audit-pages-lentes-faux-positif/
**Catégories:** Performance WordPress
---
Un audit qui annonce 100 % de pages lentes ne mesure presque jamais ce que vivent vos visiteurs. Sur un site WordPress sous LiteSpeed, ce taux reflète le temps de génération PHP au tout premier accès à une page froide, pas le temps de service depuis le cache. Les deux chiffres n’ont rien à voir : une même page peut sortir en 1 800 ms à froid et en 150 ms une fois en cache.
Je suis tombé là-dessus sur mon propre site. Le rapport d’audit technique m’a sorti 258 pages « trop lentes (> 600 ms) », taux d’erreur 100 %. De quoi paniquer. Sauf qu’en mesurant en conditions réelles, le site répondait en 146 ms. Voici comment expliquer l’écart, et comment le corriger pour de bon.
## Que mesure vraiment un audit qui dit « page trop lente » ?
La plupart des audits techniques mesurent le temps de téléchargement du HTML brut, c’est-à-dire le TTFB : le délai avant le premier octet renvoyé par le serveur. Ce délai inclut la génération de la page côté serveur. Sur WordPress, générer une [page Avada avec Rank Math](https://wordpress-freelance.com/articles/optimisation-avada-pagespeed/ "page Avada avec Rank Math") demande de nombreuses requêtes à la base de données. Sur un [hébergement mutualisé](https://wordpress-freelance.com/articles/wordpress-haute-performance-5-alternatives-incontournables/ "hébergement mutualisé"), ça prend facilement 1 à 2 secondes.
Le piège vient de la façon dont un crawler travaille. Il visite chaque URL une seule fois, et il les visite à la chaîne. Donc il tombe systématiquement sur la version froide de la page, jamais sur la version en cache. Pire : en crawlant tout le site d’un coup, il force des dizaines de régénérations PHP simultanées, qui se disputent le CPU partagé du mutualisé. Le temps de chaque page gonfle d’autant. C’est exactement le scénario qui produit un « 100 % » d’un coup.
## Cold-start contre cache chaud : la différence en chiffres
Voici ce que j’ai relevé sur trois URLs de mon site, premier hit puis deuxième hit immédiat.
| URL | 1er hit (froid) | 2e hit (en cache) |
| --- | --- | --- |
| Page pilier | 1 802 ms | 148 ms |
| Article de blog | 1 670 ms | 191 ms |
| Accueil | 1 838 ms | 191 ms |
Le premier accès régénère la page en PHP. LiteSpeed stocke alors le résultat. Le deuxième accès sert ce HTML déjà prêt, d’où la chute à environ 150 ms. Vos visiteurs récurrents, et le plus souvent Googlebot qui repasse, touchent la version en cache. Le crawler d’audit, lui, ne voit que le cold-start. C’est un artefact de méthode, pas un défaut de vos pages.
## Comment savoir si c’est un faux positif chez vous ?
Le test tient en deux requêtes sur la même URL. Mesurez le TTFB une première fois, puis recommencez aussitôt. En ligne de commande :
```
curl -s -o /dev/null -w "TTFB=%{time_starttransfer}sn" "https://votre-site.fr/une-page/"
curl -s -o /dev/null -w "TTFB=%{time_starttransfer}sn" "https://votre-site.fr/une-page/"
```
Si le premier chiffre est élevé et le second nettement plus bas, vous tenez la preuve. Pour confirmer que c’est bien le cache qui parle, regardez l’en-tête `x-litespeed-cache` :
```
curl -sI "https://votre-site.fr/une-page/" | grep -i x-litespeed-cache
```
`hit` veut dire servi depuis le cache, `miss` veut dire régénéré. Un crawler d’audit collectionne les `miss`.
## La solution : garder le cache chaud en permanence
Le correctif consiste à préchauffer le cache pour qu’aucune page ne soit jamais servie à froid, ni à un visiteur, ni à un crawler. LiteSpeed embarque un crawler interne pour ça, mais beaucoup d’hébergeurs mutualisés le désactivent côté serveur. Le réglage paraît actif dans WordPress alors que le moteur ne tourne pas.
La parade fiable est un cron qui parcourt votre sitemap et requête chaque URL à intervalle régulier. Le script lit le sitemap, déplie les sous-sitemaps, et visite chaque page avec une petite pause entre deux requêtes pour ne pas saturer un mutualisé.
```
#!/bin/bash
SITEMAP="https://votre-site.fr/sitemap_index.xml"
UA="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0 Safari/537.36"
subs=$(curl -s -A "$UA" "$SITEMAP" | grep -oE '[^<]+' | sed -e 's///' -e 's###')
for sm in $subs; do
curl -s -A "$UA" "$sm" | grep -oE '[^<]+' | sed -e 's///' -e 's###'
done | sort -u | while IFS= read -r u; do
curl -s -o /dev/null -A "$UA" "$u"
sleep 0.7
done
```
On le planifie deux fois par jour, ce qui suffit largement avec un TTL de cache de plusieurs jours :
```
0 0,12 * * * /bin/bash /chemin/vers/cache-warm.sh
```
Sur mon site, le premier passage a régénéré 199 pages sur 236. Le passage suivant, juste après, affichait 235 pages déjà en cache et zéro régénération. Le cron maintient cet état entre deux exécutions.
## Vérifier les deux autres maillons : object cache et OPcache
Deux réglages serveur pèsent sur le cold-start, et l’un des deux m’a joué un tour.
L’object cache d’abord. LiteSpeed peut le brancher sur Redis ou Memcached. Si la configuration pointe vers un service absent de votre offre, LiteSpeed tente une connexion qui échoue à chaque génération de page, et ce délai s’ajoute à chaque cold-start. Sur du mutualisé sans Redis, le bon réflexe est de désactiver l’object cache (LiteSpeed Cache, onglet Cache, sous-onglet Object). Pour vérifier si Redis existe chez vous :
```
redis-cli -h localhost -p 6379 ping
```
Une réponse `PONG` veut dire que Redis tourne. Une erreur de connexion veut dire qu’il faut couper l’object cache.
OPcache ensuite. C’est le cache d’opcode PHP. Bien réglé, il évite de recompiler le code à chaque requête. Sur mon serveur il tournait déjà à 99,8 % de hit avec 256 Mo alloués, donc rien à corriger. Vérifiez le vôtre via une page `phpinfo()` temporaire, section Zend OPcache, puis supprimez la page aussitôt : laissée en ligne, elle expose toute votre configuration serveur.
## Que faire une fois le cache préchauffé ?
Relancez l’audit. Le crawler tombe alors sur des pages déjà en cache, et le taux de pages lentes s’effondre. Le « 100 % » n’aura jamais reflété l’expérience de vos visiteurs, qui touchaient le cache depuis le début.
La leçon que j’en retire : un score d’audit alarmant mérite toujours une contre-mesure manuelle avant de réécrire 250 pages pour rien. Deux requêtes curl m’ont évité une semaine de chantier inutile.
### Pourquoi un audit indique-t-il 100 % de pages lentes alors que mon site WordPress est rapide ?
Parce que le crawler d’audit visite chaque URL une seule fois et tombe sur la version froide de la page, régénérée en PHP, jamais sur la version servie depuis le cache. Le TTFB mesuré à froid peut atteindre 1 800 ms quand le même page sort à 150 ms une fois en cache.
### Comment vérifier si une page WordPress est servie depuis le cache LiteSpeed ?
Inspectez l’en-tête HTTP x-litespeed-cache avec la commande curl -sI u0022https://votre-site.fr/une-page/u0022 | grep -i x-litespeed-cache. La valeur hit signifie que la page est servie depuis le cache, miss qu’elle a été régénérée côté serveur.
### Comment garder le cache LiteSpeed chaud sur un hébergement mutualisé ?
Mettez en place un cron qui parcourt votre sitemap et requête chaque URL deux fois par jour. Chaque page reste ainsi en cache et aucune n’est jamais servie à froid, ni à un visiteur ni à un crawler. Sur un site de 236 pages, un passage suffit à passer de 199 régénérations à zéro.
### Faut-il activer l’object cache Redis sur LiteSpeed ?
Seulement si votre hébergement fournit réellement un service Redis joignable. Si la configuration pointe vers un Redis absent, LiteSpeed tente une connexion qui échoue à chaque génération de page et ralentit chaque cold-start. Testez avec redis-cli -h localhost -p 6379 ping : sans réponse PONG, désactivez l’object cache.