Alléger un site WordPress : l'ordre compte. On mesure, on retire les extensions mortes, on traite les images, on nettoie la base, on pose un cache unique, on corrige le thème, on remesure. L'inverse (poser trois plugins « speed » sur un monstre) ajoute du JS et des conflits. Cet article est le régime du site déjà lourd. Il complète « éviter un WordPress qui rame » (prévention) et « héberger WordPress pour la perf » (serveur). Ensemble, ils couvrent la lenteur WordPress sans folklore.
🔎 Mesurer pour savoir ce qui est gras
LCP, poids, nombre de requêtes, TTFB, admin. Accueil, une page intérieure, une page produit. On note les plus gros JS, les images, le TTFB. Sans ça, on retire au hasard et on casse un paiement. L'allègement est un audit court plus des gestes, pas une après-midi de cases cochées dans un plugin.
Si le TTFB domine, on va vers l'hébergement et wp_options. Si le LCP image domine, médiathèque. Si le JS domine, plugins et builder. Trois diagnostics, trois chantiers. Rarement les trois à fond dans la même semaine, sauf crise.
🛠️ Plugins : désactiver, puis supprimer
On liste. On marque : utile, doute, mort. Les morts se désactivent en préprod, on vérifie, on supprime. Les doutes se testent une semaine. On ne laisse pas des plugins désactivés « au cas où » : ils restent une surface et une tentation.
Les doublons (deux SEO, deux caches, deux sliders) : on n'en garde qu'un. Les plugins de sécu bavards : on les remplace par des gestes (2FA, XML-RPC, URL admin). Alléger, c'est aussi durcir plus simplement.
✅ Images et médiathèque
On régénère des tailles raisonnables, on compresse, on arrête d'uploader du 6000 px. Les originaux se stockent ailleurs si besoin légal. Les images orphelines se discutent (poids disque, backups). Un plugin de régénération plus une règle de publication font plus qu'un CDN mal câblé.
Les carrousels de huit visuels pleine largeur : on en retire. C'est du produit. L'allègement n'est pas seulement technique. C'est dire non à un motif visuel qui coûte 800 ms.
⚠️ Base : autoload, révisions, transients
wp_options autoload trop gros : le bootstrap WordPress ramène un camion à chaque page. On identifie les coupables (plugins, builders). On nettoie avec méthode, sauvegarde d'abord. Les révisions : on limite. Les transients expirés : on purge. Les tables de logs de plugins : on les vide et on les empêche de renaître.
Ce n'est pas un « optimize database » hebdomadaire aveugle. C'est un diagnostic. Les boutons magiques ont déjà cassé des boutiques.
- Sauvegarde restaurable avant tout nettoyage de base
- Préprod pour chaque retrait de plugin sensible
- Un cache de page, un object cache max
- Remesure après chaque palier, pas à la fin seulement
📌 Un cache, pas une collection
On retire les caches en conflit. On en pose un, on configure les exclusions (panier, compte, preview). On purge après les paliers. On vérifie que les pages anonymes ne bootstrappent plus tout WordPress.
Le « unused CSS » automatique casse souvent des états hover et des tunnels. Je m'en sers peu. Je préfère moins de CSS à la source.
🧭 Thème et builder : le palier douloureux
Si le builder est le problème, on peut : limiter les widgets, retirer des add-ons, ou sortir (refonte partielle). Alléger n'est pas toujours possible sans toucher le design. On le dit au début. Un régime qui promet -70 % de LCP sans toucher Elementor sur 80 pages ment parfois.
Un thème enfant plein de CSS mort : on le nettoie quand on y touche. Pas un rewrite du week-end.
💡 Admin et cron
Un wp-admin lent fait faire des erreurs à l'équipe. On allège aussi là : moins de metabox, moins de plugins dans l'admin, cron système. Ce n'est pas du LCP public. C'est de la TMA humaine.
Les crons de plugins de stats et de backups locaux au mauvais moment saturent le pic. On les décale. Voir hébergement et monitoring.
🧪 Quand alléger ne suffit plus
Si après un régime honnête le LCP reste indéfendable, on parle TMA ou refonte, ou d'un front plus sec (statique, parfois headless). Alléger n'est pas une religion. C'est le premier chantier, moins cher.
Je le fais souvent en quelques jours à quelques semaines. Vous repartez avec une liste de plugins, des mesures avant / après, un cache compris. Pas avec trois extensions speed de plus.
🔎 Ordre d'une semaine type
Lundi : mesures et inventaire. Mardi : plugins morts, préprod. Mercredi : images et un cache. Jeudi : base autoload, remesure. Vendredi : ce qui reste est un sujet thème / builder / hébergement, on le dit. Comment alléger un site WordPress tient souvent dans cette semaine, pas dans un trimestre de « on va optimiser ».
Si le vendredi le LCP n'a presque pas bougé, on n'ajoute pas un plugin. On change de palier (refonte partielle, hébergeur, front). Le régime a une fin. L'acharnement a un coût.
🛠️ Ce que je ne touche pas sans vous
Un plugin de paiement, un tunnel, un bandeau cookies, un tracking de campagne en cours. Alléger n'est pas un prétexte pour tout désactiver. Les gestes risqués ont une vérification. Les gestes évidents (slider abandonné, chat mort) vont vite. On mélange les deux, on se trompe de vitesse.
Vous validez la liste avant. C'est votre site. C'est ma méthode. Les deux signatures évitent le « pourquoi le chat a disparu ». Parce qu'il coûtait 400 ms et zéro conversation. On l'avait dit.
Un site léger, c'est un site qu'on ose encore mettre à jour.
