Página inicial/guia/Otimização de sites/Detalhes do conteúdo

A causa principal da “lentidão” do site geralmente não é uma imagem específica, mas simLink de solicitação + geração de servidor + distribuição de recursos estáticoscausada pela sobreposição:

  • Os usuários estão muito distantes dos seus servidores, o RTT da rede é alto (mais pronunciado entre continentes)
  • O WordPress executa o PHP, verifica o banco de dados e renderiza o modelo para cada solicitação → TTFB (tempo até o primeiro byte) up
  • As páginas também carregam JS/CSS/fontes/scripts de terceiros, tornando a renderização e a interação mais lentas.

Plug-in de cacheA essência da solução é salvar os resultados das páginas “contadas duas vezes” para que o servidor não precise recalculá-las todas as vezes e reduzir significativamente o TTFB, permitindo que mais usuários acessem o cache com a estratégia certa.Documentação oficial do WordPressTambém foi destacado que plug-ins como o W3 Total Cache e o WP Super Cache podem armazenar em cache as páginas como arquivos estáticos e, em seguida, servi-las diretamente ao usuário, reduzindo a carga de processamento no servidor.

Antes de ler esta página, lembre-se de três regras rígidas

1. plug-ins de cache de página ao mesmo tempo, apenas um

O resultado mais comum de ativar vários plug-ins de cache ao mesmo tempo não é mais rápido:

  • Substituir as regras de cache um do outro, limpar os caches um do outro, diminuir a taxa de acerto do cache
  • O conteúdo dinâmico, como formulário de login/idioma/cartão/preço, é armazenado em cache, resultando em incidentes de “conteúdo errado”
    Muitas documentações/instruções de plug-ins sugerem que, ao usar um determinado plug-in de cacheDesativar outros plug-ins de cachepara evitar conflitos.

2. sites de comércio eletrônico/membros/multilíngues: o armazenamento em cache não é um “botão liga/desliga”, é um “sistema de regras”.”

Documentação oficial de desempenho do WooCommerceLembrete explícito: no plug-in de cache, certifique-se de que Carrinho de compras / Checkout / Conta Também é recomendável evitar a compactação de arquivos JavaScript (pois ela tende a causar problemas de compatibilidade).

3. “Plug-in de cache ≠ CDN”, mas o plug-in de cache é a base do CDN

Plug-in de cache para resolver o problema da “contagem insuficiente de estações de origem”;CDN Resolver o problema de “conteúdo mais próximo dos usuários”. A relação entre os dois é sobreposta: primeiro, o TTFB de origem é pressionado e, em seguida, os recursos estáticos são entregues ao CDN para difusão, que é a rota mais estável para os usuários globais.

Seleções rápidas: 4 dos cenários mais comuns para sites

Se você não quiser ler o artigo inteiro, não há como errar com as quatro opções a seguir:

  1. Deseja economizar dinheiro, ser estável e estar voltado para o acesso global → WP Rocket(Pago)
  2. A hospedagem é explicitamente LiteSpeed/OpenLiteSpeed → Cache LiteSpeed(gratuito, mas depende muito da capacidade do servidor)A função de cache requer Componentes de servidor do LiteSpeedtrabalhar somente então
  3. Sites de conteúdo/blogs/sites de documentos que desejam ser gratuitos e estáveis → WP Super Cache(cache HTML estático)Geração de arquivos HTML estáticos para fornecer à maioria dos usuários não conectados
  4. Você tem equipes técnicas para fazer o ajuste fino do controle (CDN/caching de objetos/multimódulos) → W3 Total Cache(forte, mas complexo)Mantém uma estrutura de desempenho abrangente com a integração do CDN

O que exatamente o cache armazena em cache?

“Por que alguns sites ainda são lentos com o armazenamento em cache”, dividimos o desempenho do WordPress em 5 camadas:

  1. cache do navegadorTornar o acesso secundário mais rápido para os usuários (cabeçalhos de cache de recursos estáticos, números de versão)
  2. cache de páginaCache: saída da página de cache como HTML (caractere principal desta página)
  3. cache de objetosObjetos de resultado de consulta de banco de dados em cache (estações dinâmicas são mais valiosas)
  4. PHP OPcacheCache PHP bytecode (geralmente configurado pelo servidor, não é o foco do plug-in)
  5. CDN/cache de bordaColocação de recursos em nós mais próximos do usuário

O foco deste artigo: plugin de cache de página;
Mas você é constantemente lembrado de que os sites geralmente precisam de uma combinação de 2 + 5 para serem “realmente rápidos”.

Plug-in 1:WP Rocket(pago) - Programas integrados “que salvam a mente

O WP Rocket é popular no cenário “WordPress” não porque seja mágico, mas porque transforma os três tipos mais comuns de trabalho de desempenho em “pacotes gerenciáveis”:

  • Cache de página (reduz o TTFB do site de origem)
  • Pré-carregamento/pré-aquecimento do cache (para aprimorar a experiência da primeira visita com acesso distribuído globalmente)
  • Principais otimizações de front-end (especialmente latência de JS, manipulação de CSS, etc.)

seudocumento oficialEle também menciona explicitamente que a ativação do pré-carregamento pode acionar/direcionar determinadas otimizações (por exemplo, otimizações relacionadas a CSS/JS), mesmo se você desativar o cache da página.

1.1 Para quem é o WP Rocket

O WP Rocket é especialmente adequado para essas estações:

  • Site corporativo, site de marca, site de marketing de conteúdo, páginas de destino (tráfego de vários países e regiões)
  • Quero “entrar em operação rapidamente, com estabilidade em primeiro lugar”, não quero soletrar muitas combinações de plug-ins gratuitos
  • Não há engenheiros de operações/desempenho dedicados, mas temos experiência e requisitos de SEO
  • WooCommerce Ele também pode ser usado, mas com mais cautela (mais sobre isso mais adiante nesta seção)Regras e riscos）

1.2 Seu principal valor em cenários de acesso à Web (não apenas uma “troca de cache”)

A. Pré-carregamento do cache: resolução de “primeiras visitas instáveis devido ao acesso distribuído a sites”

Você experimentará uma lentidão muito comum quando os usuários do site estiverem dispersos:
Um usuário em uma região abre uma página pela primeira vez e ela está fora do cache ou nunca foi aquecida → esse usuário incorre no custo total de renderização do PHP/DB.
Mecanismo de pré-carregamentoO significado disso é:Pagamento antecipado dos custos da “primeira geração”A primeira visita do programa será uma “cobaia”, reduzindo a probabilidade de uma "primeira visita como cobaia".

  • Sem pré-carregamento: quem acessa primeiro sofre
  • Com pré-carregamento: pelo sistema em segundo plano de geração unificada de cache, a experiência da primeira visita é mais estável

B. Execução diferida de JavaScript: o recurso mais fácil de “sentir-se imediato” em uma visita ao site, mas também o mais arriscado.

O WP Rocket coloca oficialmente “Execução atrasada de JS” o descreve como sua otimização JS mais forte: ele adiará a execução do script até que o usuário tenha tido uma interação (movido o mouse, tocado a tela, rolado a tela, pressionado uma tecla etc.) para priorizar a renderização da página.

Isso é importante para o acesso a sites, pois o bloqueio de carregamento e execução de scripts tem maior probabilidade de ser ampliado em redes intercontinentais:

  • Downloads de recursos mais lentos → thread principal com maior probabilidade de ser atolado por scripts
  • Os scripts de terceiros (estatísticas, anúncios, plug-ins de bate-papo) têm maior probabilidade de piorar os atrasos de INP/interação

Mas isso também pode causar problemas:

  • O atraso no JS provavelmente afetará: menus, rotações, pop-ups, validação de formulários, pagamentos, rastreamento de sepultamentos
  • Portanto, ele é adequado para uma estratégia “passo a passo + exclusão de lista negra”.

C. Compatibilidade com outros plug-ins/temas: “conflito zero” não é o mesmo que "paz de espírito".”

A WP Rocket listou oficialmente o “Plugins/temas incompatíveis”, por motivos que incluem mecanismos como buffer de saída que afetariam o cache/otimização do WP Rocket.

  • Se o seu site tiver muitos plug-ins e temas, pense na “otimização do desempenho” como um miniprojeto de ativação: teste de regressão para cada alteração (formulários, logins, pagamentos, troca de vários idiomas etc.).

1.3 Lembrete especial para WooCommerce/Dynamic Station

O principal lembrete da documentação oficial do WooCommerce ao configurar o plug-in de cache é:

Por quê? Por:

  • Forte dependência do carrinho, checkout, página da conta cookie / sessão / nonce
  • Quando o cache tratar essas páginas como “páginas estáticas”, os botões não funcionarão e as informações de preço/inventário/conta ficarão bagunçadas.
  • Esta é a parte assustadora: você pode estar testando bem em uma região e ter problemas em outra devido a discrepâncias de acerto de CDN/cache!

1.4 Recomendações de nível de estratégia do plug-in de cache

Nível 1: Benefícios básicos de segurança (quase todas as estações devem fazer isso)

  • Ativar o cache de página
  • abrePré-carregamento do cache(Aumento da estabilidade da primeira visita)
  • Política sensata de armazenamento em cache do navegador (WP Rocket/Server/CDN Qualquer uma das camadas pode ser implementada)

Nível 2: recompensa média, risco médio (adequado para a maioria dos sites de conteúdo)

  • Atraso no carregamento de imagens/iframe (a página de otimização de imagens vai além)
  • Controle do volume de CSS (por exemplo, remoção de CSS não utilizado)

Nível 3: alto rendimento, mas alto risco (deve ter uma lista de verificação de teste de regressão)

1.5 Preços e autorizações

  • O WP Rocket é uma licença paga, com licenças diferentes, dependendo do número de sites.

Plugin 2:Cache LiteSpeed (LSCWP)--A premissa do “free tops” é que o servidor é realmente LiteSpeed.

Muitas pessoas têm uma ideia errada sobre o LiteSpeed Cache: elas acham que ele é apenas um plug-in do WordPress que você pode instalar e que funcionará como o WP Rocket em qualquer host com potência total. Isso não é verdade.

Documentação oficial do LiteSpeedExplicação clara: o recurso de cache do LSCWP requer o LiteSpeed Server porque ele se comunica com o cache de página integrado do LiteSpeed Web Server (LSCache); o plug-in é responsável por informar ao servidor quais páginas podem ser armazenadas em cache, por quanto tempo e por acionar a limpeza com tags.

A força central do LiteSpeed Cache vem de “Cache de página em nível de servidor (LSCache)”. Sem os servidores LiteSpeed/OpenLiteSpeed, não há essa vantagem central.

2.1 Cache LiteSpeedpara quem

Em forma:

  • Seu painel de hospedagem está claramente identificado LiteSpeed / OpenLiteSpeed(por exemplo, muitos hosts do cPanel escreverão)
  • Você deseja “uma solução gratuita que também possa executar TTFB e concorrência fortes”.”
  • Você está disposto a aceitar: é muito eficiente, mas também mais conceitual (TTL, Tag, Purge, ESI, Crawler...)

Na verdade, não:

  • Você não tem certeza de qual é o servidor Web do host ou confirma que é o Nginx/Apache (a menos que queira usar apenas alguns de seus recursos de otimização de front-end, mas nesse caso o preço/desempenho e a complexidade não são necessariamente econômicos)
  • Você tem um site complexo de comércio eletrônico/associação/multilíngue, mas não tem um processo de teste (o LSCWP é forte, mas também é mais fácil “armazenar em cache o conteúdo errado”)

2.2 Seu mecanismo de cache: por que ele é mais como “parte da capacidade do servidor”

Você poderia escrever a mecânica do LiteSpeed Cache como uma “explicação de engenharia”:

  • WP Rocket / WP Super Cache Isso está mais relacionado ao cache e à otimização do WordPress/PHP;
  • LSCWP É uma combinação do Painel de Controle do WordPress + o LSCache integrado do LiteSpeed Server: o plug-in é responsável por emitir regras e sinais de limpeza, e o verdadeiro cache de página de alta velocidade acontece nocamada do servidor。

Isso tem um impacto direto na experiência do site: o cache de cuspe no nível do servidor geralmente é mais leve, mais rápido e mais simultâneo (especialmente com picos de tráfego e visitas de alta frequência de rastreadores de mecanismos de pesquisa).

2.3 A “maneira correta” de abrir o LSCWP para cenários de usuários do site”

Dividimos a “maneira correta de abrir” em 4 níveis:

Camada 1: Política de cache de página (determina se o TTFB pode realmente cair)

  • Esclarecer quais páginas podem ser armazenadas em cache (a maioria das páginas de conteúdo público)
  • Deixe claro quais páginas nunca devem ser armazenadas em cache (login, conta, carrinho de compras, checkout, páginas de troca de idioma/moeda que dependem de cookie forte)
  • Defina um TTL razoável para o cache (quanto mais frequentemente o conteúdo for atualizado, mais curto será o TTL e mais longo será o TTL).
  • Crie uma estratégia de limpeza: limpe a tag relevante após a atualização do conteúdo (em vez de fazer uma limpeza de força bruta em todo o site)

Essa camada, se feita corretamente, é mais diretamente visível para o site como a TTFB reduzido, primeira tela mais estável。

Camada 2: Warm-up/Crawler (determina a “primeira visita lenta a uma página fria”)

Uma “inconsistência de experiência” comum no acesso ao site decorre de “diferenças entre quente e frio” no armazenamento em cache:

  • As páginas populares são sempre visitadas e o cache está sempre ativo
  • As páginas frias não são clicadas há muito tempo, e quem clica pela primeira vez é lento

O aquecimento não é a cereja do bolo, é a chave para uma experiência consistente do visitante do site

Camada 3: Programas de segurança para conteúdo dinâmico (comércio eletrônico/associação/multilinguismo)

O poder do LSCWP é que ele oferece muitas “ferramentas avançadas”, por exemplo:

  • Estratégias de cache diferenciadas para usuários conectados, usuários de comentários, etc.
  • A ideia central do Edge Side Inclusion (ESI) é dividir a página em "corpo público armazenável em cache" e "fragmentos dinâmicos não armazenáveis em cache", que são processados separadamente e, em seguida, unidos nos nós de borda.

Camada 4: serviços on-line e aprimoramentos opcionais

Muitos webmasters acharão os serviços on-line do QUIC.cloud (por exemplo, serviços do tipo otimização na página) úteis no LSCWP.Documentação do QUIC.cloudEstá escrito explicitamente que ela fornece serviços de otimização na página para o LSCWP, incluindo CSS crítico (CCSS), CSS exclusivo (UCSS), Viewport Images (VPI) e outros.

  • Esse tipo de serviço é opcional: você pode usar apenas o cache do servidor e não ativar a otimização on-line
  • Quando os serviços on-line forem ativados, os recursos do seu site/links de processamento de página serão alterados (essa é uma informação importante para empresas/clientes sensíveis à privacidade)

2.4 Fosso comum do LSCWP

  1. O servidor não é LiteSpeed, mas usa o LSCWP como um plug-in de cache com recursos completos
    Resultado: o armazenamento em cache não é tão eficaz quanto o esperado e também aumenta a complexidade da configuração. Solução: confirme primeiro a pilha do host; se não houver LiteSpeedPor exemplo, considere o WP Rocket ou o WP Super Cache.
  2. A ativação de muitas otimizações de front-end leva a anomalias funcionais
    As otimizações na página (CSS/JS) geralmente têm mais probabilidade de causar problemas de compatibilidade do que o “cache em si”. Sugestão: execute o cache da página primeiro e, em seguida, ative as otimizações uma a uma e crie uma lista de testes de regressão (formulários, menus, pagamentos, rastreamento, troca de idioma etc.).
  3. Falta de estratégias de exclusão/slicing para páginas dinâmicas
    Incidentes típicos: carrinho de compras, checkout, página da conta sendo armazenada em cache; ou troca incorreta de vários idiomas/multidivisas. Os sites de comércio eletrônico devem considerar isso como uma verificação pré-lançamento (e os funcionários do WooCommerce também enfatizam)Não armazenar em cache as páginas principais）。

Plugin 3:WP Super Cache(Gratuito) - Uma solução clássica de “baixo risco, alto rendimento” para sites de conteúdo.

WP Super Cache Por que ele é popular há tanto tempo? Porque resolve problemas de uma forma muito direta e muito “amigável ao servidor”:
Gerar arquivos HTML estáticos a partir de páginas dinâmicas do WordPressOs arquivos HTML são então servidos diretamente do servidor da Web, ignorando o dispendioso processamento do PHP.

A página do plug-in também menciona que o HTML estático será exibido para a grande maioria dos usuários não conectados e fornece uma declaração muito intuitiva - “os visitantes do 99% receberão arquivos HTML estáticos”, e um único arquivo em cache pode ser exibido milhares de vezes. vezes.

3.1 Para quem é o WP Super Cache?

Altamente recomendado:

  • Blogs, sites de conteúdo de mídia, sites de documentos, sites de demonstração corporativa, páginas de destino
  • Os visitantes são principalmente usuários não conectados
  • Você deseja: gratuito, estável e com baixos custos de manutenção

Use com cautela/necessite de estratégias mais fortes:

  • Site altamente dinâmico: muito conteúdo personalizado, páginas que mudam de acordo com o estado do usuário
  • Comércio eletrônico grande: pode funcionar, mas certifique-se de que as páginas principais não estejam armazenadas em cache e trabalhe com seu processo de teste

3.2 Seus três métodos de cache:

A descrição do plug-in WP Super Cache lista três métodos de cache por velocidade e explica as diferenças:

  • mod_rewrite (especialista)O mais rápido, contornando completamente o PHP, mas precisa alterar o .htaccess; a configuração inadequada pode levar à indisponibilidade do site, o risco é maior!
  • Simples (abordagem recomendada)Arquivos estáticos “supercacheados” fornecidos pelo PHP, com velocidade próxima à do mod_rewrite, mas mais fácil de configurar.
  • Cache do WP-Cachemais flexível para usuários conhecidos, URLs com parâmetros, feeds de assinatura, etc., mas mais lento

Escolha recomendada:

  • Iniciantes/em busca de estabilidade: use o método recomendado (simples)
  • Você está familiarizado com as regras do servidor e está disposto a correr o risco de reescrevê-las: considere o modelo especializado novamente!
  • Você precisa de um tratamento mais flexível de “Usuário conhecido/com parâmetros”: Entendendo a posição do WP-Cache

3.3 Vantagens e desvantagens do WP Super Cache

Vantagens:

  1. Ideal para uso com o CDN.
    Como ele está essencialmente “gerando HTML estático”, isso naturalmente se encaixa na ideia do CDN/cache de borda.
  2. Os aprimoramentos na estação de origem CPU/pressão do banco de dados são muito simples
    Os mecanismos de pesquisa e os rastreadores de mídia social também podem vir de todo o mundo quando o tráfego do site é disperso. A estatização é eficaz no combate à “re-renderização”.

Prancha curta:

  1. Não se trata de um “pacote completo de otimização de desempenho”.”
    Seu ponto forte é o cache de página, e as otimizações profundas de CSS/JS não estão tão empacotadas como no WP Rocket. Talvez você precise fazer mais na “Página de otimização de imagem” e na “Página de otimização de front-end” (ou usar outras otimizações de nível de plug-in/tema).
  2. Seja mais cauteloso com a “personalização dinâmica”
    Por exemplo, exibir conteúdo diferente por região, preços/idiomas/recomendações diferentes por status do usuário etc. Nesse ponto, você deve criar uma política de exclusão ou introduzir um esquema de armazenamento em cache mais adequado.

3.4 Compatibilidade com o WooCommerce: por que é “mais seguro”

Ajuda oficial do WooCommerceMencionado: o WooCommerce é compatível nativamente com o WP Super Cache e o WooCommerce envia uma mensagem ao WP Super Cache para que ele não armazene em cache as páginas Cart, Checkout e My Account por padrão.

  • Mesmo que você seja novo no WP Super Cache + WooCommerce, é muito menos provável que você pise na mina de “páginas-chave armazenadas em cache”!
  • No entanto, ainda é recomendável fazer testes de regressão antes de entrar em operação (pagamentos, cupons, envio, taxas de impostos, várias moedas etc.).

Plugin 4:W3 Total Cache (W3TC)--A mais versátil “estrutura de desempenho” para equipes de engenharia.

W3 Total Cache Em vez de um “plug-in de cache único”, o WordPress.org está posicionado como algo mais parecido com uma “estrutura de otimização do desempenho do site”: ele enfatiza o aprimoramento do SEO, dos Core Web Vitals e da experiência geral por meio da integração e das práticas recomendadas do CDN. Sinais vitais e experiência geral por meio da integração do CDN e das práticas recomendadas.

A descrição do plug-in lista uma ampla gama de recursos: cache de página/post, cache de CSS/JS, cache de feed, cache de resultados de pesquisa, cache de objeto de banco de dados, cache de objeto, cache de fragmento (cache de fragmento) e suporte para uma variedade de métodos de cache, como Redis/Memcached/APC, mas também inclui cache de agrupamento móvel por UA/Referrer, suporte a AMP, integração com proxy reverso (Nginx/Varnish) e assim por diante.

4.1 Para quem é o W3 Total Cache?

Perfeito para:

  • Você tem habilidades de desenvolvimento/operações e está disposto a fazer “habilitação + teste de pressão + teste de regressão”.”
  • Seu site é complexo: vários idiomas, alternância de vários temas, diferenciação móvel, estrutura de conteúdo complexa
  • Você não quer apenas o cache de página, mas também incorporar o cache de objeto/fragmento ao sistema (especialmente para sites dinâmicos)

Não se encaixa:

  • Você quer “instalar e pronto”, não quer entender as hierarquias de cache.
  • Você não tem um processo de teste, mas deseja ativar itens de alto risco, como compressão e scripts atrasados, de uma só vez

4.2 Por que é “forte, mas complexo”: os sites valorizam a “controlabilidade”.”

O valor do W3TC não é que “ele deve ser mais rápido do que todos os outros”, mas que ele oferece botões de controle suficientes para criar uma estratégia de desempenho:

  • Cache de página: pode estar na memória, no disco ou no CDN
  • Cache de objetos de banco de dados, cache de objetos: Redis/Memcached disponível, etc.
  • Cache de fragmentos: bom para “páginas semidinâmicas”
  • Suporte a dispositivos móveis: armazenamento em cache de páginas por referenciador ou grupo de agentes de usuário, respectivamente
  • Gerenciamento CDN: gerenciamento transparente CDN de bibliotecas de mídia, arquivos de temas etc.

Esses recursos são especialmente valiosos para sites, nos quais o acesso global é frequentemente encontrado:

  • Variantes da mesma página em diferentes dispositivos, em diferentes regiões e em diferentes idiomas
  • Alguns conteúdos podem ser armazenados em cache, outros devem ser em tempo real (por exemplo, preço, inventário, status do usuário)

4.3 “Ordem de habilitação recomendada” do W3TC”

Pedido recomendado:

  1. Comece ativando apenas o cache de página
    Verificar: o TTFB está inativo, o conteúdo é consistente, os principais processos de estado de login/multilíngue/e-commerce estão funcionando.
  2. Reativar o cache do navegador
    Objetivo: fazer com que as visitas de retorno e os recursos estáticos carreguem mais rapidamente e reduzir os downloads repetidos em todos os continentes.
  3. Reavaliar o cache de objetos / cache de objetos do banco de dados
    Aplicável: site dinâmico (WooCommerce, sistema de associação, consulta complexa).
    N/A: as estações somente de conteúdo podem ter retornos limitados ou até mesmo aumentar o consumo de recursos.
  4. Compressão de toque final / Script de latência / Otimização de front-end
    Como essa é a camada com maior probabilidade de desencadear anomalias funcionais, deve ser criada uma lista de testes de regressão (pagamentos, formulários, rastreamento, pop-ups, menus, troca de idioma etc.).

Lembrete do WooCommerce sobre “Configuração do plug-in de cache”Páginas críticas não são armazenadas em cache e é recomendável evitar a compactação de arquivos JS.

Matriz de comparação dos quatro plug-ins

Observação: não se trata de “quem é melhor”, mas sim de “quem é a melhor opção para seu cenário”.

dimensão (matemática)WP RocketCache LiteSpeedWP Super CacheW3 Total Cache
posicionamento centralIntegração que economiza tempo (cache + otimização)Cache em nível de servidor (depende do LSCache)Cache de HTML estáticoEstrutura de desempenho (várias camadas de cache + CDN)
dependente do hostBaixa (universal)Alto (requer LiteSpeed/OpenLiteSpeed para funcionar como cache de núcleo)Baixa (universal)Médio (universal, mas mais dependente do ambiente/configurabilidade)
Custos de aprendizadobaixo-médioMédio低Alto
Recomendação de Content StationMuialtoMuito alto (desde que seja atendido)MuialtoMédio-alto (dependendo da equipe)
Site de comércio eletrônico/associaçãoDisponível, mas exclua com cautela (as páginas principais do WooCommerce não são armazenadas em cache)Disponível, mas mais necessidade de regras/estratégias de fatiamentoestá disponível, e o WooCommerce menciona a compatibilidade nativa e o não armazenamento em cache das páginas principais por padrãoDisponível e adequado para controle de engenharia
orçamentocobrir os custosfreewarefreewareVersão gratuita + paga

“Incidentes de cache” e lista de verificação de prevenção

1. Três causas principais de “conteúdo errado” devido ao armazenamento em cache

A. Tratamento de páginas “com estado” como “páginas estáticas sem estado”

Típico: a página da conta, o carrinho de compras e a página de checkout são armazenados em cache. As autoridades têm enfatizado repetidamente Cart/Checkout/Account não deve ser armazenado em cache.

B. As variantes de vários idiomas, várias moedas e regiões não são armazenadas em cache corretamente

Se o seu site exibir conteúdo diferente com base em cookie, parâmetros de consulta e localização geográfica, o cache deverá levar em conta as “dimensões variantes”. Caso contrário, um cache gerado por um usuário na região A poderá ser reutilizado por um usuário na região B.

C. Reescrita de otimização de front-end (JS/CSS) que leva a anomalias funcionais

Em particular, a compactação, a fusão e a execução atrasada do JS.Evitar a compactação de arquivos JS。

2. lista de verificação de testes de regressão pré-lançamento

  • O login/out é normal
  • Os envios de formulários (formulário de contato, assinatura, registro de login) estão funcionando corretamente
  • Processo de comércio eletrônico: adicionar compra → cupom → envio/taxas → pagamento → página de pedido
  • Estabilidade da troca de vários idiomas (conteúdo, URLs, hreflang, moeda após a troca)
  • Menus móveis, pop-ups, rolagem e carregamento lento estão funcionando corretamente
  • Rastreie se os scripts ainda estão sendo acionados (GA, Meta Pixel, eventos de transformação)

problemas comuns

Q1：Por que o acesso ao exterior continua lento mesmo depois de eu ter instalado o plug-in de cache?

O motivo mais comum para isso é que você só resolveu a “renderização duplicada na origem”, mas não a “latência de rede entre continentes”.
Os plug-ins de armazenamento em cache permitem que o servidor distribua o conteúdo mais rapidamente (TTFB para baixo), mas os recursos estáticos (imagens, CSS, JS, fontes) e o RTT para links globais ainda precisam ser CDN para encurtar a distância.
Portanto, o caminho correto é:Primeiro, torne o cache da estação de origem estável.E depois CDN para distribuição global.。

P2: Por que o conteúdo não é atualizado depois que eu o altero após o armazenamento em cache?

Porque você está vendo o “cache antigo”. Ideia de solução:

  • Criar uma estratégia de limpeza: limpar o cache correspondente após atualizar artigos/páginas (em vez de limpar todo o site)
  • Para cenários com aquecimento/rastreadores: limpe e depois faça o aquecimento, caso contrário, a primeira visita será lenta
  • Para o CDN: é preciso considerar que as bordas do CDN também podem armazenar em cache recursos antigos

P3: Posso instalar o WP Rocket + WP Super Cache ao mesmo tempo?

Não recomendado. Um plugin de cache de página por vez é o mais estável. Você pode entender a ideia de “um para armazenamento em cache e outro para otimização” como “divisão de trabalho”, mas, na realidade, eles geralmente tocam no armazenamento em cache da página/reescrita de recursos, e a probabilidade de conflito é alta. É mais recomendável escolher um “plugin de cache principal” e outras necessidades com uma única ferramenta mais clara para preencher a lacuna.

P4: Não é perigoso usar o cache para sites de comércio eletrônico?

Não é perigoso, o que é perigoso é a “ausência de regras”.Recomendações do WooCommerceÉ muito claro: carrinho/checkout/contas não são armazenados em cache e a compactação de JS é evitada.
Além disso, o WooCommerce também menciona que funciona com o Compatibilidade nativa do WP Super Cachee evitar o armazenamento em cache de páginas críticas por padrão.
Portanto, o site de comércio eletrônico pode ser armazenado em cache, mas precisa ser testado como uma “mudança ao vivo”.

P5: Devo escolher o LiteSpeed Cache ou o WP Rocket?

  • Você tem certeza de que o host é LiteSpeed/OpenLiteSpeed?Prioridade do LiteSpeed Cache (gratuito e robusto, com os principais benefícios do LSCache em nível de servidor)
  • Você não tem certeza sobre a pilha de hospedagem / não quer se comprometer / quer integrar e economizar.WP Rocket: o WP Rocket é mais estável
  • Você é um site de conteúdo e tem um orçamento limitadoWP Super Cache: o WP Super Cache é mais estável e mais leve.

Plug-in de cache com CDN

O plug-in de cache resolve o problema de “menor contagem de estações de origem e menor TTFB”; o CDN resolve o problema de “recursos estáticos e páginas mais próximas dos usuários globais”. A superposição dos dois é a solução ideal comum para o acesso global.

  • Uma combinação comum de estações de conteúdo:Cache de página + distribuição estática CDN
  • Combinações comuns de estações dinâmicas:Cache de página (controle rígido de exclusão) + Cache de objeto (sob demanda) + distribuição estática CDN

👉 Ler:Aceleração do CDN (nó global e política de cache)

Combinações recomendadas para o armazenamento em cache do site

1. site de conteúdo / blog / site de documentos

Objetivo: Reduzir o TTFB, tornar a primeira tela mais estável, reduzir a pressão do servidor, trabalhar com o CDN para distribuição global.

1.1 O mix de negócios mais descomplicado

  • WP Rocket (cache de página + pré-carregamento + otimização de front-end)
    • CDN (ir para a página de discussão do CDN)

Aplicável:

  • Você quer “baixa configuração, resultados rápidos, baixo risco”.”
  • Temas/plugins em abundância, desejo de reduzir a compatibilidade com outros

Pontos de atenção:

  • As otimizações de front-end (especialmente a latência de JS) são ativadas em etapas para evitar anomalias funcionais (menus, formulários, rastreamento etc.)
  • Os sites com revisões/publicações frequentes devem ter uma estratégia de “limpeza + aquecimento”, caso contrário, a primeira visita às páginas frias será lenta.

1.2 Combinações clássicas livres e estáveis

  • WP Super Cache (cache HTML estático)Geração de HTML estático a partir de páginas dinâmicas, principalmente para usuários não registrados.

Aplicável:

  • Orçamento sensível, mas estável
  • Os visitantes basicamente não fazem login
  • Ritmo controlado de atualizações de conteúdo

Pontos de atenção:

  • Essa é uma combinação de “cache de página primeiro”, não espere que ela resolva todas as complexidades de CSS/JS ao longo do caminho!

2. site corporativo / site da marca / página de destino

Objetivo: Seja rápido, mas, o mais importante, “não quebre o link de conversão por causa da otimização”.

2.1 Robusto e controlável (estações globais de colocação/conversão recomendadas)

  • WP Rocket
  • + (opcional) otimização leve de imagens (você tem uma página “Image Optimisation”)
    • CDN

Por que isso é bom para as estações de conversão:

  • Os sites de conversão têm medo de que “formulários/popups/scripts de rastreamento sejam prejudicados pela otimização”
  • O WP Rocket é mais “integrado” no sentido de que você pode ativar e testar regressivamente cada item em um sistema.

O “princípio on-line” do site da empresa:

  • A otimização do desempenho é uma “mudança de entrada em operação” e deve ter uma lista de verificação de teste de regressão
  • Todas as configurações que envolvam latência/mesclagem/compressão de JS devem ser verificadas em um ambiente de pré-lançamento antes de entrar em operação!

3. site de comércio eletrônico WooCommerce (pedidos + segurança de página dinâmica)

Objetivo: É importante ser rápido, mas também garantir que o carrinho de compras, o checkout e as páginas da conta estejam absolutamente corretos.

Os pontos oficiais do WooCommerce para o plug-in de cache são muito claros:Carrinho de compras / Checkout / Página da conta Não armazenar em cacheRecomenda-se também que a compactação de arquivos JavaScript seja evitada para minimizar problemas de compatibilidade.

3.1 Rotas gratuitas e seguras que são mais “amigáveis para iniciantes”

  • WP Super Cache + WooCommerce
    • CDN

Por que ele está listado como um “lugar mais seguro para começar”?

  • O WooCommerce menciona oficialmente que é nativamente compatível com o WP Super Cache e informará ao WP Super Cache que não armazena em cache as páginas principais, como carrinho/checkout/contas, por padrão.
  • Para os sites que estão começando no comércio eletrônico, “nenhum acidente primeiro” é mais importante do que “desempenho extremo”.

3.2 Se você estiver usando um host LiteSpeed (gratuito, mas poderoso)

  • LiteSpeed Cache (deve ser um host LiteSpeed/OpenLiteSpeed para aproveitar o cache do servidor principal)
  • + (opcional) cache de objetos (Redis/Memcached, dependendo da capacidade de hospedagem e do tamanho do site)
    • CDN

Aplicável:

  • A pilha do host é clara e você está disposto a estabelecer regras de cache e políticas de exclusão
  • O volume de pedidos e mercadorias é grande, e uma estação de origem mais forte é necessária para suportar a pressão.

3.3 Equipes projetadas/comércio eletrônico complexo (controlável por vários módulos)

  • W3 Total Cache (estrutura de desempenho, camada de vários caches integrada ao CDN)
    • Cache de objetos (sob demanda)
    • CDN

Aplicável:

  • Com o Dev/Ops, você pode entrar em operação com “Ativação passo a passo do módulo + teste de pressão + teste de regressão”.
  • Necessidade de cache de fragmentos / variantes mais complexas da estratégia (por exemplo, cache refinado por dispositivo/região/idioma)

4. site de associação / comunidade / cursos on-line (muitos logins, forte personalização)

Objetivo: Agilize o conteúdo público e, ao mesmo tempo, garanta que o “conteúdo do usuário conectado não seja bloqueado”.

4.1 Salvar, mas precisa de estratégias rigorosas de exclusão

  • WP Rocket
  • + Cache de objetos (opcional) (se houver muitas consultas dinâmicas)
    • CDN

Pontos principais:

  • Você deve excluir do cache as páginas “Alterar por usuário”: Centro pessoal, Pedidos, Progresso, Mensagens, Carrinho de compras etc.
  • Esse tipo de site é mais propenso a “ver o conteúdo de outras pessoas/permissões incorretas”, e os riscos devem ser explicitados na página.

4.2 LiteSpeed Hosting + Política Avançada

  • LiteSpeed Cache (cache de servidor + ferramentas de política mais sofisticadas)
  • + Cache de objetos (sob demanda)
    • CDN

Pontos principais:

  • Os sites de associação tendem a precisar mais de uma mentalidade de “corpo armazenável em cache + fragmento não armazenável”.
  • As estratégias de aquecimento e limpeza precisam ser mais refinadas, caso contrário, a frase “os usuários ainda veem conteúdo antigo após a atualização” será muito frequente

Cache da Web “Demining Casebook” (Manual de Desminagem)”

Caso 1: Instalado o plug-in de armazenamento em cache, a velocidade permanece praticamente inalterada

Fenômeno:

  • Velocidades locais/co-regionais OK, no exterior (intercontinental) ainda lentas
  • O TTFB melhorou, mas o tempo de carregamento geral não diminuiu significativamente

Causas comuns:

  • Você só faz o cache de origem (TTFB), mas os recursos estáticos (imagens/JS/CSS/fontes) ainda são carregados da origem em todos os continentes
  • Os scripts de terceiros (anúncios, bate-papo, estatísticas) tornam a renderização e a interação mais lentas
  • Downloads lentos devido ao tamanho grande das imagens (o armazenamento em cache não resolve o problema do tamanho do “primeiro download”)

Ideia de solução:

  • O plug-in de cache cuida primeiro da “subcontagem da fonte + hits”.”
  • Os recursos estáticos vão para o CDN
  • Otimização de imagens
  • Os scripts de terceiros fazem estratégias de atraso/divisão

Leitura:

Caso 2: Após ativar o armazenamento em cache, a página é alterada, mas o frontend não é atualizado.

Fenômeno:

  • O conteúdo/estilo foi atualizado no backend e a versão antiga ainda é exibida no frontend
  • Ou apenas algumas regiões são atualizadas e outras continuam as mesmas (comum para estações globais)

Causas comuns:

  • O cache de página não foi limpo ou foi limpo de forma incorreta
  • O aquecimento/rastreador não está sendo executado, o cache limpo fica frio, resultando em uma primeira visita lenta, enquanto você pensa erroneamente que não há atualização
  • Se você ativar o cache de borda do CDN, a borda também poderá reter recursos antigos

Ideia de solução:

  • Crie uma “estratégia de limpeza após o lançamento/revitalização”: limpe as páginas relevantes, não faça uma limpeza completa em todo o site
  • Crie uma estratégia de aquecimento para páginas importantes (página inicial, páginas de destino principais) para evitar “limpeza = lentidão”
  • CDN Camada para fazer limpeza de bordas quando necessário

Caso 3: Conteúdo extraviado após a troca de vários idiomas/multidivisas

Fenômeno:

  • A página ainda mostra o idioma anterior após a troca de idiomas
  • Ou os usuários de determinadas regiões veem a moeda errada/conteúdo errado

Causas comuns:

  • O cache não faz distinção entre “dimensões variantes” (cookie / parâmetros / prefixos de idioma / subdomínios).
  • O acerto no cache fornece os resultados da página do idioma A ao usuário do idioma B

Ideia de solução:

  • Esclareça seu programa multilíngue: directories/subdomains/parameters/cookie
  • Adição de “políticas variantes” às regras de cache ou exclusão de páginas-chave
  • Alguns sites exigem ideias mais avançadas de cache “slice and dice” (o W3TC é mais adequado para o controle de engenharia).

Caso 4: Problemas com o carrinho de compras/checkout em um site de comércio eletrônico com o cache ativado

Fenômeno:

  • Carrinho de compras com quantidade errada, preço errado e botão de checkout que não funciona
  • Fazer login e ver conteúdo que não pertence a você (sério)

Causas comuns:

  • Páginas críticas, como Cart/Checkout/My Account, são armazenadas em cache.
  • A minificação/combinação de JS causa incompatibilidade de pagamento/componente dinâmico

Ideia de solução:

  • O WooCommerce é oficial: carrinho/checkout/contas não devem ser armazenados em cache, e é recomendável evitar a compactação de arquivos JS.
  • Execute primeiro o “cache de página + excluir” e, em seguida, considere a otimização de front-end
  • Se você usa o WP Super Cache, o WooCommerce menciona que ele é nativamente compatível e evita o armazenamento em cache das páginas principais por padrão.

Caso 5: Menu/formulário/popup quebrado após a ativação de “Delay JS/Merge Scripts”.

Fenômeno:

  • O menu de navegação não abre
  • A validação do formulário falhou ou não pôde ser enviada
  • Exceção de pop-up/roll-up
  • Os eventos de estatísticas/conversão não são acionados (o maior problema para sites de lançamento)

Causas comuns:

  • O JS diferido altera o tempo de execução do script: os scripts não são executados até que o usuário interaja com eles, e alguns componentes dependem da “inicialização no carregamento da página”.”
  • A mesclagem/compressão pode alterar a ordem dos scripts ou quebrar dependências

O WP Rocket descreve oficialmente a “execução JS adiada” como uma de suas otimizações JS mais fortes: os scripts são adiados até depois da interação do usuário para priorizar a renderização da página. Esse é um recurso excelente, mas também significa um risco maior de compatibilidade.

Ideia de solução:

  • Ative em etapas: cache, depois imagens, depois CSS e depois JS.
  • Adicionar exclusões a scripts importantes (pagamentos, formulários, menus, rastreamento)
  • Faça uma lista de verificação de teste de regressão para cada alteração

Caso 6: somente o LiteSpeed Cache está instalado, mas parece que não está funcionando.

Fenômeno:

  • O LiteSpeed Cache está ativado, mas o TTFB não está caindo muito.
  • Os acertos também não são óbvios

Causas comuns:

  • Seu servidor não é LiteSpeed/OpenLiteSpeed e não pode usar os principais recursos do LSCache
  • Ou talvez você tenha ativado várias otimizações para ele, mas a “política de cache de página/preheat/exclude” não foi criada!

Ideia de solução:

  • Verifique primeiro a pilha do host: é LiteSpeed/OpenLiteSpeed (esse é um pré-requisito)
  • Colocando o foco novamente em “Política de cache de página + aquecimento + exclusão + limpeza”
  • Se não for um host LiteSpeed: considere o WP Rocket ou o WP Super Cache