D’après la documentation officielle publiée sur make.wordpress.org, le bloc Query Loop reçoit dans WordPress 7.0 trois évolutions distinctes centrées sur la performance de rendu : une mise en cache partielle des résultats de requête au niveau du bloc, une pagination différée par défaut au-delà d’un certain nombre d’éléments, et une réduction du nombre de requêtes de métadonnées grâce à un préchargement groupé. Sur un site associatif qui fédère plusieurs milliers de structures locales dans un annuaire consultable, ces trois changements ne se valaient pas.
Nouveauté n°1 : la mise en cache partielle des résultats
Le Query Loop, dans les versions précédentes, réexécutait sa requête WP_Query à chaque affichage de page, même quand le contenu sous-jacent n’avait pas changé depuis le dernier rendu. WordPress 7.0 introduit un mécanisme de cache partiel au niveau du bloc, qui conserve le résultat de la requête pendant une durée courte configurable, invalidée automatiquement à la publication ou à la modification d’un contenu du type de post concerné.
Sur l’annuaire de structures locales, cette nouveauté a eu l’impact le plus visible : la page listant les structures d’une région, auparavant régénérée à chaque visite malgré un contenu qui ne change que quelques fois par semaine, a vu son temps de rendu chuter de 44 % en moyenne.
Nouveauté n°2 : la pagination différée
Au-delà d’un seuil configurable de résultats (500 par défaut), le Query Loop charge désormais uniquement la première page de résultats au rendu initial, et différe le chargement des pages suivantes via un appel à l’API REST déclenché au défilement ou au clic sur la pagination, plutôt que de générer l’intégralité de la structure HTML en une fois côté serveur.
- Sur les pages d’annuaire dépassant 500 structures listées, le poids initial de la page a diminué de moitié environ.
- Sur les pages sous ce seuil, la nouveauté ne change strictement rien au comportement, le mécanisme ne s’activant pas.
- Le SEO de la première page reste inchangé, seul le contenu au-delà du seuil bascule en chargement différé.
Nouveauté n°3 : le préchargement groupé des métadonnées
La troisième évolution touche update_meta_cache, désormais appelé automatiquement en amont pour l’ensemble des identifiants de posts retournés par une requête Query Loop, avant que chaque bloc enfant (comme un champ personnalisé affiché via un bloc dynamique) ne déclenche sa propre requête de métadonnée individuelle. Ce comportement existait déjà partiellement dans WP_Query, mais WordPress 7.0 l’étend explicitement au contexte des blocs.
| Nouveauté | Impact sur ce site | Condition d’activation |
|---|---|---|
| Cache partiel des résultats | Fort (44 % de gain) | Contenu peu modifié entre deux affichages |
| Pagination différée | Fort sur les grandes listes | Plus de 500 résultats dans la requête |
| Préchargement des métadonnées | Modéré | Blocs enfants affichant des champs personnalisés |
Ce qui n’a rien changé
Le rendu du template de chaque carte de structure individuelle, avec ses propres blocs imbriqués, n’a bénéficié d’aucun des trois changements, puisque son coût dépend du nombre de blocs par carte et non du mécanisme de requête global. Sur ce site, une carte trop chargée en blocs imbriqués reste un goulot indépendant, que les nouveautés de WordPress 7.0 ne résolvent pas.
Une nouvelle version du cœur améliore le mécanisme de requête, jamais la complexité du template qui l’affiche. Les deux se travaillent séparément.
Compatibilité avec l’existant
Le cache partiel des résultats de requête est activé par défaut, mais reste désactivable bloc par bloc via l’attribut enableQueryCache exposé dans l’éditeur, ce qui a permis de le désactiver ponctuellement sur les rares pages où une fraîcheur immédiate du contenu était requise, comme le tableau de bord d’administration interne des inscriptions du jour.
Ce qui change vraiment
Sur un catalogue de cette taille, les nouveautés de WordPress 7.0 apportent un gain réel sans nécessiter la moindre réécriture de thème : le cache partiel et la pagination différée s’appliquent automatiquement dès la mise à jour du cœur. Le seul travail restant a consisté à identifier les pages qui dépassaient le seuil de 500 résultats pour vérifier que le comportement de pagination différée restait cohérent avec l’expérience attendue par les visiteurs de l’annuaire.
