Come ottimizzare Local WP su Windows perché carichi più velocemente

Per clonare un sito in locale Local WP va benissimo. Il problema è che, a volte, comincia a diventare lento, persino fin dal primo momento e su computer potenti.

E ovviamente, quando è lento, esaspera parecchio. Perché si presume che, oltre che per sicurezza, tu stia lavorando in locale per andare più veloce, non per aspettare tre secondi ogni volta che apri una pagina dell’admin.

Nel progetto del mio nuovo sito mi succedeva, ma non volevo cambiare strumento. Non volevo configurare Docker, buttare via l’ambiente né ricominciare da zero. Volevo che Local WP tornasse a essere (molto) utilizzabile.

Dopo aver provato varie cose, questi sono i cinque passaggi che hanno funzionato davvero per me.

Ci sono diverse altre opzioni di ottimizzazione, ma io mi sono limitato a queste e ora il mio ambiente locale va come un razzo.

1. Confermare che Xdebug fosse disattivato

La prima cosa è stata controllare Xdebug.

Xdebug serve per fare debug di PHP. Se devi mettere breakpoint, ispezionare variabili e fare debugging serio, perfetto. È lì per quello.

Ma se non lo stai usando, può rallentare parecchio l’ambiente.

In Local WP si controlla dalla scheda del sito:

Local WP > il tuo sito > scheda Overview / Tools > Xdebug

Nel mio caso era già disattivato, quindi non ho dovuto toccare nulla. Ma per esperienza era il primo sospettato da escludere.

La regola è semplice: se non stai facendo debug attivo di PHP, Xdebug disattivato.

Qui non è stata “la soluzione” nel mio caso, perché era già spento, ma non costa nulla controllarlo prima di impazzire con altre cose.

2. Cambiare il dominio da .local a .test

Questo cambiamento si è notato.

Avevo il sito con un dominio che finiva in .local (yg.local) e l’ho cambiato in yg.test.

In Local WP si fa così:

1. Apri Local WP.
2. Selezioni il sito.
3. Vai alla scheda Overview.
4. Cerchi il campo Site domain.
5. Premi Change.
6. Cambi il dominio da .local a .test.
7. Confermi la modifica.
8. Riavvii il sito.

Poi accedi con il nuovo URL:

https://yg.test

Oppure, se non hai SSL attivo in Local:

http://yg.test

Perché funziona? 

Perché .local può dare problemi in alcuni ambienti per come viene risolto a livello di rete. .test è molto più pensato per lo sviluppo locale ed evita parte di quell’assurda frizione.

È un cambiamento semplice che nel mio caso ha aiutato.

3. Escludere le cartelle di Local WP dall’antivirus di Windows

Un altro aggiustamento importante.

Se lavori con Windows, Windows Defender potrebbe controllare continuamente i file di WordPress, plugin, temi, upload, database, log, cache e servizi interni di Local.

E ovviamente, WordPress in locale muove moltissimi file piccoli. Se l’antivirus si mette a ispezionare ogni cosa toccata da PHP, MySQL o nginx, le prestazioni ne risentono.

Ovviamente non ho disattivato l’antivirus; ho semplicemente aggiunto delle esclusioni.

In Windows:

1. Apri Sicurezza di Windows.
2. Entra in Protezione da virus e minacce.
3. Scorri fino a Impostazioni di Protezione da virus e minacce.
4. Premi Gestisci impostazioni.
5. Scorri fino a Esclusioni.
6. Premi Aggiungi o rimuovi esclusioni.
7. Aggiungi esclusioni di tipo Cartella.

La cartella importante è quella dei siti locali:

C:UsersTUO_UTENTELocal Sites

E anche le cartelle interne di Local, che di solito si trovano in percorsi come:

C:UsersTUO_UTENTEAppDataLocalProgramsLocal

E:

C:UsersTUO_UTENTEAppDataRoamingLocal

Nel mio caso, escludere Local Sites è stato particolarmente importante, perché lì si trova davvero il sito: WordPress, plugin, temi, upload e tutto ciò che Local tocca continuamente.

Dopo aver aggiunto le esclusioni, conviene fermare e riavviare il sito da Local WP.

4. Disattivare i plugin che non mi servivano in locale

Il passaggio successivo era abbastanza ovvio, ma a volte ce ne dimentichiamo o preferiamo non farlo per simulare meglio l’ambiente di produzione.

Ci sono plugin che fanno chiamate esterne, attività programmate, controlli di sicurezza, backup, log, cache, analisi SEO, integrazioni con newsletter, monitoraggio, ottimizzazione delle immagini e mille altre cose.

Tutto questo in locale può essere superfluo, a seconda di ciò che stai provando.

Così ho rivisto la lista dei plugin e ho disattivato quelli che non mi servivano per lavorare in quel momento.

La domanda era questa: 

Mi serve questo plugin attivo per quello che sto facendo ora?

Se la risposta era no, lo disattivavo.

Nel mio caso:

1. Plugin di backup.
2. Plugin di Genesis.
3. Plugin di sicurezza.
4. Plugin di cache.
5. Plugin di analytics.
6. Plugin che avviano attività programmate

Meno plugin attivi significa meno carico, meno processi in background e meno cose che competono per le risorse.

Comunque, qui non ho notato un grande miglioramento, quindi forse conviene lasciare questo passaggio alla fine, se tutto il resto non basta.

5. Pulire il database dalla shell di Local

L’ultimo passaggio è stato pulire il database.

WordPress accumula spazzatura con grande facilità: revisioni, bozze automatiche, transients scaduti, commenti nel cestino, spam, metadati orfani e resti di plugin.

Per farlo, ho aperto la shell del sito da Local WP:

Local WP > il tuo sito > Open Site Shell

Prima di pulire, ho fatto un backup del database:

wp db export backup-before-cleanup.sql

Poi ho eseguito questo blocco di pulizia:

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

Attenzione a una cosa: questo presume che il prefisso delle tabelle sia wp_.

Se sei su Windows e quella sintassi di variabile non ti funziona, usa direttamente il prefisso che ti restituisce:

wp db prefix

e sostituiscilo a mano.

Questo passaggio non è da fare con leggerezza in produzione. In locale, con un backup precedente, sì.

Risultato

Dopo questi cinque passaggi, Local WP ha iniziato ad andare parecchio meglio. Logico, perché il mio Ryzen 7 2700 Pro con NMVE e 24GB è decisamente più potente del server di produzione.

Per questo avevo chiaro che valeva la pena dedicarci un po’ di tempo.

Ora va come deve e mi ha fatto risparmiare tanti piccoli momenti.

Il riassunto sarebbe:

1. Controllare che Xdebug sia disattivato.
2. Cambiare il dominio da .local a .test.
3. Escludere le cartelle di Local WP in Windows Defender.
4. Disattivare i plugin inutili in locale.
5. Pulire il database dalla shell.

In pratica, togliere peso all’ambiente.

In questo caso Local WP non va lento per una sola causa, ma per la somma di piccole cose: risoluzione del dominio, antivirus che controlla ogni file, plugin di troppo e un database pieno di residui.

Non ho misurato ogni cosa con il cronometro, ma a sensazione. Per questo so cosa ha funzionato per me.

Ora ho la mia copia locale che va come un razzo, quindi sono rimasto senza scuse per lavorare in produzione e non testare.

E tu, continui a usare la stessa scusa?