Dimensão Core/Dash: Load State (INP)

Segmente o INP pela fase do ciclo de vida da página em que a interação ocorreu. Identifique se seu problema de responsividade é uma condição de corrida no carregamento ou um problema de JavaScript no runtime.

Teste grátis

Trusted by market leaders · Client results

kpnnestlehappyhorizonloopearplugssaturnmy work featured on web.devdpg mediaharvardworkivasnvaleteiamarktplaatsadevintacomparewhowhatwearebayvpnnina caremonarchfotocasaperionerasmusmc

Dimensão: Load State INP (inpls)

A dimensão Load State (INP) registra o estado de prontidão do documento (ready state) no momento exato em que uma interação do usuário foi capturada. Cada evento de INP no Chrome User Experience Report carrega uma tag de load state: loading, dom-interactive, dom-content-loaded ou complete. O CoreDash exibe essa tag como uma dimensão filtrável e agrupável para que você possa responder à pergunta que as pontuações brutas de INP não conseguem: quando no ciclo de vida da página ocorreu a pior interação?

Essa pergunta é a linha divisória entre duas correções de engenharia completamente diferentes. Um problema de INP que se concentra durante o estado loading exige uma estratégia de adiamento de JavaScript. Um problema de INP que se concentra durante o estado complete exige reduzir o trabalho dos manipuladores de eventos, diminuir o overhead do framework ou dividir long tasks no seu código de runtime. O agrupamento por load state oferece essa divisão sem necessidade de instrumentação manual.

Nos dados do CoreDash de todos os sites monitorados, a distribuição de interações de INP por load state é de aproximadamente: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. A maioria das interações acontece após a página estar totalmente carregada, mas as piores pontuações de INP se concentram esmagadoramente nos estados iniciais.

Captura de tela

Por que o Load State é importante para o INP

A métrica Interaction to Next Paint mede a latência total de uma interação do usuário: atraso de entrada (input delay), tempo de processamento do manipulador de eventos e atraso de apresentação (presentation delay) até o próximo frame renderizado. Desses três componentes, o input delay é o mais diretamente controlado pelo que o navegador está fazendo no momento em que o usuário clica ou toca.

Durante o início do carregamento da página, a main thread está em máxima contenção. O navegador está analisando o HTML, executando scripts síncronos, construindo o CSSOM, executando recursos parser-blocking e disparando ciclos de renderização seguidos. Cada long task na main thread é uma janela durante a qual a interação do usuário entra na fila e aguarda. Essa espera é o input delay, e ele é o principal fator para um INP ruim durante o carregamento da página.

Interações que ocorrem após o document.readyState atingir complete encontram uma main thread mais tranquila. O navegador já terminou de carregar. Se o INP continuar ruim nessa fase, a causa não é a contenção do carregamento. É o JavaScript que sua página executa em resposta às ações do usuário: manipuladores de eventos inchados, ciclos de re-renderização do framework, layout thrashing acionado por scripts ou código de terceiros não otimizado sendo executado de forma síncrona durante a interação.

O load state é o filtro mais rápido para separar essas duas causas raiz.

Os Load States

loading

A página ainda não terminou de analisar o documento HTML. A main thread está executando scripts síncronos, buscando recursos parser-blocking e construindo o DOM inicial. Este é o ambiente mais hostil para a interação do usuário. O input delay fica no nível máximo porque qualquer long task bloqueia diretamente o navegador de processar o clique ou toque. Usuários que interagem nessa janela são tipicamente os visitantes mais impacientes ou aqueles em conexões rápidas que alcançam o conteúdo visível antes do término do carregamento da página. As pontuações de INP deles são as piores que você irá coletar. Se uma parcela significativa dos seus eventos de INP ruim apresentar o estado loading, mova os scripts não críticos para defer ou async e elimine os recursos parser-blocking acima da dobra.

dom-interactive

O document.readyState atinge interactive quando o HTML está totalmente analisado e o DOM está construído, mas subrecursos como imagens, stylesheets e scripts deferred ainda estão carregando. Os scripts deferred começam a ser executados neste momento, o que significa que a main thread ainda pode estar altamente ocupada. A hidratação do framework frequentemente começa aqui. Esta é uma janela perigosa porque a página parece pronta para o usuário, mas a main thread ainda está ocupada. O input delay permanece elevado. Se o INP ruim se concentrar aqui, a correção é a mesma para o estado loading: reduza o volume de trabalho síncrono que roda imediatamente após a conclusão da análise do DOM.

dom-content-loaded

O evento DOMContentLoaded foi disparado. O DOM está completo e os scripts deferred foram executados. A maioria dos frameworks JavaScript já terminou sua etapa inicial de hidratação neste ponto. A carga de trabalho da main thread diminui e as interações começam a receber respostas mais rápidas. As pontuações de INP durante este estado são tipicamente melhores do que nos dois estados anteriores, mas ainda elevadas se comparadas ao estado complete. Se você notar uma concentração de interações ruins aqui, analise o que os scripts do seu framework ou aplicação estão fazendo nos manipuladores (handlers) do DOMContentLoaded e se o trabalho de hidratação pode ser dividido em blocos ou submetido a yield para permitir o processamento de entradas entre as tarefas.

complete

O document.readyState atinge complete quando todos os recursos, incluindo imagens, fontes e iframes de terceiros, foram carregados. Este é o estado estável em que a página opera durante o restante da sessão. Um INP ruim nesse estado é um problema puramente de runtime. O carregamento da página terminou. Se a main thread ainda estiver bloqueando as interações, a causa está na execução do seu JavaScript durante a interação: manipuladores de eventos realizando muito trabalho síncrono, atualizações do framework acionando recálculos de layout caros ou scripts de terceiros executando long tasks continuamente. A correção não envolve adiamento. Trata-se de reduzir o custo do que acontece quando o usuário realmente clica.

Fluxo de Trabalho de Depuração

Passo 1: Filtre por load state no CoreDash. Abra a tabela de detalhamento de INP e agrupe por Load State. Identifique qual estado possui a maior proporção de interações ruins (acima de 200ms). Isso mostra imediatamente se você está diante de um problema de carregamento ou de um problema de runtime.

Passo 2: Faça o cruzamento com URL e dispositivo. Combine a dimensão Load State com a dimensão URL para encontrar quais páginas específicas geram interações ruins nos estados iniciais de carregamento. Dispositivos móveis são desproporcionalmente afetados durante o carregamento porque CPUs mais lentas prolongam cada long task.

Passo 3: Adeque a correção ao estado. Para os estados loading e dom-interactive, faça uma auditoria na sua estratégia de carregamento de scripts usando o guia Optimize INP. Mova scripts para defer, elimine recursos render-blocking e use scheduler.yield() para dividir as tarefas longas de inicialização. Para o estado complete, analise o perfil (profile) dos seus manipuladores de eventos no Chrome DevTools e reduza o trabalho síncrono disparado por interação.

Regra Prática de Engenharia

Se mais de 30% de suas interações de INP ruins estiverem marcadas com loading ou dom-interactive, seu problema de INP é de carregamento de página e o adiamento de JavaScript produzirá a maior melhoria. Se mais de 60% das interações ruins estiverem marcadas com complete, seu problema de INP é de runtime e você precisa otimizar o custo do manipulador de eventos, não a ordem de carregamento dos scripts. O Load State (INP) define isso em uma única visualização de tabela, sem exigir uma sessão de laboratório (lab session) ou instrumentação personalizada.