Saiba como otimizar o cache do seu WordPress

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.