20 passos para você otimizar seu site WordPress

6. Remova os módulos de servidor não utilizados (AVANÇADO/BAIXO)

Desative todos os módulos não usados pelo servidor. Alguns deles são lixo não utilizado de servidor; outros são coisas não utilizadas da distribuição Linux. Pilhas compatíveis com o Apache da ”velha escola” ou painéis de controle não otimizados tendem a ter muitos módulos não usados habilitados por padrão (embora também não habilitem aqueles que você pode precisar).

Leia a documentação e verifique online antes de removê-los ou substituí-los às cegas. O perigo é você desabilitar coisas de que precisa (ou pior, algo que melhora o desempenho). Você deve fazer uma lista de serviços/módulos desativados para referência posterior ou fornecer a um contratante ao solucionar problemas.

7. Use a versão mais recente do PHP (INTERMEDIÁRIO/AVANÇADO)

A versão PHP sozinha faz uma grande diferença, por isso indicamos que:

• Use a última versão do PHP possível (Facilmente configurado a partir de seu painel de controle de hospedagem na web);
• Por exemplo, o PHP 7.0 é 3 vezes mais rápido que o PHP 5.6;
• O PHP 7.3 é 10% mais rápido que o PHP 7.2;
• Desconfie de qualquer webhosts que ainda use PHP antigo.

Manter a versão do PHP do seu site atualizada não é apenas para velocidade, mas também para segurança. O único problema é que alguns temas ou plugins podem não ser compatíveis com a versão mais recente do PHP. Você saberá porque seu site não funciona direito ou parece estranho. Portanto, teste com cuidado e mantenha os temas/plugins atualizados, o que os ajuda a permanecer compatíveis com o PHP mais recente. Confira no blog da SaveinCloud, como proteger o seu site WordPress contra ataques, leia aqui.

8. Configurações recomendadas de php.ini (INTERMEDIÁRIO/MÉDIO)

Algumas pessoas que utilizam hospedagem compartilhada não tem acesso a essas configurações ou dificilmente saberá como configurá-las. Mesmo assim, vamos fazer algumas recomendações.

• max_execution_time – menor (30-60 seg) é melhor para evitar que os excessos de recursos fiquem fora do servidor. Mas você pode precisar de tempos de execução mais altos para processos longos, como importações, exportações, backups.
• max_input_time – menor (60 seg) é melhor. Aumente apenas se você estiver tentando importar algo que leva uma eternidade.
• max_input_vars – defina como “1000”, a menos que alguns plugins precisem de mais.
• memory_limit – tente “256M” para ser seguro. Aumente se você tiver plugins pesados. Gosto de definir mais baixo, então sou notificado imediatamente quando há devoradores de memória. O “error_log” dirá se você precisa de mais.
• zlib.output_compression – pode ou não ajudar. Depende do seu contexto.

9. Use uma versão atualizada do Fork do MySQL (INTERMEDIÁRIO-AVANÇADO/BAIXO)

A maioria das pessoas conhece apenas o banco de dados MySQL, que agora é propriedade da Oracle. Há também MariaDB (um fork do MySQL de seus criadores originais), Percona, e entre outros.

• MySQL 8 é muito melhor que MySQL 5.7. Mas é melhor se você pode usar MariaDB sobre MySQL. Amigável à comunidade e melhor desempenho do que o Vanilla MySQL 5.7.
• Use a versão mais recente do MariaDB  e não utilize o MySQL 5.7.

Quanto a Percona e aos outros garfos compatíveis com MySQL de terceiros, para a maioria dos sites, faz pouca diferença, se houver. Não se esqueça de fazer backup de seu banco de dados antes de alterar ou atualizar o MySQL.

10. Converta tabelas MySQL de MyISAM para InnoDB (INICIANTE/BAIXO)

Certifique-se de que suas tabelas estejam definidas como InnoDB em vez de MyISAM.

InnoDB é mais novo e considerado melhor no quesito geral, principalmente por ser mais rápido e seguro. O MyISAM pode ser mais rápido em alguns cenários, principalmente somente leitura.

Você pode converter manualmente no phpMyAdmin ou usar um plugin (Servebolt Optimizer ou LiteSpeed Cache) e excluir o plugin posteriormente, se você não precisar dele.

11. Ajustando as configurações do MySQL (AVANÇADO/BAIXO)

Normalmente não é necessário (ou visivelmente benéfico) para o site médio, mas pode ajudar tremendamente para sites grandes com alto tráfego e comprimentos de consulta variados.

Você pode executar o MySQLTuner para recomendações gerais ou perguntar à comunidade sys-admin para ver o que todo mundo usa.

Tamanho do buffer e do pacote, cache, conexões, cache, pilha, etc… Estão todos entre os itens gerais a serem ajustados. Confira a Guia Linode simples.

Ao experimentar configurações aleatórias online ou copiar o de outra pessoa, certifique-se de que seu ambiente seja semelhante ao seu. As principais distinções são:

• Tamanho do servidor, recursos disponíveis;
• Quantos clientes / sites no servidor;
• Quantos usuários finais no servidor;
• Quanto tráfego;
• Quão grandes são os sites;
• Que tipo de comportamento de leitura / gravação.

É importante saber se suas configurações são para eficiência (host de alto locatário) ou desempenho agressivo (servidor da web de baixo locatário).

12. Cache de página inteira do servidor (AVANÇADO/ALTO)

O cache de página inteira pode ajudar a acelerar qualquer site. Mas o armazenamento em cache diretamente do servidor é muito mais poderoso e eficiente em termos de recursos do que o armazenamento em cache em nível de aplicativo / PHP feito por meio de um plugin.

• Alguns servidores Apache ou NGINX usam Varnish – desatualizado. Não use proxy Varnish. Basta atualizar para pure-.LiteSpeed ou pure-NGINX stack.
• Os servidores LiteSpeed podem usar o cache LiteSpeed – poderoso, muitos recursos e vem com um plugin de cache WordPress útil, chamado “Cache LiteSpeed”.
• Os servidores NGINX podem usar FastCGI – ótimo, super rápido! Embora não haja um plugin de cache NGINX oficial para WordPress, existem vários plugins “auxiliares NGINX” para facilitar as funções básicas de cache.

Para estar seguro, você deve desabilitar o cache em páginas com formulários, carrinhos ou checkouts. Páginas privadas (para usuários conectados) PODEM ser armazenadas em cache, mas não mexa com isso, a menos que você tenha muito tráfego privado e esteja pronto para passar horas configurando o cache privado.

Você só pode habilitar o armazenamento em cache no nível do servidor se possuir ou tiver acesso ao servidor. Caso contrário, seu host decidirá quais opções de cache você tem.

• A hospedagem compartilhada geralmente permite todos os plugins de cache.
• A hospedagem gerenciada geralmente limita você apenas ao seu proprietário.

13. Cache de objeto de memória (AVANÇADO/BAIXO-ALTO)

O cache de objetos armazena em cache apenas as consultas do banco de dados, em vez de todo o HTML da página. Isso tecnicamente o torna “mais lento” do que o cache de página inteira (já que você não está armazenando em cache a página inteira), mas é útil para acelerar páginas dinâmicas ou páginas privadas (usuários conectados, back-end de administrador) que não podem ser armazenados em cache estático.

Qualquer site com muitos dados constantemente atualizados no front-end, ou muitos números e relatórios no back-end, poderia se beneficiar do cache de objetos.

A maioria dos sites estáticos ou de baixo tráfego não se beneficiariam do cache de objetos; não o use neles pode torná-los mais lentos!

• Redis é o padrão ouro em cache de objetos. É superior ao memcache mais antigo em quase todos os sentidos.
• Memcache é usado apenas em raras situações em que o Redis não funciona ou é mais lento.

Se seus dados não mudam muito, você pode definir tempos de cache de objetos mais longos (por exemplo, 60 minutos e mais). Tempos mais longos significam menos consultas ao banco de dados.

Caso contrário, siga o padrão de 5 a 10 minutos para ficar seguro, caso não se importe que os usuários vejam dados desatualizados.

O cache de objetos pode ser gerenciado por plugins do WordPress. Mas o ideal, se você tiver um plugin de cache para gerenciar o cache de página inteira e o cache de objetos.

Você pode obter um cache de objetos 25% mais rápido usando um Soquete Unix.

Os soquetes UNIX são executados em uma camada de nível inferior no modelo de rede OSI e, portanto, mais rápido do que os soquetes TCP padrão.

• Guias de configuração de soquete UNIX do Redis e Memcache para CentOS;
• Guias de configuração de soquete UNIX do Redis e Memcache para Ubuntu.

Com o soquete UNIX ativado, apenas uma conta de usuário do servidor (e provavelmente todos os sites desse usuário) pode usar o cache de objetos. Portanto, você não pode usar isso se planeja ter vários usuários de servidor implantando o cache de objetos.

Armazenamento em cache de memória

O cache de memória é o padrão ouro em cache, porque o cache é executado mais rápido na memória do que no disco. O problema é que temos quantidades limitadas de memória (a maioria já usada para aplicativos), então não podemos armazenar todo o cache do site lá. De qualquer forma, importa menos hoje em dia, já que os discos do servidor são muito mais rápidos agora graças à tecnologia SSD.

A memória hoje é mais abundante também, mas, novamente, os aplicativos são maiores. Você pode ter ouvido falar de outras pessoas carregando seu site inteiro na memória, usando a rota de cache, outros montando seu diretório WordPress na memória. Funciona muito bem se o seu site for pequeno o suficiente, mas para a maioria das pessoas, sua memória só é grande o suficiente para armazenar consultas de banco de dados. Qualquer outra coisa que você deseja armazenar em cache será armazenada em seu disco.

14. Use o protocolo HTTP mais recente (INICIANTE/ALTO)

HTTP/2 carrega solicitações de navegador muito mais rápido do que HTTP/1, graças à paralelização. 

• Recomandamos o uso do HTTP/2 ou mesmo HTTP/3;
• Evite servidores da web mais antigos ainda no HTTP/1;
• Verifique se há HTTP/2 e HTTP/3 em seu site;
• Usar HTTP/2 requer HTTPS/SSL. Se seu site não estiver em HTTPS, indicamos que realize esta alteração.

15. Codificação de conteúdo (INTERMEDIÁRIO/ALTO)

Todo servidor web deve ter compressão BROTLI. É superior ao GZIP, produz arquivos menores e em menos tempo. Mas, surpreendentemente, o BROTLI ainda não está disponível em todos os servidores da web.

• Se estiver usando BROTLI – defina a compressão estática para 4.
• Se estiver usando GZIP – defina a compactação dinâmica como 1 e a compactação estática como 6.

Você pode aumentar os níveis de compressão estática se sua CPU for forte,  servidor de baixo uso e/ou se o conteúdo estático for armazenado em cache por um longo tempo e com longos períodos de expiração. Se você estiver usando um CDN ou Cloudflare, certifique-se de habilitar a compactação BROTLI lá também.

16. Painel de controle (INTERMEDIÁRIO/ALTO)

Este assunto é importante apenas para usuários VPS. Os painéis de controle costumavam ser avaliados quanto ao peso inicial que colocavam no servidor. Isso porque os painéis de controle foram originalmente projetados para grandes servidores dedicados, mas desde então foram otimizados para VPS menores.

Embora seja verdade que não ter painel de controle é mais leve do que ter um, isso torna as tarefas do dia a dia mais difíceis. Sua pegada agora é insignificante, considerando como os painéis podem ser úteis.

O painel de controle de melhor desempenho é aquele que atende às suas necessidades.

• Permite que você escolha o servidor web – NGINX ou LiteSpeed; 
• Configure facilmente redirecionamentos no nível do servidor – em vez de um plugin de redirecionamento mais lento no nível do PHP.
• Configure facilmente regras de cache granulares – escolhendo o que e o que não armazenar em cache.
• Fácil de gerenciar – para você ou seu administrador de sistema.
• Pode prender usuários – evitando o consumo excessivo de recursos em servidores de alta ocupação.
• Seguro contra hacks – já que as tentativas de hacking consomem muitos recursos.
• Fácil de usar – para você ou seus clientes.

17. Use serviço DNS externo (INTERMEDIÁRIO/BAIXO)

• Latência DNS mais baixa (pequeno benefício);
• Facilidade em atualizar DNS (conveniência).

O uso de um DNS externo como Cloudflare ou DNS Made Easy fará muita diferença em termos de velocidade de hospedagem na web? Nós acreditamos que melhora o tempo de pesquisa, mas não é tão perceptível, a menos que seu servidor DNS anterior fosse tenha sido de baixa qualidade. 

O principal benefício é a rapidez com que você pode redirecionar as coisas. Suponha que você seja hackeado e precise redirecionar por meio de um proxy de segurança. Ou talvez você esteja trocando certos aspectos do seu site para outro servidor. Em momentos como este, ter um serviço DNS é muito conveniente! Você pode mudar as coisas com muito pouco tempo de inatividade e até mesmo voltar rapidamente se houver um problema.

Os serviços DNS podem parecer um incômodo extra para configurar, mas uma vez instalados, eles permitem que você integre novos serviços e mitigue problemas de desempenho muito mais rápido.

18. Execute o WP-cron do seu servidor (INICIANTE/MÉDIO)

Muitas tarefas do WordPress precisam de um gatilho para funcionar. Como enviar e-mails do sistema, executar backups, liberar postagens agendadas. Por padrão, o WordPress usa uma função chamada WP-Cron (convenientemente localizada em yourdomain.com/wp-cron.php).

Esta função funciona verificando e executando as tarefas pendentes sempre que alguém visita o site. É ótimo para sites pequenos, mas terrível se você tiver muito tráfego (acionando muitas verificações cron desnecessárias). Também é uma vulnerabilidade DDOS.

O sensato é desabilitar o WP-cron e usar um cron job real, seja de seu servidor ou de um serviço cron externo. Alguns cron jobs visitam o site diretamente, outros vão até o diretório Linux. Recomendamos que use o que funcionar com um intervalo de 5 minutos.

19. Usuários de enjaulamento e limites de recursos (AVANÇADO/MÉDIO-ALTO)

Você tem muitos sites ou clientes na mesma máquina? Você não consegue policiá-los com eficácia? Se você está perdendo o controle de seus inquilinos, provavelmente é hora de limitar seus recursos. Vou começar com algumas táticas abaixo. 

• Cloudlinux e CageFS – limite o uso de CPU e memória;
• Proibições em todo o servidor de pré-construção de cache, verificadores de link quebrado e outros devoradores de recursos;
• Diminua o tempo de execução do php;
• Configurações globais bloqueando os criminosos usuais, bots, etc.

Na pior das hipóteses, apenas separe alguns clientes em outro servidor. Divida-os por tamanho, uso de espaço, quantidade de tráfego, o que você quiser.

20. Rastreando porcos de recursos (ADV, MED-HIGH)

Frequentemente, encontramos problemas de servidor lento, sem nenhuma pista óbvia de onde procurar. Hoje é esse cliente. Amanhã, é aquele cliente. Parece que qualquer site pode ser o culpado em qualquer dia. Quando você tem tantos clientes, e nenhum deles pode ativar e desativar plugins, é realmente muito difícil rastrear o problema.

Aqui estão algumas ideias:

• Verifique os logs do servidor;
• Verifique os monitores de servidor;
• Uma vez que você sabe qual site é  consulte o log de erros do WordPress.
• Execute o Query Monitor.

Você precisa rastrear o que os usuários ou processos estavam fazendo quando a desaceleração aconteceu.

Às vezes, você precisará de mais mentalidade de desenvolvedor. Qual plugin foi atualizado pela última vez? Algum novo tema ou plugin que foi codificado de forma personalizada? Verifique se há comandos que esgotem a memória. Você pode usar monitores de aplicativos como o New Relic, mas os problemas mais complicados ocorrem quando parece que todo site é o problema ou também quando a carga do servidor é baixa, mas os sites ainda estão lentos.