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

Se você dividir a otimização do desempenho do WordPress em três camadas:

  • camada da estação de origem: Hospedagem / PHP / Banco de dados / Plug-ins de cache - Decidindo sobre TTFB e estresse de back-end
  • camada de recursosOtimização de imagem - determinando o tamanho e a velocidade do download da primeira imagem grande
  • camada de entrega:: CDN -- Recursos de decisão mais próximos dos visitantes, resultados mais consistentes, estações de origem mais fáceis

este documento CDN Aceleração：

  • Saiba o que o CDN faz e não resolve.
  • Selecione o formulário CDN e o provedor de serviços mais adequado para você (e entenda os limites da versão gratuita/versão inicial)
  • Entrar no ar em ordem de baixo risco, sem derrubar o site ou ter um incidente com o cache de comércio eletrônico/associação
  • Verifique se “está funcionando” e solucione os problemas “por que não está atualizando/por que está ficando lento/por que está com o conteúdo em cadeia” quando for ao ar.”

1. vamos esclarecer os conceitos: o que o CDN resolve e o que ele não resolve.

1.1 O CDN aborda três questões principais

1.1.1 Entrega mais rápida de recursos estáticos
Recursos estáticos, como imagens/CSS/JS/fontes/ícones, estão mais próximos do visitante, são baixados mais rapidamente e renderizam a página de forma mais consistente.
Para o WordPress, especialmente temas e recursos de plug-in (wp-content/themes/、wp-content/plugins/), bem como imagens da galeria de mídia (wp-content/uploads/) geralmente é o mais “volumoso”.

1.1.2 Pressão reduzida nas estações de origem
Depois de atingir o cache de borda, as solicitações não são mais retornadas à origem com a mesma frequência, e a largura de banda, as conexões simultâneas, o IO de disco e as flutuações do CPU na origem são mais leves.
Isso é especialmente verdadeiro para cenários de ondas, como “páginas de eventos, explosões de artigos e páginas de produtos que recebem muitas visitas”.

1.1.3 Estabilidade aprimorada (mais resistente a flutuações)
Quando o tráfego aumenta, os nós de borda absorvem um grande número de solicitações duplicadas, e a estação de origem tem muito menos probabilidade de ser prejudicada.
Você verá um “acesso mais suave”: o cache de borda continua a produzir mesmo quando o site de origem está momentaneamente estressado.

1.2 3 Tipos de problemas que o CDN não resolve automaticamente

1.2.1 A própria estação de fonte lenta
Bancos de dados lentos, lógica de plug-in lenta, cálculos PHP lentos - esses são problemas no nível do site de origem.
O CDN pode tornar os recursos estáticos mais rápidos, mas se até mesmo o HTML da página inicial for gerado muito lentamente, o usuário ainda sentirá que “abre devagar”. Desta vez, a prioridade volta a ser: hospedagem / cache de plug-ins / otimização de banco de dados.

1.2.2 A imagem em si é muito grande
O CDN não pode “reduzir magicamente” o tamanho do quadro geral do 3MB.
Primeiro, você deve otimizar a imagem: estratégia de dimensionamento (não baixe imagens muito grandes), compactação, WebP/AVIF, estratégia de carregamento lento etc.

1.2..3 Scripts de terceiros lentos
Anúncios, estatísticas, atendimento ao cliente, componentes de mídia social, etc. são provenientes de domínios de terceiros.
O CDN normalmente não pode ajudá-los a serem “mais rápidos”, você só pode lidar com isso reduzindo/atrasando o carregamento, substituindo fornecedores ou fazendo otimizações de políticas de script.

sugestão

Obter primeiro as camadas de origem e de recursos corretas e depois fazer o CDN será mais eficaz e menos problemático.

2. Seleção de 30 segundos: Qual formulário CDN você precisa?

Para o WordPress, há duas categorias principais. Se você escolher “Formato” e depois “Provedor de serviços”, a ideia ficará bem clara.

2.1 “Tipo de proxy reverso” tudo em um (menos esforço, adequado para a maioria dos sites)

**Recursos:** Não é apenas CDN, mas também coloca o DNS / SSL / Proteção básica de segurança (por exemplo, DDoS/WAF) Empacotados juntos. Você o acessa e ele fica na frente do seu site como um proxy.

O que você receberá:

  • HTTPS Gerenciamento mais fácil de certificados e TLS
  • Portal de segurança unificado (DDoS básico, controle de acesso, WAF, etc.)
  • Cache de borda com mecanismo de regras (pode fazer políticas de cache mais granulares, ignorar políticas)
  • “Mais espaço para expansão”: se você quiser adicionar segurança, limites de velocidade e proteção contra bots posteriormente, geralmente tudo isso está no mesmo sistema.

**Representantes:** Cloudflare / Tencent Cloud International EdgeOne / AliCloud International ESA

Se você desejar:

  • Você deseja. HTTPS + CDN + Segurança básica fazer tudo de uma só vez
  • Você gostaria de unificar a camada de resolução de nomes de domínio/proxy em uma única plataforma?
  • Você está mais interessado na “experiência geral e na expansão subsequente” e não quer dividir o DNS, os certificados, o CDN e a segurança em vários conjuntos.

2.2 Pure “Static Pull CDN” (início de baixo risco, principalmente aceleração de imagens/CSS/JS)

**Características:** Você só coloca recursos estáticos no cache de borda do CDN; as páginas HTML ainda são tratadas pela origem (e pelo plug-in de cache de origem).

O que você receberá:

  • Risco comercial muito baixo: não há “encadeamento de conteúdo/cartão” se você não mexer no HTML”
  • A modelagem de custos é mais intuitiva: geralmente cobrada por tráfego/requisição/região
  • Uma estrutura mais pura: mais parecida com um “serviço de distribuição de recursos estáticos”.”

**Representante:** bunny.net (o modelo de faturamento baseado em volume é claro)

Se você desejar:

  • Você quer dar o “passo mais seguro” primeiro: aceleração de recursos estáticos.
  • Você deseja obter a receita rapidamente antes de decidir se deve ou não usar o cache do tipo proxy/do site completo
  • Você quer que o custo seja mais próximo de “pagar pelo que você usa”.”

3. como fazer isso

  • Nível 1: Tipo de agente integrado (preferencial): Cloudflare / EdgeOne / ESA
  • Nível 2: Puxada estática CDN (início sólido): bunny.net / Cloudways CDN etc.

4. provedores de serviços recomendados

4.1 CloudflareIntegração de proxy reverso (início gratuito, ecologicamente maduro)

O que é isso?
Você conecta o domínio e ele fica na frente do site como um proxy, fornecendo CDN, certificados, proteção de base e recursos de regras de cache.

para quem

  • Quer economizar: HTTPS + CDN + segurança básica em um único pacote
  • Deseja um ecossistema maduro: acompanhamento para adicionar WAF, limite de velocidade, regras de borda, etc., o caminho é tranquilo

ponto de risco

  • As atualizações não entram em vigorLinks de cache mais longos (cache do navegador + cache do CDN + cache de origem) depois que o CDN entrou em operação, precisa de uma “política de controle de versão” para tornar as atualizações controláveis (árvore de solução de problemas mais tarde)
  • Cuidado com o HTML em cacheSe o HTML for armazenado em cache, as páginas de comércio eletrônico/filiação/personalização devem ser estritamente ignoradas ou estarão sujeitas a acidentes graves (segue uma lista de cenários)

instruções：

  • Posicionamento: integração de proxy reverso (SSL + CDN + proteção básica)
  • Adequado para: economia on-line, grande espaço para expansão posterior
  • Valor principal: certificado unificado/portal de segurança/cache
  • Riscos: as atualizações dependem de políticas de controle de versão; o cache de HTML precisa ser contornado com firmeza

4.2 Tencent Cloud International EdgeOneIntegração de proxy reverso

O que é isso?
O formulário também é uma plataforma completa de “aceleração + segurança + certificados”, que é adequada para colocar sites no gerenciamento unificado da camada de agentes.

  • tem uma versão gratuita, como o Cloudflare, mas geralmente há Cota/teto funcional(número de regras, número de tarefas de registro, etc.), mas não são necessárias modificações no DNS, apenas acesso ao cname.A versão gratuita não é recomendada para sites comerciais！
  • Enquanto isso, planos gratuitos geralmente significam SLA não garantido
    Ele funciona, mas não como um “pacote de SLA comercial”.
  • Se você quiser alternar automaticamente entre as linhas da China continental na China continental, normalmente precisará primeiro preencher o formulárioRegistro do ICP da ChinaSomente as rotas internacionais podem ser usadas quando não estão registradas.

Descrição:

  • Posicionamento: integração de proxy reverso (aceleração + segurança + certificados)
  • Ideal para: aqueles que desejam acesso integrado e estão considerando a capacidade do nó na China continental
  • Gratuito: existem planos gratuitos/versões gratuitas, mas as cotas são limitadas e os SLAs geralmente não são garantidos
  • Riscos: as cotas de regras/logs/subdomínio devem ser planejadas com antecedência; o armazenamento em cache de HTML deve ser igualmente cauteloso

4.3 Aliyun International ESAIntegração de proxy reverso

  • tem uma versão gratuita, como o Cloudflare, mas geralmente há Cota/teto funcional(número de regras, número de tarefas de registro, etc.), mas não são necessárias modificações no DNS, apenas acesso ao cname.A versão gratuita não é recomendada para sites comerciais！
  • Registre-se para obter uma conta no site internacional para usar
  • Vá para o console do ESA para adicionar um site e selecione a opção gratuita Entrada acesso à assinatura
  • Se você quiser mudar automaticamente para a linha da China continental na China continental, normalmente precisará concluir primeiro o registro do ICP; você só poderá ir para a linha internacional se não tiver feito o registro.
  • A versão gratuita é mais adequada para desenvolvimento/testes/avaliação e geralmente não é equivalente aos pacotes de SLA comerciais.
  • Os pacotes gratuitos geralmente têm limites de velocidade/restrições de método de suporte (por exemplo, SLAs, etc.)

Sobre a linha da China continental:

  • Para habilitar os nós da China continental, você geralmente precisa atender às condições regionais e de arquivamento
  • Entrada gratuita Rota internacional padrão, se desejar usar a rota da China continental, deve ser preenchida.Requisitos de registro do ICP da China

Descrição:

  • Posicionamento: integração de proxy reverso (aceleração de site + segurança)
  • Grátis: conta de estação internacional disponível Acesso gratuito à entrada; o padrão não inclui a aceleração da China continental
  • Ideal para: avaliação/teste com uso leve; ou pacote de upgrade subsequente
  • Riscos: limites livres a serem observados (SLAs/limites de velocidade/métodos de suporte); zonas e registros a serem planejados com antecedência

4.4 bunny.netStatic Pull CDN (início de baixo risco, faturamento claro por volume)

Se você quiser “obter os ganhos mais seguros primeiro”, um Pull CDN como o bunny é uma boa opção:
É mais parecido com um “serviço de entrega de recursos”: você fornece recursos estáticos para serem entregues, o custo geralmente está relacionado ao tráfego/solicitações/região, e o modelo é claro e controlável.

Em forma:

  • fazer algo primeiro Imagens / CSS / JS / Fontes Aceleração estática de
  • Primeiro, você deseja obter uma “renda estável e de baixo risco” e não tem pressa em transferir todo o site para uma plataforma do tipo proxy (DNS/SSL/WAF tudo em um).
  • Você deseja que o modelo de custo seja mais próximo de “pagar pelo que usar”, em vez de entrar em um pacote mais complexo logo de cara.

ponto de risco

O recurso estático “atualizações não entram em vigor” quase sempre não é um bug no CDN.Em vez disso, é um comportamento normal do sistema de cache:
Quando você atualiza CSS/JS/imagens no backend, mas oO URL do recurso não foi alterado.(mesmo endereço/nome de arquivo/caminho), o CDN e o navegador continuarão razoavelmente a acessar o cache antigo, e você verá “por que ele não está atualizado”.

Um princípio claro e aplicável:

Os números de versão têm precedência, bolsos Purge.

Por que esse é o mais estável:

  • Alterações no número da versão/no nome do arquivo → alteração de URL → CDN armazenado em cache como novo recurso → a nova versão entra em vigor quase imediatamente
  • O **Purge** exige que você o acione ativamente, o que tende a resultar em alcance impreciso e propagação atrasada do nó; o Purge frequente também pode resultar em taxas de acerto mais baixas, mais retornos e maior volatilidade.

Exemplos fáceis de ver:

  • style.css O conteúdo foi alterado, mas o URL ainda é style.css → CDN Continuar a fornecer o cache antigo (razoável)
  • O URL se torna style.css?ver=20260103 或 style.abc123.css → CDN é considerado um novo recurso → a nova versão entra em vigor imediatamente.

Bunny como uma prática recomendada do “First Step CDN

  1. Cobrir apenas recursos estáticos primeiro(imagens/CSS/JS/fontes), não armazene o HTML em cache logo de cara!
    • Benefício: quase não há incidentes graves, como “o usuário vê o conteúdo/número de série do carrinho de outra pessoa”.
    • Também é mais provável que você valide os ganhos: recursos estáticos mais rápidos, sites de origem mais leves
  2. Obter a estratégia de atualização correta
    • CSS/JS: tente usar o número da versão/alteração de nome de arquivo
    • Imagens: tente evitar a “cobertura do mesmo nome” a longo prazo, recomendando mais alterações no nome/caminho do novo arquivo (especialmente o banner da página inicial e o mapa do evento)
  3. Confirme o acerto com a lista de verificação de validação quando ela entrar em operação
    • São recursos estáticos do CDN
    • Se as taxas de acerto estão aumentando gradualmente e se a largura de banda/solicitações de origem estão mais suaves (segue uma lista de verificações)

tomar nota de

Se o seu negócio envolve a China continental ou se você deseja acesso mais rápido ao seu site na China continental.

Se o seu nome de domínio tiver sido registrado como ICP na China continental, ao usar o EdgeOne ou o ESA, o acesso à China continental mudará automaticamente para a linha da China continental!

“Uso de nós da China continental”Normalmente envolve registros de ICP

consulta

“Otimização da experiência de acesso internacional do site”pode ser outro recurso separado e geralmente não é o mesmo que “livre com nós da China continental”".”

5. mapa do caminho para a linha superior: avançando em 3 fases (de estável a forte)

A maneira mais fácil de “bagunçar” os uplinks CDN é tentar ativar todas as capacidades de uma só vez.

Estágio 1: Somente recursos estáticos CDN (altamente recomendado primeiro)

objetivosImagens/CSS/JS/fontes vão para o CDN primeiro; o HTML não está no cache do CDN (ou é temporariamente deixado de lado).

Por que isso é a coisa mais segura a se fazer primeiro?

  • Risco mínimo: o cache de recursos estáticos está errado, até “estilo/imagem não atualizado”, controlável
  • Não afetará o estado de login, os processos de comércio eletrônico, a correção das informações da conta
  • Você pode ver claramente os benefícios: downloads mais rápidos de recursos estáticos e sites de origem mais suaves!

Problemas comuns nesta etapa (a árvore de solução de problemas será apresentada posteriormente)

  • Conteúdo misto (HTTPS page load HTTP resource)
  • As atualizações de recursos estáticos não têm efeito (os URLs não são alterados)

Etapa 2: Estratégia de atualização (primeiro o número da versão, bolsões de purga/falha)

Esse é o divisor de águas do “CDN feito profissionalmente ou não”.

Uma regra rígida:

Não confie no Purge para atualizações que podem ser resolvidas com alterações no número da versão/nome do arquivo.

Por que os links de cache se tornam metafísicos quando ficam mais longos:

  • Cache do navegador: você pode ter CSS/JS antigos armazenados em cache localmente.
  • CDN Cache: os Edge Nodes podem estar armazenando em cache recursos antigos
  • Cache do site de origem: os plug-ins de cache/caches do servidor ainda podem estar produzindo conteúdo antigo

Se você não tiver uma estratégia de controle de versão, a versão se tornará:
“Mudou algo → Atualizar → Não funciona → Limpar cache novamente → Não funciona novamente → Limpar outro nível de cache”
Esse é o maior problema que muitas pessoas têm com o CDN.

Estágio 3 (avançado): armazenar em cache ou não armazenar em cache HTML (alto rendimento, mas maior risco)

O cache de HTML (cache de site completo/cache de borda) reduz significativamente o TTFB, mas também é uma área de alto incidente nos cenários do WordPress.

Não armazene HTML em cache se não tiver certeza. static first CDN + source caching plugin.

Se você quiser armazenar HTML em cache, duas regras se aplicam:

  1. Ele começa apenas com o “Estado do Visitante”.Cache: armazena em cache apenas páginas de visitantes não registrados
  2. Escreva primeiro a lista de derivaçãoCorreção vem primeiro, depois acertos

6. lista de regras de cenários: o que fazer em diferentes tipos de locais sem incidentes

6.1 Sites/blogs de conteúdo (baseados em artigos, muitos visitantes)

depoimentos

  • Recursos estáticos: totalmente armazenados em cache
  • HTML: considere armazenar em cache a “página do visitante não registrado”

Muitas vezes é necessário contornar o

  • Backend e login:/wp-admin/*、/wp-login.php
  • Pré-visualização/rascunho (pré-visualização)
  • Página de resultados de pesquisa (os parâmetros mudam muito, é mais econômico não armazená-los em cache primeiro)
  • POST solicitação de envio de formulário/comentário

As chaves de cache devem, pelo menos, distinguir entre

  • Se está ou não conectado (dimensão cookie)
  • Idiomas (estações multilíngues)

6.2 Site corporativo / página de destino de marketing (formulários, atividades em abundância)

depoimentos

  • Recursos estáticos: totalmente armazenados em cache
  • HTML: as páginas de destino públicas podem ser armazenadas em cache (estado de convidado), mas tenha cuidado com as páginas de resultados de formulários

A armadilha mais fácil de se cair: parâmetros de rastreamento que levam à fragmentação do cache
As páginas de destino são comuns utm_* Parâmetros:

  • Todas as chaves de cache do Engage → Cache destruído, baixa taxa de acerto
  • Ignorar tudo → Algumas páginas que dependem da renderização de parâmetros podem não ser as esperadas

6.3 Site de associação / site de curso / comunidade (alta participação de estados conectados)

chegar a um veredicto: O armazenamento em cache de HTML deve ser feito com muito cuidado.
As práticas seguras geralmente são: CDN estático + cache de fonte/objeto; o HTML armazena em cache apenas o estado do convidado.

Deve contornar

  • Login/Registro/Recuperação de senha
  • Centro de contas, Pedidos/assinaturas, Detalhes pessoais
  • Quaisquer páginas e interfaces “fortemente relevantes para o estado do usuário”

6.4 Estação de comércio eletrônico (WooCommerce)

Uma lista dos desvios mais importantes

  • Carrinho de compras, checkout, página da conta
  • Páginas relacionadas à confirmação de pedidos e retornos de chamada de pagamento
  • Login/registro, cupom/pontos e outras entradas relacionadas ao estado do usuário

Por que o comércio eletrônico é mais propenso a acidentes

  • Quando o usuário tem um carrinho de compras, uma sessão e um estado de login, a página é altamente personalizada
  • As consequências típicas do armazenamento em cache de HTML que não são contornadas/diferenciadas são: incompatibilidades no carrinho de compras, cadeias de contas e anomalias na exibição de preços.
    A correção tem precedência, não sacrifique a correção para obter resultados.

6.5 Sites em vários idiomas / várias moedas

depoimentos

  • Recursos estáticos: totalmente armazenados em cache
  • HTML: o estado do convidado pode ser armazenado em cache, mas as chaves de cache devem distinguir claramente as variantes de idioma/moeda

A chave de cache deve ser considerada

  • Idioma (caminho) /en/ /zh/ ou subdomínio en.）
  • Se deve ou não fazer o login (cookie)
  • Moeda/taxa de imposto (se afetar a apresentação)

7. alertas de risco

Risco 1: armazenamento em cache do conteúdo errado (mais grave)

  • Erro de cache de recurso estático: principalmente estilos/imagens antigos
  • Erro de armazenamento em cache de HTML: pode ser string de conteúdo, string de carrinho de compras, string de conta - esse é um incidente sério!

Risco 2: as atualizações não entram em vigor (mais comum)

À medida que o link do cache se torna mais longo, “as alterações não entram em vigor” serão mais comuns:

  • As alterações no número da versão/nome do arquivo têm precedência
  • Purga/falta de vendas
  • O processo de publicação deve ser reproduzível (saber quais URLs foram alterados para cada publicação)

Risco 3: Limite de compromisso para a versão gratuita/versão inicial

  • Características comuns dos programas gratuitos: cota limitada, alguma capacidade excluída, abordagem de SLA/suporte não equivalente ao uso comercial completo

Risco 4: as competências relacionadas à China continental são facilmente mal interpretadas

  • ESA: Registro do ICP da China necessário para rotas na China continental
  • EdgeOne: é necessário registrar o ICP da China para rotas na China continental

8 Lista de verificação de validação: como confirmar que ele “realmente funciona” depois de entrar em operação”

8.1 Os recursos estáticos realmente desapareceram do CDN?

  • Imagem/CSS/JS do CDN Domain/Edge Node
  • Se você pode ou não ver sinais claros de acessos ao cache (os sinais variam de acordo com a plataforma)

8.2 A pressão da estação de suprimento caiu?

  • A largura de banda da estação de origem é mais suave?
  • Se o número de solicitações/conexões do site de origem caiu (especialmente solicitações de recursos duplicados)

8.3 As atualizações são gerenciáveis?

  • Altere CSS/JS uma vez ou substitua uma imagem.
  • Se uma nova versão pode ser acelerada por “alteração do número da versão/alteração do nome do arquivo”.
  • Se você só pode atualizar por meio do Purge, é porque não tem uma boa estratégia de controle de versão (priorize a aplicação de patches na estratégia, não faça do Purge uma rotina diária)

8.4 As páginas-chave dinâmicas estão corretas?

(O site de comércio eletrônico/associação é obrigatório)

  • O conteúdo da página após o login/logout está correto
  • As páginas relacionadas a carrinho de compras/checkout/conta estão sempre corretas
  • Qualquer exceção do tipo “usuários diferentes veem o mesmo conteúdo no estado do usuário” (alto risco)

8.5 A taxa de erro aumentou?

  • Tempo limite de retorno à origem, 5xx, falha intermitente na abertura
  • Isso geralmente significa: suporte insuficiente na origem, regras incorretas, acionadores de limite de velocidade ou problemas com o link de volta à origem

9. atualização da árvore de não funcionalidade (transformando a “metafísica” em etapas)

Comece determinando o tipo de problema que está ocorrendo:

9.1 Recursos estáticos não atualizados (CSS/JS/imagens ainda antigos)

Cenário A: Somente você vê o dispositivo antigo, o dispositivo furtivo/troca é novo
Suspeita de prioridade: cache do navegador

  • Direção para resolução: liberar novos recursos com alterações no número da versão/nome do arquivo

Cenário B: Todos veem o antigo (dispositivos furtivos/diferentes também são antigos)
Suspeito de prioridade: CDN ainda atinge o cache antigo

  • 99% Causa: URL do recurso não foi alterado
  • Soluções prioritárias: estratégias de controle de versão
  • Pocket: Purge (meios temporários)

Cenário C: A imagem antiga continua aparecendo depois que a imagem é sobrescrita com o mesmo nome.
Esse é um problema clássico com o cache do navegador + sobreposição de cache do CDN

  • Conselho prático: tente evitar “sobrescritos com o mesmo nome” a longo prazo, use novos nomes de arquivos/caminhos ou números de versão

9.2 O HTML não está atualizado (o conteúdo da página/módulos ainda são antigos)

Cenário A: o backend/login é novo, os visitantes veem o antigo
Suspeita de prioridade: o HTML do convidado é armazenado em cache

  • Primeiro: essas páginas devem armazenar HTML em cache?
  • Se deve ser armazenado em cache: precisa de uma estratégia de atualização controlada, caso contrário, a liberação é incontrolável

Cenário B: Apenas algumas regiões/algumas redes alimentam conteúdo antigo
Dúvida de prioridade: nós de borda diferentes têm estados de cache diferentes

  • Direção para resolução: convergir as diferenças com a estratégia de versão/atualização; fazer uma invalidação mais explícita, se necessário

Cenário C: Anormalidades em usuários conectados/carrinhos de compras
Sinal de alto risco: pode estar armazenando em cache o conteúdo errado

  • Verificar imediatamente se as páginas de estado do usuário (carrinho/checkout/conta etc.) estão armazenadas em cache
  • Verifique se a chave de cache não ignora as variantes de chave, como “userland cookie/language/currency”.

10 Recomendações

Cloudflare

  • Integração de proxy reverso
  • Adequado para: início de economia
  • Foco: política de controle de versão para lidar com atualizações; cache de HTML feito a partir do estado de convidado
  • Risco: as páginas dinâmicas devem ser ignoradas

Tencent Cloud International EdgeOne

  • Integração de proxy reverso
  • Adequado: considere a capacidade do nó da China continental e o acesso integrado
  • Gratuito: existem planos gratuitos/versões gratuitas, mas os limites de cota e compromisso devem ser vistos com clareza
  • Riscos: cotas de regras/logs/subdomínio a serem planejadas; cache de HTML com cautela

Aliyun International ESA

  • Integração de proxy reverso
  • Gratuito: contas internacionais disponíveis Acesso gratuito à entrada
  • Risco: Limites gratuitos (SLA/suporte/limite de velocidade) e zonas/condições de arquivamento a serem confirmados com antecedência
  • Adequado para: avaliação/teste e acesso leve; ou atualização subsequente do pacote, ou considerando a capacidade do nó da China continental e o acesso integrado

bunny.net

  • Tração estática CDN
  • Adequado: primeiro a aceleração estática de baixo risco
  • Foco: número da versão primeiro, Purge undercover; evite substituições com o mesmo nome
  • Risco: encontros frequentes com “recursos antigos” se a estratégia de atualização não for feita corretamente.”

11. recomendações para ação

  1. Primeira opção de formulário: integração de proxy reverso (Cloudflare/EdgeOne/ESA) ou Pull CDN estático (bunny)
  2. Vá ao vivo pelo palco:Estática primeiro → depois política de controle de versão → finalmente considerar o cache de HTML
  3. Verificação por meio de lista de verificação de validação após a ativação: acertos/retornos à origem/atualizações/desvios dinâmicos/taxas de erro
  4. Precisa ser mais rápido: volte para “Cache Plugin” “Image Optimisation” e comprima a fonte e as camadas de recursos novamente!

Perguntas frequentes sobre o WordPress CDN

1) Por que ele continua lento depois de usar o CDN?

O motivo mais comum não é que o CDN não esteja funcionando, mas que o gargalo não está na “camada de entrega”.

Você pode julgá-los nessa ordem:

  • O TTFB ainda é alto.Explicação sobre a lentidão na geração de HTML a partir da fonte (banco de dados/plugin/configuração do plug-in de cache/desempenho da hospedagem) → retorno à otimização no nível da fonte
  • O primeiro quadro geral é muito lentoindica volume, tamanho ou formato incorretos da imagem → faça a otimização da imagem primeiro (compactação, WebP/AVIF, estratégia de dimensionamento)
  • Scripts de terceiros ficam mais lentosScripts de anúncios/estatísticas/atendimento ao cliente são comuns → CDN Geralmente não são úteis, precisam ser reduzidos ou atrasados no carregamento
  • Apenas algumas áreas estão lentasPode ser uma substituição de nó, uma linha de retorno ou uma falha no cache (baixa taxa de acerto) → observe a taxa de acerto e os retornos

O CDN é responsável por fornecer “recursos otimizados” mais rapidamente; sites de origem lentos, imagens grandes e scripts lentos devem ser tratados separadamente.

2) Por que os usuários ainda veem a versão antiga, mesmo que eu tenha atualizado o CSS/JS/imagens?

Esse é o problema mais comum em cenários CDN e a causa principal geralmente é:O URL do recurso não foi alterado.o sistema de cache continuará razoavelmente a acessar o cache antigo.

O princípio do tratamento mais estável:

  • prioridade do número da versãoPermitir que o URL do recurso seja alterado (por exemplo style.css?ver=xxxx ou hash de nome de arquivo)
  • Subscrição de purgaLimpando o cache como um paliativo quando você não tem uma política de controle de versão em vigor.

Se você substituir com frequência o banner da página inicial/imagem da campanha, é recomendável evitar a “substituição pelo mesmo nome”, preferindo usar o novo nome de arquivo/novo caminho (mais controlável).

3. preciso armazenar o HTML em cache? Não faz sentido não armazená-lo em cache?

Não necessariamente necessário.

Para muitos sites, o maior valor do CDN vem do fato de que ele é um produto de alta qualidade:

  • Mais rápido para recursos estáticos (imagens/CSS/JS/fontes)
  • Redução da pressão e melhoria da estabilidade da estação de abastecimento

Armazenamento em cache de HTML Os benefícios podem, de fato, ser maiores (o TTFB seria menor), mas os riscos também são maiores: comércio eletrônico, associações, conteúdo personalizado, vários idiomas/multidivisas são todos propensos a armazenar em cache o conteúdo errado.

Rota estável:

  1. Primeiro o CDN estático (baixo risco, alta recompensa)
  2. Execute a política de controle de versão e a lista de verificação de validação
  3. Reavaliar se o HTML deve ser armazenado em cache (começando com “estado de convidado”)

4) O site de comércio eletrônico pode estar no CDN e isso atrapalhará o carrinho de compras?

Ele pode ser ativado e deve ser (pelo menos para recursos estáticos), mas evite armazenar em cache as páginas do userland.

  • Os recursos estáticos podem ser armazenados em cache: imagens, CSS, JS
  • A página do espaço do usuário deve ignorar oHTML: Não armazenar em cache o carrinho de compras, o checkout e as páginas relacionadas à conta
  • Desde que você não coloque essas páginas em cache HTML, o risco de “crosstalk” é bastante reduzido!

5) Como um site multilíngue/multicurrency pode fazer o CDN sem encadear idiomas/preços?

centro Chave de cache Está correto.

  • Idioma (caminho ou subdomínio)
  • Moeda (se afetar a exibição do preço)
  • Se deve ou não fazer o login (cookie)
  • Região/taxa de imposto (se a página estiver sujeita a alterações por região)

Se essas dimensões não entrarem na lógica de cache, é fácil ter: usuários do idioma A vendo conteúdo do idioma B ou preços inconsistentes.

6) Devo optar pela integração do proxy reverso (Cloudflare/EdgeOne/ESA) ou pelo Pull CDN estático (bunny)?

Você pode selecionar por “Meta” e “Preferência de risco”:

  • Gostaria de obter HTTPS + CDN + segurança básica, com expansão subsequente de regras/WAF de uma só vez:Integração de proxy reverso
  • Deseja realizar a primeira etapa da primeira etapa mais estável (os recursos estáticos são mais rápidos) e não deseja mover o agente inteiro:Tração estática CDN(por exemplo, coelho)

Se você estiver hesitante, siga o conselho padrão:Pré-estático CDN → Execute a política de controle de versão e a lista de verificação de validação e, em seguida, decida se deseja usar o cache proxy/HTML.

7) A versão gratuita pode ser usada diretamente no site oficial?

Ele pode ser usado, mas pense em “gratuito” como “inicial/avaliação/uso leve”, não como um “programa formal com SLAs comerciais”.

  • Você se sente confortável com um programa gratuito deLimites de cotas, recursos ausentes, diferenças no suporte e possível falta de compromissos de SLA？
  • Se não for possível, você deve tratar o pacote gratuito como uma avaliação e, posteriormente, fazer o upgrade para um pacote mais adequado

8) Como posso ter certeza de que o CDN está realmente em vigor e não é apenas um conforto psicológico?

Confirme com estas três etapas (sem nenhuma ferramenta complicada):

  1. Veja se os recursos estáticos são retornados do CDN(se a origem da imagem/CSS/JS foi alterada)
  2. Veja se a taxa de acerto e a fonte de retorno melhoram(Aumentar, voltar a fonte para baixo para obter ganhos reais)
  3. Alterar a estratégia de atualização da validação de CSS/imagem uma vez(número da versão em vigor, indicando a capacidade de controle do link)

Se não for possível fazer o número 3, quanto mais você otimizar, maior será a probabilidade de ser atormentado pela mensagem “as atualizações não têm efeito”, portanto, é recomendável priorizar a estratégia de controle de versão.

9 Por que muitas vezes fico preso ao ativar a aceleração para a China continental?

A causa mais comum é:Incompatibilidade entre as escolhas regionais e as condições de registro。

  • Se você quiser selecionar uma região de aceleração que inclua a China continental, normalmente precisará preencher o formulário ICP 备案O Undocumented só pode selecionar regiões que não incluam a China continental.

10) Devo instalar o plug-in de cache ou o CDN primeiro?

A ordem geral recomendada é:

  1. Camada do site de origem: o plug-in de cache/base de hospedagem se estabilizou primeiro (TTFB diminuiu, pressão de back-end diminuiu)
  2. Camada de recursos: otimização da imagem para manter o tamanho reduzido
  3. Camada de fornecimento: CDN Fornecimento de recursos de forma mais rápida e consistente

Se você quiser fazer apenas uma coisa no momento e tiver medo de mudar:Estática CDN primeiro (Fase 1)com retornos estáveis e risco mínimo.