loader

20 passos para você otimizar seu site WordPress

Ter um site rápido é essencial para a classificação do Google e para a taxa de conversão geral. De acordo com Kissmetrics, 40% dos visitantes do site abandonarão uma página que leva três ou mais segundos para carregar. Anteriormente, a BBC calculou que eles perderam 10% de usuários adicionais para cada segundo extra que seu site levava para carregar.

Para ajudar nossos leitores e clientes a obter resultados de maior velocidade, decidimos publicar um conjunto de artigos dedicados à melhoria do desempenho do site usando ótimas dicas do The Ultimate WordPress Speed Optimization Guide escrito por Johnny Nguyen.

Hoje começaremos abordando a parte de otimização de hospedagem na web. Cada ponto será marcado com o nível de habilidades necessárias para implementação e o impacto que isso trará.

HABILIDADE:

  • INICIANTE – pode pesquisar no Google e seguir as instruções.
  • INTERMEDIÁRIO – trabalhando como contratante de WordPress.
  • AVANÇADO – programador ou administrador do servidor.

IMPACTO:

  • BAIXO – talvez 100-200ms de diferença. Possivelmente imperceptível.
  • MÉDIO – cerca de 500ms de diferença.
  • ALTO – diferença de 1 segundo ou mais.
Otimizar site WordPress
20 passos para você otimizar site WordPress

A velocidade de sua hospedagem na web determina a rapidez com que pode processar o código e quantos visitantes pode atender. Compare seu site com um carro.

Para fazer um carro andar mais rápido, você A) obtém um motor mais forte e / ou B) diminui o peso. Para sites, o servidor web é o “motor” e o código é o “peso”. O objetivo é melhorar o “motor” do nosso servidor web e diminuir o “peso” do código.
Alterar sua hospedagem na web é uma das maneiras mais fáceis de aumentar a velocidade.

Sites mais rápidos ganham mais dinheiro, têm uma classificação melhor e melhoram a experiência geral do usuário!” diz Johnny.

Aqueles de vocês com hospedagem compartilhada barata de US$5/mês irão se beneficiar ao máximo com a mudança para um serviço de hospedagem gerenciada ou até mesmo seu próprio VPS. A diferença será noite e dia sem alterações de site, gerando também economia.

Um servidor rápido pode lidar com mais visitantes do que um lento. Se o seu servidor pode suportar o dobro do tráfego, teoricamente a conta pode ser duas vezes mais barata. Não é grande coisa para um site pequeno, mas que tal um enorme site de comércio eletrônico com uma conta de servidor de US$ 1.000/mês? 50% de redução de custos parece muito atraente!

1. Escolha um Datacenter próximo (INICIANTE/BAIXO-MÉDIO)

Escolha um local de servidor mais próximo dos visitantes. Idealmente, você não quer que o tempo de ping de DNS seja superior a 100 ms do servidor para o computador do visitante. Existem muitas implicações, dependendo de suas necessidades.

  • As empresas locais devem ter um servidor o mais próximo possível de seus visitantes. Mantenha-o dentro de 100ms ou menos, dentro de 50ms é melhor. Verifique os tempos de ping com WonderNetwork;
  • Os EUA estão a cerca de 80ms de costa a costa. Canadá e México também estão próximos;
  • Toda a Europa Ocidental fica a apenas 40-50ms, muito perto;
  • A Ásia está dentro de 80ms entre a maioria dos países;
  • Índia / Paquistão, Austrália / Nova Zelândia, África estão um tanto isolados. As empresas locais precisam de um datacenter local. Mesmo Cingapura à Austrália está na fronteira “distante” pelos padrões DNS (~ 150ms);
  • A América do Sul pode ser uma infraestrutura não confiável. Por esse motivo, muitas empresas na América Central / do Sul ainda usam datacenters baseados nos Estados Unidos, como na Califórnia, Texas ou Flórida (Miami);
  • Se você tiver tráfego mundial (incluindo Ásia / Pacífico) e nenhuma região central em particular, a costa oeste dos EUA pode ser o local perfeito para tráfego rápido para a Europa e Ásia;
  • Se você tiver apenas tráfego dos EUA e Europa e nenhuma região central em particular, a costa leste dos EUA é uma boa alternativa pra tráfego rápido para a Europa.

Também é bom ter uma empresa de hospedagem WordPress na web no mesmo fuso horário de seu público principal. Dessa forma, eles podem rapidamente oferecer suporte ou solucionar problemas quando a maioria dos visitantes está acordada.

Caso pense que um CDN (Rede de Fornecimento de Conteúdo) pode compensar a localização do servidor distante, isso não é necessariamente verdade!

Se está procurando por nós dedicados, o melhor é o datacenter TIER-4 com quatro 9 (99,9999% de garantia de tempo de atividade). Você pode saber mais sobre o assunto por meio da nossa parceira Ascenty, clique aqui.

A calculadora de tempo de atividade mostra que 99,9% de tempo de atividade significa 43 minutos de inatividade por mês.

Conheça as empresas de servidores próximas através do site Nearest.host.

2. Escolha o serviço de hospedagem de site certo (INICIANTE/ALTO)

  • Hospedagem compartilhada (US $ 5-30/mês) – bom para sites pequenos e baixo tráfego de até 100 mil acessos/mês. Sem acesso às configurações do servidor;
  • Hospedagem VPS/nuvem ($ 30-300/mês) – ótimo para sites médios e tráfego de até 30 milhões de acessos/mês;
  • Servidor dedicado (bare metal) ($ 200/mês ou mais) – ótimo para sites grandes com TONELADAS de tráfego.

Compre o melhor que você pode pagar com conforto. Um pequeno site não precisa de muito poder, mas ainda é perceptível quando você obtém um servidor melhor e é mais apreciado do que você pensa. Pense como um novo telefone que abre aplicativos apenas uma fração de segundo mais rápido. Você realmente pode sentir a diferença e melhora tremendamente a experiência do usuário.

  • A hospedagem compartilhada geralmente é lenta porque coloca centenas de clientes/sites no mesmo servidor (maximiza os lucros). Isso aumenta a lentidão, travamentos inesperados ou reinicializações do servidor, ataques à segurança e o IP do seu e-mail sendo marcado como spam.
  • Ambientes de hospedagem compartilhada também são lentos porque carregam muitos scripts/módulos para maximizar a compatibilidade para o maior número possível de usuários. E sem recursos dedicados, seus visitantes acabam esperando na fila enquanto o servidor está ocupado lidando com outros sites primeiro.
  • Os servidores VPS / dedicados são mais rápidos porque há mais recursos disponíveis por conta e seus recursos estão servindo apenas seus sites. Você tem mais controle sobre seu ambiente e pode configurá-lo de acordo com suas necessidades. VPS/dedicado pode ser caro ou difícil de gerenciar para usuários regulares. Existem serviços de painel em nuvem para ajudar a gerenciá-lo e também serviços totalmente gerenciados, onde cuidam de tudo para você.
  • Aqueles incapazes de lidar com as responsabilidades técnicas do VPS podem optar por “hospedagem compartilhada premium”. Eles não sobrecarregam o servidor tanto, mas o desempenho (embora seja melhor do que a hospedagem compartilhada regular) ainda estará muito aquém de um VPS.

3. Escolha um Servidor Web de alto desempenho (INTERMEDIÁRIO-AVANÇADO/ALTO)

Use qualquer software de servidor web, exceto o Apache. O melhor é o NGINX ou LiteSpeed, ou Apache altamente otimizado. Quanto maior for o tráfego, mais notável será a diferença.

  • NGINX brilha em sites simples. Basta configurá-lo e pronto. Não há muitas configurações para otimizar. Mas, uma vez que você tenha um site complicado, o NGINX não é uma boa opção porque alguns recursos do NGINX não são fáceis de configurar. Se você tem um administrador de servidor isso não será um problema.
  • O LiteSpeed possui recursos mais acessíveis do que o NGINX. Como quando você precisa de algumas coisas em cache, mas não de outras, ou lidar com redirecionamentos no nível do servidor via htaccess. O LiteSpeed também possui um plugin de cache do WordPress que o NGINX não possui. Essa é uma vantagem ENORME. 
  • OpenLiteSpeed é a versão da comunidade gratuita do LiteSpeed. É uma ótima alternativa para aqueles que desejam o preço gratuito do NGINX, mas o poderoso plugin de cache LiteSpeed. Você pode saber mais sobre o assunto conferindo o artigo A incrível performance do LiteSpeed para hospedagens WordPress, clique aqui.
  • Alguns webhosts têm a pilha híbrida Apache + NGINX. Eu sinto que eles estão desatualizados agora e tornam a pilha desnecessariamente mais lenta / pesada.
  • Se estiver usando Apache, os eventos MPM são os melhores (em comparação com o trabalhador ou prefork).
  • Mantenha seu servidor web atualizado. Versões posteriores podem acelerar certos protocolos e processos visivelmente.

4. Configuração do Servidor Web (AVANÇADO/MÉDIO-ALTO)

A maioria dos servidores web vem com configurações seguras e funcionais, adequado para o site pequeno/médio com pouco tráfego. É quando você obtém mais tráfego e mais ataques à segurança, ou tem aplicativos mais exigentes que ajustar as configurações faz uma grande diferença.

  • Tempo limite – 30 a 60 segundos é um início seguro. Você pode aumentar até 600 ou mais, se necessário para processos longos (importação, exportação, backups). Lembre-se de que isso permite que processos mal codificados ou exploits de hack esgotem os recursos do servidor.
  • Nº de processos filhos permitidos – depende do ambiente do servidor. O padrão deve ser adequado.
  • Conexões simultâneas permitidas – de 1 a 20k. Mais alto não é necessariamente melhor!
  • Keep alive ligado, desligado ou “smart keep-alive” do LiteSpeed. “Ligado” é mais seguro! Se você tem o LiteSpeed, o smart keep-alive é incrível.
  • Tempo limite para manter ativo – 3-5 segundos é um início seguro. Aumente se necessário.

Quantos threads, tamanho do corpo / buffer, trabalhadores, clientes, etc, tudo que você pode procurar online, depende do tamanho do servidor e do cenário de uso. Entre nos fóruns e pergunte por aí ou peça a um administrador de sistema para configurar para você. Lembre-se de que diferentes administradores têm suas próprias maneiras de configurar.
A distinção mais importante é decidir se este servidor deve ser definido como agressivo ou conservador:

Configuração AGRESSIVA – fornece a cada site tantos recursos quanto possível. Bom para servidores dedicados ou com poucos inquilinos.

Configuração CONSERVATIVA – fornece a cada local o mínimo de recursos possível. Bom para servidores de alta ocupação ou compartilhados.

5. Desative serviços não utilizados (INTERMEDIÁRIO/ALTO)

Muitos servidores são configurados automaticamente com todos os recursos em execução para facilitar as coisas para você. Mas eles são como computadores novos com software pré-instalado. Livre-se daqueles que você não usa. Mesmo que eles não usem muita memória, eles ainda podem ser bombardeados por hackers e isso consome recursos.

  • DNS – desative se você estiver usando um serviço DNS externo. (Cloudflare, DNSME, etc.)
  • E-mail – desative se estiver usando e-mail de terceiros. (G-Suite, MXroute, etc.)
  • FTP/SFTP – desative se não estiver usando.
  • Memcache/Redis – desative se não o usar.
  • Outros serviços – Verniz, Elastipress, etc.

Examine também seu sistema em busca de todas as portas e serviços de escuta e confira também no vídeo abaixo disponível no canal do YouTube da SaveinCloud, quais os impactos negativos de um WordPress com problemas de performance.

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:

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. 

Otimize a velocidade do seu site WordPress com as ferramentas disponíveis na Virtuozzo. Faça um teste na nossa plataforma com 14 dias grátis!

Fonte: Blog Virtuozzo

Todo o conteúdo deste site é de uso exclusivo da SaveInCloud. Proibida reprodução ou utilização a qualquer título, sob as penas da lei. Saveincloud Hospedagem na Internet Ltda – CNPJ 66.925.934/0001-42

Atualização LGPD: Contratos | Políticas