Page builders WordPress : le coût caché que personne ne vous montre

Par Thierry Pigot — Mars 2026

Le jour où j’ai compris que le cache mentait

Il y a quelques mois, un client m’appelle. Patron d’une PME industrielle, 40 salariés, un site vitrine refait deux ans plus tôt par une agence parisienne. Le site est construit avec Elementor Pro, une dizaine d’extensions, un thème premium, WP Rocket en cache. Tout roule, en apparence.

Son problème : ses commerciaux partagent des liens produits par WhatsApp à leurs prospects. Et les prospects répondent « votre site ne charge pas » ou « j’ai abandonné, c’est trop long ».

Première chose que je fais : je lance un test WebPageTest en 4G, mobile, sans cache. Résultat : 7,2 secondes de chargement complet. LCP à 4,8 secondes. Le hero image met presque 5 secondes à apparaître.

Le site était « rapide » depuis deux ans. Du moins, c’est ce que tout le monde croyait. Parce que le cache servait une copie statique aux visiteurs récurrents, et que l’agence testait depuis un bureau en fibre sur un MacBook Pro.

Mais les vrais visiteurs, ceux qui arrivent pour la première fois, sur un Samsung milieu de gamme, en 4G dans une zone industrielle de province, eux voyaient autre chose. Ils voyaient un site qui mettait 5 secondes à afficher quoi que ce soit.

Et pendant ce temps-là, les commerciaux de la boîte perdaient des leads sans le savoir.

Le problème, ce n’est pas WordPress

J’aurais pu dire au client : « WordPress est lent, il faut tout refaire. » C’est ce que certains prestataires auraient dit.

Mais ce serait faux.

WordPress n’est pas lent. WordPress Core est léger, optimisé par des centaines de contributeurs, et il propulse 43% du web. Les sites les plus rapides que j’ai construits en 20 ans tournent sur WordPress.

Ce qui est lent, c’est ce qu’on empile dessus.

En l’occurrence, chez ce client : Elementor Pro, plus Hello Theme (qui est pourtant léger), plus Essential Addons, plus Elementor Header & Footer Builder, plus un plugin de formulaires, plus un slider, plus un plugin de témoignages, plus un plugin de portfolio. Chacun de ces plugins injecte ses propres CSS, ses propres scripts JavaScript, ses propres librairies. Pas seulement sur les pages qui les utilisent. Sur toutes les pages.

En cumulé, le navigateur du visiteur devait télécharger, interpréter et exécuter l’équivalent de tout un framework applicatif, juste pour afficher une page vitrine avec du texte, trois images et un bouton de contact.

Une couche de plus, c’est une couche de trop

Pour comprendre le problème, il faut comprendre ce que fait un page builder.

Quand vous installez Elementor ou Divi, vous n’installez pas un éditeur. Vous installez un système de rendu alternatif qui se superpose à WordPress. Ce système a ses propres templates, sa propre logique de mise en page, son propre pipeline CSS/JS, son propre mécanisme d’animation, son propre responsive, ses propres popups, sliders, onglets, accordéons, formulaires.

Tout ça doit exister quelque part dans le code. Même si votre page n’utilise que 5% des fonctionnalités, le builder est conçu pour supporter les 100%. Cette flexibilité a un prix, et c’est le navigateur de votre visiteur qui le paie.

Pas vous. Pas l’agence qui a construit le site. Le visiteur.

Ce transfert de coût est au cœur du problème. La commodité de l’éditeur est réelle. Personne ne le nie. Mais cette commodité se fait au détriment de l’expérience utilisateur. Et en 2026, Google le mesure, le quantifie, et en fait un critère de classement.

Les chiffres que je vois sur le terrain

Je ne suis pas universitaire. Je suis praticien. Ce que je vais vous partager, ce sont des ordres de grandeur que je constate en audit, confirmés par les données CrUX (Chrome User Experience Report) et les analyses de terrain de spécialistes comme CoreDash.

Un site WordPress natif (blocs Gutenberg + thème léger) démarre avec un LCP mobile médian sous les 2 secondes. C’est la ligne de base.

Un site Elementor non optimisé démarre entre 3,8 et 5,2 secondes de LCP mobile. Après une optimisation poussée (CSS critique, JavaScript différé, nettoyage du DOM), on peut descendre entre 2 et 2,8 secondes. C’est mieux, mais c’est toujours derrière la ligne de base native, et surtout, cette optimisation est fragile : chaque mise à jour du builder peut réintroduire du poids.

En volume de code, un page builder ajoute entre 200 et 600 Ko par page. Sur un site e-commerce avec WooCommerce, la différence entre FSE natif et un builder tiers peut représenter un score PageSpeed de 100/100 contre 70/100, à contenu identique.

Ces chiffres ne sont pas théoriques. Ce sont les écarts que je mesure chez nos clients en maintenance, semaine après semaine.

L’histoire de la grenouille

Vous connaissez l’histoire de la grenouille dans l’eau tiède ?

C’est exactement ce qui se passe avec la performance d’un site sous page builder.

Au lancement, le site est correct. Le builder est bien configuré, les pages sont raisonnables, le score PageSpeed est dans le vert. Puis, mois après mois, l’équipe contenu ajoute une section ici, un slider là, une animation sur la hero, un popup de newsletter, un carrousel de logos clients, un formulaire plus élaboré, un widget de réseaux sociaux.

Chaque ajout est anodin. Dans l’éditeur, ça prend 30 secondes. C’est joli. Le client valide.

Mais chaque ajout ajoute du poids. Du DOM. Du CSS. Du JavaScript. Et personne ne mesure l’impact cumulé.

Au bout d’un an, le site met 2 secondes de plus à charger qu’à son lancement. Au bout de deux ans, il en met 4 de plus. Personne ne sait exactement quand c’est arrivé, parce que c’est arrivé progressivement. L’eau a chauffé doucement.

C’est ce que j’appelle la dette de performance invisible. Elle n’est pas décidée. Elle s’accumule. Et le jour où quelqu’un la remarque, il est souvent trop tard pour la corriger sans repenser l’architecture.

Le moment où j’ai changé d’avis

Pendant longtemps, j’ai moi-même utilisé des page builders. J’ai construit des dizaines de sites avec Beaver Builder. J’ai formé des clients dessus. J’ai développé des plugins pour l’écosystème (BB Delete Cache, Toolbox for Beaver Builder, publiés sur wordpress.org).

Je ne suis pas un puriste qui n’a jamais touché à un builder. J’en ai vécu.

Ce qui m’a fait changer de position, ce n’est pas un dogme. C’est l’observation.

J’ai observé que les sites natifs que je livrais en FSE démarraient systématiquement avec de meilleurs scores. J’ai observé que ces sites restaient performants dans le temps, parce que l’éditeur natif n’encourage pas la même inflation de contenu. J’ai observé que les mises à jour de WordPress Core (speculative loading en 6.8, fetchpriority en 6.9) bénéficiaient immédiatement aux sites natifs, sans rien configurer, alors que les sites sous builder dépendaient d’Elementor ou Divi pour chaque gain de performance.

Et j’ai observé que les Patterns (Compositions WordPress) permettaient de donner exactement la même flexibilité aux équipes contenu, sans la dette technique.

Ce n’est pas une conviction. C’est un constat empirique, répété sur des dizaines de projets.

WordPress natif est un page builder (le meilleur)

Voici ce que beaucoup de gens n’ont pas encore compris : le Site Editor de WordPress est un page builder.

Vous composez des layouts visuellement. Vous ajustez des couleurs, des typographies, des espacements. Vous créez des templates de pages. Vous assemblez des Patterns réutilisables. Vous prévisualisez en temps réel. Vous ne touchez pas au code.

La seule différence : c’est natif. Il n’y a pas de couche supplémentaire. Le HTML généré est sémantique et propre. Les styles sont centralisés dans un fichier theme.json. Le contenu n’est pas enfermé dans des shortcodes propriétaires. Si vous changez de thème dans 3 ans, votre contenu est intact. Essayez de faire la même chose après 3 ans d’Elementor.

Et les Patterns, c’est la réponse à l’argument « j’ai besoin du builder pour que mon équipe puisse créer des mises en page variées ». Un Pattern, c’est un assemblage de blocs natifs, pré-configuré, réutilisable, verrouillable. Vous créez les layouts complexes en amont, votre équipe les utilise en un clic, et le résultat pèse une fraction de ce que produirait un builder.

C’est d’ailleurs le sujet que je présenterai au WordCamp Nice 2026 : comment les Compositions WordPress permettent de retrouver toute la flexibilité éditoriale sans le prix de performance.

Ce que ça change concrètement

Revenons à mon client industriel.

On a migré son site d’Elementor vers un thème FSE sur mesure, avec un design system en theme.json et une bibliothèque de Patterns couvrant tous ses cas d’usage. L’équipe marketing a été formée au Site Editor en une demi-journée.

Résultat après migration :

Le LCP mobile est passé de 4,8 secondes à 1,4 seconde. Le score PageSpeed mobile est passé de 38 à 94. Le nombre de requêtes HTTP par page est passé de 47 à 12. Et surtout, six mois après la migration, les scores sont identiques. Pas de dégradation. Parce que l’éditeur natif n’encourage pas l’inflation.

Les commerciaux ne perdent plus de prospects sur mobile. Le site charge, tout simplement.

Mais ce n’est pas pour tout le monde

Je serais malhonnête si je disais que tout le monde doit migrer demain matin.

Si votre site est un petit vitrine à faible trafic, que votre équipe n’a aucun accès technique, et que la performance n’est pas un enjeu business, un builder fait le job. Un site un peu lent mais publié et maintenu vaut mieux qu’un site parfait qui n’existe pas.

En revanche, la migration devient un vrai sujet quand :

Votre SEO stagne et votre LCP mobile dépasse les 2,5 secondes. Google ne pardonne plus.

Vous devez répondre à l’Acte Européen d’Accessibilité (EAA). Le HTML sémantique de FSE est nativement plus conforme que le DOM complexe d’un builder.

Vous avez des engagements d’éco-conception (RGESN). Moins de code transféré, c’est mesurable, c’est un argument dans un appel d’offres.

Vous voulez sortir du vendor lock-in. Le contenu d’un builder est prisonnier de ses shortcodes. Le contenu de blocs natifs, c’est du HTML standard, portable, pérenne.

Comment on fait ça sans casser ce qui marche

Chez WeAre[WP], on ne fait pas de big bang. On fait de la migration progressive.

On commence par auditer : mesurer le coût réel du builder sur chaque page, sans cache, sur mobile. On cartographie ce qui utilise vraiment le builder et ce qui l’utilise par habitude (souvent 80% des pages n’ont pas besoin du builder).

Ensuite, on conçoit le design system natif : theme.json pour les tokens visuels, Patterns pour les layouts récurrents, blocs verrouillés pour les sections sensibles. L’identité visuelle ne change pas. L’expérience éditeur évolue, mais ne régresse pas.

On migre page par page, en commençant par les plus visitées. Chaque migration est mesurée en gains de performance réels. Le client voit les chiffres bouger à chaque étape.

Et on forme l’équipe. Pas un PDF de 80 pages. Une demi-journée, les mains dans le Site Editor, à créer et modifier du contenu avec les Patterns. Le jour où tout le monde est autonome, on désactive le builder.

La vraie question

La performance, ce n’est pas un sujet technique réservé aux développeurs. C’est un sujet business.

Chaque seconde de chargement en plus, c’est 7% de conversions en moins. Chaque visiteur qui abandonne votre site, c’est un prospect perdu. Chaque dégradation progressive du score, c’est un recul silencieux dans Google.

La question n’est pas « est-ce que mon page builder est mauvais ? ». La question est : est-ce que la commodité que gagne mon équipe dans l’éditeur justifie le prix que chaque visiteur paie dans son navigateur ?

Si vous n’êtes pas sûr de la réponse, on peut la trouver ensemble. Un audit de performance, c’est 15 minutes de mesure et une vision claire de ce que votre site coûte réellement à vos visiteurs.

Et parfois, cette vision change tout.

---

Votre site est-il vraiment rapide, ou juste caché ? Demandez un audit de performance →