Score PageSpeed 90+ sur mobile : la méthode exacte que nous utilisons
La plupart des sites WordPress plafonnent à 40-60 sur mobile. Voici notre méthode pas à pas pour atteindre 90+ sans sacrifier le design ni les fonctionnalités.
Le score PageSpeed Insights sur mobile est devenu un KPI incontournable. Google l’utilise comme facteur de classement, les utilisateurs quittent un site qui met plus de 3 secondes à charger, et vos concurrents commencent à optimiser les leurs. Pourtant, la majorité des sites WordPress affichent un score entre 30 et 60 sur mobile.
Chez WebEngine, chaque site que nous livrons atteint un score minimum de 90 sur mobile. Voici exactement comment nous y parvenons — la même méthode que nous avons appliquée sur des sites clients réels comme Omra Compare (passé de 60 à 90).
Pourquoi votre site WordPress est lent sur mobile
Avant de résoudre le problème, il faut comprendre les causes. Dans 90 % des cas, les coupables sont :
- Le thème : les thèmes avec page builders (Elementor, Divi, WPBakery) chargent 500 Ko à 2 Mo de CSS/JS inutile
- Les plugins : chaque plugin ajoute ses propres fichiers CSS et JavaScript, même sur les pages où il n’est pas utilisé
- Les images : des images de 3 000 px de large affichées en 300 px, au format JPEG non compressé
- Les fonts : 4 variantes de Google Fonts chargées en render-blocking
- Pas de cache : chaque visite régénère la page complète côté serveur
Étape 1 : supprimer le page builder
C’est la décision la plus impactante. Un thème Elementor charge en moyenne 800 Ko de CSS et 400 Ko de JavaScript juste pour le framework. Avant même votre contenu.
Notre approche : un thème WordPress sur mesure, codé en PHP/HTML/CSS pur. Zéro dépendance, zéro framework front-end. Le CSS total de notre thème WebEngine : moins de 30 Ko. Contre 800 Ko+ pour un thème Elementor.
Si vous ne pouvez pas abandonner votre page builder immédiatement, utilisez au minimum un plugin comme “Perfmatters” pour désactiver les assets Elementor sur les pages qui ne l’utilisent pas.
Étape 2 : optimiser les images
Les images représentent en moyenne 60 % du poids d’une page. Notre protocole :
- Format WebP ou AVIF — 25 à 50 % plus léger que JPEG à qualité égale
- Redimensionnement exact — une image ne doit jamais être plus large que son conteneur
- Lazy loading natif — attribut
loading="lazy"sur toutes les images sous la ligne de flottaison - Attributs width/height explicites — évite le Cumulative Layout Shift (CLS)
- Compression agressive — qualité 75-80 % en WebP, imperceptible à l’œil
Étape 3 : maîtriser le CSS
Le CSS render-blocking est le premier facteur de LCP (Largest Contentful Paint) élevé sur mobile :
- CSS critique inline — les styles au-dessus de la ligne de flottaison directement dans le
<head> - Le reste en async — chargé via
media="print" onload="this.media='all'" - Pas de CSS inutilisé — chaque sélecteur doit servir. PurgeCSS peut aider à identifier le CSS mort
- Pas de @import — chaque @import crée une requête HTTP bloquante supplémentaire
Étape 4 : optimiser le JavaScript
Moins de JS = site plus rapide. Notre règle : si une fonctionnalité peut être faite en CSS, on la fait en CSS.
- Defer tout le JS — attribut
defersur tous les scripts - Supprimer jQuery si possible — WordPress charge jQuery par défaut (90 Ko). Si aucun plugin ne l’utilise, on le retire
- Pas de tracking inutile — Google Analytics 4 + Facebook Pixel + Hotjar = 300 Ko de JS. Gardez uniquement ce que vous utilisez vraiment
- Bundler et minifier — un seul fichier JS minifié plutôt que 15 fichiers séparés
Étape 5 : configurer le cache et le serveur
- Cache navigateur — headers Cache-Control avec max-age long (1 an) pour les assets statiques
- Cache serveur — WP Super Cache ou un reverse proxy (Varnish, Nginx FastCGI Cache)
- Compression Gzip/Brotli — réduit la taille des transferts de 70 %
- HTTP/2 ou HTTP/3 — multiplexage des requêtes, header compression
- CDN — Cloudflare (gratuit) pour servir les assets depuis le point de présence le plus proche
Étape 6 : optimiser les fonts
- Héberger les fonts en local — pas de requête vers fonts.googleapis.com
- Format WOFF2 uniquement — le plus léger et supporté par tous les navigateurs modernes
- font-display: swap — le texte s’affiche immédiatement avec une font de fallback
- Limiter les variantes — 2 graisses maximum (regular + bold)
- Preload la font principale —
<link rel="preload" as="font">
Résultats concrets
En appliquant cette méthode complète, voici les résultats typiques que nous obtenons :
- Score mobile : 90 — 100 (contre 30-60 avant)
- LCP : < 1,5 s (contre 4-8 s avant)
- CLS : < 0,05 (contre 0,2-0,5 avant)
- Poids total page : < 500 Ko (contre 2-5 Mo avant)
Le score PageSpeed n’est pas une vanity metric — c’est un levier direct de trafic et de conversion. Chaque seconde de chargement en moins, c’est 7 % de conversions en plus.
Vous voulez qu’on audite votre site ? Contactez-nous pour un diagnostic PageSpeed gratuit.
Besoin d’un expert ? SEO technique & PageSpeed Paris →
Questions fréquentes
Peut-on atteindre 90 de PageSpeed mobile avec un thème Elementor ?
Rarement de façon stable. Elementor charge structurellement 600 Ko à 2 Mo de CSS/JS et génère un DOM de 300+ éléments. Avec WP Rocket + Cloudflare + toutes les optimisations, on atteint parfois 75-82 en mobile. C’est nettement inférieur à un thème natif qui atteint 90+ sans plugin d’optimisation.
Le score PageSpeed impacte-t-il directement le classement Google ?
Indirectement via les Core Web Vitals (LCP, CLS, INP) qui sont des facteurs de classement depuis 2021. Un score PageSpeed élevé corrèle avec de bons Core Web Vitals, mais ce n’est pas le score lui-même que Google utilise — c’est la mesure des métriques réelles des utilisateurs (CrUX data).
Combien de temps prend l’optimisation PageSpeed d’un site WordPress ?
Pour un site WordPress avec page builder : 2 à 5 jours d’optimisation (cache, CDN, images, JS différé) pour gagner 15 à 25 points. Pour un site en code natif avec des problèmes d’images : 1 à 2 jours. Pour une refonte complète d’un Elementor vers du code natif : 4 à 8 semaines selon la taille du site.