Auditoria de Performance e Core Web Vitals

Fase P3 · Etapa A — Entender
Timebox: 4–8 horas para uma auditoria representativa; 2–5 dias úteis para uma investigação em toda a base de templates com rastreios de engenharia. A validação de campo de 28 dias ocorre após as correções e não estende o timebox inicial da auditoria.
Responsável: o líder técnico de SEO define o escopo e a aceitação. Um engenheiro de performance ou engenheiro front-end sênior é responsável pelo diagnóstico; os responsáveis por plataforma, CDN, analytics, design e produto contribuem onde seus sistemas criam atraso ou instabilidade.

Esta fase converte evidências de campo de usuários reais e testes de laboratório reproduzíveis em um registro de remediação vinculado a URLs, templates, métricas, responsáveis e testes de conclusão — não a uma pontuação genérica de velocidade.

Por que esta fase, e por que aqui

A performance pertence à Etapa A porque uma página que excede o tempo limite é um problema de rastreio antes de ser um problema de experiência do usuário. Um rastreador ou agente de recuperação tem um orçamento finito de requisições. Se a origem falha, redireciona repetidamente ou retorna uma resposta incompleta, o cliente pode abandonar a página antes mesmo de avaliar o conteúdo. Cabeçalhos mais rápidos, textos melhores e schema mais robusto não podem ajudar conteúdo que não é recuperado de forma confiável.

A P3 consome os hosts canônicos, templates indexáveis pretendidos, jornadas prioritárias, evidências de código de status e achados de infraestrutura não resolvidos da auditoria técnica de base . Essa ordem evita diagnósticos falsos. Por exemplo, um “carregamento de página” de cinco segundos causado por um loop de redirecionamento não é uma tarefa de otimização de imagens, e um teste rápido de uma página de erro em cache não é uma aprovação. A P2 estabelece que a URL correta pode ser solicitada e selecionada; a P3 estabelece que ela pode ser entregue e utilizada dentro de limites aceitáveis de tempo e estabilidade.

Realizar esta fase tardiamente gera retrabalho. Uma equipe de conteúdo pode publicar em um template cujo hero é sempre o elemento mais lento, ou aprovar um espaço promocional que desloca cada card de produto. O defeito então se multiplica por novas páginas.

Entradas e saídas

As entradas tornam a amostra representativa. As saídas formam o contrato com a próxima fase: exatamente quais páginas estão disponíveis de forma confiável, quais condições permanecem fracas e quais limitações de performance devem qualificar medições posteriores.

Dados de campo e dados de laboratório são evidências diferentes

Dados de campo descrevem o que usuários Chrome elegíveis realmente experimentaram. O Chrome User Experience Report, geralmente abreviado como CrUX, agrega medições de visitas reais e relata o 75º percentil: o valor no qual ou abaixo do qual 75% das experiências registradas se encontram. Ele inclui a complexidade de dispositivos reais, redes, localizações, caches, ferramentas de consentimento, sessões e interações. Use-o para decidir se os usuários passam pelos limites publicados e se uma mudança implantada eventualmente melhorou a população.

Dados de laboratório descrevem um carregamento de página ou interação controlada sob condições declaradas. O Lighthouse é um teste de laboratório que aplica simulação de dispositivo e rede, captura um rastreio e explica causas prováveis. Use-o para reproduzir um problema, comparar duas versões sob a mesma configuração, inspecionar cadeias de requisições e identificar trabalho. Uma pontuação de laboratório é uma evidência útil, mas não prova que usuários reais passam.

As duas fontes podem divergir sem que nenhuma esteja errada. Uma execução rápida de laboratório pode usar uma localização próxima, CDN aquecido e nenhuma interação significativa, enquanto visitantes de campo incluem telefones mais antigos e redes distantes. Registre a divergência e investigue suas condições; nunca calcule a média dos valores nem escolha o que aparenta mais saudável.

A lista de verificação

Complete estas verificações em ordem. Cada item declara a ação, o motivo, o método, a ferramenta e a condição de aceitação para que possa ser atribuído e retestado.

1. Congele a matriz de URLs representativas e condições

O quê: defina as URLs, templates, perfis de dispositivo, geografias, estados de consentimento e estados de cache a serem testados. Por quê: uma auditoria apenas da página inicial pode ser aprovada enquanto o template de produto, artigo ou checkout falha. Como: combine o inventário da P2 com dados de tráfego e prioridade de negócio; selecione exemplos típicos, pesados e críticos para conversão. Ferramenta: analytics, inventário de rastreio, registro de lançamentos e uma planilha de testes compartilhada. Concluído quando: cada template prioritário tem uma amostra de produção aprovada pelo responsável e cada teste registra premissas de dispositivo, rede, localização, login, consentimento e cache.

2. Capture a baseline de campo do CrUX

O quê: registre métricas de campo p75 disponíveis no nível de URL e, separadamente, no nível de origem. Por quê: a origem pode esconder um template fraco, enquanto uma URL individual de baixo tráfego pode não ter dados publicáveis. Como: use a mesma data de observação e janela de 28 dias, rotule explicitamente URL versus origem e registre valores em branco como “dados insuficientes”. Ferramenta: AmICited Web Vitals e CrUX. Concluído quando: cada URL amostrada tem valores de LCP, INP, CLS, FCP e TTFB ou um estado desconhecido documentado; o nível da fonte e a janela são inequívocos.

3. Verifique a confiabilidade da resposta antes de pontuar pixels

O quê: repita requisições e registre status, redirecionamentos, Time to First Byte (TTFB), timeouts e respostas inconsistentes. TTFB é o intervalo desde o início da requisição até a chegada do primeiro byte de resposta. Por quê: uma página não pode renderizar antes que seu HTML comece a chegar, e uma falha intermitente é mais grave que uma lentidão cosmética. Como: teste o comportamento de cache frio e quente a partir de regiões relevantes, inspecione o tempo do servidor e correlacione anomalias com logs de CDN e origem. Ferramenta: monitor de requisições, painel de rede do navegador, observabilidade de CDN/origem e waterfall do Lighthouse. Concluído quando: URLs prioritárias retornam a resposta 200 pretendida sem saltos inesperados ou timeouts, e toda resposta lenta ou com falha tem um achado registrado com um responsável.

4. Diagnostique o Largest Contentful Paint

O quê: identifique o elemento de Largest Contentful Paint (LCP) e divida seu tempo em atraso de servidor, descoberta de recurso, download de recurso e atraso de renderização. LCP mede quando o maior bloco visível de imagem ou texto termina de renderizar. Por quê: comprimir uma imagem faz pouco quando o navegador a descobre tardiamente, e mudanças de front-end não podem apagar uma espera lenta na origem. Como: inspecione o rastreio e o waterfall, compare execuções em cache e sem cache, verifique prioridade de pré-carregamento, dimensionamento responsivo de imagens, recursos que bloqueiam renderização, comportamento de fontes e renderização no lado do cliente. Ferramenta: Lighthouse, ferramentas de performance do navegador, waterfall de requisições e inspeção de imagens. Concluído quando: o elemento LCP real e a subparte dominante são nomeados para cada template com falha, com uma medição anterior reproduzível e uma hipótese de correção específica.

5. Diagnostique o Interaction to Next Paint

O quê: teste o caminho do Interaction to Next Paint (INP) para ações reais como abrir menu, filtrar, adicionar ao carrinho, entrada de formulário e dispensa de consentimento. INP mede o atraso desde uma interação do usuário até que o navegador exiba a próxima atualização visual, usando uma interação de alta latência da visita. Por quê: uma página pode parecer completa mas ainda ignorar o usuário enquanto o JavaScript ocupa a thread principal. Como: reproduza ações importantes, inspecione long tasks e manipuladores de eventos, teste scripts de terceiros e separe atraso de entrada, tempo de processamento e atraso de apresentação. Ferramenta: CrUX, rastreio de performance do navegador, perfilamento de interação e um dispositivo realista. Concluído quando: toda interação importante foi exercitada, a interação lenta e a tarefa responsável são identificadas para templates com falha, e a correção tem um teste de interação reproduzível.

6. Diagnostique o Cumulative Layout Shift

O quê: localize movimento inesperado que contribui para o Cumulative Layout Shift (CLS). CLS é uma pontuação sem unidade que representa movimento visual inesperado durante a vida da página. Por quê: um banner tardio, imagem sem dimensões, fonte trocada, anúncio ou componente hidratado pode mover o link que o usuário está prestes a clicar e pode alterar onde a extração automatizada encontra conteúdo. Como: use regiões de layout-shift e um filmstrip, teste ativos atrasados e estados de consentimento e inspecione elementos sem dimensões reservadas. Ferramenta: CrUX, rastreio do Lighthouse, diagnóstico de renderização do navegador e captura de regressão visual. Concluído quando: cada mudança material tem um elemento de origem, gatilho e correção de espaço reservado ou renderização; movimento esperado causado imediatamente por uma ação do usuário é documentado separadamente.

7. Use FCP para separar o atraso de tela em branco

O quê: meça o First Contentful Paint (FCP), o tempo até o navegador renderizar o primeiro conteúdo de texto, imagem, canvas ou SVG. Por quê: o FCP distingue um sinal precoce de progresso de uma página que permanece em branco, embora não prove que o conteúdo principal está pronto. Como: compare FCP com TTFB e LCP, depois inspecione CSS, fontes, scripts, marcação renderizada no servidor e comportamento de streaming que bloqueiam. Ferramenta: CrUX, Lighthouse e o rastreio de rede/performance. Concluído quando: todo FCP lento é atribuído a atraso de servidor, bloqueio de renderização, renderização exclusiva no cliente ou outra causa com evidência, em vez de ser descrito meramente como “a página parece lenta.”

8. Classifique os achados por gravidade, alcance e dependência

O quê: ordene o backlog por faixa de falha, tráfego e templates afetados, criticidade de negócio e dependência upstream. Por quê: corrigir cinco pontuações amarelas pode consumir a sprint enquanto uma falha vermelha de TTFB atrasa todas as páginas da origem. Como: coloque falhas de confiabilidade primeiro, depois métricas ruins antes de métricas que precisam de melhoria; dentro da mesma gravidade, corrija causas compartilhadas de plataforma e TTFB antes de trabalhos downstream de LCP. Ferramenta: registro de achados, analytics, inventário de templates e estimativa de engenharia. Concluído quando: todo achado tem uma gravidade, contagem de URLs afetadas ou escopo de template, evidência, responsável, esforço, dependência e prioridade explícita.

9. Valide a implementação em laboratório

O quê: compare a versão modificada com a baseline registrada sob condições idênticas. Por quê: dados de campo não podem fornecer feedback imediato de lançamento, e uma execução “depois” não reproduzível não pode estabelecer que a mudança de código causou a diferença. Como: execute múltiplas amostras controladas, compare medianas em vez da melhor execução isolada, inspecione o rastreio em busca de regressões e teste interações e layouts críticos. Ferramenta: Lighthouse, ferramentas de performance do navegador, ambiente de staging ou lançamento controlado em produção e monitoramento de requisições. Concluído quando: a causa pretendida é removida, a métrica alvo passa o orçamento de laboratório acordado em execuções repetidas, nenhuma outra métrica crítica regride e a evidência é anexada ao achado.

10. Anote o lançamento e aguarde a confirmação de campo

O quê: registre o momento da implantação, escopo, métrica esperada e datas de validação. Por quê: o CrUX é uma janela contínua de 28 dias, portanto visitas pré-lançamento permanecem no percentil reportado após a correção ser publicada. Como: monitore erros imediatamente, verifique o movimento direcional de campo à medida que novos dados chegam e faça a comparação final apenas quando dias pós-lançamento suficientes representarem a janela. Ferramenta: registro de implantação, AmICited Web Vitals, CrUX e monitoramento. Concluído quando: verificações técnicas imediatas passam, a anotação do lançamento está visível e um responsável nomeado e uma data existem para confirmação de campo; o achado não é marcado como “verificado” apenas com evidência de laboratório.

Ferramentas na AmICited

Abra https://app.amicited.com/audit/web-vitals para comparar seu domínio com concorrentes monitorados usando dados de usuários reais do CrUX. A auditoria coloca LCP, INP, CLS, FCP e TTFB em uma única tabela, marca seu domínio e torna os dados de campo ausentes visíveis em vez de transformá-los em um zero enganoso. Use a comparação para responder a duas perguntas: se o domínio passa pelos limites publicados e se um concorrente atendendo o mesmo público demonstrou um resultado de campo materialmente melhor.

O recurso Performance Impact conecta a performance no nível da página com a posição e probabilidade de citação. Trate a relação como evidência de priorização, não como prova de que a velocidade sozinha causou uma mudança na citação. Se uma página lenta citada e uma página rápida não citada diferem em autoridade, relevância ou conteúdo, a performance é apenas uma variável. O sinal útil é que uma página afetada é valiosa o suficiente para ser corrigida e monitorada.

Para o funcionamento do produto, siga Como Verificar Seus Core Web Vitals na AmICited . Este playbook define escopo da auditoria, decisões e repasse; o tutorial cobre os cliques e leituras, portanto duplicá-lo aqui criaria duas instruções que podem divergir.

Regras de decisão: como é o ruim

Julgue os Core Web Vitals a partir de dados de campo no 75º percentil. “Bom” significa que o valor p75 está no limite bom ou abaixo dele. Um valor em um limite pertence à faixa melhor; por exemplo, LCP de exatamente 2,5 segundos é bom. Os limites de suporte de FCP e TTFB orientam o diagnóstico e a aceitação, mas não fazem parte da avaliação de aprovação das três métricas do Core Web Vitals.

Use estas regras de prioridade:

1. Requisições com falha, timeouts e respostas inválidas superam pontuações. Confiabilidade é o portão de entrega.
2. Corrija faixas ruins antes de faixas que precisam de melhoria. Vermelho é uma experiência ruim demonstrada, não uma oportunidade de polimento.
3. Corrija TTFB antes de LCP quando TTFB estiver falhando. LCP não pode ocorrer antes da resposta começar, portanto o atraso do backend consome o orçamento do LCP antes que o navegador possa renderizar qualquer coisa.
4. Prefira causas compartilhadas em vez de sintomas isolados. Um reparo de política de cache em quatro templates supera quatro ajustes separados de imagem com menor alcance.
5. Use tráfego e valor da jornada dentro da mesma gravidade. Um INP ruim no checkout ou um LCP de artigo de alto tráfego supera um arquivo de baixo tráfego na mesma faixa.
6. Não considere um valor CrUX em branco como bom. Ele é desconhecido. Use evidência de laboratório reproduzível e um template comparável até que volume de campo exista.
7. Não prometa movimento de campo imediato. Valide a implantação agora, depois permita que a janela contínua substitua experiências mais antigas antes de aceitar ou rejeitar o resultado de campo.

Entregável: o registro de remediação de performance

Entregue à engenharia um registro mais sua pasta de evidências. Uma planilha, rastreador de issues ou tabela de projeto estruturada é aceitável se preservar estes campos e permitir filtragem por template, gravidade, responsável e status:

ID e achado:
URLs e templates afetados:
Jornada prioritária e contexto de tráfego:
Métrica e faixa de campo:
Nível CrUX, valor p75 e janela de 28 dias:
Configuração de laboratório e baseline repetida:
Causa observada e referência de evidência:
Condição esperada e alvo:
Mudança recomendada:
Gravidade e justificativa de prioridade:
Responsável, dependência e esforço:
Data de lançamento e anotação:
Resultado de aceitação imediata em laboratório:
Data e resultado de confirmação de campo:
Status: Aberto | Planejado | Aceito em laboratório | Verificado em campo | Risco aceito

Anexe a matriz de URLs, exportação do CrUX, rastreios de laboratório, waterfalls, filmstrips, gravações de interação, evidências de layout-shift e anotações de lançamento. Desduplique por causa: se a mesma consulta de origem sem cache cria TTFB ruim em três templates, crie um achado pai com três escopos afetados em vez de três diagnósticos concorrentes.

“Risco aceito” precisa de um aprovador nomeado, motivo, escopo afetado, data de validade ou revisão e condição de monitoramento. Não é um substituto para um responsável. O repasse está completo quando um engenheiro pode reproduzir a falha e o responsável pela próxima fase pode identificar quais resultados permanecem limitados pela performance.

O que dá errado

Tratar o Lighthouse como veredito. Uma pontuação de 100 em uma execução de laboratório não substitui dados de campo p75 ruins. Mantenha o Lighthouse como evidência diagnóstica e o CrUX como evidência populacional.

Testar apenas a página inicial. Amostre cada template de alto valor mais um exemplo pesado, ou defeitos de template escaparão da auditoria.

Otimizar a imagem LCP antes de verificar o TTFB. O ativo pode ser pequeno enquanto a origem gasta dois segundos gerando HTML. Divida o LCP em seus componentes e corrija o tempo upstream primeiro.

Usar a execução mais rápida isolada. Aquecimento de cache, atividade em segundo plano e variação de rede podem criar um outlier favorável. Mantenha a configuração fixa e compare medianas de execuções repetidas.

Declarar vitória no dia seguinte ao lançamento. O laboratório pode provar que o código e a entrega mudaram imediatamente; a janela de campo de 28 dias não pode. Anote o lançamento e agende a aceitação de campo.

Marcar dados CrUX ausentes como zero. Sem dados significa que o limite de elegibilidade ou tráfego não foi atingido. Não diz nada sobre a qualidade da performance.

Perseguir a pontuação composta em vez da experiência com falha. Uma pontuação resumida pode melhorar enquanto uma interação de checkout ainda trava ou um hero ainda se desloca. Aceite métricas e jornadas nomeadas, não movimento cosmético de pontuação.

Remover funcionalidade útil para vencer um teste. Excluir consentimento, personalização, analytics ou comportamento de acessibilidade da variante de laboratório produz um resultado que os usuários nunca recebem. Otimize o requisito de produção ou tome uma decisão explícita de produto.

Ignorar regressões fora da métrica alvo. Adiar scripts pode melhorar o LCP mas criar INP ruim na primeira interação; reservar as dimensões erradas pode substituir um atraso de carregamento por CLS. Reteste todas as cinco métricas e a jornada crítica.

Próxima fase: acessibilidade de IA e prontidão para agentes

A fase de acessibilidade de IA e prontidão para agentes recebe a matriz de URLs representativas, evidências de confiabilidade de resposta, distribuição de TTFB, achados de performance não resolvidos e uma declaração sobre qual conteúdo está presente na resposta inicial. Seu responsável usa essa evidência para distinguir uma falha de política de acesso de uma falha de entrega e para reproduzir as condições reais sob as quais um agente busca a página.

A próxima fase pode prosseguir quando URLs críticas respondem de forma confiável e nenhum defeito de performance não resolvido torna a evidência de recuperação ininterpretável. Pode prosseguir com uma limitação por escrito quando uma métrica que precisa de melhoria afeta usuários mas não impede o acesso estável. Deve pausar para templates afetados quando requisições excedem o tempo limite, retornam erros intermitentes ou a resposta principal excede regularmente o limite crítico acordado.

O repasse está completo quando o próximo responsável sabe quais URLs representam cada template, as condições de teste, as falhas de entrega restantes e se a evidência da P3 já explica uma busca lenta do agente.

FAQ

Perguntas frequentes