Une tâche planifiée qui repasse sur les mêmes pages toutes les heures et un script qu’on lance à la main trente minutes avant l’ouverture des inscriptions : deux logiques opposées pour éviter qu’un cache froid n’accueille les premiers visiteurs d’un pic annoncé. Sur un site de billetterie associative, les deux méthodes ont été testées à quelques semaines d’intervalle, avec le même objectif : qu’aucune des cinq cents premières requêtes ne tombe sur une génération complète de la page.
Le préchauffage consiste à demander au serveur de générer et de stocker en cache les pages avant qu’un vrai visiteur ne les demande. Sans lui, la première requête après une purge — ou après un redémarrage de Redis — paie le prix fort : requêtes SQL, rendu des blocs, appels aux extensions. Multipliée par des centaines de connexions simultanées au moment précis d’une ouverture de billetterie, cette lenteur peut faire tomber le site.
La tâche planifiée : simple, mais aveugle au calendrier
La première approche s’appuie sur wp_schedule_event() pour déclencher, toutes les heures, un script qui parcourt les URL les plus consultées et les recharge via une requête HTTP interne. Le code ressemble à ceci :
if ( ! wp_next_scheduled( 'wpm_cache_warmup' ) ) {
wp_schedule_event( time(), 'hourly', 'wpm_cache_warmup' );
}
add_action( 'wpm_cache_warmup', function () {
$urls = get_option( 'wpm_urls_a_chauffer', array() );
foreach ( $urls as $url ) {
wp_remote_get( $url, array( 'timeout' => 15, 'blocking' => false ) );
}
} );L’avantage : aucune intervention humaine n’est nécessaire, le cache reste tiède en permanence. L’inconvénient est apparu vite : la liste d’URL à chauffer était fixée une fois pour toutes, sans tenir compte du fait qu’une page événementielle n’existait pas encore la semaine précédente. Le cron chauffait consciencieusement des pages sans intérêt le jour J, pendant que la page qui allait recevoir l’essentiel du trafic restait absente de la liste.
Le déclenchement manuel : précis, mais qui dépend d’un humain qui s’en souvient
La seconde méthode part d’un script WP-CLI lancé à la demande, quelques minutes avant l’ouverture annoncée :
wp eval '
$urls = array(
home_url( "/billetterie/festival-de-village/" ),
home_url( "/billetterie/festival-de-village/paiement/" ),
);
foreach ( $urls as $url ) {
wp_remote_get( $url, array( "timeout" => 20 ) );
}
'Un opérateur — souvent la personne qui gère la communication — lance la commande depuis un terminal SSH juste avant l’annonce sur les réseaux sociaux. Le ciblage est parfait : seules les pages concernées par l’événement du jour sont chauffées, avec autant de répétitions que nécessaire pour couvrir les variantes de cache (connecté, non connecté, langue). Le revers de la médaille est humain : si personne ne pense à lancer le script, ou si l’annonce est avancée sans prévenir l’équipe technique, le cache reste froid.
Ce que révèle la mesure
Un test comparatif a été mené sur deux ouvertures de billetterie à une semaine d’écart, avec un outil de charge simulant 500 connexions en trente secondes :
- Avec le cron seul : 18 % des requêtes ont dépassé 2 secondes de temps de réponse, le temps que le cache se stabilise après les premières générations.
- Avec le déclenchement manuel réalisé quatre minutes avant l’ouverture : moins de 1 % des requêtes ont dépassé 800 millisecondes.
- Combiner les deux, en gardant le cron pour les pages stables et le script pour l’événement du jour, a donné le meilleur résultat des deux tests.
Automatiser sans perdre la précision
La solution retenue a consisté à déclencher le script de préchauffage ciblé automatiquement, mais depuis un événement métier plutôt que depuis l’horloge : au moment où la page passe du statut brouillon à publié via transition_post_status, un hook programme un préchauffage différé de quelques minutes avec wp_schedule_single_event(). Cela retire l’oubli humain de l’équation tout en gardant la précision du ciblage.
Un cache chaud n’a de valeur que sur les pages que le trafic va réellement toucher : chauffer large coûte du temps serveur pour un bénéfice dilué.
En résumé
Le cron convient aux sites dont le trafic est stable et prévisible d’une semaine sur l’autre. Le déclenchement ciblé s’impose dès qu’un événement précis — ouverture de billetterie, lancement de campagne, publication attendue — doit être servi rapide dès la première seconde. La combinaison des deux, pilotée par les événements du site plutôt que par le calendrier seul, a évité l’essentiel des lenteurs constatées lors des deux premiers essais.
