Como otimizar o Local WP no Windows para carregar mais rápido

Para clonar um site em local Local WP é muito bom. O problema é que, às vezes, começa a ficar lento, até desde o primeiro momento e em máquinas potentes.

E claro, quando fica lento, desespera bastante. Porque supostamente, além da segurança, estás a trabalhar em local para ir mais rápido, não para esperar três segundos sempre que abres uma página do admin.

No projeto do meu novo site isso acontecia comigo, mas eu não queria mudar de ferramenta. Não queria montar Docker, nem deitar fora o ambiente, nem começar do zero. Queria que o Local WP voltasse a ser (muito) utilizável.

Depois de testar várias coisas, estes são os cinco passos que realmente funcionaram comigo.

Há várias outras opções de otimização, mas limitei-me a estas e agora o meu local anda como um foguete.

1. Confirmar que o Xdebug estava desativado

A primeira coisa foi verificar Xdebug.

O Xdebug serve para depurar PHP. Se vais colocar breakpoints, inspecionar variáveis e fazer debugging a sério, perfeito. É para isso que ele serve.

Mas se não o estás a usar, pode abrandar bastante o ambiente.

No Local WP, isto verifica-se na ficha do site:

Local WP > o teu site > separador Overview / Tools > Xdebug

No meu caso já estava desativado, por isso não tive de tocar em nada. Mas, por experiência, era o primeiro suspeito a excluir.

A regra é simples: se não estás a depurar PHP ativamente, Xdebug desativado.

Aqui não foi “a solução” no meu caso, porque já estava desligado, mas não custa nada verificar antes de enlouquecer com outras coisas.

2. Mudar o domínio de .local para .test

Esta mudança notou-se.

Tinha o site com um domínio terminado em .local (yg.local) e mudei-o para yg.test.

No Local WP faz-se assim:

1. Abres o Local WP.
2. Selecionas o site.
3. Vais ao separador Overview.
4. Procuras o campo Site domain.
5. Clicas em Change.
6. Mudas o domínio de .local para .test.
7. Confirmas a alteração.
8. Reinicias o site.

Depois, entras com o novo URL:

https://yg.test

Ou, se não tiveres SSL ativo no Local:

http://yg.test

Porque funciona? 

Porque .local pode dar problemas em alguns ambientes pela forma como é resolvido ao nível da rede. .test foi muito mais pensado para desenvolvimento local e evita parte dessa fricção absurda.

É uma mudança simples que, no meu caso, ajudou.

3. Excluir as pastas do Local WP no antivírus do Windows

Outro ajuste importante.

Se trabalhas com Windows, o Windows Defender pode estar a verificar constantemente os ficheiros do WordPress, plugins, temas, uploads, base de dados, logs, caches e serviços internos do Local.

E claro, o WordPress em local mexe em imensos ficheiros pequenos. Se o antivírus começa a inspecionar tudo o que toca em PHP, MySQL ou nginx, o desempenho ressente-se.

Claro que não desativei o antivírus; o que fiz foi adicionar exclusões.

No Windows:

1. Abre a Segurança do Windows.
2. Entra em Proteção contra vírus e ameaças.
3. Desce até Definições de proteção contra vírus e ameaças.
4. Clica em Gerir definições.
5. Desce até Exclusões.
6. Clica em Adicionar ou remover exclusões.
7. Adiciona exclusões do tipo Pasta.

A pasta importante é a dos sites locais:

C:UsersSEU_USUARIOLocal Sites

E também as pastas internas do Local, que costumam estar em caminhos como:

C:UsersSEU_USUARIOAppDataLocalProgramsLocal

E:

C:UsersSEU_USUARIOAppDataRoamingLocal

No meu caso, excluir Local Sites foi especialmente importante, porque é aí que o site está realmente: WordPress, plugins, temas, uploads e tudo o que o Local está constantemente a tocar.

Depois de adicionar as exclusões, convém parar e arrancar novamente o site a partir do Local WP.

4. Desativar plugins de que não precisava em local

O passo seguinte foi bastante óbvio, mas às vezes esquecemo-nos ou preferimos não o fazer para simular melhor o ambiente de produção.

Há plugins que fazem chamadas externas, tarefas agendadas, verificações de segurança, backups, logs, caches, análise SEO, integrações com newsletters, monitorização, otimização de imagens e mil coisas mais.

Tudo isso em local pode ser desnecessário, dependendo do que estás a testar.

Por isso revi a lista de plugins e desativei os que não precisava para trabalhar naquele momento.

A pergunta era esta: 

Preciso deste plugin ativo para o que estou a fazer agora?

Se a resposta era não, desativava-o.

No meu caso:

1. Plugins de backup.
2. Plugins de Genesis.
3. Plugins de segurança.
4. Plugins de cache.
5. Plugins de analítica.
6. Plugins que lançam tarefas agendadas

Menos plugins ativos significa menos carga, menos processos em segundo plano e menos coisas a competir por recursos.

De qualquer forma, não observei uma grande melhoria aqui, por isso talvez seja melhor deixar este passo para o fim, se todo o resto não for suficiente.

5. Limpar a base de dados a partir da shell do Local

O último passo foi limpar a base de dados.

O WordPress acumula lixo com muita facilidade: revisões, rascunhos automáticos, transients expirados, comentários no lixo, spam, metadados órfãos e restos de plugins.

Para o fazer, abri a shell do site a partir do Local WP:

Local WP > o teu site > Open Site Shell

Antes de limpar, fiz uma cópia de segurança da base de dados:

wp db export backup-before-cleanup.sql

Depois executei este bloco de limpeza:

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

Atenção a uma coisa: isto assume que o prefixo das tabelas é wp_.

Se estás no Windows e essa sintaxe de variável não funciona contigo, usa diretamente o prefixo que for devolvido:

wp db prefix

e substitui-o à mão.

Este passo não é para fazer de ânimo leve em produção. Em local, com backup prévio, sim.

Resultado

Depois destes cinco passos, o Local WP começou a funcionar bastante melhor. Lógico, porque o meu Ryzen 7 2700 Pro com NMVE e 24GB é consideravelmente mais potente do que o servidor de produção.

Por isso tinha claro que valia a pena dedicar um tempinho.

Agora funciona como deve e poupei muitos tempinhos.

O resumo seria:

1. Verificar que o Xdebug está desativado.
2. Mudar o domínio de .local para .test.
3. Excluir pastas do Local WP no Windows Defender.
4. Desativar plugins desnecessários em local.
5. Limpar a base de dados a partir da shell.

Basicamente, tirar peso ao ambiente.

Neste caso, o Local WP não fica lento por uma única causa, mas pela soma de pequenas coisas: resolução do domínio, antivírus a olhar para cada ficheiro, plugins a mais e uma base de dados cheia de restos.

Não medi cada uma com cronómetro, mas sim por sensações. Por isso sei o que funcionou comigo.

Agora tenho a minha cópia local a andar como um foguete, por isso fiquei sem desculpas para trabalhar em produção e não testar.

E tu, continuas a usar a mesma desculpa?