Comment optimiser Local WP sous Windows pour qu’il charge plus vite

Pour cloner un site en local Local WP est très bien. Le problème, c’est que parfois il commence à devenir lent, même dès le départ et sur des machines puissantes.

Et forcément, quand c’est lent, ça devient assez désespérant. Parce qu’en plus de la sécurité, on travaille en local pour aller plus vite, pas pour attendre trois secondes chaque fois qu’on ouvre une page de l’admin.

Sur le projet de mon nouveau site, ça m’arrivait, mais je ne voulais pas changer d’outil. Je ne voulais pas monter Docker, jeter l’environnement ni repartir de zéro. Je voulais que Local WP redevienne (très) utilisable.

Après avoir essayé plusieurs choses, voici les cinq étapes qui ont vraiment fonctionné pour moi.

Il existe d’autres options d’optimisation, mais je m’en suis tenu à celles-ci et maintenant mon local file comme une flèche.

1. Confirmer que Xdebug était désactivé

La première chose a été de vérifier Xdebug.

Xdebug sert à déboguer PHP. Si tu vas mettre des breakpoints, inspecter des variables et faire du debugging sérieux, parfait. C’est fait pour ça.

Mais si tu ne l’utilises pas, il peut ralentir pas mal l’environnement.

Dans Local WP, cela se vérifie depuis la fiche du site :

Local WP > ton site > onglet Overview / Tools > Xdebug

Dans mon cas, il était déjà désactivé, donc je n’ai rien eu à toucher. Mais par expérience, c’était le premier suspect à écarter.

La règle est simple : si tu ne débogues pas activement PHP, Xdebug doit rester désactivé.

Ici, ce n’était pas “la solution” dans mon cas, puisqu’il était déjà coupé, mais ça ne coûte rien de vérifier avant de devenir fou avec autre chose.

2. Changer le domaine de .local à .test

Ce changement, lui, s’est senti.

J’avais le site avec un domaine se terminant par .local (yg.local) et je l’ai passé à yg.test.

Dans Local WP, on fait comme ça :

1. Ouvre Local WP.
2. Sélectionne le site.
3. Va dans l’onglet Overview.
4. Cherche le champ Site domain.
5. Clique sur Change.
6. Change le domaine de .local à .test.
7. Confirme le changement.
8. Redémarre le site.

Ensuite, ouvre-le avec la nouvelle URL :

https://yg.test

Ou, si SSL n’est pas actif dans Local :

http://yg.test

Pourquoi ça fonctionne ? 

Parce que .local peut poser problème dans certains environnements à cause de sa résolution au niveau réseau. .test est beaucoup plus pensé pour le développement local et évite une partie de cette friction absurde.

C’est un changement simple qui, dans mon cas, a aidé.

3. Exclure les dossiers de Local WP de l’antivirus Windows

Autre réglage important.

Si tu travailles sous Windows, Windows Defender peut analyser constamment les fichiers de WordPress, plugins, thèmes, uploads, base de données, logs, caches et services internes de Local.

Et forcément, WordPress en local manipule énormément de petits fichiers. Si l’antivirus se met à inspecter tout ce que touche PHP, MySQL ou nginx, les performances en prennent un coup.

Bien sûr, je n’ai pas désactivé l’antivirus : j’ai simplement ajouté des exclusions.

Dans Windows :

1. Ouvre Sécurité Windows.
2. Va dans Protection contre les virus et menaces.
3. Descends jusqu’à Paramètres de protection contre les virus et menaces.
4. Clique sur Gérer les paramètres.
5. Descends jusqu’à Exclusions.
6. Clique sur Ajouter ou supprimer des exclusions.
7. Ajoute des exclusions de type Dossier.

Le dossier important est celui des sites locaux :

C:UsersVOTRE_UTILISATEURLocal Sites

Et aussi les dossiers internes de Local, qui se trouvent généralement dans des chemins comme :

C:UsersVOTRE_UTILISATEURAppDataLocalProgramsLocal

Et :

C:UsersVOTRE_UTILISATEURAppDataRoamingLocal

Dans mon cas, exclure Local Sites a été particulièrement important, parce que c’est là que se trouve réellement le site : WordPress, plugins, thèmes, uploads et tout ce que Local touche en permanence.

Après avoir ajouté les exclusions, il est préférable d’arrêter puis de relancer le site depuis Local WP.

4. Désactiver les plugins dont je n’avais pas besoin en local

L’étape suivante était assez évidente, mais on l’oublie parfois ou on préfère ne pas le faire pour mieux simuler l’environnement de production.

Il y a des plugins qui font des appels externes, des tâches planifiées, des vérifications de sécurité, des sauvegardes, des logs, des caches, des analyses SEO, des intégrations avec des newsletters, de la surveillance, de l’optimisation d’images et mille autres choses.

Tout ça peut être inutile en local, selon ce que tu es en train de tester.

J’ai donc revu la liste des plugins et désactivé ceux dont je n’avais pas besoin pour travailler à ce moment-là.

La question était celle-ci : 

Ai-je besoin que ce plugin soit actif pour ce que je fais maintenant ?

Si la réponse était non, je le désactivais.

Dans mon cas :

1. Plugins de sauvegarde.
2. Plugins Genesis.
3. Plugins de sécurité.
4. Plugins de cache.
5. Plugins d’analytics.
6. Plugins qui lancent des tâches planifiées

Moins de plugins actifs, c’est moins de charge, moins de processus en arrière-plan et moins de choses qui se disputent les ressources.

Cela dit, je n’ai pas observé une grande amélioration ici, donc il vaut peut-être mieux garder cette étape pour la fin, si tout le reste ne suffit pas.

5. Nettoyer la base de données depuis le shell de Local

La dernière étape a été de nettoyer la base de données.

WordPress accumule très facilement des déchets : révisions, brouillons automatiques, transients expirés, commentaires à la corbeille, spam, métadonnées orphelines et restes de plugins.

Pour le faire, j’ai ouvert le shell du site depuis Local WP :

Local WP > ton site > Open Site Shell

Avant de nettoyer, j’ai fait une sauvegarde de la base de données :

wp db export backup-before-cleanup.sql

Ensuite, j’ai exécuté ce bloc de nettoyage :

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

wp post delete $(wp post list --post_status='trash' --format=ids) --force

wp comment delete $(wp comment list --status=spam --format=ids) --force

wp comment delete $(wp comment list --status=trash --format=ids) --force

wp transient delete --expired

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

wp db query "DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id WHERE c.comment_ID IS NULL;"

wp db query "DELETE tm FROM wp_termmeta tm LEFT JOIN wp_terms t ON t.term_id = tm.term_id WHERE t.term_id IS NULL;"

wp db query "DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON u.ID = um.user_id WHERE u.ID IS NULL;"

wp db optimize

Attention à une chose : cela suppose que le préfixe des tables est wp_.

Si tu es sous Windows et que cette syntaxe de variable ne fonctionne pas, utilise directement le préfixe renvoyé :

wp db prefix

et remplace-le à la main.

Cette étape n’est pas à faire à la légère en production. En local, avec une sauvegarde préalable, oui.

Résultat

Après ces cinq étapes, Local WP a commencé à tourner nettement mieux. Logique, parce que mon Ryzen 7 2700 Pro avec NMVE et 24GB est considérablement plus puissant que le serveur de production.

C’est pour ça que j’étais certain que ça valait la peine de y consacrer un petit moment.

Maintenant, il tourne comme il doit et m’a évité beaucoup de petits moments perdus.

Le résumé serait :

1. Vérifier que Xdebug est désactivé.
2. Changer le domaine de .local à .test.
3. Exclure les dossiers de Local WP dans Windows Defender.
4. Désactiver les plugins inutiles en local.
5. Nettoyer la base de données depuis le shell.

En gros, enlever du lest à l’environnement.

Dans ce cas, Local WP n’est pas lent pour une seule raison, mais à cause d’une somme de petites choses : résolution du domaine, antivirus qui regarde chaque fichier, plugins superflus et base de données pleine de restes.

Je n’ai pas tout mesuré au chronomètre, mais au ressenti. C’est pour ça que je sais ce qui a fonctionné pour moi.

Maintenant, j’ai ma copie locale qui file comme une flèche, donc je n’ai plus d’excuses pour travailler en production sans tester.

Et toi, tu utilises encore la même excuse ?