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

> Le taux de cache hit est la métrique la plus utile pour comprendre la santé de votre cache. Voici comment le mesurer selon votre stack et quels chiffres viser.

Source: https://www.cache-boost.com/fr/blog/comment-mesurer-taux-de-cache-hit.md
Language: fr

---


Tags: tutorial, performance
Published: 2026-06-24
Author: Nicolas Hodin
Reading time: 5 min

---

## 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) :
```bash
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

```bash
# 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 :

```nginx
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`.

```bash
# 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

| Taux de hit | Évaluation |
|-----------|------------|
| > 90 % | Sain : la plupart des visiteurs obtiennent des réponses en cache |
| 70–90 % | Acceptable : marge d'amélioration, surtout pour les pages à fort trafic |
| 50–70 % | Bas : examinez vos réglages de TTL et votre fréquence de purge |
| < 50 % | Critique : impact significatif sur les performances et les coûts |

## 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.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try