120 lignes dans un même Repeater, et le simple fait de faire défiler le panneau de l’éditeur commence à saccader. C’est le constat fait sur un widget personnalisé développé pour afficher une liste de partenaires commerciaux, chaque ligne portant un nom, un logo, une URL et une courte description.
Le contrôle Repeater, natif à l’API des widgets Elementor, permet de construire une liste de champs répétables directement dans le panneau de l’éditeur, sans recourir à un champ personnalisé externe. Il rend un vrai service tant que le nombre de lignes reste raisonnable, mais son comportement se dégrade de façon mesurable passé un certain seuil.
Le contexte du projet et la mesure
Le widget en question affichait une liste de partenaires pour un site institutionnel. Le client souhaitait à terme y faire figurer l’ensemble de son réseau, soit plus de cent entrées. Avant de valider cette approche, un test a été mené en ajoutant progressivement des lignes au Repeater et en mesurant, à l’aide des outils de développement du navigateur, le temps de réponse de l’interface lors d’un simple défilement du panneau.
| Nombre de lignes | Temps de rendu du panneau | Ressenti au défilement |
|---|---|---|
| 20 | moins de 50 ms | fluide |
| 60 | environ 150 ms | léger à-coup |
| 100 | environ 400 ms | saccades visibles |
| 150 | plus de 900 ms | interface qui se fige brièvement |
Pourquoi ce ralentissement se produit
Chaque ligne d’un Repeater n’est pas une simple donnée stockée : elle génère, côté éditeur, un ensemble de champs HTML réels avec leurs propres gestionnaires d’événements JavaScript, gérés par le framework Backbone.js sur lequel repose historiquement l’interface d’Elementor. Cent lignes de quatre champs chacune représentent donc plusieurs centaines d’éléments DOM actifs simultanément dans le panneau, chacun capable de déclencher un rendu à la moindre interaction.
Ce coût ne concerne que l’éditeur : côté site public, une fois la page publiée, le rendu HTML final ne conserve pas cette lourdeur, puisque les données sont simplement lues et affichées sans les mécanismes interactifs du panneau d’administration.
Les pistes explorées pour contourner le seuil
Face à ce constat, plusieurs options ont été évaluées avant de choisir la plus adaptée au projet.
- Découper la liste en plusieurs widgets, un par catégorie de partenaires, pour rester sous la centaine de lignes par instance.
- Remplacer le Repeater par un champ personnalisé alimenté depuis un post type dédié, chaque partenaire devenant un contenu séparé.
- Charger les données via une requête personnalisée plutôt que de tout stocker dans les réglages du widget.
La deuxième option a été retenue : un post type « partenaire » avec logo, nom et lien, affiché ensuite via une boucle personnalisée dans le widget. Cette approche déplace le stockage hors du Repeater et redonne à l’éditeur un panneau de configuration léger, puisque le widget ne gère plus que les réglages d’affichage (nombre de colonnes, espacement), pas les données elles-mêmes.
Ce que cela signifie pour un développeur de widgets
Le Repeater reste parfaitement adapté pour des listes courtes et stables : une liste de témoignages, des étapes d’un processus, des questions fréquentes limitées à une dizaine d’entrées. Il devient un mauvais choix architectural dès qu’un client exprime l’intention de faire grossir une liste au-delà de quelques dizaines d’éléments, ou dès que le contenu de chaque ligne mérite sa propre page.
Un Repeater qui dépasse la cinquantaine de lignes est souvent le signe qu’un post type dédié aurait dû être utilisé dès le départ.
Notre verdict
Cent lignes constituent un seuil raisonnable à retenir comme signal d’alerte pour tout widget personnalisé reposant sur un Repeater. En dessous, l’expérience d’édition reste confortable ; au-delà, la charge de rendu côté panneau devient perceptible et justifie de repenser le stockage des données vers une structure plus adaptée, typiquement un post type ou une taxonomie dédiée.
