
Pourquoi tant de sites WordPress sont insupportablement lents
Un site WordPress qui mettait 12 secondes à charger est passé à 1,8 seconde en corrigeant trois erreurs courantes. Voici lesquelles.

Un client me contacte avec un site WordPress qu'il gère depuis cinq ans. Son problème : le site devient de plus en plus lent malgré un hébergement qui coûte maintenant 80 francs par mois. Il passe deux heures par semaine à faire les mises à jour de sécurité et à gérer les conflits entre plugins.
Son site est un portfolio avec une vingtaine de projets et un blog. Pas de boutique en ligne, pas de système complexe. Juste du contenu statique qui ne change que quelques fois par mois.
Je lui propose de migrer vers Next.js. Trois mois et 6000 francs plus tard, le site charge en 0,8 seconde au lieu de 4,5. L'hébergement coûte 0 franc (Vercel gratuit pour son usage). Il n'y a plus de mises à jour à faire.
Mais ce n'était pas sans compromis.
La performance a été le changement le plus visible. Son site WordPress, même après optimisation, chargeait entre 3 et 5 secondes selon la connexion. Avec Next.js en génération statique, toutes les pages chargent en moins d'une seconde, partout dans le monde.
Google a remarqué. Son trafic organique a augmenté de 40% en deux mois, sans aucun changement de contenu. Juste parce que le site est devenu plus rapide et que Google favorise les sites performants.
L'hébergement est passé de 80 francs par mois à zéro. Son site WordPress nécessitait un serveur costaud pour gérer le trafic. Next.js génère des pages statiques hébergées gratuitement sur Vercel. Économie annuelle : 960 francs.
La maintenance est tombée à quasiment zéro. Plus de mises à jour WordPress toutes les semaines. Plus de plugins qui cassent après une mise à jour. Plus de problèmes de sécurité. Le site tourne tout seul.
Modifier le contenu n'est plus aussi simple. Avec WordPress, le client se connectait, cliquait sur "Modifier", tapait son texte, publiait. Deux minutes chrono.
Avec Next.js, il faut éditer des fichiers Markdown, puis déployer. On a mis en place un CMS headless (Contentful) pour qu'il puisse éditer le contenu de manière visuelle, mais ce n'est pas aussi fluide que WordPress. Il y a un léger délai entre l'édition et la publication (environ 2 minutes pour que le build se fasse).
Le client a dû accepter cette contrainte. Pour lui, ça valait le coup pour les gains de performance et les économies, mais certains clients n'accepteraient pas.
La migration a pris trois mois à temps partiel. Recréer le design, migrer le contenu, implémenter les fonctionnalités manquantes. Facture totale : 6000 francs.
Pour un site qui lui coûtait 80 francs par mois en hébergement, l'investissement est rentabilisé en environ 6 ans uniquement sur les économies d'hébergement. C'est long.
Mais si on ajoute les gains de trafic (plus de clients), le temps économisé en maintenance (2h par semaine = 100h par an), et l'amélioration de l'expérience utilisateur, le ROI devient positif bien plus vite.
Pour un client qui génère des revenus significatifs de son site, la migration se rentabilise en 6 à 12 mois. Pour un site vitrine qui ne génère pas de revenus directs, c'est plus discutable.
Un restaurant qui change son menu toutes les semaines et veut pouvoir le faire lui-même en 30 secondes ? WordPress. La facilité d'édition est imbattable.
Une petite entreprise avec un budget de 2000 francs pour son site ? WordPress. Développer sur mesure en Next.js coûterait 5000 à 8000 francs minimum.
Un site qui a besoin de fonctionnalités spécifiques existant déjà en plugin WordPress (réservations, e-learning, annuaire) ? WordPress. Redévelopper ces fonctionnalités en Next.js coûterait une fortune.
WordPress n'est pas mort. Il reste pertinent pour beaucoup de cas d'usage. Mais ses limites de performance et de scalabilité deviennent problématiques pour les sites à fort trafic ou à fort enjeu business.
Si votre site génère des revenus significatifs et que chaque seconde de chargement compte, Next.js commence à se justifier. Les sites e-commerce, les SaaS, les plateformes à fort trafic bénéficient énormément de la performance.
Si vous avez besoin d'une expérience utilisateur très spécifique que les thèmes WordPress ne peuvent pas offrir, Next.js donne une liberté totale. Mais ça nécessite un vrai développeur.
Si vous prévoyez de scaler significativement (passer de 1000 à 100'000 visiteurs par jour), Next.js va mieux encaisser la charge. WordPress nécessitera un hébergement de plus en plus cher pour tenir la charge.
Un aspect qu'on sous-estime : la dette technique. Le site WordPress de mon client avait accumulé 5 ans de plugins, de hacks, de modifications. Personne ne savait plus exactement ce qui faisait quoi. Chaque modification devenait risquée.
Avec Next.js, le code est propre, versionné, compréhensible. Dans 5 ans, un autre développeur pourra reprendre le projet sans problème. Avec WordPress après 5 ans, c'est souvent un cauchemar.
Mais cette propreté a un coût : il faut un développeur pour tout. Impossible de "juste installer un plugin" pour ajouter une fonctionnalité. Tout doit être développé ou intégré proprement.
Pour les nouveaux clients, je pose trois questions :
Qui va gérer le contenu ? Si c'est le client lui-même et qu'il n'est pas technique, WordPress reste plus pertinent. Si c'est moi ou un développeur, Next.js est envisageable.
Quel est le budget ? En dessous de 4000 francs, WordPress est presque toujours le choix le plus rationnel. Au-dessus, Next.js devient intéressant si le projet le justifie.
Quel est l'enjeu business ? Un site vitrine sans enjeu de conversion peut rester sur WordPress. Un site qui génère des ventes ou des leads importants justifie l'investissement dans Next.js.
La technologie n'est pas une fin en soi. Next.js n'est pas "meilleur" que WordPress de manière absolue. Chacun répond à des besoins différents.
Le client avec qui j'ai fait la migration est ravi. Son site est rapide, moderne, et ne lui pose plus de problèmes. Mais il accepte de passer par moi pour les modifications de contenu importantes.
Un autre client avec un cas similaire a choisi de rester sur WordPress après avoir entendu les contraintes. Il préfère pouvoir tout gérer lui-même, même si c'est un peu moins performant.
Les deux ont raison. Il n'y a pas de mauvais choix, juste des choix adaptés ou non au contexte.

Un site WordPress qui mettait 12 secondes à charger est passé à 1,8 seconde en corrigeant trois erreurs courantes. Voici lesquelles.

Deux clients avec le même budget. L'un a choisi un template, l'autre du sur-mesure. Un an plus tard, un seul des deux a fait le bon choix.

Trois ans à jongler entre React, Vue et Svelte en production. Voici pour quels types de projets chacun est devenu mon choix par défaut.