Comment mesurer votre taux de cache hit (et quoi faire s'il est bas)

Qu'est-ce que le taux de cache hit ?

Le taux de cache hit est le pourcentage de requêtes HTTP servies directement depuis le cache, sans atteindre votre serveur d'origine. Un taux de 90 % signifie que 9 requêtes sur 10 n'atteignent jamais votre application PHP ni votre base de données.

Taux de hit = (cache hits) / (cache hits + cache misses) × 100

Un taux de hit élevé signifie :

• Des réponses plus rapides pour les utilisateurs (les réponses en cache sont 10 à 100× plus rapides que les réponses de l'origine)
• Une charge serveur réduite (moins de requêtes atteignent PHP/la base de données)
• De meilleurs scores Core Web Vitals (sur un miss, le TTFB est dominé par le temps de réponse de l'origine)

Mesurer le taux de cache hit selon votre stack

Cloudflare

Le point de départ le plus simple. Dans le dashboard Cloudflare :

1. Allez dans Caching → Cache Analytics (ou Analytics & Logs → Traffic)
2. Regardez la répartition par statut de cache (hit / miss / expired …)

Cloudflare répartit les requêtes en : hit, miss, expired, bypass, revalidated, dynamic.

Pour un taux approximatif : hit / (hit + miss + expired). Ignorez bypass (requêtes configurées pour contourner le cache) et dynamic (Cloudflare Workers ou réponses d'API).

Via l'API (l'ancien endpoint Zone Analytics a été retiré en 2020 — utilisez l'API GraphQL Analytics) :

SINCE=$(date -u -d '7 days ago' +%Y-%m-%d)   # macOS : date -u -v-7d +%Y-%m-%d
curl https://api.cloudflare.com/client/v4/graphql \
  -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
  -d '{"query":"query($zone:String!){viewer{zones(filter:{zoneTag:$zone}){httpRequests1dGroups(limit:7,filter:{date_geq:\"'"$SINCE"'\"}){sum{requests cachedRequests}}}}}","variables":{"zone":"'"$ZONE_ID"'"}}' \
  | jq '[.data.viewer.zones[0].httpRequests1dGroups[].sum]
        | {cached:(map(.cachedRequests)|add), total:(map(.requests)|add)}
        | {cached, total, ratio:(.cached/.total*100)}'

Varnish

# Stats en direct (rafraîchies chaque seconde)
varnishstat -f MAIN.cache_hit -f MAIN.cache_miss

# Instantané unique avec taux calculé
varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss | awk '
  /cache_hit/  { hit  = $2 }
  /cache_miss/ { miss = $2 }
  END { printf "Hit: %d  Miss: %d  Ratio: %.1f%%\n", hit, miss, hit/(hit+miss)*100 }
'

Pour des stats par fenêtre de temps, utilisez varnishlog avec vsl-query ou mettez en place Prometheus + un exporter Varnish.

Nginx (proxy_cache)

Ajoutez ces variables à votre format de log d'accès :

log_format cache_status '$remote_addr - $upstream_cache_status '
                        '"$request" $status $body_bytes_sent';
access_log /var/log/nginx/cache.log cache_status;

$upstream_cache_status renvoie HIT, MISS, EXPIRED, BYPASS, STALE ou UPDATING.

# Répartition des statuts de cache dans le log
awk '{print $3}' /var/log/nginx/cache.log | sort | uniq -c | sort -rn
# Puis : HIT / (HIT + MISS + EXPIRED) × 100

WP Rocket / LiteSpeed Cache

Vous pouvez détecter ces plugins sur chaque réponse :

• WP Rocket : aucun en-tête de cache par défaut — vérifiez à la fin du source HTML la présence du commentaire de signature <!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket... - Debug: cached@<timestamp> -->
• LiteSpeed : X-LiteSpeed-Cache: hit

Pour des stats agrégées, il vous faut soit un logging au niveau serveur (Nginx/Apache), soit un plugin comme Query Monitor qui affiche le statut de cache par requête.

Google Search Console (pour l'impact SEO)

Search Console n'affiche pas de taux de cache hit, mais elle montre les conséquences d'un taux trop bas. Dans Core Web Vitals :

• Un TTFB (Time to First Byte) élevé sur les pages crawlées indique généralement des hits sur cache froid
• Les pages avec de mauvais scores LCP sont souvent corrélées à des réponses d'origine non mises en cache

Croisez vos événements de vidage de cache (déploiements, mises à jour de plugins) avec les baisses de scores Core Web Vitals dans Search Console pour visualiser l'impact SEO des périodes de cache froid.

Quels chiffres viser

Causes courantes d'un taux de hit bas

1. TTL trop court : si votre Cache-Control: max-age est de 60 secondes, les pages expirent avant que le trafic organique ne les réchauffe. Étendez le TTL à 3600–86400 secondes pour le contenu majoritairement statique.

2. Règles de bypass trop larges : Cache-Control: no-cache ou no-store sur des pages qui n'en ont pas besoin. Vérifiez si votre CMS ou framework ajoute ces en-têtes par défaut.

3. Purges excessives : les boutiques WooCommerce qui purgent à chaque changement de stock peuvent vider leur cache des centaines de fois par jour. Limitez ou regroupez les événements de purge.

4. Variations de query string : example.com/page?ref=newsletter et example.com/page?ref=twitter sont traitées comme des URLs distinctes par la plupart des caches. Normalisez les query strings dans votre configuration de cache pour éviter la fragmentation.

5. Pas de préchauffage : même une configuration de cache parfaite produit un taux de hit bas juste après un vidage. Sans préchauffage, le taux remonte lentement au rythme où le trafic organique re-remplit le cache. Avec préchauffage, il remonte en quelques minutes.

Construire un dashboard de santé du cache

Pour les sites en production, suivez le taux de hit dans le temps plutôt que par sondages ponctuels :

• Cloudflare Analytics (intégré)
• Varnish + exporter Prometheus + Grafana (auto-hébergé)
• Historique des exécutions CacheBoost (montre l'achèvement des préchauffages, corrélé à la remontée du taux de hit)

Configurez une alerte quand le taux de hit passe sous 70 % : cela révèle généralement un vidage de cache imprévu ou un problème de configuration à investiguer.