---
title: "Elementor et PageSpeed : ce que nous avons mesuré sur un vrai site, étape par étape"
description: "Début novembre 2026, un client nous a demandé de faire monter le score PageSpeed de son site : 80 sur mobile, 90 sur ordinateur. Le site tourne sous WordPress et Elementor : environ 250 pages, articles et événements, un thème acheté sur une place de marché et plusieurs extensions Elementor. Nous avons appliqué toutes les […]"
url: "https://www.newp.fr/actualites/cas-clients-coulisses/case-study/elementor-pagespeed-etude-de-cas/"
author: "Kévin Papot"
date: "2026-11-08T10:34:03+00:00"
lang: "fr_FR"
categories: ["Études de cas"]
tags: ["Étude de cas"]
---

# Elementor et PageSpeed : ce que nous avons mesuré sur un vrai site, étape par étape

Début novembre 2026, un client nous a demandé de faire monter le score PageSpeed de son site : 80 sur mobile, 90 sur ordinateur. Le site tourne sous WordPress et Elementor : environ 250 pages, articles et événements, un thème acheté sur une place de marché et plusieurs extensions Elementor. Nous avons appliqué toutes les optimisations habituelles, puis nous avons mesuré l'effet de chaque étape, y compris une sortie d'Elementor testée sur une copie du site. Les résultats sont plus nuancés que ce qu'on lit souvent. Sur une page simple, bien optimiser Elementor fait presque jeu égal avec une page reconstruite sans lui. Sur une page riche, en revanche, c'est la structure d'Elementor qui fixe le plafond. Voici les chiffres. Le client n'est pas nommé.

## L'essentiel en 30 secondes

| Question | Réponse |
|---|---|
| Point de départ ? | Accueil entre 31 et 43 sur mobile selon les passages, environ 15 Mo chargés et environ 2 400 éléments HTML. |
| Ce que les optimisations classiques ont donné ? | Le cache et le WebP allègent fortement le site, mais ne bougent pas le score mobile. Le thème Hello, le CSS allégé et les scripts différés font passer une page de service de 29-46 à 61-68, et l'accueil à 45. |
| Et sans Elementor ? | La page de service reconstruite dans l'éditeur de blocs : 69 à 82. L'accueil reconstruit sans Elementor : 85 sur mobile, 99 sur ordinateur. |
| Les outils tiers étaient-ils en cause ? | Peu sur l'accueil : en les bloquant tous, le score ne gagnait que quelques points. |
| La leçon ? | Optimiser d'abord, c'est rentable partout. Quitter Elementor ne se justifie vraiment que pour les pages riches, ou quand un objectif chiffré élevé est imposé. |

## Une précaution avant les chiffres

Le score PageSpeed est une mesure de laboratoire : Google charge la page une fois, sur un mobile simulé, et calcule une note. Il varie d'un passage à l'autre. Le 8 novembre, la même page de service, testée deux fois à deux minutes d'intervalle, a obtenu 29 puis 46. C'est pourquoi nous donnons des fourchettes, mesurées sur plusieurs passages entre le 5 et le 8 novembre.

Autre point : Google n'avait aucune donnée réelle pour ce site (« Aucune donnée » dans PageSpeed), faute de visites Chrome en nombre suffisant. Or ce sont ces mesures réelles, les [Core Web Vitals](https://www.newp.fr/actualites/referencement/core-web-vitals-2026-pourquoi-pres-dun-site-sur-deux-est-en-zone-rouge-sans-le-savoir/), que Google utilise. Le score de laboratoire reste un bon outil de diagnostic, à condition de ne pas le lire au point près.

## Étape 1 : les optimisations classiques

Chaque opération a été faite avec une sauvegarde complète, et testée sur une copie du site avant d'être mise en ligne. Les quatre premières lignes du tableau ont été mises en ligne d'abord ; les quatre suivantes ont été préparées ensuite sur la copie de travail.

| Action | Effet mesuré |
|---|---|
| Cache des pages (LiteSpeed Cache) | Temps de réponse du serveur divisé par 3 à 5 |
| Images converties en WebP, sans toucher aux originaux ni aux adresses | 3 741 images, de 1,37 Go à 184 Mo (−87 %) |
| Paiement en ligne chargé seulement sur les pages qui en ont besoin | Un script lourd en moins sur toutes les autres pages |
| Vidéos de l'accueil chargées seulement quand le visiteur les atteint | Moins de poids au premier affichage |
| Thème acheté remplacé par Hello Elementor, avec un thème enfant | Le code hérité du thème et de Bootstrap passe d'environ 410 Ko à 54 Ko |
| En-tête et pied de page repris dans le constructeur de thème | Le pied de page, auparavant exécuté trois fois par page, ne l'est plus qu'une fois |
| Anti-spam des formulaires et assistant de discussion chargés à la première action du visiteur | Moins de scripts au chargement |
| Icônes intégrées au lieu de trois polices d'icônes, extensions inutiles désactivées | Moins de fichiers à télécharger |

Résultats sur mobile :

- **Cache, WebP, paiement et vidéos** : le poids et le temps de réponse chutent, mais le score mobile reste dans le bruit de mesure. L'accueil était à 43 avant, il oscille entre 31 et 39 après. Une page de service type oscille entre 29 et 46.
- **Thème Hello, CSS allégé, pied de page unique, scripts différés** : la page de service passe à **61-68**. C'est le gain le plus net de toute l'étude. L'accueil passe à **45** (56 à 65 sur ordinateur). Sur ordinateur, son contenu principal s'affiche en 2,7 secondes au lieu de 6,0, et son poids passe d'environ 15 Mo à 5 Mo.

Le site est nettement plus rapide à l'usage. Mais l'accueil reste loin de l'objectif.

## Étape 2 : chercher ce qui bloque sur l'accueil

L'accueil est la page la plus riche du site : diaporama, vidéos, compteurs, témoignages, plusieurs listes dynamiques, environ 2 400 éléments HTML. Nous avons fait deux tests pour trouver le plafond.

**Premier test : bloquer tous les outils tiers.** Gestionnaire de balises, pixels publicitaires, bannière de cookies, assistant de discussion, anti-spam, vidéos YouTube : tout bloqué. Le score ne gagnait que quelques points.

**Second test : reconstruire l'accueil sans Elementor.** Mêmes textes, mêmes images, même présentation et mêmes outils tiers, mais un code HTML écrit à la main, sans diaporama lourd ni bibliothèque jQuery. Résultat : **85 sur mobile et 99 sur ordinateur**, avec un affichage principal à 0,7 seconde sur ordinateur.

Sur cette page, le plafond venait donc de la structure produite par Elementor et ses extensions : des milliers d'éléments imbriqués, des feuilles de style et des scripts chargés pour chaque widget, des animations et un diaporama qui dépendent de jQuery.

Score PageSpeed mobile, sur 100 (fourchettes mesurées) PAGE DE SERVICE TYPE Cache et WebP 29 à 46 Elementor optimisé 61 à 68 Éditeur de blocs 69 à 82 ACCUEIL (PAGE RICHE) Cache et WebP 31 à 39 Elementor optimisé 45 Sans Elementor 85 Mesures PageSpeed Insights sur mobile, du 5 au 8 novembre 2026, sur le site du client et sur sa copie de travail. La partie claire de chaque barre montre l'écart entre plusieurs passages.## Étape 3 : une page de service dans l'éditeur de blocs

Un accueil codé à la main prouve le diagnostic, mais l'équipe du client ne peut pas le modifier. Nous avons donc converti une vraie page de service dans l'éditeur de blocs de WordPress (Gutenberg), avec l'extension GenerateBlocks pour la mise en page. Même contenu, même présentation, mêmes outils tiers, sur la copie de travail du site.

| Page de service type | Elementor optimisé (Hello) | Éditeur de blocs |
|---|---|---|
| PageSpeed mobile | 61 à 68 | 69 à 82 |
| PageSpeed ordinateur | — | 97 |
| Requêtes au chargement | 156 | 75 |
| Poids transféré (ordinateur) | 3,8 Mo | 2,8 Mo |

La version en blocs est plus légère : deux fois moins de requêtes et un mégaoctet de moins. Elle obtient aussi les meilleurs scores. Mais sur cette page relativement simple, l'écart avec la version Elementor bien optimisée va de quelques points à une quinzaine, selon les passages. Le temps de blocage restant vient surtout des outils tiers : pixel publicitaire, gestionnaire de balises, bannière de cookies.

## Ce qu'une sortie d'Elementor coûte

Pour passer tout le site dans l'éditeur de blocs, nous avons écrit un convertisseur. Il lit la structure Elementor de chaque page et la réécrit en blocs WordPress standard, avec un retour arrière testé. Les adresses des pages ne changent pas, ce qui préserve le référencement. Sur ce site, la sortie complète est estimée à environ six jours et demi de travail : modèles des articles et des événements, conversion des pages par lots avec un contrôle visuel de chacune, recette des formulaires et du paiement, puis désactivation d'Elementor et de ses extensions.

Le changement le plus sensible est humain. L'équipe qui fait vivre le site passe du glisser-déposer très libre d'Elementor à un éditeur plus sobre, où la mise en page est plus cadrée. C'est aussi ce qui garde les pages légères au fil des modifications. Une prise en main et un guide d'édition font partie du projet.

## Faut-il quitter Elementor ?

- **Commencez par optimiser.** Cache, WebP, thème Hello, nettoyage des extensions et scripts différés : c'est réversible, peu coûteux, et c'est là que nous avons mesuré le plus gros gain sur les pages courantes.
- **Mesurez votre plafond.** Bloquez les outils tiers, puis testez une page reconstruite. Deux mesures suffisent à savoir si vos limites viennent de vos scripts ou de votre constructeur de pages.
- **Envisagez la sortie** si vos pages clés sont très riches (diaporamas, animations, nombreuses extensions Elementor), si un objectif chiffré élevé vous est imposé, ou si vous prévoyez de toute façon une [refonte](https://www.newp.fr/refonte-site-web/).

## Notre lecture

On lit souvent qu'Elementor serait lent par nature. Nos mesures disent quelque chose de plus utile. Un site Elementor mal tenu (thème lourd, images brutes, scripts partout) perd beaucoup de points, et la plupart se récupèrent sans changer d'outil. Le vrai plafond apparaît sur les pages très riches, où la structure générée par le constructeur pèse plus que tout le reste.

Le score PageSpeed n'est pas une fin en soi : pour Google, ce qui compte, ce sont les mesures réelles des visiteurs, et pour l'entreprise, les demandes de contact. Mais quand un objectif de score est posé, mieux vaut le fixer avant de choisir l'outil. Il conditionne le choix entre Elementor, l'éditeur de blocs ou un constructeur plus léger comme [Bricks](https://www.newp.fr/agence-seo-bricks/). C'est une question à poser dès le devis d'un projet [WordPress](https://www.newp.fr/agence-wordpress/).

## Questions fréquentes

Elementor rend-il forcément un site lent ?Non. Sur notre cas, une page de service sous Elementor est passée de 29-46 à 61-68 sur mobile, uniquement avec des optimisations classiques. Elementor devient limitant sur les pages très riches, comme un accueil avec diaporama, vidéos et nombreuses animations.

Le thème Hello Elementor suffit-il à rendre un site rapide ?Il aide beaucoup, car il est très léger, surtout s'il remplace un thème acheté chargé de code. Il ne change pas la structure des pages construites avec Elementor : il faut le combiner avec le cache, la compression des images et le tri des scripts.

Les outils tiers comme Google Tag Manager ou les pixels font-ils chuter le score ?Ils pèsent sur le temps de blocage. Sur l'accueil étudié, les bloquer tous ne faisait gagner que quelques points. Sur une page légère, en revanche, ils deviennent la principale source de lenteur restante.

Pourquoi mon score PageSpeed change-t-il à chaque test ?Parce que c'est une mesure de laboratoire faite sur un seul chargement simulé, sensible au réseau et au serveur du moment. Sur notre cas, la même page a obtenu 29 puis 46 à deux minutes d'intervalle. Il faut raisonner sur plusieurs passages et sur les données réelles de la Search Console.

Quitter Elementor fait-il perdre son référencement ?Non, si les adresses des pages, les titres, les descriptions et le maillage interne sont conservés. Dans notre méthode, aucune adresse ne change et chaque page peut revenir à Elementor tant que la migration n'est pas terminée.

Combien de temps faut-il pour sortir d'Elementor ?Cela dépend du nombre de pages et de modèles. Pour un site d'environ 250 contenus avec événements et paiement en ligne, nous avons estimé six jours et demi de travail, conversion automatique comprise.

{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": \[{"@type": "Question", "name": "Elementor rend-il forcément un site lent ?", "acceptedAnswer": {"@type": "Answer", "text": "Non. Sur notre cas, une page de service sous Elementor est passée de 29-46 à 61-68 sur mobile, uniquement avec des optimisations classiques. Elementor devient limitant sur les pages très riches, comme un accueil avec diaporama, vidéos et nombreuses animations."}}, {"@type": "Question", "name": "Le thème Hello Elementor suffit-il à rendre un site rapide ?", "acceptedAnswer": {"@type": "Answer", "text": "Il aide beaucoup, car il est très léger, surtout s'il remplace un thème acheté chargé de code. Il ne change pas la structure des pages construites avec Elementor : il faut le combiner avec le cache, la compression des images et le tri des scripts."}}, {"@type": "Question", "name": "Les outils tiers comme Google Tag Manager ou les pixels font-ils chuter le score ?", "acceptedAnswer": {"@type": "Answer", "text": "Ils pèsent sur le temps de blocage. Sur l'accueil étudié, les bloquer tous ne faisait gagner que quelques points. Sur une page légère, en revanche, ils deviennent la principale source de lenteur restante."}}, {"@type": "Question", "name": "Pourquoi mon score PageSpeed change-t-il à chaque test ?", "acceptedAnswer": {"@type": "Answer", "text": "Parce que c'est une mesure de laboratoire faite sur un seul chargement simulé, sensible au réseau et au serveur du moment. Sur notre cas, la même page a obtenu 29 puis 46 à deux minutes d'intervalle. Il faut raisonner sur plusieurs passages et sur les données réelles de la Search Console."}}, {"@type": "Question", "name": "Quitter Elementor fait-il perdre son référencement ?", "acceptedAnswer": {"@type": "Answer", "text": "Non, si les adresses des pages, les titres, les descriptions et le maillage interne sont conservés. Dans notre méthode, aucune adresse ne change et chaque page peut revenir à Elementor tant que la migration n'est pas terminée."}}, {"@type": "Question", "name": "Combien de temps faut-il pour sortir d'Elementor ?", "acceptedAnswer": {"@type": "Answer", "text": "Cela dépend du nombre de pages et de modèles. Pour un site d'environ 250 contenus avec événements et paiement en ligne, nous avons estimé six jours et demi de travail, conversion automatique comprise."}}\]}

---

*Source : [www.newp.fr](https://www.newp.fr/actualites/cas-clients-coulisses/case-study/elementor-pagespeed-etude-de-cas/)*