Quando o assunto é desempenho da web, o cache do WordPress é mais uma daquelas coisas que qualquer proprietário de um site tem de enfrentar mais tarde ou mais cedo. Adoramos o WordPress, mas não são todas as plataformas que são rápidas, especialmente se a comparar com um site estático. Uma razão para isso é estar construído sobre PHP, cuja velocidade de execução é limitada. Notámos algumas grande melhorias com o PHP 8.0 e PHP 8.1, mas se o seu cache não for o apropriado, o seu site vai sentir dificuldades.
Não seria ótimo não ter de se preocupar com ter de saber que plugin de cache é o melhor? Bom, aqui na Kinsta, cuidamos do cache por você, assim pode colocar seu foco no crescimento dos seus negócios.
O que é cache WordPress?
O cache é o processo que permite armazenar recursos de um pedido e reutilizar esses mesmos recursos para pedidos posteriores. Basicamente isso reduz a quantidade de trabalho necessário para gerar uma visualização de página.
Por que você deve usar o cache? A explicação é simples, o cache torna os websites WordPress mais rápidos e reduz a carga colocada sobre o servidor web. É por isso que cada site deve fazer todos os esforços para usar tanto cache quanto possível. Além disso, no caso de armazenamento em cache de CDN, isso também reduz a quantidade de largura de banda necessária para gerar uma visualização de página, ao armazenar recursos estáticos externos ao seu host WordPress.
Com a Kinsta não é necessário plugins de cache
Você leu bem! Se hospedar seu site WordPress na Kinsta, você não precisa de se preocupar em lidar com plugins de cache confusos e complicados. Já temos diferentes tipos de cache implementados. Pode deixar de recorrer ao Google para buscar os “melhores plugins de cache de 2024”, colocando ao invés disso o seu foco em tarefas mais produtivas.
Na Kinsta utilizamos esses quatro tipos de cache, que são todos executados automaticamente no software ou no servidor:
Muitos dos nossos clientes relatam enormes reduções nos tempos de carga simplesmente ao migrar para Kinsta. Abaixo está um exemplo de um site que viu um aumento de 212,5% no desempenho. E isso sem nenhum plugin de cache instalado.
Existem outras variáveis envolvidas no tempo de carregamento que também são diminuídas, mas o cache é extremamente importante. Não estamos afirmando que todos os plugins de cache são ruins, na verdade o problema reside na má configuração do plugin por parte do usuário, que desacelera o seu site WordPress. Você já tentou configurar o W3 Total Cache? Ele pode ficar bem confuso rapidamente.
Não confie apenas em nossa palavra
E no que diz respeito ao desempenho, não confie somente na nossa palavra, confira alguns desses testemunhos de pessoas que migraram para Kinsta. Todos deixarem de utilizar plugins de cache.
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
@TheSportReview's new @Googlecloud based @kinsta environment handled the post-match @ManUtd v @ChelseaFC traffic spike in style 👌⚽ pic.twitter.com/kJewykSqaV
— Martin Caparrotta (@MartinCap) April 16, 2017
60%+ drop in @pingdom load times for @voompla after move to @kinsta + @CloudFlare CDN + site optimization! support by @tomzur @MarkGavalda
— Palash Bakshi (@ppbakshi) September 11, 2016
Tipos de cache do WordPress
Agora vamos ver em detalhe cada tipo de cache WordPress que encontrará regularmente na Kinsta. Compreender cada camada de cache irá ajudar você a solucionar problemas relacionados com o cache e garantir que o seu site funciona sem problemas.
Cache de Bytecode
O cache de Bytecode armazena código PHP para que a etapa de compilação possa ser pulada da próxima vez que ele for utilizado. Na Kinsta, ativamos o OPcache no PHP 8.0 e 8.1 (e irá permiti-lo nas versões mais recentes do PHP à medida que são lançados na nossa plataforma).
Atualização: PHP 8.1 (versão oficial) está agora disponível para todos os clientes Kinsta. O PHP 7.4 não é mais suportado na Kinsta. Por favor, note que somente suportamos as versões 8.0, 8.1, 8.2 e 8.3 do PHP.
Quando um arquivo ou script PHP é processado, ele primeiro tem de ser compilado em opcode legível por máquina. Aquilo que o OPcache faz é armazenar o opcode convertido para que o PHP seja capaz de pular a etapa de compilação da próxima vez que um determinado arquivo ou script for necessário. Utilizar o OPcache melhora significativamente o desempenho do PHP. Mas isso significa que alterações nos arquivos PHP não são imediatamente refletidas. Por essa razão, o OPcache é desativado nos sites de testes WordPress da Kinsta.
Leia mais sobre como o OPcache acelera as aplicações PHP.
Cache de Objetos
O cache de objetos armazena os resultados das consultas à base de dados, para que esse bit de dados em particular possa ser prontamente entregue através do cache, sem consultar a base de dados. Isso agiliza o tempo de execução do PHP e reduz a carga no seu banco de dados de WordPress.
O WordPress tem um cache de objetos integrado: WP_Object_Cache. Contudo, esse cache de objetos apenas armazena objetos para um carregamento de página. O objetivo do cache é garantir que o banco de dados não é consultado exatamente da mesma maneira várias vezes durante um carregamento de página. Contudo, os objetos guardados em cache não são utilizados depois desse carregamento de página. Apesar de esse ser um recurso útil no WordPress, o cache de objetos é muito mais poderoso se for utilizado entre múltiplos carregamentos de páginas.
Você pode alterar esse comportamento e reutilizar os objetos guardados em cache para vários carregamentos de página ao mudar do cache de objetos incorporado no WordPress para uma solução externa. Isso é executado colocando um script de cache no diretório /wp-content/. Existem opções de cache de objetos baseadas em plugins como o W3 Total Cache.
Os nossos clientes Kinsta também podem comprar a extensão do Redis e fazer a sua instalação com o PHP 7.2, 7.3 ou 7.4. O Redis é um armazenador open source de estrutura de dados, utilizado como base de dados, cache e corretor de mensagens. Confira nosso artigo sobre como usar o Redis como um cache de objetos persistente se você deseja saber mais.
Cache de Páginas
O cache de páginas armazena todo o HTML de uma página para que as subsequentes visualizações de página possam ser geradas sem que o WordPress tenha de gerar essa página.
Quando você carrega um site WordPress, o WordPress tem de processar um grande número de arquivos PHP e consultar o banco de dados várias vezes. Para páginas que não são constantemente atualizadas, esse esforço representa um desperdício. É muito mais eficaz gerar cada página apenas uma vez, armazenando depois essa página e mostrar ela para os visitantes seguintes. É isso que faz o cache de páginas.
As vantagens do cache de páginas inclui:
- Carregamentos de páginas muito mais rápidos.
- Redução drástica dos carregamentos do servidor e consequentemente o aumento da capacidade de lidar com muito mais tráfego.
Nossos servidores usam o nginx fastcqi cache module para o cache de páginas, e está configurado para expirar a cada 1 hora por padrão. Entretanto, os clientes podem alterar a expiração do cache de páginas a qualquer momento no painel de controle MyKinsta. Para alterar o tempo de expiração do cache de página, vá para a página “Ferramentas” de seu site, clique no menu suspenso “Modificar” em “Site Cache”, e clique em Alterar Expiração do Cache.
No modal ” Alterar Expiração do Cache”, selecione o tempo de expiração desejado e clique em Alterar Expiração do Cache. Nós fornecemos opções de 1 hora a 7 dias. Para sites que não mudam com frequência, pode ser benéfico em termos de desempenho ter um prazo de validade de cache mais longo.
O cache de páginas é configurado para funcionar imediatamente com os sites padrão WordPress, BuddyPress, WooCommerce, e Easy Digital Download. Isto significa que páginas como o painel do WordPress, carrinhos de compras WooCommerce, fóruns BuddyPress para usuários logados, e mais são automaticamente contornadas do cache de páginas. Se você estiver usando uma configuração WordPress altamente personalizada, podem ser necessárias outras personalizações nas configurações do cache de páginas, e nossa equipe de suporte pode auxiliá-lo com isso.
Por padrão, o cache de páginas é desativado nos sites de teste Kinsta. Em alguns casos, a ativação do cache de páginas na fase de testes é útil para fins de teste. O cache de páginas para sites de teste pode ser ativado no painel do MyKinsta.
Cache de CDN
O cache da CDN armazena arquivos (como arquivos JavaScript, CSS e arquivos multimédia) em uma rede de fornecimento de conteúdo para os entregar mais rapidamente a usuários que estão geograficamente distantes do local do host do servidor. Quando alguém tenta entrar em um site, esses arquivos são entregues com base na CDN em vez de utilizar o servidor que hospeda o site. Leia mais sobre o porquê de dever usar uma CDN.
Uma rede de fornecimento de conteúdo (CDN) tem duas vantagens principais:
- Reduz os recursos do servidor necessários para carregar um site. Quando a CDN está fazendo o trabalho, o servidor web não precisa de ser usado.
- Permite entregar os recursos a partir de locais em todo o mundo, acelerando o desempenho do website para os usuários que estão geograficamente distantes do servidor que hospeda o site.
Existem dois tipos básicos de CDN: aquelas que são CDN simples e aquelas que oferecem uma CDN e recursos de segurança. Alguns exemplos comuns para ambos incluem:
- CDN padrão: Stackpath, CloudFront.
- CDN mais segurança: Kinsta CDN (Cloudflare), Sucuri, Akamai (opcional).
O primeiro tipo de CDN é definido com a criação de URLs de CDN, que são utilizados para aceder aos recursos do site. A forma exata como acontece essa ativação varia entre CDN. A ideia-chave é que os URLs para recursos estáticos serão alterados para o URL da CN, garantindo que os recursos são extraídos a partir da CDN. Uma CDN padrão normalmente armazena somente arquivos estáticos, como JS, CSS e arquivos de multimédia.
O segundo tipo de CDN serve como um servidor proxy completo. Isto significa que cada solicitação tem que atravessar os servidores do provedor antes de chegar aos servidores da Kinsta. Isto é habilitado usando os servidores de nomes do provedor CDN, para que o provedor CDN tenha o controle total do DNS do site. Isto permite que o provedor faça muitas coisas que um simples CDN não pode fazer, tais como filtrar o tráfego de IPs ruins, oferecer proteção DoS/DDoS, ou mesmo armazenar um cache de página completo no CDN. Nosso Kinsta CDN é alimentado pelo Cloudflare, um serviço de proxy de desempenho/segurança.
Cache de CDN avançado
Se estiver usando um servidor proxy CDN, como o Cloudflare ou Sucuri, você tem a capacidade de criar um cache de páginas completo na CDN. O uso de uma CDN como o Cloudflare ou o Sucuri para fazer o cache de páginas HTML inteiras diminui totalmente o trabalho dos nossos servidores e é uma ótima solução para um site que espera ver um grande aumento no tráfego.
- Sucuri configura um cache de página inteira se o nível de cache estiver ajustado para ser “Ativado”.
- O Cloudflare exige a configuração de regras de página para que o cache de página completa funcione. As regras devem utilizar um nível de cache “Cache Everything”.
Cabeçalho de resposta de cache da Kinsta
Você pode fazer um teste para verificar se sua página está sendo disponibilizada através do cache da Kinsta ao verificar os cabeçalhos HTTP de resposta. Kinsta adiciona um cabeçalhoX-Kinsta-Cache Após a primeira solicitação de uma página em cache, ele exibirá MISS, como mostrado abaixo.
Após o segundo pedido à mesma página, o valor do cabeçalho X-Kinsta-Cache mostrará um HIT,o que significa que ela está sendo disponibilizada a partir do cache.
E se você ler o nosso artigo sobre pontuar 100/100 no Google PageSpeed Insights, ficará sabendo que Kinsta também tem otimizações adicionais no nível de servidor para corrigir automaticamente os seguintes avisos que você já deve conhecer:
- Ativar Compressão (Kinsta já habilita o Gzip em todos os servidores, sem necessidade de ativação)
- Reduz o tempo de resposta do servidor (Kinsta já é muito rápido, bem dentro dos parâmetros aceitáveis do Google, sem quaisquer otimizações)
- Expirar Cabeçalhos (Não é necessário já que Kinsta tem cabeçalhos de cache habilitados no nível do servidor)
Por exemplo, o nosso site de testes pontua 100/100 no PageSpeed Insights sem quaisquer plugins de cache habilitados. O cache do WordPress é inteiramente gerenciado pela Kinsta no nível do servidor.
Configurações de cache da Kinsta
Você pode estar pensando sobre como controlar o cache na Kinsta. Haverá momentos em que precisará de limpar o cache. Você tem várias opções. Você pode limpar o cache no painel do MyKinsta ou utilizar o Kinsta MU Plugin.
Limpando o cache do WordPress
Para limpar manualmente o cache da página inteira, você pode fazer isso dentro do painel MyKinsta. Basta entrar no seu site, clicar em Ferramentas e no botão “Limpar Cache”.
Por padrão, o cache é desativado nos ambientes de teste da Kinsta WordPress. Se você quiser testar a funcionalidade de cache de página em um site de teste, você pode ativar o cache usando a ferramenta ” Cache do site” no painel do MyKinsta. Depois que o cache estiver habilitado para um ambiente de teste, você pode usar o botão “Limpar Cache” para limpar o cache, assim como o ambiente de produção.
Kinsta MU Plugin
A segunda opção é utilizar o Kinsta MU Plugin. O quê? Sim, tecnicamente é um plugin de cache, mas não é o seu típico plugin de cache, já que ele opera no nível do servidor.
Por padrão, Kinsta MU plugin instalado em cada site hospedado por nós e está disponível no lado esquerdo do seu painel de administrador WordPress. É utilizado para limpar inteligentemente o cache nas páginas apropriadas do seu website. O plugin é necessário para garantir que o seu site funciona corretamente no nosso ambiente. Além disso, você deve lembrar que o cache de página expira a cada 1 hora por padrão.
O plugin também permite que você limpe o cache diretamente a partir da sua barra de administração WordPress. Essa seria provavelmente uma das melhores razões para utilizá-lo, já que não precisará de ir diretamente no painel MyKinsta. Você pode fazer isso no seu site.
Também lhe permite configurar as regras de cache personalizado. Dependendo da configuração do site, regras adicionais de cache podem ser necessárias. Você pode adicionar caminhos personalizados para fazer uma limpeza sempre que seu site é atualizado.
Você também pode entrar em contato com nossa equipe de suporte se precisar de uma determinada página ou URL excluída do cache.
Kinsta Staging Environment
Por padrão, os ambientes de teste na Kinsta têm o cache de página desativado. Isto facilita o desenvolvimento e a depuração do seu site WordPress sem a necessidade de limpar manualmente o cache após cada edição. Em alguns casos, você pode querer ativar o cache de páginas em um ambiente de teste para executar um teste de velocidade preciso para uma página em cache, sem precisar ativar seu site de produção.
Para ativar o cache de páginas em um ambiente de teste, navegue até Sites > Ferramentas no MyKinsta e clique no botão “Habilitar Cache”. Quando o cache estiver habilitado na fase de teste, você pode usar o botão ” Limpar Cache” para limpar o cache.
Cache de análises da Kinsta
Você pode se aprofundar em quão bem o seu site WordPress está fazendo o cache em Análises MyKinsta. A pilha do componente de cache permite ver o status de cada solicitação, seja HIT, BYPASS, MISS ou EXPIRED. Você pode filtrar os dados nas últimas 24 horas, 7 dias ou 30 dias.
O gráfico do componente de cache dá uma rápida olhada na sua taxa de cache. Quanto mais solicitações você veicular no cache, melhor.
A seção principal de ignorar o cache permite ver quais solicitações não estão sendo atendidas no cache. Geralmente, eles podem incluir tarefas CRON, solicitações admin-ajax, páginas de checkout de comércio eletrônico, strings de consulta e parâmetros UTM, etc.
Colocando páginas 404 em cache
Páginas 404 podem ser muito intensivas em recursos. Muitos sites do WordPress, especialmente grandes sites de associação, geram mais erros 404 do que você imagina. Talvez você tenha mudado a localização de uma página e tenha esquecido de adicionar um redirecionamento, ou você tem um link errado em algo que você compartilhou na mídia social. Em outras palavras, há muitas coisas que fazem com que um visitante acabe na sua página 404. Essas páginas também tendem a ter consultas para extrair resultados de pesquisa alternativos que, em seguida, atingem o banco de dados.
Para garantir um melhor desempenho em seu site WordPress, Kinsta armazena páginas 404 por 15 minutos. O valor do cabeçalho X-Kinsta-Cache mostrará um HIT, o que significa que está sendo servido do cache. Se você criar uma página que anteriormente era um 404, o cache será removido imediatamente.
Nossa ferramenta de Análises no painel MyKinsta pode ajudar você a determinar a quantidade exata de erros 404 que ocorrem em seu site.
É importante esclarecer que não armazenamos em cache todas as solicitações 404. Existem dois tipos diferentes: os das páginas PHP que chegam à sua página 404 e os arquivos que faltam ou que já não existem ou foram movidos. Armazenamos as páginas 404 em cache, solicitações 404 para arquivos ausentes e as imagens são tratadas de maneira diferente.
Portanto, você pode usar os “Principais erros 404” para determinar melhor onde e o que está causando isso.
Você também pode verificar erros 404 no Google Search Console ou instalar um plugin de terceiros, como o Redirection, que registra erros 404. No entanto, lembre-se de que plugins como esses também afetam o desempenho. É muito melhor confiar em uma ferramenta no nível do servidor.
Crie um modelo 404 simples que evite consultar o banco de dados ainda mais, se possível.
Solicitações POST e Cache BYPASS
Queremos que nossas estatísticas de análise e armazenamento em cache sejam as mais precisas possíveis. É importante que, ao solucionar problemas de desempenho, você normalmente analise a proporção total de cache do seu HIT, que deseja ser o mais alto possível. Portanto, as solicitações POST são incluídas em nossos relatórios.
As solicitações POST não podem ser armazenadas em cache, além de algumas configurações altamente especializadas. O valor do cabeçalho X-Kinsta-Cache mostrará um BYPASS para essas solicitações. Estes não devem ser confundidos com postagens no blog ou qualquer tipo de post do WordPress (que podem ser armazenados em cache). Uma solicitação POST é usada para enviar dados para o servidor. Por exemplo, os dados enviados quando você envia um formulário da Web são armazenados no corpo da solicitação HTTP.
Resumo
Esperamos que você saiba agora um pouco mais sobre o cache de WordPress e os quatro tipos diferentes que encontrará regularmente na Kinsta: cache de bytecode, cache de objetos, cache de páginas e cache de CDN.
Se está cansado de trabalhar com os plugins de cache do WordPress e simplesmente quer um site rápido imediatamente, recomendamos que experimente Kinsta! Existe uma razão que justifica termos conquistado durante 5 anos consecutivos o estatuto de “nível superior” em desempenho WordPress por parte da ReviewSignal. E é por isso que nossos servidores estão configurados na Google Cloud Platform, para que os tempos de carregamento sejam rápidos. Você não ficará desapontado com o nosso desempenho.
Brian tem uma enorme paixão pelo WordPress, e tem utilizado há mais de uma década e até desenvolve alguns plugins premium. Brian gosta de blogs, filmes e caminhadas. Conecte-se com Brian no Twitter.
Deixe um comentário