A performance do WordPress é uma parte crítica do gerenciamento de um site. Então, você precisa monitorá-lo para saber a quantidade de visitantes simultâneos, a velocidade de carregamento e se está sempre online. Principalmente porque os dados sobre essas áreas te ajudarão a tomar decisões críticas.

Se você é um parceiro de anúncios da Grumft, seja bem-vindo ao nosso blog. Mas se ainda não é, esperamos que este conteúdo te motive a conhecer nossas soluções exclusivas de programática para publishers, desenvolvedores de aplicativos e anunciantes. Neste artigo, você vai entender quais os gargalos mais frequentes que tornam o WordPress mais lento e aprender como corrigi-los.

Por que se preocupar com a performance WordPress?

Antes de mais nada, você precisa ter em mente que um site rápido pode aumentar a receita de anúncios e a retenção de usuários. No entanto, encontrar os gargalos é apenas o primeiro passo. Em seguida, você precisará corrigi-los. 

Estrutura de dados e algoritmos

Em um ambiente normal, o PHP fornece a funcionalidade, enquanto o MySQL armazena a maioria dos dados no WordPress. Mas existem variantes, como ambientes de hospedagem como Linux ou Windows e servidores web fornecidos pelo Apache, NGINX ou IIS. Eles muitas vezes sofrem das mesmas armadilhas e restrições gerais.

PHP e MySQL

Normalmente, saber que PHP e MySQL são os principais componentes e as áreas onde os problemas geralmente acontecem é suficiente. Uma nova página, itens de menu e tipos de postagem personalizados, são  representados como uma linha no banco de dados. Porém, os dados não contidos nessa única linha também se espalham para outros registros. Isso inclui campos personalizados, taxonomias (tags, categorias, etc), informações do usuário, entre outros componentes não listados de outra forma.

O sistema de arquivos armazena o Código PHP ou imagens, entre outros recursos. Na maioria das solicitações feitas ao seu site (incluindo chamadas AJAX), a maior parte de sua base de código PHP do WordPress, bem como quaisquer plugins ativos e funções de tema, representam a maior parte da carga da CPU em um ambiente de hospedagem.

Exceção

Um site em cache, onde o trabalho é feito apenas periodicamente e a resposta resultante é salva para visitas repetidas (às custas de memória e/ou armazenamento, juntamente com a sobrecarga de gerar essa cópia em cache).

Considerações básicas de performance WordPress

A otimização de desempenho da web não está disponível como uma funcionalidade pronta para uso. Por isso, você precisa estar atento e selecionar cuidadosamente as ferramentas e técnicas para aprimorar a performance do seu site WordPress.

Lazy loading e solicitações assíncronas (“AJAX”)

A maior preocupação em sites monetizados com exibição de anúncios, certamente é a capacidade de resposta percebida. Se uma única solicitação consumir muitos recursos ou tiver um desempenho insatisfatório, você precisa dividir em várias tarefas menores ocorrendo ao mesmo tempo.

Por exemplo

Digamos que uma página da web leva três segundos (3000ms) para responder da seguinte forma:

• 150ms: gera um cabeçalho de página com menus personalizados e informações dinâmicas geradas em tempo de execução;
• 700ms: recupera os campos de postagem e personalizados do banco de dados e usa-os para gerar a estrutura da página;
• 1800 ms: pesquisar no banco de dados todos os eventos (tipo de postagem fictício que representa um evento de calendário) que acontecem depois de hoje, classificá-los e gerar um widget de calendário que os liste;
• 350ms: gera as barras laterais e rodapés, incluindo outros widgets variados e elementos de navegação.

Como você resolve?

Como você pode perceber, o site está levando 1800 milissegundos para produzir o widget Calendário. Se for implausível reduzir o tempo necessário para gerar esse widget, talvez faça mais sentido pular este elemento na primeira passagem e usar o lazy loading após a conclusão da renderização da página. 

Pode ser que essa página fique da seguinte forma:

• 150ms: gera um cabeçalho de página com menus personalizados e informações dinâmicas geradas em tempo de execução;
• 700ms: recupera os campos de postagem e personalizados do banco de dados e usa para gerar a estrutura da página;
• 350ms: gera barras laterais e rodapés, incluindo outros widgets variados e elementos de navegação  (a página terminou de carregar neste ponto [1250 ms], e o usuário pode visualizar seu conteúdo sem widget de calendário);
• 2000ms: solicitação AJAX para pesquisar no banco de dados todos os eventos (tipo de postagem fictícia que representa um evento de calendário) que acontecem depois de hoje, classificá-los e gerar um widget de calendário que os liste.

Como você pode perceber, o tempo total aumentou em um total fictício de 200 ms. Em partes isso ocorre devido a solicitação AJAX separada requer que o servidor carregue toda a base de código PHP novamente. 

Porém, apesar do tempo adicional, certamente o usuário perceberá que o site carrega mais rápido. Na experiência do usuário o site vai responder após 1250 ms e em seguida aparece o Calendário. O usuário praticamente não perceberá o Calendário durante esse período, melhorando sua experiência geral no site.

“Vai e Volta”

“Vai e Volta” descreve o processo de começar a partir de um recurso, consultar outro e trazer os resultados de volta para o primeiro. Cenários incluem solicitações de banco de dados de PHP (uma linha de código executa uma consulta SQL e recupera os resultados) ou um navegador solicitando uma página da Web (uma chamada AJAX ou puxando uma imagem ou outro recurso). 

Devido à sobrecarga necessária para realizar o processo “vai e volta” de um recurso para o outro, estas devem ser tratadas com cautela e feitas apenas quando absolutamente necessárias. É importante que você faça o menor número possível desses processos para um desempenho ideal.

Algumas dessas situações podem ser evitadas ajustando cuidadosamente.

Por exemplo

Considere uma página de arquivo com as 5 postagens mais recentes (um cenário comum no WordPress). Uma abordagem para isso pode ser identificar primeiro as postagens são as 5 mais recentes e, em seguida, para cada uma, retornar ao banco de dados e solicitar os detalhes sobre cada postagem (6 viagens de ida e volta ao banco de dados). Uma abordagem mais limpa seria uma única consulta SQL que enumera as 5 postagens mais recentes e retorna todas as informações sobre elas em sua resposta (fazendo uma única viagem de ida e volta). Essa resposta será maior em tamanho do que as solicitações individuais separadamente, mas deve ser consideravelmente mais rápida a longo prazo.

Ajax

Considere a mesma coisa ao tornar uma página pesada em AJAX. Cada solicitação (também considerada um “thread” neste contexto) pode ser executada simultaneamente, ou o servidor pode ver a ordem em que foram solicitadas e colocá-las em uma fila. O desempenho do servidor nessas condições depende muito de sua configuração (um núcleo de CPU ou muitos, o modelo de encadeamento do servidor web etc.).

Isso é agravado pela quantidade de sobrecarga de dados (cabeçalhos HTML, quadros Ethernet) gerados por cada solicitação que precisa ser tratada, bem como pela sobrecarga de processamento no servidor para cada uma dessas solicitações. Assim como na consulta ao banco de dados, frequentemente há oportunidades para agrupar as coisas para aumentar a eficiência, mas isso deve ser equilibrado em relação ao tempo de execução percebido. Em outras palavras, estamos vendo o outro lado da moeda de carregamento lento.

Não existe verdade absoluta, pois cada situação deve ser avaliada individualmente. Porém, um programador menos experiente pode não identificar isso como uma área de preocupação e, portanto, ignorá-la ao ajustar o desempenho.

Cache

Como já dissemos aqui, o PHP é uma linguagem interpretada e o código é avaliado em tempo de execução. Isso pode ser afetado por “includes” de dentro do código.

Por exemplo

O WordPress pode usar condicionalmente um arquivo PHP em uma situação, mas não em outra, e, portanto, o tamanho do seu código pode diferir com base na natureza da solicitação. 

Isso é ainda mais evidente nos plugins do WordPress, que são bases de código PHP que são carregadas dinamicamente quando presentes e ativas. Devido a isso, ativar um plugin mal codificado pode ter um efeito devastador no desempenho.

Além disso, se o conteúdo do site não for alterado com frequência e for consistente por longos períodos de tempo, cada consulta no banco de dados continuará retornando os mesmos dados das vezes anteriores em que foi solicitada.

Embora um sofisticado sistema de gerenciamento de banco de dados relacional (RDBMS) tal vez perceba que os dados não foram alterados desde a última solicitação e retorne uma cópia em cache, é mais seguro supor que ele deve executar o mesmo trabalho toda vez que fez pela primeira vez por aí.

Quando utilizar cache

Em tais situações, pode ser ideal implementar uma ou mais camadas de cache. Eles podem ser implementados de várias maneiras e, embora não seja viável considerar todas as situações.

Dados de terceiros

Uma situação frequentemente encontrada é o uso de uma API ou fonte de dados de terceiros. Isso acontece de diversas formas, como feeds de eventos iCal, feeds RSS, integração com Facebook ou Twitter, CRM de terceiros, etc. O fluxo de trabalho para essa integração pode ser semelhante a:

1. Solicitações de usuários do seu site
2. Seu site recebe a solicitação
3. Seu site faz uma solicitação à API de terceiros
4. A API de terceiros responde
5. Seu site processa a resposta
6. Seu site responde ao usuário

No cenário acima, metade das etapas (3 a 5) representam o trabalho necessário para lidar com a integração de terceiros. Considere o assunto do ponto de vista geográfico ou logístico; o usuário pode estar em Salvador, BA, mas seu site pode estar hospedado em São Paulo, SP, e o aplicativo de terceiros pode estar hospedado em Toronto (Ontário, Canadá).

Por exemplo

Supondo um salto teórico de 60ms entre cada um desses pontos e uma única solicitação/resposta necessária para realizar qualquer comunicação entre dois pontos, um “vai e volta” seria mapeada para:

1. Salvador para São Paulo (passos 1, 2): 60ms
2. São Paulo a Toronto (passo 3): 50 ms
3. Toronto a São Paulo (etapa 4): 50 ms
4. São Paulo para Salvador (passo 6): 60ms

O exemplo acima chega a um total de 220 ms. Se o aplicativo de terceiros for removido do processo, o número cai para 120 ms (quase metade do tempo). Na realidade, qualquer um desses números pode flutuar rapidamente, pois o número de sequências de “vai e volta” necessárias entre dois pontos pode aumentar conforme a situação exigir. 

Handshaking, autenticação e a natureza da carga de trabalho podem ser combinados para aumentar o número de viagens necessárias para concluir o processo. Além disso, em cada terminal, assume-se que algum processamento é necessário para compreender os dados que estão sendo distribuídos. Por isso, tudo pode ficar mais lento se algumas precauções não forem tomadas pensando em como essas trocas são executadas.

Uma fonte de dados de terceiros bastante estática, como um feed RSS, pode precisar ser solicitada apenas uma vez por dia. Trabalhando com essa suposição, se os resultados da primeira solicitação deste tipo fossem armazenados em cache por essa duração, você pode evitar a sobrecarga e o atraso envolvidos na solicitação para solicitações subsequentes. Assim, no cenário fictício acima o comportamento conforme descrito para a primeira solicitação (ida e volta de 220 ms), e cada solicitação adicional omitiria a solicitação de terceiros (caindo para o valor de 120ms).

Otimização de RDBMS

Um DBA (administrador de banco de dados) geralmente analisa as consultas solicitadas com frequência ou de bloqueio de recursos que tornam o sistema lento e, dessas consultas, derivam índices ajustados com precisão. Uma boa indexação vai muito além do escopo desta narrativa, mas se as consultas complexas estiverem funcionando mal, pode ser útil ter um especialista em banco de dados profissional para fazer alguns perfis.

Isso muitas vezes se tornará um problema para um grande site que acumulou milhares de páginas, onde identificar gargalos torna-se muito mais difícil. Os índices podem ter um efeito negativo nas operações de gravação, mas quando bem projetados, melhoram consideravelmente as operações de leitura (que é o objetivo final).

Além disso, como uma tabela teve várias operações (INSERT/UPDATE/DELETE) executadas nela, as coisas ficaram confusas. Isso depende muito do modelo de armazenamento usado, mas a otimização de tabelas geralmente ajuda um banco de dados com desempenho insatisfatório como resultado de manutenção inadequada.

Cache de código operacional

O site como um todo também pode ser armazenado em cache usando um cache de código operacional. Essa ferramenta depende da plataforma e requer que certas extensões PHP estejam instaladas para funcionar corretamente, mas se essas condições forem atendidas, você poderá utilizar um plugin de cache do WordPress.

Muitos desses plugins também podem tentar armazenar recursos em cache (incluindo hospedagem CDN para recursos maiores, como vídeos ou imagens). O resultado final deve ser que, independentemente do plugin escolhido, a experiência do usuário final seja consideravelmente melhorada do ponto de vista da capacidade de resposta percebida.

Ressalvas

Mas isso não vem sem ressalvas, pois como acontece com outras estratégias de armazenamento em cache, haverá um impacto no desempenho na primeira tentativa (o trabalho que teria ido para a solicitação original, juntamente com o trabalho adicional necessário para construir a cópia em cache). Além disso, essa abordagem pode não ser sensível o suficiente para perceber quando os dados que suportam a cópia em cache foram alterados e usuários poderão experimentar uma cópia obsoleta e desatualizada do seu conteúdo.

Ao fazer qualquer modificação em seu site, esquecer esse fato pode ser um ponto de frustração significativa quando você não vê nada acontecer. Às vezes, os requisitos de recursos para armazenamento em cache podem ser difíceis de suavizar. Haverá maiores requisitos de memória e armazenamento, dependendo da estratégia de armazenamento em cache e a carga da CPU durante a solicitação inicial será aumentada. Se um usuário encontrar uma parte do seu site que não foi acessada recentemente e o cache precisar ser construído, isso possivelmente não irá agradar.

Porém, essa é a maneira mais fácil de obter melhorias visíveis na capacidade de resposta de um site. Mas esta não é uma abordagem para ocultar defeitos na programação do site, pois o primeiro visitante (ou o primeiro em muito tempo) de qualquer página ou consulta em particular, sofrerá todas as consequências negativas.

Hospedagem

Você pode otimizar o tempo de resposta do seu servidor e reduzir o tempo até o primeiro byte (TTFB) seguindo algumas etapas:

1. Fale com seu host e pergunte se eles podem ajudar a baixar o site. Muitas vezes, os provedores de hospedagem podem ajustar suas configurações para que seu site carregue mais rápido.
2. Se você usa o CloudFlare CDN habilitado, fale com a equipe de suporte e também pergunte se é possível fazer alguns ajustes para o site carregar mais rápido
3. Por fim, elimine dados antigos do seu banco de dados.

Ter um bom plano de hospedagem é muito importante e na maioria das vezes deve ser o primeiro passo para fazer seu site carregar mais rápido. Os sites WordPress se beneficiam muito de hospedagem otimizada. Existem certas configurações técnicas que as empresas de hospedagem podem fazer que permitem que o WordPress carregue mais rápido se o plano de hospedagem for focado apenas no WordPress. 

Se você tem uma empresa de hospedagem genérica que permite instalar todos os tipos de sistemas de gerenciamento de conteúdo, essas otimizações provavelmente não estarão disponíveis. No caso de sites que a principal estratégia de negócios é gerar renda, a hospedagem é um bom lugar para investir.

Tema do site

Outro gargalo comum é o tema que você está usando. Os temas controlam o design do seu site e a qualidade do código varia muito. Existem temas do WordPress que se concentram em ser super-rápidos e temas que têm muitos recursos, mas prejudicam a velocidade de carregamento.

Se você achar que seu tema adiciona vários itens de menu ao seu menu WP Admin que você não usa, seu tema pode ser otimizado. Converse com um desenvolvedor sobre a reconstrução do site com um tema mais adaptado para a velocidade de carregamento. Muitas vezes é simples manter o design ao reconstruir um site WordPress com um novo tema.

Além disso, verifique as solicitações individuais e veja se elas têm “wp-content/themes/” em seu URI. Se encontrar, seu tema está gerando essa solicitação.

Como corrigir

Se você perceber que seu tema causa muitas solicitações, há algumas etapas que você pode seguir para corrigi-lo (execute uma nova análise de velocidade depois de executar cada etapa e verifique se você tem um backup):

1. Instale um plugin de cache.
2. Ative a minificação e a combinação de arquivos para arquivos CSS e JS. Tenha cuidado aqui e certifique-se de testar o front-end do seu site após esta etapa. Especialmente combinar arquivos CSS ou JS pode quebrar seu layout.
3. Use o plugin de cache para carregar arquivos JS de forma assíncrona ou estenda seu tema para carregar JS async/deferred .

Neste ponto, você pode estar se perguntando quais arquivos carregar de forma assíncrona. O PageSpeed ​​Insights mostra exatamente em quais arquivos você deve trabalhar. Verifique a sugestão no relatório “Eliminar recursos de bloqueio de renderização”:

Se você ainda não executou essas etapas, isso provavelmente vai corrigir um gargalo comum. As três etapas descritas acima não apenas corrigem os arquivos do seu tema, mas também abordam os arquivos de plugin. Especialmente quando você habilitou a minificação de arquivos, começou a carregar arquivos selecionados de forma assíncrona e começou a combinar arquivos CSS/JS, seu site deve carregar razoavelmente mais rápido.

Plugins

Depois de seguir os passos descritos acima para otimizar o tema, você precisa analisar os plugins que estão sendo utilizados. Para descobrir gargalos de plugins, verifique com sua empresa de hospedagem se algum plugin está ocupando mais recursos do servidor do que outros. Um bom host poderá verificar se algum plugin em seu site está deixando o servidor mais lento.

Plugins para mostrar posts relacionados, plugins de segurança que verificam seu site em busca de malware, entre outros, geralmente são muito pesados. A forma mais rápida de verificar se um determinado plugin está deixando seu site lento é copiar seu site para uma versão de teste e depois desativar um plugin após o outro. Após cada desativação, execute os relatórios de análise de velocidade novamente. Os números mostrarão qual plugin causa lentidão.

Google Bot

Outro gargalo que muitas vezes é negligenciado é a frequência com que bots como o Google Bot (ou bots de outros mecanismos de pesquisa) visitam seu site para indexar seu conteúdo. Eles podem sobrecarregar o servidor quando visitam seu site com muita frequência, portanto, se for esse o caso, convém reduzir a frequência de rastreamento.

Tarefas de manutenção para manter seu site rápido

Por fim, deixe-me mencionar algumas tarefas de manutenção que você deseja realizar regularmente para manter seu site funcionando sem problemas e carregando rapidamente:

• Mantenha seu núcleo, temas e plugins do WordPress atualizados;
• Elimine plugins e temas não utilizados de sua instalação;
• Limpe regularmente seu banco de dados com WP Sweep ou plugins semelhantes;
• Descarregue tarefas como backups e segurança para serviços de terceiros executados em seus próprios servidores e não no seu;
• Tenha cuidado ao usar suítes de plugins ou plugins grandes.

Pensamentos Finais

Em resumo, garantir que seu site tenha uma classificação alta, ótimos lucros e forneça uma excelente experiência ao usuário e funcione sem problemas, mantendo a otimização de velocidade é fundamental. Por isso, você precisa estabelecer uma base sólida para o seu site e mantê-lo limpo para que ele prospere com sucesso.

Para alcançar bons resultados, você precisa estar familiarizado com o WordPress, conseguir identificar gargalos e entender como tudo está conectado. Acima de tudo, conte com a Grumft para apoiá-lo nessa jornada.