Site WordPress lent PageSpeed : pourquoi il plafonne
Un client d'agence m'envoie l'URL de son site vitrine refait six mois plus tôt, thème premium acheté sur une marketplace, montage Elementor, clé en main. Score PageSpeed mobile : 38. Il veut comprendre pourquoi, parce que son propre client commence à poser la question. Je lance Lighthouse, et le rapport dit toujours à peu près la même chose.
Le score plafonne parce que le poids est structurel, pas accidentel
Sur ce type de site, le rapport Lighthouse remonte quatre lignes rouges récurrentes. Reduce unused CSS avec 480 Ko de feuilles chargées dont 90 pour cent jamais appliquées à la page. Reduce unused JavaScript autour de 320 Ko. Largest Contentful Paint à 4,8 s. Total Blocking Time à 640 ms. Le score composite tombe mécaniquement sous 45.
Ces chiffres ne sont pas des bugs de configuration. Ils sont la conséquence directe de l'architecture. Un thème premium doit tout faire pour tout le monde, donc il embarque une bibliothèque de composants, des sliders, des icônes, des animations, chargés que la page les utilise ou non. Elementor et Divi ajoutent leur propre moteur de rendu : Elementor charge à lui seul entre 200 et 400 Ko de CSS et JavaScript sur chaque page, avant même votre contenu. Divi est du même ordre. Vous démarrez donc à 600 ou 700 Ko de code de framework sur une page qui devrait en peser 80.
Le CSS non purgé est le premier coupable mesurable
Prenez la couverture de code dans l'onglet Coverage de Chrome DevTools sur une page produite avec un page builder. Vous verrez couramment 85 à 92 pour cent de CSS inutilisé. Ce n'est pas anodin : le navigateur doit télécharger, parser et construire le CSSOM pour l'intégralité de ces feuilles avant de peindre le premier pixel. Sur mobile bridé, parser 480 Ko de CSS coûte facilement 300 à 500 ms de temps CPU, purs, avant tout rendu.
Un thème codé en propre charge le CSS de la page et rien d'autre, typiquement 15 à 40 Ko après purge. L'écart n'est pas de 10 pour cent, il est d'un facteur 15. C'est ce facteur qui explique qu'un thème premium optimisé au maximum plafonne là où un thème léger démarre sans effort. Je détaille la méthode de mesure dans mon article sur l'audit technique avant refonte.
Les images non servies en AVIF pèsent le double de ce qu'elles devraient
Deuxième ligne rouge systématique : Serve images in next-gen formats. Le hero d'un site vitrine fait souvent 1600 pixels de large. En JPEG qualité 80, c'est 280 à 450 Ko. Le même visuel en WebP tombe à 120 Ko, en AVIF à 70 Ko pour une qualité perceptuelle équivalente. Sur une page qui affiche cinq à huit images, vous parlez de 1,5 Mo évitable.
WordPress ne sert pas l'AVIF par défaut. Il faut un plugin de conversion, correctement configuré, qui régénère la médiathèque et sert le bon format via un srcset conditionnel. Beaucoup de montages premium laissent tourner les JPEG d'origine parce que personne n'a fait ce travail. C'est réparable sans changer de plateforme, et c'est souvent le gain le plus rapide : passer les images en AVIF fait monter le LCP à lui seul de 4,8 s à 3,1 s dans les cas que je mesure.
Le JavaScript bloquant et les requêtes plugin étalent le Total Blocking Time
Chaque plugin qui s'affiche côté public tend à enfiler son propre script dans le head, sans defer ni async. Un formulaire de contact, un cookie banner, un plugin de partage social, un chat, un slider : cinq scripts synchrones, et le thread principal reste bloqué pendant que le navigateur les exécute un par un. Le Total Blocking Time reflète exactement ça. Passé 300 ms, la page paraît figée au tap sur mobile.
| Poste | Thème premium + page builder | Thème léger codé en propre |
|---|---|---|
| CSS transféré | 480 Ko | 28 Ko |
| JavaScript transféré | 320 Ko | 60 Ko |
| Requêtes HTTP | 78 | 22 |
| LCP mobile | 4,8 s | 1,9 s |
| Total Blocking Time | 640 ms | 90 ms |
| Score PageSpeed mobile | 38 | 88 |
Ce tableau vient de comparaisons que je fais régulièrement sur des sites équivalents en contenu. Les valeurs de gauche sont un cas typique, pas un pire cas fabriqué.
La limite : parfois WordPress bien optimisé suffit, et parfois la perf n'est pas le sujet
Je ne dirai pas que tout site WordPress est condamné à 40, ce serait malhonnête. Un thème sobre comme GeneratePress ou Kadence, sans page builder, avec un hébergement correct, un cache de page, les images en AVIF et une discipline de cinq à huit plugins maximum, passe 85 en mobile sans tour de magie. Le plafond n'est pas dans WordPress, il est dans l'empilement thème premium plus builder plus extensions. Si votre client tolère un thème contraint et que personne ne bricole le montage tous les deux mois, WordPress tient très bien la route.
Autre limite qu'il faut assumer devant un client : la performance n'est pas toujours le vrai problème. Un site à 40 qui reçoit trente visites par jour et convertit correctement n'a pas de problème de perf, il a peut-être un problème d'acquisition. Refaire un site pour gagner cinquante points PageSpeed pendant que le vrai frein est un tunnel de conversion cassé, c'est vendre la mauvaise prestation. Je pose toujours la question du chiffre d'affaires réel avant de proposer une refonte pour la vitesse.
Quand la perf est bien le sujet, l'arbitrage se joue entre optimiser l'existant et repartir propre. J'ai détaillé cette décision dans Symfony ou WordPress pour un site client, et la logique de sous-traitance de ce type de chantier dans la sous-traitance de développement web pour agence. Si vous préférez déléguer l'audit et la remise en état à quelqu'un qui vit dans ces rapports Lighthouse, je travaille avec des agences sur ce type de dossier via mon offre partenaires.