# Un site média à 500 000 contenus en éditeur de site : notre audit de performance

> 500 000 articles publiés, un thème bloc unique, et des temps de réponse qui se dégradent sur les archives. Retour chiffré sur les goulots d'étranglement identifiés à cette échelle.

- Auteur : Clément Hadrot
- Publié le : 2026-02-06
- Mis à jour le : 2026-02-06
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/audit-performance-site-media-500000-contenus/

## L’essentiel

- La Query Loop des archives générait une requête non indexée sur les métadonnées
- Le bloc de navigation regénérait sa structure à chaque requête
- Les patterns imbriqués multipliaient le nombre de hooks exécutés

500 000 contenus publiés en quinze ans d'existence, un thème bloc entièrement rebâti sur l'éditeur de site il y a deux ans, et des pages d'archive qui mettent plus de quatre secondes à se générer aux heures de pointe : voilà le point de départ de cet audit, mené sur un site de presse généraliste à fort trafic.

L'objectif n'était pas de réécrire le thème, mais d'identifier précisément où partait le temps de génération, à une échelle où chaque milliseconde gagnée se traduit en charge serveur réelle sur des dizaines de milliers de visiteurs simultanés.

## Premier goulot : une Query Loop sur métadonnées non indexées

Le template `archive-actualite.html` affiche une Query Loop filtrée par une métadonnée personnalisée (`meta_key` stockant la rubrique éditoriale), utilisée en complément de la taxonomie standard pour des raisons historiques. Sur une table `postmeta` qui dépasse plusieurs millions de lignes à cette échelle, une requête filtrée sur une métadonnée non indexée spécifiquement se traduit par un scan de table conséquent à chaque appel.

Le profilage de la requête générée par `WP_Query` confirme le diagnostic : la clause `meta_query` ajoutée par le filtre `pre_get_posts` du thème provoque une jointure coûteuse, exécutée à chaque chargement de page d'archive, sans aucune mise en cache de résultat.

## Deuxième goulot : un bloc de navigation reconstruit à chaque requête

> L'essentiel à retenir : La Query Loop des archives générait une requête non indexée sur les métadonnées ; Le bloc de navigation regénérait sa structure à chaque requête ; Les patterns imbriqués multipliaient le nombre de hooks exécutés

Le bloc `core/navigation` utilisé dans `header.html` référence un menu de navigation stocké comme entité `wp_navigation`, correctement mis en cache par le cœur de WordPress dans la majorité des cas. Le profilage révèle ici qu'un filtre personnalisé, ajouté pour afficher un badge « nouveau » sur certaines rubriques du menu selon la date du dernier article publié, s'exécute à chaque rendu du bloc, sans aucune mise en cache de son résultat, alors même que ce badge ne change réellement que quelques fois par jour.

## Troisième goulot : des patterns imbriqués sur plusieurs niveaux

La page d'accueil du site combine une douzaine de patterns imbriqués les uns dans les autres (bloc de mise en avant, colonnes de rubriques, encart abonnement), chacun déclenchant son propre lot de hooks `render_block`. À l'échelle d'une page d'accueil visitée plusieurs millions de fois par jour, la multiplication des hooks exécutés à chaque rendu de bloc représente une charge cumulée non négligeable, même quand chaque hook pris isolément reste rapide.

## Les correctifs mis en œuvre

- Migration de la métadonnée de rubrique éditoriale vers la taxonomie native déjà en place, correctement indexée, avec un script de migration en arrière-plan exécuté via `wp-cli` sur l'ensemble des 500 000 contenus.
- Mise en cache du résultat du filtre de badge de navigation, recalculé une seule fois toutes les quinze minutes via une tâche planifiée plutôt qu'à chaque requête.
- Fusion de plusieurs patterns de la page d'accueil en un nombre réduit de blocs de groupe, sans changer le rendu visuel, pour limiter le nombre de hooks déclenchés inutilement.

## Résultats mesurés après correction

| Page | Avant | Après |
| --- | --- | --- |
| Archive de rubrique | 4,1 s | 0,7 s |
| Page d'accueil | 1,9 s | 0,9 s |

Le temps de génération de la page d'archive de rubrique, la plus consultée du site après la page d'accueil, passe de 4,1 secondes à 0,7 seconde après la migration de la métadonnée vers la taxonomie native. La page d'accueil, moins affectée par le problème principal mais concernée par la multiplication des hooks, gagne également une seconde de génération moyenne.

> Sur un site de cette taille, un profilage rapide vaut toujours mieux qu'une intuition d'optimisation : le goulot le plus coûteux n'était pas celui qu'on attendait au départ, mais une métadonnée héritée d'une ancienne architecture jamais nettoyée.

## En résumé

À l'échelle de 500 000 contenus, les défauts d'architecture qui passent inaperçus sur un site plus modeste deviennent des goulots d'étranglement mesurables. Cet audit ne couvre volontairement ni la configuration du CDN d'images, gérée séparément par l'équipe infrastructure, ni les aspects liés à la monétisation publicitaire du site, hors périmètre de ce travail de profilage technique.