# Les antipatterns du Loop Grid Elementor retrouvés dans presque tous les audits

> Reprendre un site bâti avec le Loop Grid révèle toujours les mêmes symptômes : requêtes dupliquées, pagination qui casse au clic, filtres ignorés par le cache. Le tour des erreurs qui reviennent le plus.

- Auteur : WordPress Développement
- Publié le : 2022-11-08
- Mis à jour le : 2022-11-08
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/loop-grid-antipatterns-audit-elementor/

## L’essentiel

- Query ID dupliqués entre deux Loop Grid
- Pagination AJAX qui casse le cache de page
- Tri « aléatoire » resté en production

Un Loop Grid propre se reconnaît en dix secondes : un Query ID explicite, une pagination cohérente avec le cache, un tri stable. À l'inverse, un Loop Grid négligé se repère tout aussi vite, et c'est justement ce qu'on retrouve dans la majorité des audits de reprise. Le widget Loop Grid, arrivé avec les Containers Flexbox dans Elementor Pro, a démocratisé l'affichage dynamique de contenus, mais sa souplesse a aussi ouvert la porte à des réglages approximatifs qui ne se voient qu'à l'usage.

Cet article ne parle pas du widget Posts classique, plus rigide et moins sujet à ces travers : il traite spécifiquement du Loop Grid et de son couple Loop Item, là où se nichent les erreurs de requête et de pagination les plus coûteuses. Voici les cinq antipatterns qui reviennent le plus souvent lors d'une reprise de site, avec, à chaque fois, ce qu'on observe, pourquoi c'est un problème, et comment le corriger.

## Des Query ID dupliqués qui se marchent dessus

**Ce qu'on voit :** deux Loop Grid sur la même page, l'un pour les articles à la une, l'autre pour les derniers billets, partagent le même Query ID par défaut, ou pire, aucun Query ID explicite n'a été renseigné.

**Pourquoi c'est un problème :** Elementor génère un identifiant de requête pour isoler la pagination de chaque widget. Sans Query ID unique et explicite, la pagination AJAX du second Loop Grid peut repaginer le premier, ou les deux widgets se marchent dessus dès qu'un paramètre d'URL est ajouté à la page.

**Quoi faire :** nommer systématiquement chaque Query ID de façon descriptive (`une_a_la_une`, `derniers_billets`) dans l'onglet Requête du widget, et vérifier qu'aucun nom n'est réutilisé ailleurs sur le même gabarit.

## La pagination AJAX qui ignore le cache de page

**Ce qu'on voit :** un clic sur « page suivante » recharge la même liste d'articles, ou affiche une page blanche, uniquement en production, jamais en local.

> L'essentiel à retenir : Query ID dupliqués entre deux Loop Grid ; Pagination AJAX qui casse le cache de page ; Tri « aléatoire » resté en production

Le coupable est presque toujours le cache de page : la requête AJAX de pagination transite par `admin-ajax.php`, un point d'entrée que la plupart des plugins de cache excluent par défaut, mais le HTML renvoyé, lui, peut être servi depuis une version en cache obsolète du fragment contenant le Loop Grid. Le résultat : la page 2 affiche les mêmes articles que la page 1.

**Pourquoi c'est un problème :** l'utilisateur perd confiance dans la navigation, et les moteurs de recherche qui suivent la pagination indexent des doublons.

**Quoi faire :** exclure explicitement les requêtes vers `admin-ajax.php` du cache de page, et vérifier que le fragment HTML du Loop Grid n'est pas mis en cache indépendamment de sa pagination réelle.

## Le widget imbriqué qui déclenche une requête N+1

**Ce qu'on voit :** un Loop Item qui contient lui-même un widget Posts ou un second Loop Grid pour afficher des contenus liés, par exemple des articles de la même catégorie sous chaque carte.

**Pourquoi c'est un problème :** chaque itération de la boucle principale déclenche une requête supplémentaire, ce qui transforme une liste de vingt éléments en vingt-et-une requêtes SQL. Sur un template de blog avec beaucoup de trafic, ce schéma alourdit nettement le temps de réponse serveur.

**Quoi faire :** remonter la logique un cran au-dessus, avec une seule requête bien construite (via `tax_query` ou `meta_query`) plutôt que d'empiler les widgets, ou précharger les données liées avant le rendu de la boucle.

## Le tri « aléatoire » laissé en production

**Ce qu'on voit :** un ordre de tri réglé sur aléatoire dans l'onglet Requête, souvent choisi en phase de maquette pour varier visuellement les exemples, puis jamais repassé sur un tri stable.

**Pourquoi c'est un problème :** un tri aléatoire empêche toute mise en cache fiable du fragment, car chaque chargement de page produit un ordre différent. Combiné à un cache de page actif, cela crée des incohérences visibles : l'utilisateur voit un ordre, revient, en voit un autre, sans rechargement volontaire.

**Quoi faire :** remplacer le tri aléatoire par un tri sur la date, un champ personnalisé ou l'ordre de menu, et réserver l'aléatoire aux cas où la mise en cache est explicitement désactivée pour ce fragment.

## Le filtre visuel qui n'existe pas côté requête

**Ce qu'on voit :** des boutons de filtre construits avec un widget Onglets ou des ancres personnalisées, censés filtrer le Loop Grid, mais qui ne modifient en réalité que l'affichage CSS et non la requête WP_Query sous-jacente.

**Pourquoi c'est un problème :** le filtrage visuel masque des éléments côté client sans réduire le nombre de contenus réellement chargés, ce qui gonfle le poids de la page et casse la pagination, puisque celle-ci continue de compter les éléments masqués.

**Quoi faire :** passer par les filtres natifs du Loop Grid Pro liés à la taxonomie, ou reconstruire le filtre avec un rechargement AJAX qui modifie réellement les arguments de la requête.

## En résumé

Aucun de ces antipatterns n'est une fatalité du Loop Grid lui-même : ce sont des réglages qu'on prend le temps de vérifier, un par un, lors d'une reprise de site. Un Query ID nommé, une pagination compatible avec le cache, un tri stable et une requête qui reflète vraiment le filtre affiché suffisent à éliminer l'essentiel des symptômes rencontrés en audit. La check-list tient sur une carte, mais elle évite des heures de débogage a posteriori.