Encontrar e Corrigir Problemas de Interaction to Next Paint (INP): Um Guia Passo a Passo
Aprenda a identificar e corrigir problemas de Interaction to Next Paint usando dados RUM, Chrome DevTools e a API LoAF
Encontrar e Corrigir problemas de Interaction to Next Paint (INP)
Esta página faz parte da nossa série sobre Interaction to Next Paint (INP). O INP mede a capacidade de resposta do seu site ao rastrear o atraso entre uma interação do utilizador e a próxima atualização visual. Uma boa pontuação INP é inferior a 200 milissegundos, enquanto pontuações acima de 500 milissegundos são classificadas como ruins. Se é novo no INP, comece pela página principal sobre INP para uma visão geral completa.
Neste artigo vamos percorrer uma metodologia completa para identificar problemas de Interaction to Next Paint e depois explicar como corrigi-los. O processo envolve confirmar o problema no Google Search Console, diagnosticar as causas raiz com dados de Real User Monitoring (RUM), replicar as condições localmente e aplicar correções direcionadas a cada fase do INP.
DICA INP: na maioria das vezes o INP será muito pior
quando um utilizador interage com a página durante a fase de arranque do
carregamento da página. É por isso que, ao depurar o INP,
faz sentido registar todas as interações bem como o estado de carregamento da página!
Table of Contents!
Passo 1: Verificar o INP no Search Console
O primeiro passo é confirmar que tem realmente um problema de INP. Antes de fazer quaisquer alterações no código, verifique o problema no Google Search Console para que esteja a trabalhar com dados reais de campo em vez de suposições.
Inicie sessão no seu Google Search Console. No menu à esquerda clique em Core Web Vitals e selecione Mobile ou Desktop (dica: na maioria das vezes os problemas de INP surgem primeiro no mobile, por isso comece pelo mobile).
Aqui verá uma visão geral de todos os problemas relacionados com Core Web Vitals que existem atualmente no seu site. Se um destes problemas estiver relacionado com INP, confirmou que existe um problema.
Passo 2: Identificar problemas de Interaction to Next Paint
O Google Search Console não fornece nenhuma informação além de grupos de URLs para descobrir o que está a causar os problemas com o Interaction to Next Paint. Por isso, na maioria das vezes, os programadores avançam às cegas. Começam a remover JavaScript não utilizado (sempre uma ótima ideia) e a dividir a thread principal (também uma ótima ideia), mas isso raramente corrige o INP completamente.
É por isso que, ao melhorar o INP, precisamos de saber exatamente o que se está a passar. Precisamos de respostas a quatro perguntas críticas:
Que elementos, quando interagidos, causam uma má pontuação INP?
Normalmente uma má pontuação INP não é causada por um único elemento, mas por uma combinação de problemas. Precisamos de os
resolver um a um, começando pelos piores e avançando progressivamente.
Quando acontecem essas interações? Acontecem
durante a fase de arranque do
carregamento da página, ou acontecem mesmo quando a página principal já carregou completamente?
Onde acontecem
essas interações? Acontecem em todas as páginas, ou acontecem
apenas em algumas páginas específicas?
Como podemos replicar
essas interações? Já deve ter percebido que
é difícil replicar problemas de INP. É por isso que precisamos de nos preparar para o sucesso,
imitando as características do dispositivo com uma má pontuação INP.
Configurar o rastreamento RUM
Para responder a todas estas perguntas precisamos de começar a rastrear utilizadores reais e registar quaisquer problemas que
possam acontecer com o Interaction to Next Paint. Existem várias formas de ativar o rastreamento RUM. A
primeira é aproveitar a biblioteca Web Vitals e enviar os resultados para o seu próprio backend de analytics.
A vantagem deste método é que é barato e flexível. A desvantagem é que pode dar
muito trabalho extra.
Uma boa alternativa a enviar os seus dados de Core Web Vitals para o seu próprio backend é usar uma das muitas ferramentas RUM disponíveis. Desenvolvemos o CoreDash precisamente para estes casos de uso. O CoreDash é uma ferramenta RUM de baixo custo, rápida e eficaz que faz o trabalho. Claro que existem muitas outras soluções RUM disponíveis e também farão o trabalho (embora a um preço mais elevado).
Encontrar interações lentas por elemento que causam um INP elevado
A primeira coisa a fazer é encontrar as interações mais lentas que causam as piores pontuações INP. Liste as suas páginas por "INP metric by Elements" no CoreDash e obterá as suas interações mais lentas. Clique na primeira linha para filtrar as suas métricas por essas interações.
Descobrir quando ocorrem as interações com mau INP
Em seguida, ordene os URLs filtrados por estado de carregamento. Isto dar-lhe-á mais informação sobre a causa raiz do INP. Neste caso, o INP elevado acontece quando o conteúdo DOM foi carregado. Isto significa que os scripts foram analisados mas os scripts assíncronos e os sub-recursos da página ainda não foram carregados. Neste caso, o INP é causado por cliques precoces quando o carregamento da página ainda não terminou completamente.
Continue clicando no estado de carregamento com maior impacto para criar outro filtro.
Encontrar URLs responsáveis por pontuações INP elevadas
Finalmente, quando filtrámos pelo elemento com a interação mais lenta e o estado de carregamento correto, vamos analisar os URLs onde o INP está pior. Neste caso, isto acontece claramente num conjunto específico de páginas.
Encontrar características do dispositivo
Quando identificámos interações lentas, estado de carregamento e URLs que causam um Interaction to Next Paint elevado, vamos analisar que tipos de visitantes causam as piores pontuações INP. Analisaríamos Device Memory, Bandwidth, tamanho do ecrã e outras características de hardware. Depois de identificarmos estas características podemos avançar para replicar e registar o problema.
Usar a API Long Animation Frames (LoAF) para diagnósticos INP
A API Long Animation Frames (LoAF) fornece dados de atribuição granulares que ajudam a identificar exatamente quais scripts e funções são responsáveis por interações lentas. Ao contrário da antiga API Long Tasks, o LoAF fornece URLs de scripts, nomes de funções e decomposições de tempo por frame. Isto torna-o uma ferramenta inestimável para depuração de INP, especialmente quando combinado com dados RUM de uma ferramenta como o CoreDash.
Use o código seguinte para recolher entradas LoAF para interações que excedam um limiar. Este observador captura a atribuição do script, duração e tempo de bloqueio para cada long animation frame:
// Observe Long Animation Frames for INP attribution
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Only log frames longer than 50ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
A API LoAF revela quais scripts contribuem para cada fase do INP. O array scripts indica o ficheiro fonte exato e o nome da função, enquanto renderStart e styleAndLayoutStart ajudam a separar o tempo de processamento do atraso de apresentação. Para uma discussão mais aprofundada sobre como o carregamento async vs defer JavaScript afeta estes tempos, consulte o nosso guia dedicado.
Passo 3: Replicar e depurar interações que causam uma pontuação INP elevada
Quando tivermos toda a informação necessária podemos começar a investigar profundamente os problemas subjacentes do Interaction to Next Paint.
Preparar para o sucesso: replicar as circunstâncias de falha do INP
A próxima coisa a fazer é tentar recriar a falha do INP. Fazemos isto imitando as circunstâncias onde o INP pode estar a falhar.
Use o Painel de Performance do Chrome: Abra as ferramentas de programador do Chrome (Ctrl+Shift+I) e selecione o
painel de performance. Na barra superior pode selecionar o CPU Throttle (reduza para 4x para
emular um dispositivo móvel normal), o Network Throttle (selecione o preset fast 3G para imitar o
seu dispositivo móvel médio), e defina o hardware concurrency para 4 ou 8 para imitar o seu dispositivo móvel médio.
Para iniciar o Chrome com menos memória disponível (embora baixar as definições de rede e CPU muitas vezes seja suficiente) inicie o Chrome num contentor Docker e atribua menos memória.
Recarregue a página, interaja e verifique o INP com o visualizador Core Web Vitals
O próximo passo para encontrar a causa das más pontuações INP é simular as condições e confirmar
que as pontuações INP são de facto tão más como reportado.
Recarregue a página e clique no elemento certo no momento certo
Depurar o INP com um trace de performance
Este é o momento para o qual se preparou nos passos anteriores. É hora de descobrir por que uma determinada interação está a causar a má pontuação de Interaction to Next Paint.
Abra a Consola de Programador do Chrome (Ctrl+Shift+I), navegue até ao painel de Performance e desta vez clique no ícone de Seta Circular para recarregar a página e começar a gravar (ou use o atalho Ctrl+Shift+E). Enquanto a gravação está a decorrer, interaja com o elemento que causa o mau INP. Após alguns segundos, pare a gravação e examine a linha temporal. Procure o evento de interação na faixa "Interactions", depois inspecione as tarefas correspondentes na faixa "Main" para ver exatamente que código está a ser executado durante cada fase.
Ler o trace de performance
No painel de Performance do Chrome, a interação aparecerá como uma barra colorida na faixa "Interactions". Clique nela para ver a duração total do INP e a sua decomposição. Abaixo, na faixa "Main", pode ver as tarefas individuais que foram executadas durante a interação. Preste atenção a:
- Tarefas antes do event handler: estas contribuem para o input delay
- O próprio event handler: este é o tempo de processamento
- Trabalho de renderização após o handler terminar: este é o atraso de apresentação
Cruze estas descobertas com os seus dados LoAF para confirmar que os scripts identificados no trace correspondem aos dados de atribuição da sua ferramenta RUM. Este também é um bom momento para verificar se algum handler de scroll JavaScript está a contribuir para o problema.
Passo 4: Corrigir problemas de INP
Estamos agora num ponto em que sabemos que interação está a causar o nosso mau INP e analisámos exatamente o que se está a passar durante esta interação lenta. Isto significa que é hora de começar a corrigir o Interaction to Next Paint. O Interaction to Next Paint pode ser decomposto em 3 fases: input delay, tempo de processamento e atraso de apresentação.
Cada fase do Interaction to Next Paint deve ser tratada de forma diferente. Abaixo está um resumo das estratégias mais impactantes para cada fase. Para guias de otimização completos, siga os links para as páginas dedicadas.
Minimizar o Input Delay:
O input delay é o tempo entre a interação com a página e quando o callback do evento começa a executar. Embora exista sempre algum input delay (até os browsers precisam de tempo para agendar os callbacks) há várias coisas a considerar:
- Evitar tarefas longas. Sempre que uma tarefa é executada, bloqueia a thread principal e deixa os callbacks de eventos à espera. Isto é especialmente importante ao otimizar cliques precoces (já que a maioria dos scripts estará a ser executada nessa altura). Para estratégias de redução do bloqueio por JavaScript, consulte o nosso guia sobre async vs defer JavaScript.
- Ter cuidado ao criar novas tarefas. Por exemplo, tarefas recorrentes via
setTimeout()ou tarefas que provavelmente ocorrerão antes do evento INP como callbacks no eventomouseover. - Medir e avaliar a interação precoce. Quando um elemento interativo é apresentado cedo (por exemplo um elemento de pesquisa do site) e é controlado por JavaScript que carrega mais tarde, qualquer interação com o elemento não irá desencadear uma atualização imediata do layout. Priorize a funcionalidade ou oculte/desative o elemento antes de estar a funcionar corretamente.
- Usar web workers para executar JavaScript fora da thread principal do browser. Os web workers permitem que scripts sejam executados fora da thread principal. Isto impedirá que a thread principal bloqueie e cause problemas de input delay no INP.
- Carregar scripts de terceiros não essenciais durante o tempo de inatividade do browser. Alguns scripts são mais críticos do que outros. Faz sentido priorizar esses scripts e carregar os menos importantes durante o tempo de inatividade do browser. Por exemplo, um script de chat. Consulte o nosso guia sobre 14 métodos para adiar JavaScript para técnicas práticas.
Minimizar o Tempo de Processamento
- Remover código desnecessário. Código desnecessário é código antigo que ainda é executado ou código novo que não é necessário nesta página específica mas ainda consome tempo de CPU. Esta é de longe a forma mais fácil de melhorar imediatamente o INP.
- Adiar código que não precisa de ser executado antes do próximo paint. Separe o código em código crítico que deve ser executado antes do INP e código não crítico (por exemplo envio de analytics) e agende isso após o evento de paint com o método
requestIdleCallback(). - Otimizar código que deve ser executado antes do paint. Verifique o seu código e reescreva partes lentas ou ineficientes.
- Fornecer feedback imediato. Em tarefas complicadas ou potencialmente lentas, forneça feedback imediato antes de executar o código principal.
Minimizar o Atraso de Apresentação
- Manter o DOM pequeno e simples. Será muito mais fácil para um browser renderizar uma página com poucos e simples elementos DOM não aninhados (nós HTML) do que renderizar uma página com muitos nós DOM aninhados. Leia mais sobre corrigir tamanho excessivo do DOM.
- Usar content-visibility para renderizar preguiçosamente conteúdo fora do ecrã. O content-visibility irá acelerar a renderização das partes visíveis da página ao adiar a renderização do conteúdo fora do ecrã e renderizá-lo mesmo a tempo.
Correção rápida: yield à thread principal com scheduler.yield()
Uma das técnicas mais eficazes para melhorar o INP em todas as três fases é yielding à thread principal entre trabalho crítico e trabalho não crítico. A API scheduler.yield() fornece uma forma limpa de fazer isto. Aqui está uma função auxiliar reutilizável com um fallback para browsers que ainda não suportam a API:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Usage in an event handler
async function handleButtonClick() {
// Critical work: update the UI
updateVisualFeedback();
// Yield to let the browser paint
await yieldToMain();
// Non-critical work: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Aprofundamento em cada fase do INP
Agora que sabe como identificar e corrigir problemas de INP, explore cada fase em detalhe:
- Input Delay: Aprenda a minimizar o tempo entre a interação do utilizador e o início do processamento do evento. O input delay representa aproximadamente 18% do tempo total do INP.
- Tempo de Processamento: Otimize a execução do event handler que representa aproximadamente 40% do tempo total do INP.
- Atraso de Apresentação: Reduza o trabalho de renderização e pintura que representa aproximadamente 42% do tempo total do INP.
Para estratégias adicionais que abrangem todas as três fases, consulte os nossos guias sobre melhorar o INP eliminando o scroll JavaScript e escolher async vs defer para o seu JavaScript.
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
