fig. início/guia/Otimização do sítio Web/Detalhes do conteúdo

A causa principal da “lentidão” de um sítio Web não é normalmente uma imagem específica, mas simLigação de pedido + Geração de servidor + Distribuição estática de recursoscausada pela sobreposição:

  • Os utilizadores estão demasiado longe dos seus servidores, o RTT da rede é elevado (mais visível nos continentes)
  • O WordPress executa o PHP, verifica a base de dados e apresenta o modelo para cada pedido → TTFB (tempo até ao 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.

Plugin de cacheO núcleo da solução é guardar os resultados das páginas “duplamente contadas” para que o servidor não tenha de os recalcular sempre e para reduzir significativamente o TTFB, permitindo que mais utilizadores atinjam a cache com a estratégia certa.Documentação oficial do WordPressTambém foi referido que plugins como o W3 Total Cache e o WP Super Cache podem armazenar páginas em cache como ficheiros estáticos e depois servi-las diretamente ao utilizador, reduzindo a carga de processamento no servidor.

Antes de ler esta página, lembre-se de 3 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:

  • Substituição das regras de cache uns dos outros, limpeza das caches uns dos outros, diminuição da taxa de acerto da cache
  • Os conteúdos dinâmicos, como o estado de início de sessão/idioma/carro/preço, são armazenados em cache, dando origem a incidentes de “conteúdo errado”
    Muitas documentações/instruções de plugins sugerem que, ao utilizar um determinado plugin de cacheDesativar outros plug-ins de cachepara evitar conflitos.

2) Sítios de comércio eletrónico/membros/multilingues: o armazenamento em cache não é um “interrutor de ligar/desligar”, é um “sistema de regras”.”

Documentação oficial de desempenho do WooCommerceLembrete explícito: no plugin da cache, certifique-se de que Carrinho de compras / Checkout / Conta Recomenda-se também que a compressão de ficheiros JavaScript seja evitada (uma vez que tende a causar problemas de compatibilidade).

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

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

Seleção rápida: 4 dos cenários mais comuns para os sítios Web

Se não quiser ler o artigo completo, não pode errar com as 4 opções seguintes:

  1. Pretende poupar dinheiro, ser estável e estar orientado para o acesso global → WP Foguetão(Pago)
  2. O alojamento é explicitamente LiteSpeed/OpenLiteSpeed → Cache LiteSpeed(gratuito mas fortemente dependente da capacidade do servidor)A função de cache requer Componentes do Servidor LiteSpeedapenas trabalho
  3. Sítios de conteúdos/blogues/sítios de documentos que pretendem ser gratuitos e estáveis → WP Super Cache(cache HTML estática)Gerar ficheiros HTML estáticos para fornecer à maioria dos utilizadores não registados
  4. Dispõe de equipas técnicas para afinar o controlo (CDN/object caching/multi-módulos) → W3 Total Cache(forte mas complexo)Mantém um quadro de desempenho abrangente com a integração do CDN

O que é que a cache guarda exatamente?

“Porque é que alguns sítios continuam a ser lentos com o armazenamento em cache”, dividimos o desempenho do WordPress em 5 camadas:

  1. cache do navegadorAcesso secundário mais rápido para os utilizadores (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 (carácter principal desta página)
  3. cache de objectosObjetos de resultado de consulta de banco de dados em cache (estações dinâmicas são mais valiosas)
  4. PHP OPcacheCache PHP bytecode (normalmente configurado pelo servidor, não é o foco do plugin)
  5. CDN/cache de bordaColocação de recursos em nós mais próximos do utilizador

O foco deste artigo: plugin de cache de páginas;
Mas somos constantemente recordados de que os sítios Web necessitam frequentemente de uma combinação de 2 + 5 para serem “realmente rápidos”.

Ficha 1:WP Foguetão(pago) - Programas integrados “Mentes que salvam

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

  • Armazenamento de páginas em cache (reduz o TTFB do sítio de origem)
  • Pré-carregamento/pré-aquecimento da cache (para melhorar a experiência da primeira visita com acesso distribuído globalmente)
  • Optimizações fundamentais do front-end (especialmente latência JS, tratamento de CSS, etc.)

seudocumento oficialTambém menciona explicitamente que a ativação do pré-carregamento pode desencadear certas optimizações (por exemplo, optimizações relacionadas com CSS/JS), mesmo que se desactive o caching da página.

1.1 A quem se destina o WP Rocket

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

  • Sítio Web da empresa, sítio da marca, sítio de marketing de conteúdos, página de destino (tráfego de vários países e regiões)
  • Quero “entrar em funcionamento rapidamente, estabilidade em primeiro lugar”, não quero soletrar uma grande quantidade de combinações de plugins gratuitos
  • Não há engenheiros de operações/desempenho dedicados, mas temos experiência e requisitos de SEO
  • WooCommerce Também pode ser utilizado, mas com mais cautela (mais sobre isto mais adiante nesta secção)Regras e riscos）

1.2 O seu valor fundamental em cenários de acesso à Web (não apenas um “interrutor de cache”)

A. Pré-carregamento da cache: resolução do problema das “primeiras visitas instáveis devido ao acesso distribuído aos sítios Web”

Verificar-se-á uma lentidão muito típica quando os utilizadores do sítio estão dispersos:
Um utilizador de uma região abre uma página pela primeira vez e esta está fora da cache ou nunca aqueceu → esse utilizador incorre no custo total de renderização PHP/DB.
Mecanismo de pré-carregamentoO significado deste facto é: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 aceder primeiro sofre
  • Com pré-carregamento: através do sistema de geração unificada de cache em segundo plano, a experiência da primeira visita é mais estável

B. Execução diferida de JavaScript: a funcionalidade mais fácil para “sentir o imediato” numa visita a um sítio Web, mas também a mais arriscada.

WP Rocket coloca oficialmente “Execução atrasada de JS” descreve-a como a sua otimização JS mais forte: adiará a execução do script até que o utilizador tenha tido uma interação (movido o rato, tocado no ecrã, deslocado, premido uma tecla, etc.) para dar prioridade à apresentação da página.

Isto é importante para o acesso a sítios Web, porque o bloqueio do carregamento e da execução de scripts tem mais probabilidades de ser amplificado em redes transcontinentais:

  • Descarregamentos de recursos mais lentos → thread principal com maior probabilidade de ser sobrecarregada por scripts
  • É mais provável que os scripts de terceiros (estatísticas, anúncios, plug-ins de conversação) agravem os atrasos do INP/interação

Mas também pode causar problemas:

  • É provável que o atraso no JS afecte: menus, rotações, popups, validação de formulários, pagamentos, acompanhamento de enterros
  • Por isso, é adequado para uma estratégia “passo-a-passo + exclusão da lista negra”.

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

A WP Rocket incluiu oficialmente na lista “Plugins/temas incompatíveis”, por razões que incluem mecanismos como o buffer de saída que afectariam o caching/otimização do WP Rocket.

  • Se o seu sítio tiver muitos plugins e temas, pense na “otimização do desempenho” como um mini-projeto go-live: testes de regressão para cada alteração (formulários, logins, pagamentos, mudança para várias línguas, etc.).

1.3 Lembrete especial para WooCommerce/Site dinâmico

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

Porquê? Porque:

  • Forte dependência da página do carrinho, do checkout, da conta cookie / sessão / nonce
  • Quando a cache tratar estas páginas como “páginas estáticas”, os botões não funcionarão e as informações sobre preços/inventário/conta ficarão baralhadas.
  • Aqui está a parte assustadora: pode estar a testar bem numa região e ter problemas noutra devido a discrepâncias no CDN/cache hit!

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

Nível 1: Prestações de segurança básicas (quase todas as estações devem fazer isto)

  • Ativar o caching de páginas
  • abrePré-carregamento da cache(Reforço da estabilidade na primeira visita)
  • Política de cache sensata 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 sítios de conteúdos)

  • Atraso no carregamento de imagens/iframe (a página de otimização de imagens vai mais longe)
  • Controlo 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 testes de regressão)

1.5 Preços e autorizações

  • O WP Rocket é uma licença paga, com licenças diferentes consoante o número de sítios.

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: pensam que é apenas um plugin para WordPress que pode instalar e obter todo o poder em qualquer alojamento, tal como o WP Rocket. Mas não é.

Documentação oficial do LiteSpeedExplicação clara: a funcionalidade de cache do LSCWP requer o LiteSpeed Server porque comunica com a cache de páginas incorporada no LiteSpeed Web Server (LSCache); o plugin é responsável por dizer ao servidor quais as páginas que podem ser guardadas em cache, durante quanto tempo, e por ativar a limpeza com etiquetas.

A força principal do LiteSpeed Cache vem de “Armazenamento em cache de páginas ao nível do servidor (LSCache)”. Sem os servidores LiteSpeed/OpenLiteSpeed, não existe essa vantagem essencial.

2.1 Cache LiteSpeedpara quem

Em forma:

  • O seu painel de alojamento está claramente identificado LiteSpeed / OpenLiteSpeed(por exemplo, muitos anfitriões cPanel escreverão)
  • Pretende “uma solução gratuita que também possa funcionar com TTFB e concorrência fortes”.”
  • Está disposto a aceitar: é muito poderoso, mas também mais concetual (TTL, Tag, Purge, ESI, Crawler...)

Não é bem assim:

  • Não tem a certeza de qual é o servidor Web do anfitrião, nem confirma que é o Nginx/Apache (a menos que pretenda utilizar apenas algumas das suas funcionalidades de otimização de front-end, mas nesse caso o preço/desempenho e a complexidade não são necessariamente rentáveis)
  • É um sítio complexo de comércio eletrónico/filiação/multilínguas, 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 O seu mecanismo de cache: porque é que é mais uma “parte da capacidade do servidor”

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

  • WP Rocket / WP Super Cache Isto é mais sobre o lado WordPress/PHP do caching e da otimização;
  • LSCWP É uma combinação do Painel de Controlo do WordPress + o LSCache integrado do LiteSpeed Server: o plugin é responsável pela emissão de regras e sinais de limpeza, e o verdadeiro cache de páginas de alta velocidade acontece nocamada de servidor。

Isto tem um impacto direto na experiência do sítio Web: o caching de cuspo ao nível do servidor é normalmente mais leve, mais rápido e mais concorrente (especialmente com picos de tráfego e visitas de alta frequência de rastreadores de motores de busca).

2.3 A “forma correta” de abrir o LSCWP para cenários de utilizadores de sítios Web”

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

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

  • Clarificar quais as páginas que podem ser colocadas em cache (a maioria das páginas de conteúdo público)
  • Definir claramente quais as páginas que nunca devem ser colocadas em cache (início de sessão, conta, carrinho de compras, checkout, páginas de mudança de língua/moeda que dependem de cookie forte)
  • Defina um TTL razoável para a 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 etiqueta relevante após a atualização do conteúdo (em vez de fazer uma limpeza de força bruta em todo o sítio)

Esta camada, se for feita corretamente, é mais diretamente visível para o sítio Web como a TTFB em baixo, primeiro ecrã 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 sítio Web resulta de “diferenças entre quente e frio” no armazenamento em cache:

  • As páginas populares são sempre visitadas e a cache está sempre ativa
  • 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 no topo do bolo, é a chave para uma experiência consistente do visitante do sítio Web

Camada 3: Programas de segurança para conteúdos dinâmicos (comércio eletrónico/membros/multilinguismo)

O poder do LSCWP reside no facto de lhe dar uma série de “ferramentas avançadas”, por exemplo:

  • Estratégias de armazenamento em cache diferenciadas para utilizadores com sessão iniciada, utilizadores com comentários, etc.
  • A ideia central da Edge Side Inclusion (ESI) é dividir a página em "corpo público armazenável" e "fragmentos dinâmicos não armazenáveis", que são processados separadamente e depois unidos nos nós de extremidade.

Nível 4: Serviços em linha e melhorias opcionais

Muitos webmasters considerarão os serviços em linha da QUIC.cloud (por exemplo, serviços do tipo otimização na página) úteis no LSCWP.Documentação QUIC.cloudEstá explicitamente escrito que fornece serviços de otimização on-page ao LSCWP, incluindo Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) e outros.

  • Este tipo de serviço é facultativo: pode utilizar apenas a cache do servidor e não ativar a otimização em linha
  • Assim que os serviços em linha forem activados, os recursos do seu sítio/ligações de processamento de páginas serão alterados (esta é uma informação importante para empresas/clientes sensíveis à privacidade)

2.4 Fosso comum LSCWP

  1. O servidor não é LiteSpeed, mas usa o LSCWP como um plugin de cache completo
    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 a pilha do host primeiro; se não LiteSpeedPor exemplo, considere o WP Rocket ou o WP Super Cache.
  2. A ativação de demasiadas optimizações de front-end conduz a anomalias funcionais
    As optimizações na página (CSS/JS) são frequentemente mais susceptíveis de causar problemas de compatibilidade do que a própria “cache”. Sugestão: execute primeiro a cache da página, depois active as optimizações uma a uma e crie uma lista de testes de regressão (formulários, menus, pagamentos, rastreio, mudança de língua, etc.).
  3. Falta de estratégias de exclusão/slicing para páginas dinâmicas
    Incidentes típicos: cache do carrinho de compras, do checkout, da página da conta; ou mudança incorrecta para vários idiomas/multidivisas. Os sítios de comércio eletrónico devem considerar isto como uma verificação de pré-lançamento (e os funcionários do WooCommerce também salientam)Não colocar páginas-chave em cache）。

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

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

A página do plugin também menciona que: o HTML estático será servido à grande maioria dos utilizadores não registados, e dá uma declaração muito intuitiva - “os visitantes do 99% serão servidos com ficheiros HTML estáticos”, e um único ficheiro em cache pode ser servido milhares de vezes.

3.1 A quem se destina o WP Super Cache?

Altamente recomendado:

  • Blogues, sítios de conteúdos multimédia, sítios de documentos, sítios de apresentação de empresas, páginas de destino
  • Os visitantes são principalmente utilizadores não registados
  • Pretende: gratuito, estável, com baixos custos de manutenção

Utilizar com precaução/necessidade de estratégias mais fortes:

  • Sítio fortemente dinâmico: muitos conteúdos personalizados, páginas que mudam de acordo com o estado do utilizador
  • Grande comércio eletrónico: pode funcionar, mas certifique-se de que as páginas principais não são colocadas em cache e de que trabalha com o seu processo de teste

3.2 Os seus três métodos de caching:

A descrição do plugin WP Super Cache lista 3 métodos de cache por velocidade e explica as diferenças:

  • mod_rewrite (especialista): o mais rápido, contornando completamente o PHP, mas precisa de alterar o .htaccess, uma configuração incorrecta pode levar a um maior risco de indisponibilidade do site!
  • Simples (abordagem recomendada)ficheiros estáticos “super cacheados” fornecidos pelo PHP, próximos da velocidade do mod_rewrite, mas mais fáceis de configurar.
  • Cache do WP-Cachemais flexível para utilizadores conhecidos, URLs com parâmetros, feeds de subscrição, etc., mas mais lento

Escolha recomendada:

  • Principiantes/estabilidade: utilizar o método recomendado (simples)
  • Está familiarizado com as regras do servidor e está disposto a correr o risco de as reescrever: considere novamente o modelo de perito!
  • Precisa de um tratamento mais flexível de “Utilizador conhecido/com parâmetros”: Compreender o posicionamento da WP-Cache

3.3 Pontos fortes e fracos do WP Super Cache

Vantagem:

  1. Ideal para utilização com o CDN.
    Uma vez que está essencialmente a “gerar HTML estático”, isto encaixa-se naturalmente na ideia do CDN/cache de borda.
  2. As melhorias na estação fonte CPU/pressão da base de dados são muito simples
    Os motores de busca e os rastreadores das redes sociais também podem vir de todo o mundo quando o tráfego do sítio Web está disperso. A estatização é eficaz no combate ao “re-rendering”.

Prancha curta:

  1. Não se trata de uma “suite de otimização de desempenho tudo-em-um”.”
    É principalmente forte no caching de páginas, e as optimizações CSS/JS profundas não são tão empacotadas como no WP Rocket. Poderá ser necessário fazer mais na “Página de otimização de imagens” e na “Página de otimização de front-end” (ou utilizar outras optimizações ao nível do plugin/tema).
  2. Seja mais cauteloso com a “personalização dinâmica”
    Por exemplo, apresentar conteúdos diferentes por região, apresentar preços/idiomas/recomendações diferentes por estado do utilizador, etc. Nesta altura, é necessário criar uma política de exclusão ou introduzir um esquema de cache mais adequado.

3.4 Compatibilidade com o WooCommerce: porque é “mais seguro”

Ajuda oficial do WooCommerceMencionado: o WooCommerce é nativamente compatível com o WP Super Cache e o WooCommerce envia uma mensagem ao WP Super Cache para que não armazene em cache as páginas Carrinho, Finalizar compra, Minha conta por padrão.

  • Mesmo que seja novo no WP Super Cache + WooCommerce, é muito menos provável que pise a mina das “páginas-chave colocadas em cache”!
  • No entanto, continua a recomendar-se a realização de testes de regressão antes da entrada em funcionamento (pagamentos, cupões, envios, taxas de imposto, várias moedas, etc.).

Plugin 4:W3 Total Cache (W3TC)--O “quadro de desempenho” mais versátil para as equipas de engenharia.

W3 Total Cache Em vez de um “plugin de cache único”, o WordPress.org está posicionado como algo mais parecido com uma “estrutura de otimização do desempenho do site”: enfatiza a melhoria de SEO, Core Web Vitals e experiência geral através da integração do CDN e das melhores práticas. Sinais vitais e experiência geral através da integração do CDN e das melhores práticas.

A descrição do plugin enumera uma vasta gama de capacidades: cache de páginas/postes, cache de CSS/JS, cache de feeds, cache de resultados de pesquisa, cache de objectos de base de dados, cache de objectos, cache de fragmentos (fragment cache) 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 AMP, integração de proxy reverso (Nginx/Varnish) e assim por diante.

4.1 A quem se destina o W3 Total Cache?

Ideal para:

  • Tem competências de desenvolvimento/operacionais e está disposto a fazer “ativação + testes de pressão + testes de regressão”.”
  • O seu sítio é complexo: multi-idioma, alternância de vários temas, diferenciação móvel, estrutura de conteúdos complexa
  • Não se pretende apenas o armazenamento em cache de páginas, mas também incorporar o armazenamento em cache de objectos/fragmentos no sistema (especialmente para sítios dinâmicos)

Não serve:

  • Quer “instalar e pronto”, não quer compreender as hierarquias das cache.
  • Não tem um processo de teste, mas pretende ativar itens de alto risco, como a compressão e os scripts atrasados, de uma só vez

4.2 Porque é “forte mas complexo”: os sítios Web valorizam a “controlabilidade”.”

O valor do W3TC não reside no facto de “ter de ser mais rápido do que todos os outros”, mas sim no facto de lhe dar botões de controlo suficientes para conceber uma estratégia de desempenho:

  • Cache de páginas: pode estar na memória, no disco ou no CDN
  • Cache de objectos da base de dados, cache de objectos: Redis/Memcached disponível, etc.
  • Cache de fragmentos: bom para “páginas semi-dinâmicas”
  • Suporte móvel: armazenamento em cache de páginas por referenciador ou grupo de agentes do utilizador, respetivamente
  • Gestão CDN: Gestão transparente CDN de bibliotecas multimédia, ficheiros de temas, etc.

Estas capacidades são especialmente valiosas para sítios Web, onde o acesso global é frequentemente encontrado:

  • Variantes da mesma página em diferentes dispositivos, em diferentes regiões, em diferentes línguas
  • Alguns conteúdos podem ser armazenados em cache, outros têm de ser em tempo real (por exemplo, preço, inventário, estado do utilizador)

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

Encomenda recomendada:

  1. Comece por ativar apenas o caching de páginas
    Verificar: a TTFB está desactivada, o conteúdo é consistente, os processos-chave do estado de início de sessão/multilingue/e-commerce estão a funcionar.
  2. Reativar a cache do navegador
    Objetivo: Fazer com que as visitas de retorno e os recursos estáticos carreguem mais rapidamente e reduzir os descarregamentos repetidos em todos os continentes.
  3. Reavaliar a cache de objectos / cache de objectos da base de dados
    Aplicável: Sítio dinâmico (WooCommerce, sistema de membros, consulta complexa).
    N/A: As estações só de conteúdo podem ter um retorno limitado ou mesmo aumentar o consumo de recursos.
  4. Compressão do toque final / Script de latência / Otimização do front-end
    Uma vez que esta é a camada mais suscetível de desencadear anomalias funcionais, deve ser criada uma lista de testes de regressão (pagamentos, formulários, rastreio, pop-ups, menus, mudança de língua, etc.).

Lembrete do WooCommerce para “Configuração do plug-in de cache”Páginas críticas não são armazenadas em cache e recomenda-se que se evite a compressão de ficheiros JS.

Matriz de comparação dos quatro plug-ins

Nota: Não se trata de “quem é melhor”, mas sim de “quem se adequa melhor ao seu cenário”.

dimensão (matemática)WP FoguetãoCache LiteSpeedWP Super CacheW3 Total Cache
posicionamento centralIntegração que permite poupar tempo (armazenamento em cache + otimização)Cache ao nível do servidor (depende da LSCache)Armazenamento em cache de HTML estáticoEstrutura de desempenho (várias camadas de cache + CDN)
dependente do hospedeiroBaixo (universal)Alta (requer LiteSpeed/OpenLiteSpeed para funcionar como cache de núcleo)Baixo (universal)Média (universal, mas mais dependente do ambiente/configurabilidade)
Custos de aprendizagemmédio-baixoMédio低Alto
Recomendação de Content StationMuialtoMuito elevado (desde que seja cumprido)MuialtoMédio-alto (dependendo da equipa)
Sítio de comércio eletrónico/filiaçãoDisponível, mas excluir com precaução (as páginas principais do WooCommerce não são armazenadas em cache)Disponível, mas mais necessidade de regras/estratégias de corteestá disponível, e o WooCommerce menciona a compatibilidade nativa e a ausência de armazenamento em cache das páginas principais por defeitoDisponível e adequado para controlo de engenharia
orçamentocobrir os custosfreewarefreewareVersão gratuita + paga

“Incidentes com a cache” e lista de controlo de prevenção

1. as três causas principais do “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 guardados em cache. Os funcionários têm repetidamente sublinhado Carrinho/Checkout/Conta não deve ser armazenado em cache.

B. As variantes multilingues/multidivisas/regionais não são armazenadas corretamente em cache

Se o seu sítio apresenta conteúdos diferentes com base em cookie, parâmetros de consulta e localização geográfica, então a cache deve ter em conta as “dimensões variantes”. Caso contrário, as caches geradas por utilizadores da região A podem ser reutilizadas por utilizadores da região B.

C. Reescrita da otimização do front-end (JS/CSS) que conduz a anomalias funcionais

Em particular, a compressão JS, a fusão e a execução diferida.Evitar a compressão de ficheiros JS。

2. lista de verificação dos testes de regressão antes do lançamento

  • O início/fim de sessão é normal
  • Os envios de formulários (formulário de contacto, subscrição, registo de início de sessão) estão a funcionar corretamente
  • Processo de comércio eletrónico: adicionar compra → cupão → envio/impostos → pagamento → página de encomenda
  • Estabilidade da comutação multilingue (conteúdo, URLs, hreflang, moeda após a comutação)
  • Menus móveis, pop-ups, deslocação e carregamento lento estão a funcionar corretamente
  • Verificar se os scripts ainda estão a ser activados (GA, Meta Pixel, eventos de transformação)

problemas comuns

Q1：Porque é que o acesso ao estrangeiro continua lento, apesar de ter instalado o plugin de cache?

A razão mais comum para isso é o facto de só ter resolvido a “renderização duplicada na origem”, mas não a “latência de rede intercontinental”.
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 RTT para links globais ainda precisam ser CDN para encurtar a distância.
Portanto, o caminho correto é:Em primeiro lugar, tornar estável a cache da estação de origem.E depois CDN para distribuição global.。

P2: Porque é que o conteúdo não é atualizado depois de o alterar após a colocação em cache?

Porque está a ver a “cache antiga”. Ideia de solução:

  • Criar uma estratégia de limpeza: limpar a cache correspondente depois de atualizar artigos/páginas (em vez de limpar todo o sítio)
  • Para cenários com aquecimento/rastreadores: limpar e depois aquecer, caso contrário a primeira visita será lenta
  • Para o CDN: é necessário ter em conta que as extremidades do CDN também podem armazenar em cache recursos antigos

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

Não recomendado. Um plugin de cache de página de cada vez é o mais estável. Pode interpretar a ideia de “um para o caching e outro para a otimização” como uma “divisão do trabalho”, mas, na realidade, estes plugins tocam frequentemente no caching de páginas/reescrita de recursos e a probabilidade de conflito é elevada. É mais recomendável escolher um “plugin de cache principal”, outras necessidades com uma ferramenta única mais clara para compensar.

P4: Não é perigoso utilizar o armazenamento em cache para sítios de comércio eletrónico?

Não é perigoso, o que é perigoso é a “ausência de regras”.Recomendações do WooCommerceÉ muito claro: os carrinhos/contas não são guardados em cache e a compressão JS é evitada.
Além disso, o WooCommerce também menciona que funciona com o Compatibilidade com o WP Super Cache Nativoe evitar o armazenamento em cache de páginas críticas por defeito.
Assim, o sítio de comércio eletrónico pode ser colocado em cache, mas tem de ser testado como uma “alteração em direto”.

Q5: Devo escolher LiteSpeed Cache ou WP Rocket?

  • Tem a certeza de que o anfitrião é o LiteSpeed/OpenLiteSpeed?Cache LiteSpeed prioritária (gratuita e forte, com os principais benefícios da LSCache ao nível do servidor)
  • Não tem a certeza sobre a pilha de alojamento / não quer comprometer-se / quer integrar e poupar.WP Rocket: o WP Rocket é mais estável
  • É um sítio de conteúdos e é sensível ao orçamentoWP Super Cache: o WP Super Cache é mais estável e mais leve.

Plug-in de cache com CDN

O plugin 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 utilizadores globais”. A sobreposição dos dois é a solução óptima comum para o acesso global.

  • Uma combinação comum de estações de conteúdos:Cache de página + Distribuição estática CDN
  • Combinações comuns de estações dinâmicas:Cache de páginas (controlo de exclusão rigoroso) + Cache de objectos (a pedido) + distribuição estática CDN

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

Combinações recomendadas para o armazenamento em cache de sítios Web

1. sítio de conteúdos / blogue / sítio de documentos

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

1.1 A combinação de negócios mais simples

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

Aplicável:

  • Pretende “baixa configuração, resultados rápidos, baixo risco”.”
  • Temas/plugins em abundância, quero reduzir a compatibilidade

Pontos de atenção:

  • As optimizações de front-end (especialmente a latência JS) são activadas por fases para evitar anomalias funcionais (menus, formulários, rastreio, etc.)
  • Os sítios de revisão/publicação frequente 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ática)Gerar HTML estático a partir de páginas dinâmicas, principalmente para utilizadores não registados.

Aplicável:

  • Orçamento sensível mas estável
  • Os visitantes basicamente não iniciam sessão
  • Ritmo controlado de actualizações de conteúdos

Pontos de atenção:

  • É uma combinação de “cache de página primeiro”, não espere que resolva todas as complexidades de CSS/JS pelo caminho!

2. sítio da empresa / sítio da marca / página de destino

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

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

  • WP Foguetão
  • + (opcional) otimização ligeira de imagens (tem uma página “Otimização de imagens”)
    • CDN

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

  • Os sítios que convertem têm receio de que “os formulários/popups/scripts de rastreio sejam danificados pela otimização”
  • O WP Rocket é mais “integrado” no sentido em que pode ativar e testar regressivamente cada item num sistema.

O “princípio em linha” do sítio Web da empresa:

  • A otimização do desempenho é uma “alteração go-live” e deve ter uma lista de verificação de testes de regressão
  • Quaisquer definições que envolvam latência/fusão/compressão JS devem ser verificadas num ambiente de pré-lançamento antes de serem activadas!

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

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

Os pontos oficiais do WooCommerce para o plugin de cache são muito claros:Carrinho de compras / Finalização da compra / Página da conta Não armazenar em cacheRecomenda-se também que a compressão de ficheiros JavaScript seja evitada para minimizar os problemas de compatibilidade.

3.1 Percursos gratuitos e seguros que são mais “amigos dos novatos”

  • WP Super Cache + WooCommerce
    • CDN

Porque é que está listado como um “local mais seguro para começar”:

  • O WooCommerce menciona oficialmente que é nativamente compatível com o WP Super Cache e informa o WP Super Cache de que, por defeito, não armazena em cache páginas-chave como o carrinho/checkout/contas.
  • Para os sítios que se iniciam no comércio eletrónico, “não ter acidentes primeiro” é mais importante do que “desempenho extremo”.

3.2 Se estiver a utilizar um anfitrião LiteSpeed (gratuito mas potente)

  • Cache LiteSpeed (tem de ser um anfitrião LiteSpeed/OpenLiteSpeed para tirar partido da cache do servidor principal)
  • + (opcional) armazenamento em cache de objectos (Redis/Memcached, dependendo da capacidade de alojamento e da dimensão do sítio)
    • CDN

Aplicável:

  • A pilha do anfitrião é clara e está disposto a estabelecer regras de armazenamento em cache e políticas de exclusão
  • O volume de encomendas e mercadorias é elevado, sendo necessária uma estação de origem mais forte para suportar a pressão.

3.3 Equipas de engenharia/comércio eletrónico complexo (controlável por vários módulos)

  • W3 Total Cache (estrutura de desempenho, camada multi-cache integrada com CDN)
    • Armazenamento em cache de objectos (a pedido)
    • CDN

Aplicável:

  • Com o Dev/Ops, pode entrar em ação com “Ativação passo-a-passo do módulo + testes de pressão + testes de regressão”.
  • Necessidade de armazenamento em cache de fragmentos / variantes mais complexas da estratégia (por exemplo, armazenamento em cache de granularidade fina por dispositivo/região/língua)

4. sítio de membros / comunidade / cursos em linha (muitos logins, forte personalização)

Objetivo: Tornar o conteúdo público rápido, assegurando ao mesmo tempo que “os utilizadores com sessão iniciada não têm cadeias de conteúdo”.

4.1 Salvar, mas é necessário adotar estratégias de exclusão rigorosas

  • WP Foguetão
  • + (opcional) armazenamento de objectos em cache (se as consultas dinâmicas forem numerosas)
    • CDN

Pontos-chave:

  • Deve excluir do armazenamento em cache as páginas “alteradas pelo utilizador”: Centro pessoal, Encomendas, Progresso dos estudos, Mensagens, Carrinho de compras, etc.
  • Este tipo de sítio é o mais propenso a “ver o conteúdo de outras pessoas/permissões incorrectas” e os riscos devem ser explicitados na página.

4.2 LiteSpeed Hosting + Política Avançada

  • LiteSpeed Cache (armazenamento em cache do servidor + ferramentas de política mais sofisticadas)
  • + armazenamento em cache de objectos (a pedido)
    • CDN

Pontos-chave:

  • Os sítios de membros tendem a necessitar mais de uma mentalidade de “corpo armazenável + fragmento não armazenável”.
  • As estratégias de aquecimento e limpeza têm de ser mais refinadas, caso contrário, a frase “os utilizadores continuam a ver conteúdos antigos após a atualização” será muito frequente

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

Caso 1: Instalado o plugin de cache, a velocidade mantém-se praticamente inalterada

Fenómeno:

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

Causas comuns:

  • Só faz caching de fonte (TTFB), mas os recursos estáticos (imagens/JS/CSS/fonts) continuam a ser carregados a partir da fonte em todos os continentes
  • Os scripts de terceiros (anúncios, chat, estatísticas) tornam a renderização e a interação mais lentas
  • Descarregamentos lentos devido a imagens de grandes dimensões (o armazenamento em cache não resolve o problema do tamanho do “primeiro descarregamento”)

Ideia de solução:

  • O plugin de cache trata primeiro da “subcontagem da fonte + hits”.”
  • Os recursos estáticos vão para CDN
  • Otimização de imagens de distância
  • Os scripts de terceiros utilizam estratégias de atraso/separação

Leitura:

Caso 2: Depois de 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 é apresentada no frontend
  • Ou apenas algumas regiões são actualizadas e outras permanecem inalteradas (comum para estações globais)

Causas comuns:

  • A cache de páginas não foi limpa ou foi limpa de forma incorrecta
  • O aquecimento/rastreador não está a funcionar, a cache limpa arrefece, o que resulta numa primeira visita lenta, enquanto o utilizador pensa erradamente que não há atualização
  • Se ativar o caching de borda do CDN, a borda também pode reter recursos antigos

Ideia de solução:

  • Criar uma “estratégia de limpeza após o lançamento/revogação”: limpar as páginas relevantes, não uma limpeza profunda em todo o sítio
  • Criar uma estratégia de aquecimento para páginas importantes (página inicial, páginas de destino principais) para evitar “limpar = abrandar”
  • CDN Camada para efetuar a limpeza dos bordos quando necessário

Caso 3: Conteúdo extraviado após mudança de língua/multimoeda

Fenómeno:

  • A página continua a mostrar a língua anterior depois de mudar de língua
  • Ou os utilizadores de determinadas regiões vêem a moeda errada/conteúdo errado

Causas comuns:

  • A cache não faz distinção entre “dimensões variantes” (cookie / parâmetros / prefixos de língua / subdomínios).
  • Cache Hit dá resultados de páginas no idioma A a utilizadores do idioma B

Ideia de solução:

  • Defina o seu programa multilingue: diretories/subdomains/parameters/cookie
  • Adicionar “políticas de variantes” às regras de armazenamento em cache ou excluir páginas-chave
  • Alguns sítios requerem ideias mais avançadas de caching “slice and dice” (o W3TC é mais adequado para o controlo de engenharia).

Caso 4: Problemas com o carrinho de compras/checkout num sítio de comércio eletrónico com o armazenamento em cache ativado

Fenómeno:

  • Carrinho de compras com quantidade errada, preço errado, botão de checkout não funciona
  • Iniciar sessão e ver conteúdos que não lhe pertencem (a sério)

Causas comuns:

  • As páginas críticas, como Carrinho/Checkout/Minha conta, são armazenadas em cache.
  • JS minify/merge causa incompatibilidade de pagamento/componente dinâmico

Ideia de solução:

  • O WooCommerce é oficial: o carrinho/checkout/contas não deve ser guardado em cache e recomenda-se que se evite a compressão de ficheiros JS.
  • Executar primeiro “cache de página + excluir”, depois considerar a otimização do front-end
  • Se utilizar o WP Super Cache, o WooCommerce menciona que é nativamente compatível e evita o armazenamento em cache de páginas-chave por defeito.

Caso 5: Menu/formulário/popup quebrado depois de ativar “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 submetida
  • Exceção de popup/rollup
  • As estatísticas/eventos de conversão não são activados (o maior problema para os sítios de lançamento)

Causas comuns:

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

O WP Rocket descreve oficialmente a “execução JS diferida” como uma das suas optimizações JS mais fortes: os scripts são diferidos até depois da interação do utilizador para dar prioridade à apresentação da página. Trata-se de uma grande capacidade, mas também significa um maior risco de compatibilidade.

Ideia de solução:

  • Ativar por fases: cache, depois imagens, depois CSS, depois JS.
  • Adicionar exclusões aos scripts principais (pagamentos, formulários, menus, rastreio)
  • Fazer uma lista de verificação de testes de regressão para cada alteração

Caso 6: Apenas a Cache LiteSpeed está instalada, mas não parece estar a funcionar.

Fenómeno:

  • A cache LiteSpeed está activada, mas o TTFB não está a baixar muito.
  • Os êxitos também não são óbvios

Causas comuns:

  • Seu servidor não é LiteSpeed/OpenLiteSpeed e não pode usar os recursos principais do LSCache
  • Ou talvez tenha ativado uma série de optimizações, mas a “política de cache de páginas/preheat/exclude” não foi criada!

Ideia de solução:

  • Verifique primeiro a pilha do host: é LiteSpeed/OpenLiteSpeed (este é um pré-requisito)
  • Voltar a colocar o foco na “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