# Un site à 100 000 pages en éditeur de site : le rendu de la hiérarchie mesuré

> Reprendre un site de 100 000 pages construit en éditeur de site impose de mesurer, pas de deviner. Chiffres concrets sur l'impact du nombre de templates et de leur ordre de résolution à cette échelle.

- Auteur : WordPress Développement
- Publié le : 2022-06-06
- Mis à jour le : 2022-06-06
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/site-100000-pages-editeur-site-rendu-hierarchie-mesure/

## L’essentiel

- 100 000 pages générées par sept types de contenu distincts
- Le nombre de templates candidats influence directement le temps de résolution
- Réduire l'arborescence a mesurablement amélioré le rendu

340 millisecondes : c'est l'écart mesuré, sur ce site de comparateur de prix reposant sur sept types de contenu personnalisés et plus de 100 000 pages indexées, entre le temps de résolution de template avant et après simplification de l'arborescence du thème bloc. Un chiffre qui a surpris l'équipe reprenant ce projet, hérité d'une précédente agence, tant l'intuition initiale penchait plutôt vers le poids des requêtes en base de données comme principal facteur de lenteur.

Le site, construit sous WordPress 6.0 fraîchement sorti, utilisait un thème bloc comportant dix-huit fichiers de templates différents, avec des règles de priorité imbriquées sur plusieurs niveaux : des templates spécifiques par type de contenu, eux-mêmes déclinés par taxonomie, dans une arborescence dont plus personne dans l'équipe cliente ne comprenait entièrement la logique.

## Comprendre comment WordPress résout un template à cette échelle

À chaque requête, WordPress parcourt une hiérarchie de templates candidats, du plus spécifique au plus générique, jusqu'à trouver une correspondance. Sur un thème classique avec peu de templates, ce parcours reste négligeable en temps de calcul. Mais sur un thème bloc comportant dix-huit fichiers, avec des combinaisons de type de contenu et de taxonomie multipliant les candidats potentiels à chaque requête, ce parcours devient mesurable, en particulier sous une charge de plusieurs centaines de requêtes simultanées.

## La mesure : instrumenter la résolution de template

Plutôt que de se fier à une impression générale de lenteur, l'équipe a instrumenté la fonction de résolution de template à l'aide du hook `template_include`, en mesurant précisément le temps écoulé depuis le début de la requête jusqu'à la détermination du fichier final à charger, sur un échantillon de mille requêtes réelles issues des journaux d'accès.

> L'essentiel à retenir : 100 000 pages générées par sept types de contenu distincts ; Le nombre de templates candidats influence directement le temps de résolution ; Réduire l'arborescence a mesurablement amélioré le rendu

```
add_filter( 'template_include', function ( $template ) {
    static $debut = null;
    $debut = $debut ?? $GLOBALS['timestart'];
    $duree_ms = ( microtime( true ) - $debut ) * 1000;
    error_log( sprintf( 'Résolution template : %s en %.2f ms', $template, $duree_ms ) );
    return $template;
}, 999 );
```

Les résultats ont montré une corrélation nette entre le nombre de templates candidats évalués pour un type de contenu donné et le temps de résolution mesuré : les pages de type `produit-comparatif`, dont la hiérarchie comportait cinq niveaux de spécificité imbriqués, affichaient un temps de résolution presque deux fois supérieur à celui des pages de type `article-guide`, plus simples dans leur hiérarchie.

## La simplification appliquée

La correction n'a pas consisté à réduire les fonctionnalités du site, mais à aplatir la hiérarchie de templates là où elle n'apportait aucune valeur réelle : plusieurs templates quasi identiques, créés initialement pour des besoins ponctuels jamais réutilisés, ont été fusionnés en un seul template générique par type de contenu, avec des conditions internes plutôt que des fichiers séparés.

| Type de contenu | Templates candidats avant | Templates candidats après |
| --- | --- | --- |
| produit-comparatif | 5 | 2 |
| article-guide | 3 | 2 |
| marque | 4 | 1 |

## Ce que cette mesure a confirmé, et ce qu'elle n'explique pas

Cette simplification explique une partie du gain mesuré, mais pas la totalité : l'équipe a également constaté, en parallèle, une réduction du nombre de requêtes SQL redondantes, liée non pas à la hiérarchie de templates elle-même mais à des appels dupliqués dans certains patterns réutilisés sur plusieurs templates fusionnés. Ce billet ne traite pas cette optimisation de requêtes, ni le cache serveur mis en place en complément, tous deux hors du périmètre strict de cette mesure sur la résolution de templates.

> Sur un site de cette taille, deviner ne suffit jamais : mesurer précisément où le temps est réellement consommé évite de corriger un problème qui n'existe pas, au détriment d'un autre bien réel mais invisible sans instrumentation.

## Ce qui reste à surveiller

La hiérarchie simplifiée reste plus facile à maintenir pour l'équipe éditoriale, mais impose une discipline stricte pour éviter qu'elle ne se complexifie à nouveau au fil des demandes ponctuelles futures : chaque nouveau besoin de template spécifique doit désormais être justifié par un volume de pages suffisant pour en valoir le coût de maintenance.

## En résumé

Sur un site de 100 000 pages, la hiérarchie de résolution de templates d'un thème bloc n'est pas un détail théorique : elle se mesure, en millisecondes, et son impact grandit avec le nombre de templates candidats évalués à chaque requête. Aplatir une arborescence héritée, sans réduire les fonctionnalités, a permis un gain mesuré de 340 millisecondes en moyenne sur ce projet, un chiffre suffisamment significatif pour justifier l'effort de refonte.