Elementor ou éditeur de blocs : ce que la refonte de ce site m’a appris

Un site que j’avais plaisir à construire

Je vais être honnête sur la première version de ce site. Je l’aimais bien. Elle avait été montée avec Elementor, et Elementor est un outil agréable quand on veut avancer vite. On glisse un bloc, on le déplace, on voit le résultat à l’écran sans passer par un développeur. Des centaines de widgets tout prêts, une mise en page qu’on ajuste à la souris. Pour quelqu’un qui a un pied dans le marketing, c’est très tentant.

Le problème vient de ce qu’on ajoute autour d’Elementor. Un constructeur de pages appelle vite des compléments, un peu comme un téléphone neuf sur lequel on installe une appli, puis une autre, puis dix. Sur ce site, le constructeur était accompagné de quatre extensions additionnelles. Chacune venait avec ses propres styles et ses propres scripts. Et chacune les chargeait sur toutes les pages, y compris celles qui ne les utilisaient pas.

Le jour où j’ai compté les fichiers

Je n’avais jamais vraiment mesuré ce que la page d’accueil demandait au navigateur. Quand je l’ai fait, j’ai eu un petit choc. Pour afficher cette seule page, le navigateur devait télécharger 58 feuilles de style et 38 scripts. Deux menus de navigation différents étaient intégrés sur chaque page, alors qu’un seul s’affichait. Les polices de caractères étaient appelées depuis des serveurs externes. Et une ancienne version de jQuery, une bibliothèque dont beaucoup d’extensions dépendent, se chargeait deux fois à cause d’un simple effet de survol sur un bouton.

Aucun de ces éléments n’était grave pris isolément. Mis bout à bout, ils faisaient un site lent à l’ouverture, surtout sur mobile, pour un rendu visuel qui aurait pu tenir dans dix fois moins de fichiers. Pour un site dont le but est de montrer ce que je sais faire, ce n’était pas un très bon message.

Reconstruire sans changer de visage

J’ai hésité un moment. Refaire un site qu’on vient de finir, ce n’est jamais réjouissant. Mais je voulais savoir ce que donnerait la même identité visuelle, sans constructeur du tout. J’ai donc reconstruit le site avec le thème Kadence et l’éditeur de blocs livré avec WordPress, celui qu’on appelle souvent Gutenberg. L’objectif était que personne ne remarque le changement en arrivant sur la page. Les grands titres, le fond clair, les cartes blanches aux angles arrondis sont restés.

Toute la mise en forme tient désormais dans une seule feuille de style personnalisée. Les polices sont hébergées sur le site lui-même au lieu d’être demandées à Google à chaque visite. Les extensions liées au constructeur ont été désinstallées, puisqu’elles n’avaient plus de raison d’exister. Ce qui m’a le plus surpris, c’est que l’éditeur de blocs couvrait presque tout ce dont j’avais besoin. Les quelques mises en page un peu particulières ont été obtenues avec les blocs du thème.

Ce que les chiffres ont donné

Sur la page d’accueil, les feuilles de style sont passées de 58 à 7. Les scripts, de 38 à 8. Les appels à Google Fonts, de 5 à 0. Les extensions liées au constructeur, de 7 à 0. Je n’ai rien fait d’autre que retirer ce qui ne servait pas et laisser WordPress faire son travail.

Moins de fichiers, c’est d’abord un affichage plus rapide, et de meilleurs Core Web Vitals, ces indicateurs que Google utilise pour juger de l’expérience d’une page. Mais l’effet qui compte le plus au quotidien est ailleurs. Il y a beaucoup moins de mises à jour à surveiller, et beaucoup moins de portes d’entrée pour quelqu’un qui chercherait une faille. Un site avec sept extensions de moins est un site qui me réveille moins souvent la nuit.

Faut-il jeter Elementor pour autant ?

Non, et je tiens à le dire parce que ce genre d’article finit souvent en règlement de comptes. Le bon outil dépend du projet, et surtout de l’équipe qui fera vivre le site après la mise en ligne.

Quand une équipe marketing doit sortir des pages d’atterrissage toutes les semaines, avec des mises en page très différentes et des délais courts, Elementor garde tout son sens. Il donne de l’autonomie à des gens qui n’ont pas envie d’attendre un développeur pour déplacer un bouton. J’ai vu ce cas de figure, et je ne recommanderais pas de le priver de son outil au nom de la performance.

Quand la vitesse d’affichage et la facilité de maintenance passent avant la liberté de mise en page, l’éditeur de blocs est préférable. C’est le cas d’un site vitrine, d’un blog ou d’un portfolio comme celui-ci. Dans les deux situations, la règle que je m’applique est la même. Limiter les extensions, désactiver ce qui ne sert pas, et mesurer régulièrement ce que chaque page charge réellement, parce que ce chiffre a tendance à grimper sans que personne s’en aperçoive.

Comment je tranche aujourd’hui

Depuis cette refonte, je pose les mêmes questions au début de chaque projet, avant de choisir un outil. Elles sont assez simples pour être posées à un client qui n’a jamais ouvert WordPress.

• Quels types de pages faut-il produire, et qui va les créer au quotidien ?
• Les blocs natifs et ceux du thème couvrent-ils déjà le besoin, avant d’ajouter la moindre extension ?
• Quel budget de performance se fixe-t-on, en nombre de requêtes, en poids de page et en Core Web Vitals ?
• Après chaque extension ajoutée, a-t-on remesuré, et retiré ce qui n’apportait rien ?

La dernière question est celle qu’on oublie le plus souvent. On mesure au lancement, puis plus jamais, et deux ans plus tard la page d’accueil charge le double de fichiers.

Un compromis qui se renégocie

Un constructeur de pages n’est ni bon ni mauvais. C’est un échange entre liberté de mise en page et légèreté, et cet échange se renégocie à chaque projet. Savoir travailler avec les deux, et sentir le moment où il faut passer de l’un à l’autre, fait partie du métier de développeur WordPress tel que je le pratique. Si j’avais mesuré ma page d’accueil plus tôt, j’aurais probablement fait ce choix dès le départ. C’est aussi pour ça que je raconte cette histoire.