Core Web Vitals: medir LCP, INP e CLS antes de corrigir

ANÁLISE EDITORIAL

Core Web Vitals não é uma lista de truques para deixar o medidor verde. Antes de mexer em imagens, JavaScript ou CSS, é preciso separar três perguntas: o que usuários reais sentiram, o que aconteceu em uma execução de laboratório e qual recurso ou trecho de código explica o problema. A Skill Core Web Vitals organiza essa sequência para LCP, INP e CLS, evitando que uma observação isolada seja apresentada como resultado de campo.

O material foi criado para agentes que analisam ou alteram projetos web. Ele orienta medição, diagnóstico, correção pequena e nova medição. Não promete melhora de ranking, não garante aprovação no Search Console e não transforma um teste único em evidência sobre todos os visitantes.

Imagem: Ilustração editorial exclusiva do Bastidores da IA sobre uma página atravessando três estações de medição antes de chegar a um checkpoint de decisão. Não é captura de tela, interface real, logotipo, relatório, benchmark nem prova de desempenho.

O que esta Skill faz de verdade

O SKILL.md fixado no commit auditado concentra o trabalho nos três Core Web Vitals atuais. LCP representa o carregamento do maior elemento de conteúdo visível, INP acompanha a responsividade das interações e CLS mede instabilidade visual inesperada. A Skill fornece limiares, hipóteses comuns, exemplos de implementação e referências específicas para cada métrica.

A contribuição mais importante não é o número do limiar. É a disciplina de evidência. Com uma URL executável, o fluxo começa por dados de campo disponíveis para página ou origem, registra uma execução controlada e investiga apenas os sinais ligados à métrica suspeita. Quando há somente código-fonte, o agente deve falar em causa provável, não declarar que a página falhou.

A Skill não inclui um navegador, não executa o Lighthouse sozinha e não acessa automaticamente Search Console ou CrUX. Essas capacidades dependem do ambiente do agente e das permissões concedidas. O ZIP do Bastidores contém instruções e referências, não uma ferramenta de monitoramento.

Para quem serve

Serve para desenvolvedores, profissionais de performance, equipes de produto e responsáveis técnicos que precisam investigar uma rota lenta, um clique que demora a produzir resposta visual ou um layout que se desloca durante o uso. Também ajuda em revisões de pull request quando a pergunta é específica, por exemplo, se uma imagem de destaque está sendo descoberta tarde ou se um componente insere conteúdo sem reservar espaço.

Ela é diferente da Skill SEO Audit já existente no catálogo. SEO Audit faz uma revisão ampla de rastreamento, metadados, indexação e outros fatores, citando Core Web Vitals como uma parte do quadro. Core Web Vitals dedica o fluxo inteiro à medição e ao diagnóstico de LCP, INP e CLS, com referências detalhadas e separação explícita entre campo, laboratório, RUM e inspeção estática.

Não é adequada para prometer posição na Busca, calcular impacto comercial sem dados do negócio ou substituir uma auditoria de acessibilidade. Se o objetivo for uma inspeção geral de qualidade, use uma skill mais ampla e só acione esta quando houver uma métrica, uma rota ou uma hipótese de performance a investigar.

Compatibilidade e pré-requisitos

A versão 2.0 é apresentada como independente de framework. Os exemplos cobrem HTML, JavaScript, React, Next.js, Vue e Nuxt, mas as decisões precisam ser traduzidas para a arquitetura real. O host precisa carregar Agent Skills em Markdown. Para medições ao vivo, também precisa de uma URL acessível e de uma ferramenta compatível com traces de performance ou Lighthouse.

A rota preferida do projeto usa capacidades equivalentes às do Chrome DevTools MCP para registrar trace e analisar insights focados. Quando isso não existe, a referência de medição de performance admite Lighthouse CLI, PageSpeed Insights, CrUX e inspeção estática como alternativas. Cada alternativa responde a uma pergunta diferente.

Páginas autenticadas exigem cuidado adicional. Um audit de navegação pode recarregar a página, perder estado não salvo ou tocar recursos externos. Defina URL, estado, perfil de dispositivo, cache, rede, CPU, consentimento e autenticação antes de comparar duas execuções. Sem condições equivalentes, uma diferença aparente pode não vir do código alterado.

Instalação recomendada

O README oficial documenta instalação por Skills CLI. Para instalar somente esta Skill no projeto, revise a origem e use:

npx skills add addyosmani/web-quality-skills --skill core-web-vitals

O comando consulta a rede, executa um pacote via npx e grava arquivos. Confirme qual pacote será executado, onde a Skill será instalada e quais arquivos mudaram. O repositório também oferece instalação como plugin para Codex e Claude Code, além de extensão para Gemini CLI. Essas rotas podem trazer o catálogo completo, então habilite apenas o necessário.

Para uma revisão reproduzível, fixe o commit afa8da942115f2961fdbfa80807ea0b232ff6c00. O pacote local do Bastidores mantém somente Core Web Vitals e cinco referências necessárias. Ele não instala Chrome, Lighthouse, MCP, dependências ou CLIs.

Configuração antes do primeiro uso

Comece pela pergunta operacional. Registre a URL exata, o estado da página e a métrica que motivou o trabalho. Se a evidência vier do Chrome UX Report, marque se o dado é da página ou apenas da origem. Ausência de dados não significa aprovação. Rotas novas, privadas ou com pouco tráfego podem não ter amostra elegível.

Separe quatro caixas no relatório: CrUX ou outro dado de campo, RUM próprio, trace ou Lighthouse de laboratório e hipótese obtida pelo código. Não some nem compare esses valores como se fossem a mesma amostra. O percentil 75 de visitas reais não é equivalente a uma navegação local, mesmo quando os dois exibem a mesma unidade.

Defina ainda o limite de ação do agente. Ele pode somente diagnosticar, pode preparar um diff ou pode aplicar uma correção e rodar testes? Consultas a serviços externos, abertura de página autenticada, gravação de trace e edição de código precisam respeitar o escopo aprovado. Nunca inclua cookies, tokens ou dados pessoais em relatórios públicos.

Primeiro uso seguro

Escolha uma rota não destrutiva, preferencialmente pública ou de staging, e peça diagnóstico sem escrita. Registre três execuções equivalentes quando a decisão depender de um valor de laboratório. Use mediana e intervalo, além de documentar dispositivo, viewport, rede, CPU e cache. Uma única execução pode sofrer variação de rede, aquecimento de cache ou tarefas do sistema.

Se o problema for LCP, identifique o elemento e decomponha tempo de resposta, descoberta, transferência e atraso de renderização. Se for INP, reproduza a interação e separe atraso de entrada, processamento e apresentação. Se for CLS, capture o nó deslocado e o evento que alterou a geometria. A vítima visível nem sempre é a origem do deslocamento.

Somente depois disso peça uma correção pequena. Refaça a mesma medição sob as mesmas condições. O resultado imediato valida o laboratório. Para afirmar melhora de campo, aguarde novas visitas no RUM ou na janela agregada do CrUX.

Como o fluxo deve funcionar

1. Confirmar URL, estado, dispositivo e objetivo da análise.
2. Consultar dado de campo disponível e marcar o escopo como página ou origem.
3. Registrar trace ou auditoria controlada sem alterar a aplicação.
4. Escolher somente a métrica realmente suspeita.
5. Associar o valor observado a um elemento, interação, tarefa ou mudança de layout.
6. Inspecionar o código e os recursos envolvidos.
7. Propor a menor correção coerente com a evidência.
8. Revisar efeitos colaterais, privacidade, compatibilidade e custo de rede.
9. Repetir a medição com condições equivalentes.
10. Esperar dados novos antes de declarar melhora para usuários reais.

O guia oficial de Web Vitals usa o percentil 75 para avaliar a experiência de campo. A Skill preserva esse contexto e trata o trace como ferramenta de diagnóstico. Esse encadeamento reduz correções por palpite, como adicionar preload a todos os recursos ou dividir tarefas sem saber qual fase domina o atraso.

Resultado esperado

O primeiro resultado útil é um relatório curto e rastreável. Ele deve mostrar a evidência, o escopo, a condição do teste, a métrica, o elemento ou interação implicada e a hipótese técnica. Também precisa dizer o que ainda não foi medido. Frases como “o site está lento” ou “Core Web Vitals estão ruins” são insuficientes sem rota, fonte e condição.

Quando houver mudança, o resultado deve ser um diff pequeno acompanhado de comparação antes e depois no laboratório. Em LCP, isso pode tornar o recurso principal descoberto no HTML inicial ou reduzir o atraso de renderização. Em INP, pode reduzir uma tarefa longa ou antecipar feedback visual. Em CLS, pode reservar espaço antes de inserir mídia ou aviso.

Não espere um certificado. Uma página pode passar no laboratório e continuar ruim para parte dos usuários. Também pode ter bom Core Web Vitals e falhar em acessibilidade, segurança ou objetivo comercial. A Skill organiza uma decisão técnica específica, não uma avaliação total do produto.

Permissões, privacidade e riscos

O uso funcional pode abrir URLs, enviar consultas ao PageSpeed Insights ou CrUX, registrar traces, ler código e gravar relatórios. Uma página autenticada pode conter nomes, dados de clientes e identificadores em HTML, rede, console ou armazenamento. Use perfil e ambiente aprovados, minimize o escopo e não exponha artefatos de sessão.

A Skill também pode sugerir edição de código. Otimizações de imagem, cache, renderização, prioridade de rede e agendamento de tarefas alteram comportamento real. Um preload desnecessário compete por largura de banda. Um prerender pode iniciar analytics, anúncios ou efeitos antes da navegação. Um requestIdleCallback mal aplicado pode atrasar trabalho necessário. Revise cada mudança no contexto do produto.

RUM exige governança própria. A referência recomenda a biblioteca web-vitals para respeitar o ciclo de vida das métricas, mas coleta em produção continua exigindo finalidade, minimização, retenção e proteção do endpoint. Não inclua URL completa com parâmetros sensíveis nem identificadores pessoais sem base e controles adequados.

Erros comuns

• Chamar uma execução de campo: PerformanceObserver em uma sessão é observação de laboratório.
• Tratar ausência no CrUX como aprovação: dado indisponível não é dado bom.
• Comparar página com origem sem rótulo: o agregado da origem não prova a rota.
• Usar um único teste: variação pode dominar a diferença.
• Corrigir LCP com preload genérico: recursos especulativos competem pela rede.
• Atacar apenas o handler no INP: o atraso pode estar antes ou depois do processamento.
• Culpar o nó que se moveu no CLS: conteúdo inserido acima pode ser a causa.
• Lazy-load na imagem LCP: o recurso acima da dobra pode ser descoberto tarde.
• Prometer ranking: passar Core Web Vitals não garante posição na Busca.
• Declarar melhora de campo imediatamente: CrUX e RUM precisam de novas visitas.
• Rodar audit em formulário não salvo: uma recarga pode destruir o estado.
• Confundir ZIP documental com ferramenta: o pacote não executa medição sozinho.

Versão, licença e origem verificadas

Em 06/09/2026, o repositório addyosmani/web-quality-skills estava público, não arquivado, declarava licença MIT e registrava 2.757 estrelas. A curadoria fixou o HEAD afa8da942115f2961fdbfa80807ea0b232ff6c00. O último commit específico do SKILL.md era c6b06ad1285cd6b129b58455b2eec96ab6b67fa7.

A versão declarada é 2.0. A licença MIT permite redistribuição com preservação do aviso. O pacote local contém oito arquivos textuais: SKILL.md, cinco referências Markdown, LICENSE e ORIGEM.md. Não contém as outras cinco Skills do repositório, scripts, executáveis, dependências, navegador, Lighthouse, traces, relatórios, credenciais ou dados.

Para manter uma única Skill, os links relativos para MEASUREMENT e RUM foram ajustados para as cópias incluídas no ZIP, e o link opcional para a Skill Performance aponta ao arquivo oficial. Isso está declarado em ORIGEM.md. O ZIP tem 18519 bytes e SHA-256 f261eca48c07a492e24a955a77e7a6ef0123eb20f7dbb02c291464376e8de1ea.

Checklist antes de automatizar

• Fixe commit, versão, licença e pasta oficial.
• Leia a Skill e as cinco referências incluídas.
• Defina URL, estado, dispositivo, rede, CPU e cache.
• Marque toda evidência como campo, RUM, laboratório ou hipótese estática.
• Proteja autenticação, cookies, tokens, parâmetros e dados pessoais.
• Comece sem escrita e peça causa ligada à métrica observada.
• Faça mudança pequena e confira efeitos colaterais.
• Repita condições equivalentes e registre mediana e intervalo.
• Não prometa ranking, conversão ou melhora de campo imediata.
• Revise o diff e aprove a publicação separadamente.

Baixar o pacote documental auditado e abrir a pasta oficial fixada são ações separadas. Compare os arquivos antes de instalar. O pacote local existe para inspeção e não substitui as ferramentas de medição descritas pela fonte.

Fontes primárias

• Repositório oficial Web Quality Skills
• Pasta Core Web Vitals no commit auditado
• SKILL.md oficial
• Referência de LCP
• Referência de INP
• Referência de CLS
• Fluxo de medição
• Referência de RUM
• Instalação e compatibilidade
• Licença MIT
• Web Vitals
• Largest Contentful Paint
• Interaction to Next Paint
• Cumulative Layout Shift
• Chrome UX Report
• Referência atual do painel Performance do Chrome DevTools
• PageSpeed Insights API
• Biblioteca web-vitals