# Deux architectures de préchauffage : tout précharger ou suivre le trafic réel

> Parcourir toutes les pages d'un site après chaque purge, ou ne chauffer que celles réellement visitées : deux philosophies de préchauffage à l'épreuve des faits.

- Auteur : Clément Hadrot
- Publié le : 2026-03-09
- Mis à jour le : 2026-03-09
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/deux-architectures-warmup-exhaustif-ou-trafic-reel/

## L’essentiel

- Le préchauffage exhaustif garantit une couverture totale mais coûte cher
- Le préchauffage suivant le trafic réel économise des ressources mais laisse un trou initial
- Le choix dépend de la taille du site et de la fréquence des purges

Deux fichiers de configuration, deux philosophies. Le premier lance un script qui parcourt méthodiquement les douze mille pages d'un site de documentation technique après chaque déploiement. Le second se contente d'observer les journaux d'accès des dernières vingt-quatre heures et ne réchauffe que les pages qui y apparaissent. Le même objectif — éviter qu'un visiteur ne tombe sur une génération complète de page après une purge de cache — poursuivi par deux moyens radicalement différents.

Ce site de documentation technique pour développeurs comptait plusieurs milliers de pages générées à partir d'articles, de références d'API et de guides, avec un trafic très inégal : une centaine de pages recevaient l'essentiel des visites, tandis que des milliers d'autres n'étaient consultées que quelques fois par mois, souvent via un moteur de recherche externe.

## L'architecture exhaustive : tout reconstruire, sans distinction

Le script exhaustif s'appuyait sur `wp-cli` pour lister l'intégralité des URL publiées, puis les parcourait une par une avec un léger délai entre chaque requête pour ne pas saturer le serveur :

```
wp post list --post_status=publish --field=url --posts_per_page=-1 > urls.txt

while read -r url; do
    curl -s -o /dev/null "$url"
    sleep 0.05
done < urls.txt
```

Sur ce site, ce script mettait un peu plus de dix minutes à parcourir les douze mille pages publiées. Le bénéfice : n'importe quelle page, même consultée une fois par trimestre, restait toujours servie depuis le cache. L'inconvénient : la grande majorité de ce temps de calcul était dépensée sur des pages que peu de visiteurs allaient réellement consulter avant la purge suivante.

## L'architecture suivant le trafic réel : cibler ce qui compte

> L'essentiel à retenir : Le préchauffage exhaustif garantit une couverture totale mais coûte cher ; Le préchauffage suivant le trafic réel économise des ressources mais laisse un trou initial ; Le choix dépend de la taille du site et de la fréquence des purges

La seconde approche interrogeait les journaux d'accès du serveur web sur les dernières vingt-quatre heures, en extrayait la liste des URL uniques réellement demandées, et ne réchauffait que celles-ci après chaque purge :

```
awk '{print $7}' /var/log/nginx/access.log \
  | grep -v '\.\(css\|js\|png\|jpg|svg\)$' \
  | sort -u > urls_recentes.txt

while read -r chemin; do
    curl -s -o /dev/null "https://exemple-doc.test${chemin}"
done < urls_recentes.txt
```

Sur ce même site, cette liste ne comptait généralement qu'entre 400 et 600 URL, réduisant le temps total de préchauffage à un peu moins d'une minute. Le revers de la médaille est apparu lors d'un pic de trafic inhabituel, provoqué par la mention du site sur un forum de développeurs : plusieurs pages rarement visitées, absentes des journaux des vingt-quatre heures précédentes, ont dû être générées à la volée par les premiers visiteurs venus de ce pic, avant d'intégrer le préchauffage du lendemain.

## Comparaison mesurée sur trois mois

| Critère | Warmup exhaustif | Warmup suivant le trafic |
| --- | --- | --- |
| Durée d'exécution moyenne | 11 minutes | 50 secondes |
| Pages jamais consultées en cache pourtant chaud | Élevé (gaspillage) | Faible |
| Pages consultées pour la première fois après un pic externe | Toujours en cache | Génération à la volée pour les premiers visiteurs |
| Charge serveur lors du préchauffage | Modérée mais prolongée | Brève mais concentrée |

## La solution hybride retenue

Le compromis final combine les deux logiques : un préchauffage suivant le trafic réel s'exécute après chaque purge pour couvrir rapidement l'essentiel de l'audience, complété une fois par semaine par un passage exhaustif, exécuté la nuit, pour garantir qu'aucune page ancienne référencée par un moteur de recherche externe ne reste durablement froide.

- Le préchauffage quotidien suivant le trafic couvre plus de 95 % des visites réelles avec un coût minime.
- Le passage exhaustif hebdomadaire, exécuté hors heures de pointe, rattrape les pages moins visibles.
- Aucune des deux exécutions ne se déclenche plus d'une fois par purge, évitant tout gaspillage redondant.

> Chauffer tout coûte cher pour un bénéfice dilué ; ne chauffer que le trafic connu laisse un angle mort sur ce qu'on n'a pas encore vu venir.

## En résumé

Ni l'architecture exhaustive ni celle suivant uniquement le trafic réel ne s'est révélée suffisante seule sur ce site de documentation à plusieurs milliers de pages. La combinaison des deux, avec des fréquences d'exécution différentes selon leur coût respectif, a offert la meilleure couverture pour le coût de calcul le plus raisonnable.