200 143 articles publiés, une moyenne de soixante-dix nouvelles publications par jour, et un cache de page qui se vidait intégralement à chaque publication : c’est la situation trouvée sur ce média d’actualité régionale au moment de la reprise du thème. Le symptôme visible pour les lecteurs était simple — des pages qui mettaient parfois plus de trois secondes à charger aux heures de forte publication — mais la cause tenait entièrement à l’architecture du thème et à sa stratégie de cache, pas au serveur lui-même.
Ce retour d’expérience détaille les deux chantiers menés sur ce thème : la purge de cache ciblée par catégorie, et la refonte de la hiérarchie de templates d’archives. Il ne couvre ni la configuration du CDN d’images ni la stratégie de monétisation publicitaire du site, traités séparément par d’autres équipes.
Le problème : une purge de cache en cascade
Le thème d’origine, hérité d’un précédent prestataire, déclenchait une purge complète du cache de page à chaque publication ou mise à jour d’article, via un simple hook save_post qui appelait une purge globale de l’extension de cache installée. Sur un site à faible fréquence de publication, cette approche ne pose aucun problème. À soixante-dix publications par jour, réparties sur douze sections thématiques (économie locale, sport, culture, faits divers…), chaque publication reconstruisait l’intégralité du cache du site, y compris les pages d’archives de sections totalement étrangères à l’article publié.
Le calcul est parlant : avec une moyenne de trois publications par heure sur les heures ouvrées, et un temps de reconstruction du cache d’environ quarante secondes pour l’ensemble du site, les pages servaient en continu du contenu en cours de régénération, avec des pics de temps de réponse mesurés jusqu’à 2,8 secondes sur la page d’accueil.
Le correctif : une purge de cache scopée par taxonomie
La réécriture cible désormais uniquement les pages réellement affectées par une publication : la page de l’article, la page d’archive de sa catégorie, la page d’accueil, et les pages d’archives des taxonomies associées (tags principaux). Un article publié en section « sport » ne déclenche plus de reconstruction des pages « culture » ou « faits divers » :
add_action( 'save_post', function( $post_id ) {
if ( wp_is_post_revision( $post_id ) ) {
return;
}
$urls_a_purger = [ get_permalink( $post_id ), home_url( '/' ) ];
$categories = get_the_category( $post_id );
foreach ( $categories as $categorie ) {
$urls_a_purger[] = get_category_link( $categorie->term_id );
}
foreach ( $urls_a_purger as $url ) {
mon_cache_purger_url( $url );
}
}, 20 );Résultat mesuré sur un mois de production : le nombre de purges déclenchées par jour est passé d’environ 480 (une purge globale par publication, multipliée par le nombre de pages concernées en interne) à environ 80 purges ciblées, soit un facteur proche de six. Le temps de reconstruction global du cache après une purge complète — désormais rare, réservée aux changements de structure du thème — reste inchangé, mais il n’est plus déclenché en continu.
La hiérarchie de templates d’archives, section par section
Le second chantier a porté sur la hiérarchie de templates. Le thème d’origine utilisait un unique archive.php générique pour toutes les catégories, avec une cascade de conditions if ( is_category( 'sport' ) ) à l’intérieur du même fichier. Cette structure, en plus d’être difficile à maintenir, chargeait systématiquement toutes les requêtes secondaires possibles (widgets « articles liés », compteurs de commentaires par section) même quand elles n’étaient pas nécessaires pour la section affichée.
La refonte s’appuie sur la hiérarchie de templates native de WordPress, en tirant parti de fichiers spécifiques par catégorie plutôt que de conditions empilées :
wp-content/themes/media-theme/
├── archive.php (page d'archive générique, filet de sécurité)
├── category-economie.php (section économie, avec widget cours de bourse)
├── category-sport.php (section sport, avec widget classement)
└── category-culture.php (section culture, avec galerie d'images)WordPress résout automatiquement category-economie.php pour l’archive de la catégorie economie, sans condition explicite à écrire dans le code : c’est la hiérarchie de templates elle-même qui fait le tri. Chaque fichier ne charge plus que les requêtes secondaires réellement utiles à sa section, ce qui réduit mécaniquement le nombre de requêtes SQL par page d’archive.
Un filet de sécurité conservé sciemment
Le fichier archive.php générique reste en place pour toute nouvelle catégorie créée par la rédaction sans intervention technique — un nouveau format éditorial temporaire, par exemple — évitant qu’une page blanche n’apparaisse en attendant qu’un template dédié soit développé.
Ce que ce chantier n’a pas résolu à lui seul
La purge ciblée et la hiérarchie de templates ont réduit la charge liée aux publications, mais n’ont pas éliminé les pics de trafic liés à un article viral partagé massivement sur les réseaux sociaux, qui restent gérés par une couche de cache en amont du serveur, hors du périmètre du thème lui-même.
Un thème bien architecturé réduit la charge qu’il génère lui-même ; il ne remplace jamais une vraie stratégie de cache en amont pour absorber les pics de trafic externes.
En résumé
Sur un site à fort volume de publication, la purge de cache globale et une hiérarchie de templates trop générique sont deux angles morts fréquents, invisibles tant que le volume de contenu reste modéré. Ici, cibler la purge par catégorie et éclater les templates d’archives par section a divisé par six le nombre de purges quotidiennes et rendu les temps de réponse nettement plus stables aux heures de forte publication.
