Saiba como otimizar o cache do seu WordPress
Neste artigo, continuaremos nossa série de recomendações dedicada à melhoria do desempenho do site usando dicas do The Ultimate WordPress Speed Optimization Guide, escrito por Johnny Nguyen. Você também pode acompanhar as primeiras recomendações por meio da publicação 20 passos para otimizar o WordPress, clique aqui. Começaremos abordando a parte de otimização através de plugin cache WordPress.
O armazenamento em cache é melhor definido quando salvado as solicitações processadas para que possam ser atendidas mais rapidamente quando solicitadas novamente. Ele é utilizado em todos os aspectos da tecnologia de computador desde sempre e absolutamente essencial para acelerar o carregamento da página.
Existem muitos tipos de cache em diferentes camadas, protocolos e serviços e muitas maneiras de configurá-los. Configurando corretamente você terá um site rápido que reduz a carga do servidor e economiza dinheiro, porém configurando incorretamente você terá um site que às vezes é rápido e tem design e funções corrompidos.
Se você já ouviu falar de pessoas reclamando sobre cache, é uma combinação daqueles que não sabem como configurá-lo para seu caso de uso e/ou que usam uma solução de cache configurada para eficiência de servidor mais do que para velocidade.
Cada dica de otimização de cache abaixo será marcada com o nível de habilidades necessárias para implementação e o impacto que isso trará ao seu sistema.
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.
1. Escolhendo o servidor correto para cache (INICIANTE-AVANÇADO/ALTO)
Cache de página inteira também conhecido como “cache estático” ou apenas “cache”, significa pré-construir a página inteira, tornando-a estática como HTML, para que esteja pronta pra servir imediatamente quando a página for visitada.
Não há espera para qualquer consulta de banco de dados ou processamento de PHP. A página simplesmente aparece instantaneamente.
Antigamente, o cache era feito apenas pelo servidor da web, portanto, chamado de “cache do servidor” e utilizado para manter a carga do servidor baixa. Era uma tática para ajudar servidores da web ocupados a lidar com muito tráfego.
Alguém mais tarde percebeu que isso poderia ajudar a acelerar os sites inchados de hoje, então agora, o cache também é usado do ponto de vista da velocidade e implantado mesmo em pequenos servidores da web com pouco tráfego.
Os desenvolvedores até criaram mecanismos de cache em nível de software para recriar o mesmo benefício para usuários sem acesso ao servidor ou em servidores sem módulos de “cache de servidor” habilitados. Não são tão rápidos quanto o cache de servidor verdadeiro, mas ainda têm um grande impacto e, em alguns casos, ainda mais úteis por terem recursos de cache extras.
A distinção mais importante para usuários regulares é saber suas limitações de cache com cada webhost ou servidor web. Em termos de servidor web, Apache, LiteSpeed e NGINX, todos têm diferentes caches de servidor disponíveis. Nós já apontamos alguns benefícios do NGINX, no Blog SaveinCloud, confira em nosso artigo, leia aqui.
Em termos de webhosting, saiba que alguns webhosts permitem a você a liberdade de usar o cache do servidor ou qualquer plugin de terceiros de sua escolha. Outros webhosts forçam você a usar sua solução de cache proprietária. Claro, eles vão vendê-lo como sendo de alta tecnologia e “melhor desempenho”, mas geralmente é uma solução de cache simplificada que é construída para eficiência de recursos em vez de desempenho agressivo.
Se você tentar usar um plugin externo, ele simplesmente não funcionará ou a empresa de hospedagem irá desativá-lo automaticamente.
O armazenamento em cache é geralmente mais rápido e mais eficiente em termos de recursos a partir do servidor, em vez de por meio do armazenamento em cache de PHP em nível de software.
Se estiver usando o servidor LiteSpeed, você pode usar o cache do servidor LiteSpeed integrado;
Se estiver usando o servidor NGINX, você pode usar o armazenamento em cache do servidor FastCGI integrado;
Se estiver usando Apache (o que você não deve), pode usar o proxy Varnish ou até mesmo o proxy NGINX;
Todos os servidores web podem usar qualquer cache PHP de nível de software (via plugin de cache). Mas alguns plugins são projetados mais para servidores Apache/LiteSpeed, outros para servidores NGINX;
Cuidado com certos webhosts (especialmente “webhosts gerenciados”) que o forçam a usar suas soluções de cache e não permitem que você use outros plugins de cache.
Apenas saiba que o servidor da web ou empresa de hospedagem de sites que você escolher afetará sua experiência de cache e quais plugins de cache você pode usar.
2. Escolhendo o plugin cache WordPress correto (INICIANTE-AVANÇADO/ALTO)
Os melhores plugins de cache para WordPress têm recursos úteis, fáceis de usar e não prejudicam seu site. Se você gerencia apenas alguns sites, pode preferir plugins agressivos com muitas otimizações e até grupos do Facebook onde as pessoas compartilham truques. Caso gerencie dezenas de clientes, preferirá um plugin mais seguro, com menos recursos e menos chance de problemas.
Os melhores plugins de cache versáteis (permitidos em qualquer servidor da web) são Swift Performance ou WP Rocket. O Swift é mais agressivo, enquanto o Rocket é mais estável;
Existem outros bons plugins de cache (WP Fastest Cache, Breeze, WP Performance, Comet Cache, Borlabs);
Não recomendamos o uso do W3TC pela sua complexidade na hora de configurar. Não use a menos que você seja um profissional;
Se estiver usando o servidor LiteSpeed, você pode usar o plugin LiteSpeed Cache;
Se estiver usando o servidor NGINX, você pode ficar com os plugins auxiliares NGINX para mantê-lo simples ou um plugin de cache completo como Swift ou WP Rocket;
Não combine vários plugins de cache no seu WordPress;
Não recomendamos combinar plugins de cache com outros plugins de desempenho na sua instalação do WordPress, mas pode funcionar se configurado com cuidado e não sobrepor funções.
Decidir qual plugin de cache usar depende do seu caso de uso;
No caso de site pequeno com 400 páginas e pouco tráfego recomendamos o uso do Swift ou WP Rocket, com pré-cache habilitado;
Site médio com 400-1.000 páginas e tráfego médio, pode utilizar o plugin de cache Swift, Rocket ou o cache de servidor LiteSpeed ou NGINX.
Site grande com 1.000 ou mais páginas e muito tráfego, indicamos o LiteSpeed cache com configuração personalizada ou do cache NGINX nativo. Nenhum pré-cache é necessário, quando possui muito tráfego.
3. Configuração do plugin cache WordPress (INTERMEDIÁRIO-AVANÇADO/ALTO)
Os plugins de cache WordPress estão mais complicados do que nunca para configurar agora, pois eles fazem muito mais coisas do que apenas armazenar em cache. Esta seção cobre especificamente apenas as configurações relacionadas ao cache. Em relação a outras opções que você vê nas configurações do plugin de cache, nossa recomendação estará em outras partes deste guia.
Reescrita vs PHP – a maioria dos plugins de cache oferece apenas a opção PHP. Se você tiver a opção de usar o método de reescrita, tente, pois é mais rápido. Se causar problemas, mude para o método PHP;
Cache TTL – significa quanto tempo o cache deve durar. Você deve definir isso enquanto acontece intervalos de atualização de conteúdo. Se você atualizar todos os dias, defina 24 horas, mas se quase nunca atualiza, pode torná-lo 1 mês;
Cache privado ou usuários/páginas logados – não use a menos que você realmente tenha tantos usuários logados e saiba como evitar que o cache misture conteúdo entre os usuários;
Cache separado para dispositivos móveis – não use a menos que você tenha AMP ou um design ou conteúdo específico que só aparece em dispositivos móveis. Só porque você tem um site responsivo a dispositivos móveis, não significa que precisa disso;
Armazenar páginas 404 em cache – Caso tenha muitos usuários acessando-as esta pode ser uma boa opção. Melhor se você redirecionar todos eles para páginas reais;
Cache dinâmico – ótimo para armazenar URLS em cache com consultas ou filtros, como pesquisas ou filtros de produtos de comércio eletrônico;
Excluir – absolutamente crítico para excluir páginas que não devem ser armazenadas em cache. Recomendamos excluir o check-out, páginas de usuário conectado ou páginas com formulários;
Cache do navegador – indicamos habilitar sem receio;
Controle de pulsação – Recomendamos que desative para todas as páginas, exceto postagens. Ou, se precisar, pode aumente seu intervalo para cada 120 segundos.
Nem toda configuração de cache ou plugin de cache permitirá que você configure todas essas opções. Existem muitas outras configurações possíveis, por isso disponibilizamos guias de configuração de cache, como pode ver abaixo:
- Guia de configuração de cache Swift Performance
- Guia de configuração de cache WP Rocket
- Guia de configuração de cache LiteSpeed
Para todos os outros plugins de cache WordPress, você pode seguir os guias acima para ter uma ideia geral.
4. Configurando cache-prebuild (INTERMEDIÁRIO/MÉDIO-ALTO)
Um dos aspectos mais negligenciados do cache é o processo de pré-construção do cache. Alguns plugins chamam de “cache-preload”, outros chamam de “cache-warming” ou “cache-crawler”. A função cache-prebuild é um mecanismo que pré-armazena páginas em cache para que carreguem rapidamente quando visitadas.
Antigamente, o cache era usado apenas em sites de alto tráfego e, portanto, nenhum pré-carregamento de cache era necessário. O cache foi construído pelo primeiro visitante e todos os visitantes subsequentes se beneficiaram de um cache já construído. Esse acontecimento foi bom, pois possibilitou milhares de visitas e apenas a primeira pessoa teve o azar de ver uma página “mais lenta”.
Mas na era de cache de hoje, deixar a “primeira pessoa aquecer seu cache” é uma ideia terrível se você tem muito pouco tráfego. Em um site não muito ocupado sem pré-criação de cache, pode parecer que todos os seus visitantes acessaram uma página fria e sem cache. Os usuários que acessam o cache frio verão um carregamento de página mais lento do que sem nenhum cache. De qualquer forma, agora temos a pré-construção do cache.
Existem muito poucos servidores que têm ou permitem uma função de pré-criação de cache em todo o servidor. Eles provavelmente têm medo de que os usuários abusem dele. É na mesma lógica que muitos webhosts não permitem que você use esses plugins verificadores de link quebrado por conta do consumo de recursos.
- Os servidores LiteSpeed possuem uma função de rastreamento de cache embutida. Porém, poucos webhosts permitem isso em servidores compartilhados. Você provavelmente só terá acesso se tiver em seu próprio VPS. Saiba mais sobre a performance do LiteSpeed para hospedagens no WordPress por meio do artigo da SaveinCloud, clique aqui;
- Existem muitos scripts e mecanismos de aquecimento de cache no nível do servidor, mas não tão amigáveis ao usuário. Recomendamos o uso do LiteSpeed pela sua praticidade;
- Na maioria das vezes, a única opção para as pessoas é usar um plugin de cache que tenha funções de pré-construção de cache embutidas, como Swift Performance e WP Rocket;
- A pré-construção melhora muito a experiência de cache em seu site. Ative-o se puder.
Existem alguns casos em que você NÃO DEVE usar o cache-prebuild. Uma é se você tiver muitos visitantes, é inútil, pois já há tráfego ativo aquecendo o cache. A outra é quando você tem muitas páginas, sendo 1.000 páginas geralmente o limite. Se você tem mais de 1.000 páginas e atualiza seu site com frequência, recomendamos NÃO fazer um pré-cache, pois seu servidor usará muitos recursos e nunca terminará o trabalho. Se seu cache for limpo antes mesmo de terminar, ele ficará preso em um ciclo perpétuo de cache de pré-criação constante que nunca é usado.
5. Configuração de cache de objeto (INICIANTE-INTERMEDIÁRIO/MÉDIO-ALTO)
O cache de objetos é útil para sites dinâmicos, dados constantemente atualizados e/ou não podem ser armazenados em cache, ou qualquer site com muitos números/relatórios calculados no back-end do administrador.
O cache de objetos salva as chamadas de banco de dados na RAM para que não tenham que ser pesquisadas toda vez que forem consultadas. Como a RAM é preciosa (menos abundante que o espaço no disco rígido e necessária para a execução de programas), o cache de objetos geralmente não é permitido em muitos planos de hospedagem compartilhada.
Como deve ser habilitado através do servidor só é possível se você tiver seu próprio servidor ou em um plano de hospedagem que permite o cache de objetos.
- O armazenamento em cache do objeto deve ser ativado no servidor;
- O cache de objetos pode ser gerenciado por meio do painel de controle de webhosting ou plugin do WordPress. Nós recomendamos o plugin.
- É melhor se você tiver um plugin de cache que gerencie o cache de página e o cache de objeto como o LiteSpeed Cache. Dessa forma, eles limpam o cache ao mesmo tempo;
- É possível usar um tempo de expiração do cache de objeto de 5 a 10 minutos para estar seguro. Mas se o seu conteúdo não é atualizado com frequência, você pode ir mais alto, como até 30-60 minutos.
Também recomendamos não usar o cache de objetos se você tiver apenas um site estático. Em alguns casos, é ainda mais lento do que apenas o cache de páginas simples. Ativá-lo “por precaução” não ajuda. Principais motivos para usar o cache de objetos:
- Back-end de administrador lento;
- Funções lentas com grande volume de banco de dados;
- Caso esteja em dúvida, sobre as páginas estarem sofrendo de consulta lenta, verifique com o Query Monitor.
6. Cache do navegador, também conhecido como “htaccess expire headers” (INICIANTE/BAIXO)
Esta é a tática comum em que as pessoas colam um monte de linhas em seu htaccess para que os arquivos estáticos sejam armazenados em cache do navegador por um longo tempo (1 semana, 1 mês ou até um ano), para que os usuários não tenham que baixá-los novamente. Talvez fosse um grande negócio antes, porém não recomendamos esta forma de uso nos dias atuais.
Muitos dispositivos como os móveis, têm espaço limitado e excluem o cache do navegador quando querem, não quando você quer.
O cache do navegador só ajuda a retornar visitantes, e muitos sites não têm muito tráfego repetido de qualquer maneira. Além disso, é com os novos visitantes que nos preocupamos mais em melhorar a experiência do usuário.
Se você optar em usar o cache do navegador, é mais conveniente através de um plugin de cache ao em vez de copiar e colar longos comandos em seu arquivo htaccess.
7. Ignorar Strings de consulta no cache de página (INICIANTE/MÉDIO)
Strings de consulta são o texto extra no final das URLS, usados para enviar informações ao servidor. Segue abaixo exemplos de strings de consulta e o que elas fazem:
- pesquisa – mostra diferentes resultados de pesquisa, por exemplo, pesquisar? = wordpress + dicas;
- ref – permite que o site rastreie quem encaminhou o usuário e salve informações no software de rastreamento de conversão, por exemplo, ref? = affiliateID;
- fbclid – permite que o site saiba que o usuário veio do Facebook, por exemplo, fbclid = 123ABC;
- filtro (produto) – mostra produtos diferentes com base no nome, preço, tamanho ou outras especificações do produto, por exemplo, filter_size? = grande.
Como você pode ver, algumas dessas strings de consulta realmente alteram o conteúdo da página, enquanto outras strings mostram o mesmo conteúdo da página, independentemente da string de consulta.
A ideia aqui é excluir as strings de consulta que não alteram o conteúdo do armazenamento em cache, para que seu mecanismo de cache não armazene esses acessos como uma página diferente. Isso evitaria que seu servidor trabalhasse desnecessariamente com o recacheamento da mesma página sob uma string de URL diferente e serviria a página mais rapidamente para os visitantes do cache existente.
Isso faz uma grande diferença para os visitantes vindos de URLS de string de consulta, como anúncios do Facebook, links de afiliados, links de boletins informativos por e-mail (com rastreamento de conversão).
8. Cache privado para usuários conectados (AVANÇADO/MÉDIO)
O cache privado raramente é praticado, pois a maioria dos sites não precisam dele, já que não têm muitos usuários conectados. Armazenar páginas públicas em cache é fácil, porque todos veem a mesma página, mas armazenar páginas privadas em cache é difícil por causa da necessidade de armazenar em cache como cada usuário vê a página de maneira diferente.
De preferência, não desperdice tanto espaço, salvando novamente páginas quase sempre semelhantes no cache.
- Algumas páginas privadas são fáceis – mesmo conteúdo para todos os usuários logados, mas algo diferente para usuários não logados;
- Algumas páginas privadas são mais difíceis – mostram principalmente o mesmo conteúdo, mas também dados personalizados, dependendo do usuário (como seu nome/nome de usuário);
- Outras páginas privadas são complicadas – mostra um conteúdo completamente diferente para cada usuário.
A maneira mais fácil de lidar com páginas privadas é usar o cache de objetos em vez de cache de páginas. Para ser mais agressivo, você pode habilitar cuidadosamente o cache privado, mas certifique-se de que os usuários não possam ver as informações uns dos outros e o público não possa ver o conteúdo privado.
Existem certos mecanismos por aí, como o recurso ESI do LiteSpeed, onde você pode mostrar diferentes conteúdos e widgets dependendo dos usuários. Em última análise, neste nível, você precisa contratar um profissional ou gastar muito tempo para configurar algo que não apenas funcione, mas também não consuma tantos recursos como memória e espaço.
9. HTML-Caching no limite (INTERMEDIÁRIO/MÉDIO)
Esta é uma tecnologia relativamente nova para WordPress. Existem vários plugins e serviços que podem armazenar em cache suas páginas no limite e usar espelhos CDN para atender clientes em todo o mundo. Conheça 3 benefícios principais:
- O armazenamento em cache é feito no servidor deles, não no seu – reduz a carga do servidor, ajuda a tornar a hospedagem na web mais lenta, diminui os custos do servidor, permite o armazenamento em cache e ajuda a otimizar, mesmo se o seu servidor/hospedagem na web não for potente o suficiente;
- HTML entregue a partir do CDN – tradicionalmente, o CDN apenas transfere ativos estáticos como imagens e CSS/JS. Com este novo cache de borda para HTML, eles podem servir o HTML de um servidor pop próximo também. Teoricamente melhorando o carregamento da página para visitantes distantes de seu servidor de origem;
- Proteção adicional de DDOS – uma vez que menos do seu servidor é usado, menos do seu servidor é exposto a ataques de DDOS.
Estão disponíveis plugins e serviços de cache de borda notáveis:
- QUIC.cloud– dos criadores dos servidores da web LiteSpeed. Seu serviço Q.C permite que qualquer site se beneficie da rapidez do LiteSpeed, mesmo se não tiver servidores LiteSpeed.
- Shifter – vendido como um “gerador de sites estáticos para WordPress”. É uma experiência de usuário muito diferente do fluxo de trabalho normal do WordPress.
- WP Cloudflare Super Page Cache – permite que você armazene tudo em cache com o plano Cloudflare gratuito.
Essas podem ser ótimas opções para servidores mais fracos. Fique de olho neste segmento, pois com certeza evoluirá rapidamente.
Otimize o cache do seu site WordPress com as ferramentas disponíveis na SaveinCloud. Faça um teste na nossa plataforma com 14 dias grátis!
Fonte: Blog Virtuozzo
