Sur un site à 100 000 pages, reprendre un thème existant impose de comprendre précisément comment WordPress choisit le gabarit à utiliser pour chaque page, avant d’ajouter la moindre nouvelle règle. Ce projet, une base documentaire technique organisée par catégories et sous-catégories profondes, avait accumulé au fil des années une hiérarchie de templates si détaillée qu’elle finissait par peser sur le temps de rendu de chaque page.
Comprendre la hiérarchie de templates en jeu
Pour une page de catégorie, WordPress teste dans l’ordre une série de fichiers avant de retomber sur index.php : category-{slug}.php, category-{id}.php, category.php, archive.php, puis index.php. Sur ce projet, l’équipe précédente avait créé un fichier category-{slug}.php distinct pour chacune des 340 catégories du site, chacun ne différant du gabarit générique que par quelques lignes de mise en forme spécifique.
Mesurer l’impact réel
Avant toute intervention, un comptage a établi la réalité du problème : sur la résolution de template d’une page de catégorie profonde, WordPress testait l’existence de 47 fichiers différents avant de trouver une correspondance, en remontant la hiérarchie de templates pour chaque niveau de la structure (catégorie, catégorie parente, taxonomie personnalisée associée). Ce chiffre a été obtenu en instrumentant temporairement le filtre template_include pour journaliser chaque tentative de résolution :
add_filter( 'template_include', function( $template ) {
error_log( 'Template resolu : ' . $template );
return $template;
}, 999 );
Ce que ce nombre coûte réellement
Chaque test de fichier correspond à un appel système file_exists() sur le disque. Pris isolément, ce coût est négligeable ; multiplié par des dizaines de fichiers testés à chaque requête, sur un site recevant plusieurs centaines de milliers de visites mensuelles, l’effet cumulé devient mesurable. Les tests de charge menés sur ce projet ont montré un gain d’environ 8 millisecondes par requête après simplification de la hiérarchie, un chiffre modeste isolément mais qui s’ajoute à d’autres optimisations sur un site à ce volume.
La solution retenue : un template_include ciblé
Plutôt que de maintenir 340 fichiers category-{slug}.php quasiment identiques, la logique a été centralisée dans un unique gabarit category.php, avec les variations spécifiques gérées par une donnée stockée en métadonnée de terme plutôt que par un fichier distinct :
function mon_theme_donnees_categorie( $template ) {
if ( is_category() ) {
$terme = get_queried_object();
$variante = get_term_meta( $terme->term_id, 'variante_affichage', true );
set_query_var( 'variante_affichage', $variante ?: 'standard' );
}
return $template;
}
add_filter( 'template_include', 'mon_theme_donnees_categorie', 5 );
Le gabarit unique lit ensuite cette variable de requête pour adapter son affichage, sans multiplier les fichiers physiques que WordPress doit tester à chaque résolution :
<?php
$variante = get_query_var( 'variante_affichage', 'standard' );
if ( 'mise-en-avant' === $variante ) {
get_template_part( 'template-parts/categorie', 'mise-en-avant' );
} else {
get_template_part( 'template-parts/categorie', 'standard' );
}
Ce qui a été volontairement conservé en fichiers séparés
Trois catégories majeures du site, avec une mise en page réellement distincte et non une simple variation cosmétique, ont conservé leur propre fichier category-{slug}.php. La règle retenue par l’équipe a été de réserver un fichier de template dédié aux différences structurelles réelles, et de ramener toute variation purement visuelle vers une donnée de configuration au sein d’un gabarit commun.
Ce que ce cas ne couvre pas
Cette étude porte uniquement sur la hiérarchie de résolution de templates. L’optimisation des requêtes de base de données associées à ces pages de catégorie, ainsi que la stratégie de cache serveur appliquée au site, relèvent de chantiers distincts, menés séparément sur ce même projet.
En résumé
Sur un site à fort volume de contenu, une hiérarchie de templates trop fine, même si chaque fichier reste simple individuellement, finit par peser sur le temps de rendu à cause du nombre de tests de fichiers effectués à chaque requête. Centraliser la logique dans un nombre restreint de gabarits, avec les variations pilotées par des données plutôt que par des fichiers distincts, redonne de la marge de performance sans sacrifier la richesse de personnalisation par catégorie.
