loader

Como deixar seu site em WordPress mais rápido

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.
“Sites mais rápidos ganham mais dinheiro, têm uma classificação melhor e melhoram a experiência geral do usuário!” diz Johnny.
Hoje começaremos com 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.
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, ok? Alterar sua hospedagem na web é uma das maneiras mais fáceis de aumentar a velocidade. 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. A diferença não é apenas velocidade, mas também uma questão de custo (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! Otimize a velocidade do seu site WordPress com as ferramentas disponíveis na Jelastic. Faça um teste na nossa plataforma com 14 dias grátis.  

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

Obviamente, você deve escolher 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, gosto da costa oeste dos EUA como 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… Gosto da costa leste dos EUA para tráfego rápido para a Europa.
Também é bom ter uma empresa de hospedagem 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.
  • Aqueles de vocês pensando que um CDN (Rede de Fornecimento de Conteúdo) pode compensar a localização do servidor distante (isso não é necessariamente verdade!)
Aqueles de vocês que procuram nós dedicados… O melhor é o datacenter TIER-4 com quatro 9 (99,9999% de garantia de tempo de atividade). Mas boa sorte em conseguir isso garantido!
  • Calculadora de tempo de atividade (99,9% de tempo de atividade significa 43 minutos de inatividade por mês)
  • Nearest.host – site legal mostrando as empresas de servidores próximas.

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 (raro de encontrar). 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 é um saco misturado. Alguns recursos do NGINX não são fáceis de configurar. Se você tem um administrador de servidor para ajustar, é ótimo, mas muitas pessoas não.
  • 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. (Eu pessoalmente prefiro o LiteSpeed.)
  • 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.
  • 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/funcionais logo de cara. 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. Eu acho que “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 para mim é 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.
Se você deseja ter “TOC”, examine seu sistema em busca de todas as portas e serviços de escuta.

6. Remova os Módulos de Servidor não Utilizados (AVANÇADO/BAIXO)

Quer ser ainda mais “TOC”? 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.
  • 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.
  • Até o PHP 7.3 é 10% mais rápido que o PHP 7.2.
  • No momento em que este livro foi escrito, o PHP 7.4 estava disponível.
  • 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

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

A maioria de vocês (em hospedagem compartilhada) nem mesmo terá acesso a essas configurações ou saberá como configurá-las. Mesmo assim, aqui estão minhas 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. Eu deixo isso fora.

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

A maioria das pessoas conhece apenas o MySQL, que agora é adquirido/propriedade da Oracle. Há também MariaDB (um fork do MySQL de seus criadores originais) e Percona, 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 que puder.
  • Faça o que fizer, apenas não use MySQL 5.7.
E quanto a Percona? E quanto 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 geral (mais rápido, mais seguro).
  • MyISAM pode ser mais rápido em alguns cenários (quando principalmente somente leitura).
  • Você pode converter manualmente no phpMyAdmin ou usar um plugin (Servebolt Optimizer ou LiteSpeed Cache). Pode excluir o plugin posteriormente, se você não precisar dele.
Otimize a velocidade do seu site WordPress com as ferramentas disponíveis na Jelastic. Faça um teste na nossa plataforma com 14 dias grátis.  

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, tamanho do pacote, cache, conexões, cache, pilha, etc… Estão todos entre os itens gerais a serem ajustados
  • 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 (como limpeza).
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, backend 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 agora. É 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 … a menos que você não se importe que os usuários vejam dados desatualizados.
  • O cache de objetos pode ser gerenciado por plugins do WordPress. Mais 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.
  • Nota: 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.
Algumas informações básicas sobre 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). Claro que a memória é mais abundante agora também, mas, novamente, os aplicativos são maiores. Você pode ter ouvido falar de outras pessoas carregando seu site inteiro na memória … alguns 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). Parece 3 vezes mais rápido para mim.
  • Você deve usar HTTP/2 ou mesmo HTTP/3 (lançado recentemente).
  • Evite servidores da web mais antigos ainda no HTTP/1 arcaico.
  • 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, faça isso agora!

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

GZIP é tão 2016. Todo servidor web deveria ter compressão BROTLI hoje em dia. É 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 (ou servidor de baixo uso) e/ou se o conteúdo estático for armazenado em cache por um longo tempo (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 de sua escolha – 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? Acho que melhora o tempo de pesquisa, mas não é tão perceptível, a menos que seu servidor DNS anterior fosse um lixo de um host barato. O principal benefício para mim é a rapidez com que posso 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). Ele 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 óbvia. 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. Use o que funcionar. Acho que um intervalo de 5 minutos é bom.

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. Você procura o resto.
  • 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 idéias:
  • Verifique os logs do servidor – você está sendo hackeado? Existem pedidos excessivos?
  • Verifique os monitores de servidor – quais usuários estão consumindo CPU, memória e largura de banda?
  • Uma vez que você sabe qual site é… Verifique o log de erros do WordPress. Execute o Query Monitor.
  • Claro, pode nem acontecer o tempo todo. 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.) Sim, você pode usar monitores de aplicativos como o New Relic, mas para mim, é um exagero. 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. Boa sorte! Fonte Otimize a velocidade do seu site WordPress com as ferramentas disponíveis na Jelastic. Faça um teste na nossa plataforma com 14 dias grátis.  

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Open chat