loader

Deixando seu WordPress com cache adequado

WooCommerce Hoje continuamos nossa série de blogs dedicada à melhoria do desempenho do site usando dicas do The Ultimate WordPress Speed ​​Optimization Guide escrito por Johnny Nguyen. Esta parte será sobre a otimização do cache: O armazenamento em cache é melhor definido como salvar as solicitações processadas para que possam ser atendidas mais rapidamente quando solicitadas novamente. Ele é usado 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. Configure-os corretamente e você terá um site rápido que reduz a carga do servidor e economiza dinheiro. Configure-os incorretamente e 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 otimização de cache abaixo da dica será marcada 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.
Otimize o cache do seu site WordPress com as ferramentas disponíveis na Jelastic. Faça um teste na nossa plataforma com 14 dias grátis.

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 para 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. Como um hambúrguer feito antes de você pedir! 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. Claro, eles 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. 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 os plugins de cache corretos (INICIANTE-AVANÇADO/ALTO)

Eu teste mais de 50 plugins de cache diferentes. Os melhores 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. Se você gerencia 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. Swift mais agressivo, Rocket mais estável.
  • Existem outros bons plugins de cache (WP Fastest Cache, Breeze, WP Performance, Comet Cache, Borlabs).
  • W3TC é uma porcaria e muito difícil 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. Meu favorito.
  • 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!
  • Eu também não gosto de combinar plugins de cache com outros plugins de desempenho, 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.
Decidir qual plugin de cache usar depende do seu caso de uso.
  • Site pequeno com 400 páginas e pouco tráfego? – Swift ou WP Rocket, com pré-cache habilitado.
  • Site médio com 400-1.000 páginas e tráfego médio? – Pode ir com o plugin de cache Swift / Rocket ou o cache de servidor LiteSpeed ​​/ NGINX. Ambos têm prós e contras.
  • Site grande com 1.000 ou mais páginas e muito tráfego? – Eu gosto do LiteSpeed ​​Cache com configuração personalizada ou do cache NGINX nativo e nenhum pré-cache é necessário, pois você tem muito tráfego.

3. Configuração do plugin do cache (INTERMEDIÁRIO-AVANÇADO/ALTO)

Os plugins de cache 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, minha 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 seus intervalos de atualização de conteúdo. Se você atualizar todos os dias, defina 24 horas. Se você 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 – sim, se você tiver muitos usuários acessando-as. 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. Eu normalmente excluo check-out, páginas de usuário conectado ou páginas com formulários.
  • Cache do navegador – sim, habilite-o.
  • Controle de pulsação – Eu geralmente desativo para todas as páginas, exceto postagens. Ou, se precisar, pode aumentar seu intervalo para cada 120 segundos.
Nem toda configuração de cache ou plug-in de cache permitirá que você configure todas essas opções. Não surte se você não os ver. Na verdade, existem tantas configurações possíveis… Consulte meus guias de configuração de cache abaixo: Otimize o cache do seu site WordPress com as ferramentas disponíveis na Jelastic. Faça um teste na nossa plataforma com 14 dias grátis.

4. Configurando Cache-Prebuild (INTERMEDIÁRIO/MÉDIO-ALTO)

Um dos aspectos mais negligenciados do cache para mim é 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. Isso foi bom, pois você teve 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 (sem cache). Para sua informação: 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 (porque consome recursos preciosos).
  • 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.
  • Qualquer um que não esteja no LiteSpeed ​​… Bem, existem muitos scripts e mecanismos de aquecimento de cache no nível do servidor, mas não tão amigáveis ​​ao usuário. Você pode procurá-los se insistir. É muito mais fácil se você estiver no LiteSpeed, no entanto.
  • A única opção (para a maioria das pessoas) é usar um plugin de cache que tenha funções de pré-construção de cache embutidas, como Swift Performance e agora WP Rocket (que copiou essa ideia do Swift).
  • 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.
  • Eu diria que 1.000 páginas é o limite geral. Se você tem mais de 1.000 páginas e atualiza seu site com frequência, eu recomendo 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.
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. Eu diria que 1.000 páginas é o limite geral. Se você tem mais de 1.000 páginas e atualiza seu site com frequência, eu recomendo 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. Também deve ser habilitado através do servidor… Então 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 (plugin é melhor).
  • É 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.
  • Você pode 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.
Eu recomendo 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! Claro, você pode testar e ver por si mesmo. Principais motivos para usar o cache de objetos:
  • Back-end de administrador lento.
  • Funções lentas com grande volume de banco de dados.
  • Não sabe se suas páginas estão 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 … bem, não é mais.
  • Muitos dispositivos (como 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ê quiser usar o cache do navegador, é mais conveniente através de um plugin de cache… 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 dos urls) usados ​​para enviar informações ao servidor. Exemplos de strings de consulta abaixo 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 precisa dele (eles não têm muitos usuários conectados). Armazenar páginas públicas em cache é fácil, pois todos veem a mesma página. 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 E (de preferência) não desperdiçar 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… o que é bom. Mas, 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 (memória e espaço). O cache privado é difícil!

9. HTML-Caching no limite (INTERMEDIÁRIO/MÉDIO)

Esta é uma tecnologia relativamente nova para WordPress. Existem vários plug-ins e serviços por aí que podem armazenar em cache suas páginas no limite e usar espelhos CDN para atendê-los a clientes em todo o mundo. Existem 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 mesmo se o servidor não tiver. Basicamente… permite velocidades rápidas, mesmo se o seu servidor / hospedagem na web for uma merda!
  • 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 plug-ins 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”. Parece ser 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. Algo que plug-ins anteriores afirmavam fazer, mas falham de uma forma ou de outra.
  • Acredito que haja mais alguns, mas não consigo encontrá-los agora.
Você precisa desses serviços ou eles são úteis se você já tiver um servidor rápido? Eu acho que não muito. Eu não uso nenhum deles porque já estou feliz com o cache do meu servidor. Mas essas podem ser ótimas opções para servidores mais fracos. Fique de olho neste segmento, pois tenho certeza que evoluirá rapidamente. Fonte Otimize o cache 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