« Est-ce qu’un en-tête avec cinq template parts imbriquées coûte vraiment plus cher qu’un en-tête simple ? » La question m’a été posée par un développeur qui soupçonnait, sans preuve, qu’un thème client conçu par une autre agence multipliait les parts sans réelle nécessité. Plutôt que de trancher à l’intuition, j’ai mesuré, sur un même environnement de test, plusieurs configurations réalistes.
Méthode de mesure : hors cache de page, en isolant le rendu des blocs
Toute mesure de performance côté page se heurte au cache : un cache de page bien configuré rend cette question presque théorique en production. Mais elle reste pertinente pour la charge serveur au moment de la génération (première visite, contenu dynamique, pages non mises en cache comme un panier ou un compte utilisateur). Les mesures ci-dessous isolent donc volontairement le temps de rendu PHP des blocs, en désactivant tout cache de page et tout cache d’objet persistant, via des points de mesure placés autour de l’appel qui transforme les blocs enregistrés en HTML final (la fonction render_block(), appelée en cascade pour chaque bloc et sous-bloc).
Quatre configurations testées
Sur un même thème de base, j’ai comparé quatre versions d’un même en-tête, en ne faisant varier que sa profondeur de composition :
| Configuration | Temps de rendu moyen | Poids HTML généré |
|---|---|---|
| En-tête statique, un seul niveau, aucune template part | 1,2 ms | 3,1 Ko |
| En-tête en une template part unique | 1,6 ms | 3,3 Ko |
| En-tête avec deux parts imbriquées (logo + navigation séparés) | 2,4 ms | 3,6 Ko |
| En-tête avec cinq parts imbriquées et deux patterns synchronisés inclus | 4,9 ms | 5,8 Ko |
Ce que ces chiffres cachent : la résolution, pas seulement l’affichage
L’augmentation n’est pas linéaire par accident : chaque template part imbriquée déclenche sa propre résolution de hiérarchie (recherche du fichier thème, vérification d’une éventuelle version personnalisée en base via wp_template_part), en plus du rendu du contenu qu’elle contient. Un pattern synchronisé ajoute, lui, une requête pour récupérer l’article wp_block correspondant — sauf si son contenu a déjà été mis en cache d’objet dans le même cycle de requête, ce qui atténue partiellement le coût sur les pages où le même pattern apparaît plusieurs fois.
Le poids du HTML généré grossit également, moins à cause du contenu réel affiché qu’à cause des commentaires de blocs et des classes générées automatiquement (identifiants de blocs, classes utilitaires de espacement et de couleur) présents à chaque niveau d’imbrication.
Le vrai facteur aggravant : les blocs dynamiques, pas la profondeur seule
Un test complémentaire, ajoutant un bloc Requête (core/query) affichant six articles dans le pied de page plutôt qu’en dehors du test précédent, a fait grimper le temps de rendu à plus de 14 ms sur la même configuration — largement au-delà de l’effet de la seule imbrication de parts et patterns statiques. Un bloc dynamique exécute une requête WP_Query complète à chaque affichage non caché, un coût sans commune mesure avec la simple résolution d’une template part ou d’un pattern statique.
Ce qu’il faut retenir de ces ordres de grandeur
- Multiplier les template parts statiques a un coût réel, mais reste de l’ordre de quelques millisecondes même à cinq niveaux d’imbrication.
- Un seul bloc dynamique mal placé (Requête, Derniers commentaires) pèse largement plus que toute la structure statique environnante.
- Le poids en Ko du HTML augmente avec l’imbrication, un facteur à surveiller séparément du temps de rendu serveur, notamment pour le temps de transfert sur mobile.
Notre verdict
Structurer un en-tête ou un pied de page en plusieurs template parts reste largement justifié pour la maintenabilité (zones éditables séparément, droits différenciés), et le coût de performance associé reste marginal en valeur absolue, surtout derrière un cache de page correctement configuré. La vraie vigilance à avoir porte sur les blocs dynamiques : leur présence répétée dans une structure très imbriquée, elle, peut réellement se faire sentir sur la charge serveur, bien avant que le nombre de template parts n’en devienne un facteur significatif.
