Elementor fait le boulot — et il le fait peser
Un site construit avec Elementor peut être magnifique et parfaitement lent en même temps. Ce n’est pas une fatalité, c’est une mécanique prévisible : le page builder génère du HTML imbriqué en profondeur, charge ses propres feuilles CSS sur chaque page, appelle Google Fonts sans cache, et s’appuie sur un WordPress qui tourne parfois sur un hébergement sous-dimensionné.
Résultat : un Largest Contentful Paint (LCP) à 6 secondes, un score PageSpeed sous les 40 sur mobile, et des visiteurs qui partent avant que la page ait fini de s’afficher. C’est récupérable dans la majorité des cas, à condition d’intervenir dans le bon ordre.
Avant de toucher quoi que ce soit, prends une mesure de référence : PageSpeed Insights, GTmetrix ou WebPageTest. Note le LCP, le TBT et le score global. Tu en auras besoin pour juger si chaque levier a vraiment servi.
Ce qui pèse sur un site Elementor
- Le DOM surchargé : chaque widget Elementor génère plusieurs divs imbriquées. Une page complexe peut dépasser 2 000 nœuds DOM — le seuil critique pour Chrome.
- CSS redondant : Elementor charge un fichier CSS global (
elementor-frontend.css) même sur les pages qui n’utilisent qu’un tiers de ses composants. - Google Fonts non optimisées : par défaut, l’appel externe bloque le rendu et déclenche un FOIT (flash of invisible text).
- Images non optimisées : pas de lazy-load natif configuré, des fichiers à 2 Mo chargés au-dessus de la ligne de flottaison.
- Plugins qui s’accumulent : chaque plugin qui charge son propre CSS/JS sur toutes les pages ajoute des requêtes inutiles.
- Directives PHP trop basses : un
memory_limità 128 Mo sur un Elementor chargé de widgets provoque des ralentissements ou des erreurs silencieuses.
1. Réglages natifs Elementor à activer en premier
Elementor propose plusieurs options qui réduisent le poids de sortie sans plugin supplémentaire. Toutes se trouvent dans Elementor → Réglages → Fonctionnalités (ou “Experiments” selon ta version) et dans Elementor → Réglages → Avancé.
Optimized DOM Output (expérimental, stable depuis 3.x) : réduit les wrappers inutiles autour des sections et colonnes. Active-le, visite quelques pages en front-end, vérifie qu’aucun style ne casse.
Improved Asset Loading : charge uniquement le CSS des widgets réellement présents sur la page, au lieu du fichier global. Gain visible sur les pages simples.
Font Display : Swap : dans Réglages → Avancé → Google Fonts, passe font-display à swap. Le navigateur affiche immédiatement une police système en fallback — le texte reste lisible pendant le chargement. Cette seule option peut éliminer un avertissement PageSpeed.
Désactiver Google Fonts si tu les héberges localement : dans Réglages → Avancé, choisis “Désactiver”. Tu gères les fonts toi-même (voir levier 4), tu coupes la dépendance externe.
2. Alléger le CSS et le JS
Minification et combinaison : un plugin de cache sérieux (WP Rocket, LiteSpeed Cache, W3 Total Cache) minifie et différer le JS non critique. Configure le “defer” sur les scripts qui ne sont pas nécessaires au premier rendu.
Supprimer les CSS inutiles (CSS non utilisé) : WP Rocket et LiteSpeed Cache proposent un chargement conditionnel des CSS par page. C’est puissant mais demande des tests : certains sliders ou popups ont besoin de leurs CSS globaux.
Bloquer le chargement de CSS tiers sur les pages où ils ne servent à rien : un plugin de formulaire qui charge son CSS sur la page d’accueil — supprime ce chargement avec les règles de chargement conditionnel.
3. Images : lazy-load et compression
Active le lazy-load natif WordPress (loading="lazy") — il est inclus depuis WordPress 5.5. Elementor le respecte depuis la version 3.x.
Pour les images au-dessus de la ligne de flottaison (hero, logo), ne lazy-load pas : elles doivent se charger immédiatement pour un bon LCP.
Convertis les images en WebP : un plugin comme ShortPixel ou Imagify génère les versions WebP et sert automatiquement le format selon le navigateur. Réduction de 25 à 40 % du poids sans perte visible.
Dimensionne les images à leur taille d’affichage réelle : une image de 3 000 px affichée en 800 px, c’est du poids mort.
4. Fonts : héberger localement
Passer par un outil comme Google Fonts Helper (générique, disponible publiquement) permet de télécharger les fichiers WOFF2, de les placer dans /wp-content/themes/ton-theme/fonts/, et de les déclarer via @font-face dans le CSS du thème. Résultat : plus de requête DNS externe, un font-display: swap sous ton contrôle total.
5. Limiter les plugins et choisir un cache solide
Chaque plugin actif, même “léger”, peut ajouter des requêtes en base de données et des assets. Désactive tout ce qui ne sert pas activement. Si tu peux remplacer 3 plugins par une fonctionnalité native de WordPress ou d’Elementor, fais-le.
Pour le cache : WP Rocket reste la référence payante, LiteSpeed Cache est gratuit si ton hébergeur tourne sous LiteSpeed. Configure le cache de page, la précharge du cache, et le CDN si disponible.
Un article connexe sur le sujet des plugins qui cassent après mise à jour : plugin cassé après MAJ WordPress — utile si tu mets à jour Elementor et que quelque chose se brise.
6. Directives PHP à augmenter
Elementor est gourmand. Sur un hébergement partagé standard, les valeurs par défaut suffisent à provoquer des lenteurs ou des erreurs critiques WordPress.
| Directive | Rôle | Symptôme si trop bas | Valeur conseillée | Où régler |
|---|---|---|---|---|
memory_limit | RAM allouée par requête PHP | Erreur critique, page blanche | 256M min, 512M idéal | wp-config.php, php.ini ou panel hébergeur |
max_execution_time | Durée max d’un script | Timeout, sauvegarde incomplète | 60 à 120 | php.ini, .htaccess |
max_input_vars | Nombre de variables de formulaire | Options Elementor non enregistrées | 3000 à 5000 | php.ini |
post_max_size | Taille max d’une requête POST | Imports bloqués | 64M | php.ini |
upload_max_filesize | Taille max d’un fichier uploadé | Erreur 413 à l’import d’image | 64M | php.ini, .htaccess |
Dans wp-config.php, la ligne define('WP_MEMORY_LIMIT', '256M'); est souvent le premier réglage à poser. Si ton hébergeur bloque la modification du php.ini, passe par le panel (cPanel, Plesk) — voir SSH sur Plesk pour les accès directs. Pour les erreurs liées aux gros fichiers, l’article sur l’erreur 413 couvre les directives en détail.
7. Mesurer après chaque levier
C’est le seul moyen de savoir ce qui a vraiment aidé. Après chaque modification, vide le cache et relance un test PageSpeed. Note le delta. Un site Elementor bien configuré peut passer de 35 à 75+ sur mobile — pas 100, Elementor a un coût structurel, mais 75 est parfaitement atteignable et suffisant pour la majorité des PME.
Si après tous ces réglages le LCP reste bloqué au-delà de 4 secondes, le problème vient probablement de l’hébergement lui-même : un serveur lent répond lentement, peu importe l’optimisation front-end. C’est le moment de regarder les performances de ton hébergeur et les Core Web Vitals dans leur ensemble.
Quand passer la main à un pro
Si tu as activé tous les réglages Elementor natifs, configuré un cache, compressé les images et ajusté les directives PHP — et que le score PageSpeed mobile reste sous 50 — il reste probablement un problème structurel : thème mal codé, CSS global incontrôlable, ou hébergement réellement sous-dimensionné. À ce stade, un audit technique ciblé (profil de requêtes, waterfall, analyse du TTFB) est plus efficace qu’une heure de plus à tâtonner dans les réglages.
Est-ce qu'Elementor est intrinsèquement plus lent que d'autres solutions ?
Oui, structurellement. Elementor génère plus de HTML et charge plus de CSS qu’un thème codé à la main ou qu’un site sous Astro. Mais “plus lourd” ne signifie pas “inutilisable” : avec les bons réglages, un site Elementor peut atteindre des scores corrects. Le vrai problème, c’est quand on accumule un thème lourd + Elementor + 30 plugins sans jamais optimiser.
Faut-il désactiver tous les Google Fonts dans Elementor ?
Seulement si tu les héberges localement toi-même. Désactiver sans alternative donne un site sans typographie cohérente. La solution propre : télécharger les fichiers WOFF2, les déclarer via @font-face dans ton thème, puis désactiver l’appel Google dans Elementor.
Le cache de page suffit-il à compenser un Elementor mal optimisé ?
Partiellement. Le cache sert la page HTML pré-générée, ce qui réduit le TTFB. Mais si la page contient 4 Mo d’images non compressées et 8 fichiers CSS non minifiés, le cache ne change rien au poids total envoyé au navigateur. Les deux leviers sont complémentaires, pas substituables.
Mon Elementor plante après activation d'un "experiment" — que faire ?
Retourne dans Elementor → Réglages → Fonctionnalités, désactive l’experiment concerné, vide le cache. Si l’accès à l’admin est bloqué, l’article sur Elementor bloqué au chargement couvre les cas de récupération. Si la page est blanche, commence par l’écran blanc WordPress.
Quelle valeur de memory_limit est vraiment nécessaire avec Elementor Pro ?
256 Mo est le minimum raisonnable. Sur un site avec WooCommerce, Elementor Pro, et une vingtaine de plugins actifs, 512 Mo est préférable. Au-delà, c’est souvent un signe que le code (thème ou plugin tiers) a une fuite mémoire — augmenter la limite masque le problème sans le résoudre.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy