Vous vous doutez peut-être que votre site WordPress n'est pas aussi rapide qu'il le devrait. Mais l'avez-vous vérifié sur mobile ?
Prenez votre téléphone maintenant et chargez votre propre site. Comptez les secondes. Regardez la mise en page sauter. Observez les images se charger dans des dimensions incorrectes. C'est l'expérience que vivent 60 % de vos visiteurs, car c'est la part du trafic web provenant des appareils mobiles en 2026.
Google observe également.
Mobile-First Indexing : pourquoi la vitesse mobile compte le plus
Depuis 2021, Google applique l'indexation mobile-first à l'ensemble des sites. Cela signifie que votre classement repose sur les performances mobiles de votre site, et non sur celles du bureau.
Les performances desktop restent importantes pour de nombreux parcours B2B, mais l'index de Google est mobile-first : la vitesse mobile pèse davantage en SEO. Si votre PageSpeed mobile est à 45, c'est ce chiffre que l'explorateur de Google prend en compte. C'est un facteur déterminant pour savoir si vous apparaissez en première ou en troisième page.
De nombreux sites WordPress affichent un score de 35 à 55 sur mobile PageSpeed sans travail de performance dédié. C'est en dessous du seuil recommandé par Google, et cela peut devenir un véritable problème commercial.
Pourquoi les sites WordPress peinent sur mobile
Des thèmes non conçus pour le mobile-first
La plupart des thèmes WordPress sont conçus pour le bureau puis «rendus responsives» via des media queries CSS. Résultat : votre téléphone télécharge les mêmes ressources lourdes qu'un navigateur desktop, puis masque ce dont il n'a pas besoin. Les données sont quand même transférées. Le JavaScript s'exécute quand même. Vous ne le voyez simplement pas.
Un site véritablement mobile-first n'envoie que ce dont l'appareil a besoin. La plupart des thèmes WordPress ne le font pas nativement, même si cela reste possible avec un choix de thème et une configuration soignés.
CSS et JavaScript bloquant le rendu
Un site WordPress moyen charge 15 à 25 fichiers CSS et JavaScript distincts avant qu'un seul élément n'apparaisse à l'écran. Chaque fichier représente un aller-retour vers le serveur. Sur les réseaux mobiles, même en 4G rapide, cela peut ajouter 2 à 4 secondes d'attente pure avant qu'un seul pixel ne s'affiche.
Les plugins de cache tentent de combiner et de minifier ces fichiers, sans pouvoir résoudre le problème fondamental : WordPress charge tout en amont parce que les plugins ne se coordonnent pas entre eux.
Les images : le principal facteur de ralentissement
WordPress génère plusieurs tailles d'image, mais envoie rarement celle qui correspond à l'appareil. Une image hero de 2 000 px est transmise à un écran de téléphone de 390 px. Même avec des plugins de chargement différé, WordPress ne sert pas les formats modernes comme WebP ou AVIF par défaut, et n'utilise pas de nœud CDN proche de votre visiteur.
Sur mobile, les images représentent souvent 60 à 80 % du poids total de la page. Négliger ce point rend toute autre optimisation dérisoire.
Les constructeurs de page alourdissent massivement le chargement
Elementor, Divi, WPBakery : ces outils facilitent la conception sous WordPress. Le JavaScript d'un constructeur de page peut ajouter de 500 ko à 1,5 Mo par page ; les sites utilisant plusieurs constructeurs se chargent fréquemment en 5 à 8 secondes sur des appareils mobiles milieu de gamme en 4G. Sur desktop avec une connexion rapide, la différence est à peine perceptible.
L'hébergement mutualisé ne supporte pas les pics de trafic mobile
Les utilisateurs mobiles sont impatients : ils attendent des pages en moins de 2 secondes. Un serveur mutualisé qui met 800 ms à répondre à la première requête a déjà consommé la moitié de ce budget avant qu'une seule ressource ne se charge.
Chiffres réels : WordPress vs Next.js sur mobile
Après des dizaines de migrations WordPress vers Next.js, les résultats mobiles ressemblent généralement à ceci :
| Métrique | WordPress (sans optimisation) | Next.js sur Vercel |
|---|---|---|
| Mobile PageSpeed | 35-55 | 90-99 |
| First Contentful Paint | 3,0-5,5 s | 0,3-0,8 s |
| Largest Contentful Paint | 4,0-8,0 s | 0,6-1,2 s |
| Cumulative Layout Shift | 0,15-0,35 | 0,01-0,05 |
| Poids total de la page | 2-5 Mo | 200-500 ko |
Même contenu. Même identité visuelle. La différence tient à l'architecture.
Ce que signifie réellement une architecture "mobile-first"
Les sites Next.js reposent sur des bases fondamentalement différentes :
Génération statique. Les pages sont pré-construites sous forme de fichiers HTML au moment du déploiement. Quand un utilisateur mobile visite le site, il reçoit un fichier statique depuis un CDN : aucun traitement serveur, aucune requête base de données, aucune exécution PHP. Temps de réponse : environ 50 ms dans le monde entier.
Images responsives par défaut. Next.js intègre un composant Image qui sert automatiquement la bonne taille, au format WebP/AVIF, en chargement différé, depuis l'edge. Un utilisateur mobile sur un écran de 390 px reçoit une image de 390 px, pas une image de 2 000 px compressée dans un petit viewport.
Déploiement sur CDN edge. Vercel sert votre site depuis plus de 100 points de présence edge dans le monde. Un utilisateur mobile à Lyon reçoit votre page depuis Paris, pas depuis un serveur mutualisé à Dallas. La distance physique seule peut économiser 200 à 400 ms.
JavaScript minimal. Pas de jQuery. Pas de chaîne de plugins. Pas de runtime de constructeur de page. Un site d'entreprise Next.js typique embarque 50 à 100 ko de JavaScript au total, soit beaucoup moins que les builds WordPress classiques (souvent de 500 ko à 1,5 Mo).
Ce que vous pouvez faire
Commencez par vérifier votre score mobile. Sans connaître votre score PageSpeed mobile actuel, vous agissez à l'aveugle. Obtenez un rapport WordPress Health gratuit sur webvise.io/wp-health-report : il indique votre vrai score mobile, les alertes de sécurité, et ce que votre site pourrait atteindre après une reconstruction.
Évaluez si une optimisation WordPress supplémentaire vous permettra d'atteindre votre objectif. Si votre score mobile est inférieur à 60, atteindre 90 ou plus via des plugins seuls s'avère très difficile. Vous pouvez dépenser en plugins de cache, optimiseurs d'images et abonnements CDN, et plafonner quand même dans les 60. À un certain stade, c'est l'architecture qui devient le facteur limitant.
Envisagez une reconstruction. Une migration WordPress vers Next.js est dimensionnée selon la complexité du site, le volume de contenu, le risque SEO et les intégrations, et s'attaque aux causes architecturales des problèmes de vitesse mobile. Les sites atteignent généralement 90 ou plus sur mobile dès le lancement lorsqu'ils sont correctement construits. Aucun pipeline de maintenance de plugins ; les performances ne se dégradent pas suite aux mises à jour de plugins ou de thèmes, même si les mises à jour du framework et des dépendances restent nécessaires.
Les visiteurs mobiles et le crawler mobile de Google font la différence.
Prêt à découvrir le score mobile de votre site ? Obtenez votre rapport WordPress Health gratuit sur webvise.io/wp-health-report : 60 secondes suffisent. Sans inscription.