Core Web Vitals 2025: foco em INP

Em 2025, o principal pilar de desempenho e UX da web é o Core Web Vitals INP. A métrica Interaction to Next Paint substituiu oficialmente o FID e se tornou o indicador definitivo de responsividade real das páginas. Entender o comportamento do INP é crucial para qualquer time de SEO e desenvolvimento que queira garantir experiências rápidas, suaves e competitivas no ecossistema digital.

O Core Web Vitals INP avalia a latência total das interações, incluindo cliques, toques e teclas pressionadas, reportando o valor mais lento observado (ignorando outliers). Ele é medido no percentil 75 (p75), e uma página é considerada boa quando mantém esse valor em até 200 ms — e ruim quando ultrapassa 500 ms.

O que é INP (e por que ele manda na responsividade)?

O Interaction to Next Paint (INP) mede o tempo entre a ação do usuário e a próxima renderização visual. Diferente de métricas pontuais, ele observa todas as interações durante a visita, registrando o pior caso como representativo da experiência. Esse modelo torna o INP a métrica mais estável e fiel à percepção humana de fluidez.

Em 2025, dominar o Core Web Vitals INP significa garantir respostas instantâneas a qualquer interação. A experiência percebida pelo usuário depende diretamente desse intervalo — um atraso acima de 200 ms já transmite sensação de lentidão. Portanto, o INP é o novo padrão-ouro de responsividade, consolidando seu papel no trio essencial com LCP e CLS.

Quando o INP entrou no Core Web Vitals (e o que mudou do FID)?

O INP entrou oficialmente no conjunto de Core Web Vitals em 12 de março de 2024, substituindo o First Input Delay (FID). Enquanto o FID mede apenas o primeiro input e apenas o tempo de atraso antes da execução do evento, o INP mede toda a jornada da interação — do clique até o próximo paint.

Essa mudança tornou o diagnóstico de performance mais realista. O FID capturava apenas uma fração mínima do comportamento da página; o INP, em contrapartida, cobre todos os eventos, detectando gargalos em rotinas recorrentes. Essa evolução exige times atentos ao ciclo completo: input delay → callbacks → renderização.

Como medir INP corretamente (campo vs. laboratório)?

RUM vs lab: o desempenho real é decidido pelo campo. Para validar o Core Web Vitals INP, 75% das visitas precisam estar dentro da faixa “boa”. As medições de campo (RUM/CrUX) são as únicas que contam para o ranking. Ferramentas como PageSpeed Insights, Search Console e CrUX Vis ajudam a visualizar o p75 e tendências históricas.

Em ambiente de laboratório, o INP não pode ser observado diretamente sem interação humana. Por isso, usa-se o TBT (Total Blocking Time) como proxy em testes automatizados. Ele indica tarefas longas que impactariam a responsividade. Para análises detalhadas, reproduza fluxos reais no DevTools ou WebPageTest. Essa abordagem híbrida (campo + lab) é o padrão recomendado pelo web.dev.

O que mudou no CrUX em 2025 (e por que seu dashboard pode variar)?

O Chrome UX Report (CrUX) atualizou sua metodologia em 2025, ampliando a cobertura de dados de INP. O relatório passou a considerar dimensões adicionais, como ECT (Effective Connection Type), o que aumentou a amostragem de origens com dados válidos.

Essa atualização impacta dashboards e séries históricas: percentuais de URLs “boas” podem oscilar a partir de fevereiro de 2025, não necessariamente por piora de performance, mas por mudança na base de comparação. O ideal é alinhar o histórico com o novo modelo, garantindo consistência entre períodos e mantendo o foco no p75.

Como diagnosticar onde está o gargalo do INP?

Para melhorar o Core Web Vitals INP, é preciso identificar em qual fase da interação ocorre o gargalo. A primeira etapa é o input delay, causado por filas ocupadas no carregamento inicial — geralmente devido a scripts, bibliotecas de terceiros e inicializações pesadas.

A segunda etapa envolve callbacks longos, quando os event handlers executam tarefas demoradas na main thread. Por fim, vem a apresentação, que abrange renderização, layout e pintura até o próximo frame. Registrar o tipo de interação (clique, tecla ou toque) e o contexto (durante ou após o load) ajuda a correlacionar travamentos e momentos críticos da jornada.

Como reduzir input delay (o usuário clicou e nada aconteceu)?

Para cortar o input delay, o ideal é evitar long tasks durante o carregamento. Divida scripts e inicializações em partes menores, permitindo que o navegador respire entre execuções. Priorize apenas o essencial na rota de startup e adie trabalhos secundários.

Um exemplo prático: antes, um e-commerce carregava todos os scripts de recomendação no início, atrasando o clique no botão “Comprar”. Após dividir o processamento e aplicar carregamento assíncrono, o INP caiu de 380 ms para 160 ms. Reduzir o peso de terceiros e modularizar tarefas é o primeiro passo do playbook de otimização.

Como otimizar callbacks de evento (sem travar a main thread)?

Durante o tratamento de eventos, a regra é simples: faça o mínimo possível dentro do handler. Divida processamentos em microtarefas usando setTimeout, requestIdleCallback ou padrões de yield, evitando que a main thread fique bloqueada.

Sempre que possível, aplique técnicas de debounce e throttle em eventos contínuos, como scroll e input. Recalcular o layout a cada digitação, por exemplo, é um erro comum que degrada o Interaction to Next Paint. Pequenas pausas e fragmentação de tarefas garantem fluidez — cada long task acima de 50 ms pode ser um vilão da responsividade.

Como diminuir o tempo de apresentação (next paint mais rápido)?

Depois que o código é executado, o desafio é acelerar o Next Paint. Estruture o DOM de forma plana e enxuta, evitando layout thrashing (refluxos de cálculo de posição). A propriedade content-visibility: auto é uma aliada valiosa, permitindo o render lazy de elementos fora de tela.

Cautela também com renderizações via JavaScript, comuns em SPAs: injeções grandes de conteúdo atrasam o frame seguinte. O checklist ideal inclui DOM limpo, uso moderado de frameworks e renderização progressiva. Assim, o Core Web Vitals INP reflete a agilidade real percebida pelo usuário.

Quais ferramentas usar no dia a dia (time SEO+Dev)?

Times maduros combinam medições de campo e laboratório. O PageSpeed Insights e o CrUX oferecem o retrato do p75; o Search Console exibe tendências históricas e alertas de degradação. Para debug, use o painel Performance do DevTools e o Lighthouse (com TBT como proxy).

O RUM próprio, usando a biblioteca web-vitals.js, é a melhor forma de observar o Core Web Vitals INP no contexto real. Ele mostra qual interação específica estourou o limite e em que momento. Essa combinação de ferramentas aproxima SEO e desenvolvimento, permitindo agir rápido sobre cada causa raiz.

Como priorizar correções no CWV?

O plano de ação pode seguir três marcos. Em 14 dias, identifique as interações mais lentas via RUM e elimine long tasks óbvias. Em 30 dias, refatore handlers críticos, reduza dependências de terceiros e reestruture a carga de scripts da rota inicial.

No ciclo de 60 dias, avance para ajustes estruturais: simplifique o DOM, reorganize padrões de renderização e adote content-visibility ou streaming SSR em páginas interativas. Esse roteiro incremental é o caminho mais eficiente para estabilizar o Interaction to Next Paint (INP) abaixo de 200 ms e manter o selo “Good” no Search Console.

Onde acompanho impacto (sem repetir o post de métricas)?

O impacto do Core Web Vitals INP deve ser acompanhado, consolidando os dados de campo: p75 mobile e desktop, porcentagem de URLs “boas” e distribuição de interações lentas. Os resultados complementares — CTR, conversões e coortes AIO — são tratados em outro material.

Monitorar essas métricas em um painel único permite detectar regressões rapidamente e correlacionar o INP com indicadores de negócio. Afinal, performance e conversão caminham lado a lado.

FAQ — Perguntas frequentes sobre INP

O que exatamente o INP mede?
O INP avalia a latência de interações reais — cliques, toques e teclas — do início da ação até o próximo paint. O valor final reflete a pior interação da sessão, ignorando outliers.

Quais são os thresholds do INP?
Bom: ≤200 ms. Precisa melhorar: entre 200 e 500 ms. Ruim: acima de 500 ms, considerando o p75 das visitas. Mire 200 ms ou menos para garantir uma experiência fluida.

INP dá para medir em laboratório?
Parcialmente. Como muitos testes automáticos não interagem com a página, o TBT é o proxy mais confiável em ambiente de lab. O INP real depende de RUM e CrUX.

Por que meus números de INP mudaram em 2025?
O CrUX passou a incluir novas dimensões de rede, como ECT, o que ampliou a base e alterou percentuais a partir de fevereiro de 2025.

O que mais move o INP na prática?
Os maiores causadores são long tasks na inicialização, handlers pesados e renderizações complexas. Atacar essas três fases é o núcleo da otimização.

Ainda preciso olhar FID?
Não como Core Web Vital. O INP substituiu o FID em março de 2024. Agora o foco é manter INP, LCP e CLS dentro das faixas “boas”.