Perguntas frequentes sobre latência, cache, CDN e Core Web Vitals

O desempenho de uma página não é uma propriedade fixa do site. Ele varia conforme a página, o usuário, a rede, o dispositivo, a região, o estado dos caches e a configuração do servidor. Por isso, relatórios diferentes respondem perguntas diferentes: um teste de laboratório ajuda a reproduzir um cenário; dados de campo mostram a experiência de usuários reais; cabeçalhos HTTP ajudam a investigar a entrega; e os Core Web Vitals resumem aspectos específicos da experiência.

O que é latência e como ela difere do tempo total de carregamento?

Resposta curta: latência é o atraso para uma comunicação atravessar a rede e retornar; tempo total de carregamento inclui também DNS, conexão, processamento no servidor, transferência dos bytes, execução de JavaScript, renderização e outros recursos.

Explicação e limite: em uma requisição inicial, a latência pode envolver resolução de DNS, handshake TCP, negociação TLS e a viagem de ida e volta entre navegador e servidor. A página, porém, costuma depender de muitas requisições para HTML, CSS, JavaScript, fontes e imagens. Um site pode ter pouca latência de rede, mas ainda carregar devagar por causa de arquivos grandes, bloqueios de renderização ou trabalho excessivo no navegador. A explicação da MDN sobre latência diferencia esses tempos e descreve as etapas observáveis no DevTools.

Próximo passo: no painel Network do Chrome, examine separadamente DNS, conexão, espera, recebimento e tamanho dos recursos. Não use o tempo de uma única requisição como sinônimo do carregamento completo.

O que TTFB mede e o que ele não permite concluir?

Resposta curta: TTFB (Time to First Byte) mede o tempo desde o início da navegação até o começo da chegada da primeira resposta. Ele não mede o tempo até a página ficar visível, interativa ou estável.

Explicação e limite: o TTFB soma redirecionamentos, eventual inicialização de service worker, DNS, conexão, TLS e o processamento até o primeiro byte. A documentação do web.dev sobre TTFB indica, como orientação aproximada, buscar até 0,8 segundo, mas não trata esse valor como um Core Web Vital nem como uma garantia de experiência. Um TTFB baixo pode ser seguido por CSS bloqueante, uma imagem LCP lenta ou JavaScript pesado. Além disso, a interpretação depende do que a ferramenta considera como “primeiro byte”, inclusive quando há Early Hints.

Próximo passo: compare TTFB em laboratório e no campo, separando usuários por dispositivo e região quando possível. Use-o como pista para servidor, rede e cache; confirme o diagnóstico observando LCP e as demais métricas.

Qual é a diferença entre cache de página e cache de objeto?

Resposta curta: cache de página guarda uma resposta pronta, geralmente HTML; cache de objeto guarda resultados reutilizáveis da aplicação, como consultas e dados, para evitar trabalho repetido.

Explicação e limite: um plugin ou mecanismo de page cache pode servir um HTML estático sem executar todo o WordPress a cada visita. Já o object cache atua dentro da aplicação e pode usar Redis, Memcached, APC ou outro mecanismo. A documentação do WordPress sobre cache observa que o cache de objeto persistente é separado do cache de página e que dados de cache devem ser regeneráveis. Também existem cache do navegador, cache do servidor web e cache compartilhado de proxy ou CDN. Eles não são intercambiáveis: uma página personalizada não deve ser entregue como se fosse pública apenas porque o cache existe.

Próximo passo: desenhe as camadas antes de instalar um plugin: navegador, CDN/proxy, servidor, page cache, PHP e object cache. Verifique regras de exclusão para login, carrinho, sessão e conteúdo personalizado, e teste invalidação em staging.

Uma CDN deixa qualquer site mais rápido?

Resposta curta: não. Uma CDN pode reduzir a distância até recursos cacheáveis e aliviar o origin, mas o resultado depende do conteúdo, da política de cache, da localização dos usuários e do custo adicional da própria arquitetura.

Explicação e limite: o ganho costuma ser mais direto para arquivos estáticos ou respostas públicas que podem ser reutilizadas no edge. HTML dinâmico, respostas com cookies, conteúdo personalizado e cache misses podem continuar dependendo do origin. A documentação da Cloudflare sobre comportamento padrão de cache mostra que a CDN respeita cabeçalhos do origin, que HTML e JSON não são necessariamente cacheados por padrão e que regras específicas podem mudar esse comportamento. Uma CDN também não corrige JavaScript excessivo, imagens mal dimensionadas, consultas lentas ou uma renderização bloqueada.

Próximo passo: antes e depois da mudança, compare a mesma URL com cache frio e quente, de regiões e redes relevantes. Meça TTFB, LCP e tempo de transferência, sem presumir um ganho fixo.

Como saber se uma página está sendo servida do cache?

Resposta curta: observe os cabeçalhos da resposta, o painel Network e o painel da CDN; não conclua apenas porque a página “parece rápida”.

Explicação e limite: Cache-Control informa diretivas para caches privados e compartilhados. max-age define uma vida útil de frescor; s-maxage se aplica a caches compartilhados; no-cache permite armazenar, mas exige validação antes do reuso; no-store instrui a não armazenar. A referência da MDN para Cache-Control explica essas diferenças e alerta que no-cache não significa “não armazenar”. Em uma CDN específica, cabeçalhos como CF-Cache-Status: HIT, MISS, BYPASS ou REVALIDATED ajudam, mas o significado é próprio do fornecedor. A documentação do Cloudflare-Cache-Status não deve ser generalizada para todas as CDNs.

Próximo passo: inspecione uma resposta anônima e uma autenticada, sem expor cookies ou dados pessoais. Registre Cache-Control, Age, ETag, Vary e o cabeçalho de status da sua CDN. Confirme que uma resposta personalizada nunca aparece em cache compartilhado.

Core Web Vitals são iguais a uma pontuação Lighthouse?

Resposta curta: não. Core Web Vitals são métricas de experiência; a pontuação de Performance do Lighthouse é um índice de laboratório calculado com métricas e pesos próprios.

Explicação e limite: o conjunto atual de Core Web Vitals é LCP para carregamento, INP para responsividade e CLS para estabilidade visual. As orientações de “bom” são, no percentil 75 e separadas entre mobile e desktop, LCP até 2,5 s, INP até 200 ms e CLS até 0,1, conforme a documentação de Web Vitals. O Lighthouse, por outro lado, calcula uma média ponderada de métricas de laboratório, incluindo TBT em vez de INP no seu diagnóstico de interatividade. A documentação da pontuação do Lighthouse explica que a nota pode oscilar por dispositivo, tráfego, extensões, anúncios e rede.

Próximo passo: use Lighthouse para encontrar regressões reproduzíveis e use dados de campo para avaliar a experiência real. Não transforme uma nota 90 ou 100 em certificado universal de velocidade.

Por que dados de campo e laboratório divergem?

Resposta curta: porque medem populações e condições diferentes. O laboratório usa um dispositivo, uma rede e uma localização controlados; o campo agrega visitas reais, com variação de hardware, rede, região e comportamento.

Explicação e limite: dados de campo, também chamados RUM, podem vir do CrUX ou da instrumentação própria. O Chrome UX Report reúne dados de usuários reais elegíveis do Chrome, não de todas as pessoas nem de todas as páginas. A análise do web.dev sobre laboratório e campo explica que o campo é uma distribuição e que o laboratório pode não capturar rolagem, personalização, cache já aquecido, bfcache ou diferentes elementos LCP. Para priorizar problemas vividos pelos usuários, campo é essencial; para depurar uma alteração antes do lançamento, laboratório é mais controlável.

Próximo passo: compare o mesmo URL, período, dispositivo e região. Prefira percentis a médias e documente se o teste usou cache frio, cache quente, throttling e sessão anônima.

Um plugin de cache ou otimização é sempre necessário?

Resposta curta: não. A necessidade depende de quais camadas já existem no host, no servidor, na CDN e no próprio WordPress.

Explicação e limite: um plugin pode gerar cache de página ou aplicar otimizações úteis, mas pode duplicar regras do servidor, criar conflitos com outro plugin, entregar HTML desatualizado ou quebrar scripts, sessões e conteúdo personalizado. O WordPress documenta plugins de cache como uma opção, não como receita universal, e distingue cache de página, navegador, servidor e objeto. A recomendação editorial é medir primeiro e mudar uma variável por vez. O fato de uma ferramenta oferecer muitas opções não prova que todas sejam adequadas ao tema, ao host ou ao fluxo editorial.

Próximo passo: faça backup verificável e teste em staging. Confirme quem invalida cada cache, como excluir áreas dinâmicas e como reverter a configuração. Só depois compare métricas e verificações funcionais — login, formulários, busca, carrinho e atualização de conteúdo.

Uma pontuação boa garante experiência rápida para todo mundo?

Resposta curta: não. Uma boa pontuação descreve um cenário ou percentil específico, não cada visita individual.

Explicação e limite: os Core Web Vitals usam o percentil 75 para representar a maioria das experiências em um segmento, mas ainda haverá usuários acima e abaixo desse ponto. O CrUX também tem critérios de elegibilidade e cobertura limitada. Além disso, uma página pode passar LCP e CLS e continuar frustrante por interação lenta, conteúdo que aparece tarde ou problemas que não são capturados no teste escolhido. O guia de medição de Web Vitals no campo recomenda acompanhar distribuições, evitar depender de médias e versionar as mudanças, pois caches podem fazer diferentes usuários receberem versões distintas.

Próximo passo: acompanhe p75 por tipo de dispositivo, país ou região, template e versão implantada. Combine métricas com uma verificação humana de tarefas importantes, sem prometer ranking ou velocidade uniforme.

Nota de limites

Este FAQ resume documentação pública e não substitui a análise do host, da CDN, do tema, dos plugins ou do código de uma instalação específica. Limiares e definições podem evoluir; confirme a versão vigente das fontes antes de comparar relatórios ao longo do tempo. Uma recomendação editorial — medir, isolar a variável e testar reversão — não é uma conclusão documental sobre o seu site. Em produção, evite armazenar respostas personalizadas em cache compartilhado, não exponha credenciais nos diagnósticos e valide conteúdo e funções depois de qualquer alteração.

Referências

[1] Understanding latency — MDN Web Docs

[2] Web Vitals — web.dev

[3] Cache — WordPress Developer Resources