Zéro milliseconde de calcul serveur supplémentaire : c’est le coût de rendu d’un pattern de blocs statique une fois inséré dans le contenu, contre 38 millisecondes en moyenne pour un bloc dynamique équivalent affichant visuellement la même chose sur une page d’accueil à fort trafic.
Le test portait sur une section « nos derniers projets » affichée en haut de la page d’accueil d’un site à fort trafic. Deux implémentations strictement équivalentes visuellement ont été comparées : un pattern de blocs statique, où la liste des projets est écrite directement dans le contenu de la page, et un bloc dynamique doté d’un render_callback qui interroge la base à chaque affichage pour récupérer les projets les plus récents.
Ce qui distingue fondamentalement les deux approches
Un pattern de blocs enregistré et inséré dans une page devient, une fois sauvegardé, du contenu HTML classique stocké tel quel dans wp_posts. Son affichage ne déclenche aucun traitement particulier au moment du rendu : WordPress le sert comme n’importe quel autre paragraphe de contenu, sans requête ni calcul additionnel.
Un bloc dynamique, à l’inverse, ne stocke dans le contenu que ses attributs de configuration. À chaque affichage de la page, la fonction associée au render_callback s’exécute pour générer le HTML final, ce qui implique dans ce cas précis une requête WP_Query filtrée par date et par taxonomie pour récupérer les trois projets les plus récents.
Mesure du coût de rendu
Le profilage via Query Monitor a confirmé l’écart annoncé : le bloc dynamique ajoutait systématiquement une requête SQL et environ 38 millisecondes de temps de traitement PHP à chaque affichage de la page d’accueil, cache de page désactivé. Le pattern statique, lui, n’ajoutait strictement rien de mesurable au temps de génération de la page, son contenu étant déjà présent dans le HTML récupéré lors de la requête principale.
Pourquoi le bloc dynamique reste pourtant justifié dans certains cas
Ce constat ne signifie pas que le bloc dynamique constitue un mauvais choix. Sa raison d’être est précisément d’afficher un contenu à jour sans intervention manuelle : dès qu’un nouveau projet est publié, il apparaît automatiquement en haut de la liste, sans que qui que ce soit n’ait à retoucher la page d’accueil pour mettre à jour un pattern statique devenu obsolète.
Avec un cache de page actif, comme c’est le cas sur la quasi-totalité des sites à fort trafic, le coût du render_callback n’est de toute façon payé qu’à chaque régénération du cache, pas à chaque visite. L’écart mesuré ici correspond donc au pire des cas, celui d’un cache de page désactivé ou tout juste vidé.
Un hybride possible : le rendu différé
Une troisième voie a également été testée sur ce site : un pattern statique régénéré automatiquement une fois par jour via une tâche planifiée, plutôt qu’à chaque affichage ou de façon totalement manuelle. Une commande WP-CLI programmée reconstruit le contenu du pattern à partir des projets les plus récents, puis enregistre ce contenu directement dans la page d’accueil, sans passer par un calcul au moment du rendu pour les visiteurs.
wp post update 42 --post_content="$(wp eval-file bin/generer-pattern-projets.php)"
Cette approche conserve l’avantage du coût de rendu nul pour les visiteurs, tout en gardant un contenu relativement frais, avec un décalage maximal d’une journée entre la publication d’un projet et son apparition sur la page d’accueil. Ce compromis convient bien aux sites où une fraîcheur à la minute près n’apporte aucune valeur perçue supplémentaire pour le visiteur final.
Le vrai critère de décision
| Contexte | Recommandation |
|---|---|
| Contenu changeant plusieurs fois par semaine | Bloc dynamique, la mise à jour automatique justifie le coût |
| Contenu modifié une fois par trimestre ou moins | Pattern statique, mis à jour manuellement lors des changements |
| Contenu à jour critique mais cache de page fiable | Bloc dynamique, coût absorbé par le cache |
- Fréquence de mise à jour du contenu affiché
- Présence ou non d’un cache de page fiable sur le site
- Charge de travail éditoriale acceptable pour une mise à jour manuelle du pattern
Le dynamisme d’un bloc n’est jamais gratuit, mais il n’est pas non plus un luxe superflu. La question à se poser n’est pas « statique ou dynamique », mais « ce contenu change-t-il assez souvent pour justifier le coût du calcul répété ».
Notre verdict
Pour une section dont le contenu évolue rarement, un pattern statique reste le choix le plus économe, sans aucun compromis sur l’expérience utilisateur puisque le rendu final est strictement identique. Un bloc dynamique garde tout son sens dès que la fraîcheur du contenu affiché prime sur le coût de rendu, à condition qu’un cache de page vienne absorber ce coût pour la majorité des visiteurs réels du site.
