Une page construite avec Elementor, une fois enregistrée, ne laisse presque aucune trace dans la structure habituelle de WordPress. Pas de dizaines de lignes dans wp_postmeta, pas de shortcodes empilés dans post_content : tout tient dans une seule clé, _elementor_data, qui contient l’intégralité de la structure de la page sous forme de tableau sérialisé.
Ce choix architectural, présent depuis les premières versions publiques d’Elementor, mérite qu’on s’y attarde, parce qu’il explique à la fois des qualités (portabilité, versionnage possible) et des désagréments bien réels une fois qu’un site grossit.
Ce que contient réellement la ligne
Ouvrir la table wp_postmeta pour un post donné et filtrer sur meta_key = '_elementor_data' renvoie une seule ligne, dont la colonne meta_value contient une chaîne JSON représentant un tableau d’éléments imbriqués. Chaque élément — section, colonne, widget — possède un identifiant unique de sept caractères, un type (elType), des réglages (settings) et, le cas échéant, des enfants (elements).
[
{
"id": "7f3a921",
"elType": "section",
"settings": { "layout": "boxed" },
"elements": [
{
"id": "b12cd44",
"elType": "column",
"elements": [
{
"id": "9e001aa",
"elType": "widget",
"widgetType": "heading",
"settings": { "title": "Bienvenue" }
}
]
}
]
}
]Cette structure arborescente est exactement ce que l’éditeur manipule visuellement : déplacer un widget dans l’interface revient, en coulisses, à déplacer un objet dans ce tableau puis à réenregistrer l’intégralité de la valeur.
Pourquoi une seule ligne plutôt que plusieurs
Un choix alternatif aurait consisté à répartir chaque élément dans sa propre ligne de métadonnée, avec des références croisées. Elementor ne fait pas ce choix : il sérialise tout l’arbre en une seule fois. L’avantage immédiat est la simplicité de lecture et d’écriture : un seul get_post_meta() suffit pour récupérer la page entière, et un seul update_post_meta() pour la sauvegarder, sans transaction complexe à orchestrer entre plusieurs lignes.
La contrepartie apparaît dès qu’une page grossit. Un aperçu de projet mené sur une page d’accueil comportant une trentaine de sections et une centaine de widgets a montré une valeur _elementor_data dépassant 300 Ko de texte brut. Chaque enregistrement dans l’éditeur réécrit cette valeur en entier, même si un seul mot a changé dans un titre.
Ce que cela implique pour la requête de lecture
Quand une page s’affiche côté public, WordPress charge cette métadonnée via l’objet $post puis Elementor la décode avec json_decode() avant de parcourir récursivement l’arbre pour générer le HTML final. Cette étape de décodage et de parcours a un coût CPU réel, proportionnel à la taille de l’arbre, ce qui explique en partie pourquoi la mise en cache d’objets (via un cache de type Redis ou Memcached) apporte un gain mesurable sur des pages Elementor volumineuses : elle évite de refaire ce décodage à chaque visite.
- La métadonnée est lue en une fois, jamais fragment par fragment.
- Le décodage JSON puis le parcours récursif ont un coût lié à la taille de l’arbre.
- La mise en cache d’objets réduit la fréquence de ce traitement, pas sa nature.
Ce qu’il ne faut pas faire avec cette donnée
Modifier directement la valeur _elementor_data depuis phpMyAdmin, sans passer par l’éditeur, est une tentation dangereuse : un simple guillemet mal échappé rend le JSON invalide et la page cesse de s’afficher correctement, parfois sans message d’erreur explicite. WordPress propose des fonctions comme wp_slash() pour ce genre de manipulation programmatique, mais l’édition manuelle en base reste réservée à des cas d’urgence bien maîtrisés.
Sur un projet où une modification en base a corrompu la structure, revenir à une sauvegarde a pris moins de temps que de tenter de réparer le JSON à la main.
Pour aller plus loin
Ce format en une seule métadonnée sérialisée n’est pas propre à Elementor : d’autres constructeurs de pages font des choix similaires. Comprendre cette mécanique aide surtout à interpréter correctement les recommandations de performance qu’on lit ici ou là, et à ne pas confondre un problème d’optimisation de requêtes SQL classique avec un problème de taille de structure JSON, qui appelle des solutions très différentes.
