Como melhorar a interação com a próxima pintura (INP)

A interação com a próxima pintura (INP) não é mais experimental.

A partir de março de 2024, o Google está comprometido em promover o INP como a nova métrica principal da Web vital para capacidade de resposta, substituindo o primeiro atraso de entrada.

E embora você possa pensar que lidar com a pontuação INP do seu site é uma tarefa que você pode adiar, discordamos.

O Google já começou a sinalizar problemas de INP no Search Console e enviar e-mails para sites que não atingem o limite de boa capacidade de resposta:

Em outras palavras, o momento perfeito para começar a otimizar seu site para a próxima métrica de capacidade de resposta é agora. E nas linhas a seguir, você aprenderá exatamente como.

• Visão geral da interação com a próxima pintura
• Compreendendo a latência da interação
• Por que seu site falha no INP
• Como identificar interações lentas
• Como otimizar o INP

Leia.

Interação com a próxima pintura: visão geral

Antes de mergulhar nas várias técnicas de otimização, aqui está uma rápida recapitulação do que o INP mede.

O INP avalia a capacidade de resposta geral de uma página às interações do usuário observando a latência de todas as interações qualificadas durante a visita de um usuário a uma página. O valor final de INP é a interação mais longa observada.

As interações que desempenham um papel nos cálculos do INP são:

• Clicar com o mouse;
• Tocar em um dispositivo com tela sensível ao toque;
• Pressionar uma tecla em um teclado físico ou digital.

Semelhante aos outros Core Web Vitals, sua pontuação INP pode estar em um dos três limites:

• Bom : 0-200ms
• Precisa de Melhorias : 200-500ms
• Ruim : >500ms

Para garantir que você atinja esse objetivo para a maioria de seus usuários, é recomendável avaliar o 75º percentil de carregamentos de página, segmentado em dispositivos móveis e desktop.

Se você quiser aprender mais ou aprimorar seus conhecimentos sobre o INP, leia nosso artigo sobre a próxima métrica de capacidade de resposta.

Compreendendo a latência da interação

Se você deseja que sua pontuação de INP vá de ruim para boa, precisa entender a latência da interação.

Então, o que exatamente é latência de interação?

A latência de interação refere-se ao atraso ou atraso experimentado entre a entrada ou ação de um usuário e a resposta ou saída resultante na tela. É um fator crucial para determinar a capacidade de resposta e o desempenho percebido do seu site.

Três componentes principais contribuem para a latência da interação:

atraso de entrada

O atraso de entrada refere-se ao tempo entre quando um usuário começa a interagir com a página e quando as ações associadas ou retornos de chamada de evento começam a ser executados. Inclui os atrasos físicos ou técnicos causados ​​pelo dispositivo de entrada (por exemplo, teclado, mouse, tela sensível ao toque) e os mecanismos de processamento de entrada do sistema.

Tempo de processamento

Depois que a entrada do usuário é recebida, o sistema deve processá-la para determinar a resposta ou ação apropriada. O tempo de processamento refere-se à duração necessária para o sistema analisar e interpretar os dados de entrada, realizar quaisquer cálculos ou operações necessárias e gerar a saída ou resposta.

Atraso na apresentação

Depois que o sistema gera a saída ou resposta, geralmente há um atraso antes de ser apresentado ao usuário. O atraso de apresentação abrange o tempo que leva para o sistema atualizar a exibição, renderizar gráficos ou interfaces de usuário e entregar a saída para a interface de usuário ou dispositivo de saída.

Se precisar de mais informações, você pode conferir a apresentação de Jeremy Wagner na JSConf Korea 2022:

Compreender e otimizar a latência da interação pode fornecer uma experiência de usuário perfeita e corrigir suas pontuações de INP.

Mas antes disso, vamos dar uma olhada nos principais culpados pela alta latência de interação e pontuações de INP ruins…

Problema de INP do Core Web Vitals detectado em seu site: o que pode estar causando isso?

Embora o INP seja rotulado como pendente,isso não significa que você deva entrar no processo de otimização sem uma estratégia.

A primeira coisa que você precisa fazer é aprender quais são os principais culpados do INP, para que você possa lidar com eles de maneira eficaz.

Aqui estão os principais motivos para a mensagem de erro"Problema de INP: mais de 200 ms":

Tarefas longas

Tudo o que um navegador faz é considerado uma tarefa. Isso inclui renderização, análise de HTML, execução de JavaScript e qualquer coisa sobre a qual você possa ou não ter controle.

O thread principal é onde o navegador faz a maior parte do trabalho necessário para exibir uma página. E embora possa haver dezenas de tarefas que precisam ser executadas,o thread principal pode processar apenas uma tarefa por vez.

Mas isso é apenas metade do problema.

A outra metade é quese uma tarefa leva mais de 50 milissegundos para ser executada, ela é classificada como umatarefa longa. 

Considerando que o thread principal pode lidar com uma tarefa por vez, quanto mais longa for a tarefa, mais tempo o navegador ficará bloqueado para processá-la.

Em outras palavras, se o usuário estiver tentando interagir com a página durante a execução de uma tarefa longa, o navegador demorará a atender à solicitação.

O resultado é - latência de interação e uma pontuação INP mais baixa.

Tamanho grande do DOM

Outro motivo para falha no INP é ter um tamanho grande de DOM.

O Document Object Model (DOM) é uma parte inseparável de cada página da web. O DOM é uma representação de um documento HTML estruturado como uma árvore. Cada ramificação da árvore termina em um nó e cada nó contém objetos. Os nós podem representar diferentes partes do documento, como elementos, strings de texto ou comentários.

O DOM em si não é um problema, mas seu tamanho pode ser. Um tamanho grande de DOM afeta a capacidade de um navegador de renderizar uma página com rapidez e eficiência.

Quanto maior o DOM, mais intensivo é o uso de recursos para exibir inicialmente a página e fazer atualizações subsequentes durante o ciclo de vida da página.

Simplificando:

Se você deseja que uma página responda rapidamente às interações do usuário, certifique-se de que seu DOM inclua apenas os elementos necessários.

Você pode estar se perguntando o que significa “necessário”. De acordo com o Lighthouse, o tamanho do DOM de uma página é excessivo quandoexcede 1.400 nós .

Portanto, certifique-se de ficar dentro desse limite. Caso contrário, você poderá ver o seguinte erro em seu relatório PageSpeed ​​Insights:

Renderização do lado do cliente de HTML

Para entender por que a renderização do site do cliente pode causar pontuações de INP ruins, precisamos explicar como ela difere da renderização do lado do servidor do HTML.

O carregamento de página tradicional envolve o navegador recebendo HTML do servidor a cada navegação. O que acontece em segundo plano quando uma pessoa decide carregar uma página é:

1. O navegador envia uma solicitação de navegação para o URL fornecido.
2. O servidor responde com HTML em blocos.

A chave aqui é “em partes”.

Quando o navegador recebe o primeiro pedaço de HTML, ele pode começar a analisá-lo. Mas, como sabemos, analisar HTML é uma tarefa da thread principal.

No entanto, depois que cada bloco é processado, o navegador faz uma pausa na análise e permite que outras tarefas sejam executadas. Isso evita tarefas longas que podem deixar o navegador lento.

Em vez disso, ele pode começar a renderizar as partes da página que já foram analisadas, para que o usuário veja uma página parcialmente carregada mais cedo. Ele também pode lidar com qualquer interação do usuário que ocorra durante o carregamento inicial da página.

Em outras palavras:

Essa abordagem se traduz em uma melhor pontuação de Interação para a próxima pintura (INP) para a página.

Pelo contrário, se o seu site usa o padrão de aplicativo de página única (SPA), que cria dinamicamente grandes partes do HTML/DOM no cliente com JavaScript, você pode esperar efeitos negativos em sua pontuação de INP.

Na renderização do lado do cliente, o servidor envia um pequeno pedaço de HTML básico para o cliente. Em seguida, o cliente se encarrega de preencher o conteúdo principal da página com os dados que ele busca no servidor.

Todas as navegações futuras são tratadas por JavaScript, buscando novo HTML do servidor e atualizando dinamicamente a página sem recarregá-la totalmente. Infelizmente, quando se trata de tarefas JavaScript no lado do cliente, elas não são divididas automaticamente.

Isso pode levar a tarefas longas que bloqueiam o encadeamento principal, afetando potencialmente a pontuação de interação com a próxima pintura da sua página. Portanto, a renderização do lado do cliente pode prejudicar o carregamento e a interatividade da sua página.

Se você precisar de informações adicionais sobre os prós e contras da renderização do lado do servidor versus do lado do cliente, confira este vídeo:

Agora que você conhece alguns dos principais culpados, vamos continuar medindo sua pontuação INP e identificando interações lentas.

Como identificar interações lentas usando dados de campo e depurá-las no laboratório

A próxima etapa na jornada de otimização do INP é medir o desempenho do seu site e identificar quaisquer interações lentas.

Semelhante ao primeiro atraso de entrada, o INP é melhor medido em campo - examinando como os usuários reais experimentam seu site.

O processo de teste ideal seria assim:

1. Reunir dados de campo para INP
2. Identifique as ações exatas responsáveis ​​pelo INP
3. Use ferramentas de laboratório para descobrir por que essas interações são lentas

Dissemos ótimoporque, em alguns casos, seu site pode não ter dados de campo (também conhecidos como dados de monitoramento de usuário real (RUM)). No entanto, isso não significa que você deva desistir de otimizar sua pontuação INP. Você precisa adotar uma abordagem diferente e aproveitar as ferramentas de laboratório disponíveis.

Vamos dar uma olhada em ambos os cenários e explicar como obter a maior parte de seus dados de campo e laboratório.

Dados de campo

Idealmente, você deseja ter dados de campo quando começar a melhorar a capacidade de resposta do seu site. Confiar nos dados RUM economiza muito tempo para descobrir quais interações precisam ser otimizadas.

Além disso, as ferramentas baseadas em laboratório podem simular certas interações, mas não podem replicar completamente as experiências do usuário no mundo real.

Ao coletar dados de campo INP, você deve capturar o seguinte para contextualizar por que as interações foram lentas:

• O valor INP – A distribuição desses valores determinará se a página atende aos limites INP.
• A string do seletor de elemento responsável pelo INP da página – Apenas saber o valor INP de uma página não é suficiente.Você quer saber quais elementos são responsáveis ​​pelas interações.
• O estado de carregamento da página para a interação que é o INP da página – Entender se uma interação ocorre durante o carregamento da página ou depois ajuda a determinar se você deve otimizar o thread principal ou se a própria interação é lenta, independentemente do carregamento inicial da página.
• O startTime da interação – Certifique-se de registrar o startTime da interação, pois permite que você saiba quando a interação ocorreu na linha do tempo de desempenho.
• O tipo de evento – conhecer o tipo de evento de interação – clique em pressionamento de tecla, outros eventos elegíveis – permite identificar qual retorno de chamada de evento na interação levou mais tempo para ser executado.

Se você está se perguntando:

Como devo capturar todas essas coisas?

Não se preocupe. Todos os dados são expostos na biblioteca JavaScript web-vitals. Você pode verificar o guia passo a passo do Google sobre como aproveitar a biblioteca vital da web e até mesmo como transmitir dados INP diretamente para o seu Google Analytics.

Além disso, mesmo que você já esteja coletando dados com um provedor RUM de terceiros, considere compará-los com os dados do Chrome UX Report (CrUX), pois há diferenças nas metodologias que eles usam.

Dados de laboratório

Os dados de campo são a fonte mais confiável para medição. No entanto, como dissemos, nem sempre está disponível.

Mas não há necessidade de se preocupar porque você ainda pode medir e identificar interações para melhorar com a ajuda de dados de laboratório.

Você pode usar o Lighthouse ou o PageSpeed ​​Insights para executar alguns testes de desempenho. A métrica que você deve ficar de olho é o Tempo Total de Bloqueio (TBT).

TBT é uma métrica que avalia a capacidade de resposta da página durante o carregamento e se correlaciona muito bem com o INP. Uma pontuação baixa de TBT é um sinal de que há interações que podem ser lentas durante o carregamento da página.

Veja como você pode reproduzir a interação lenta com ferramentas de laboratório:

• Use a extensão Web Vitals do Chrome

A Web Vitals Chrome Extension é uma das maneiras mais fáceis de medir a latência de interação do seu site. Aqui está o que você precisa fazer para recuperar informações úteis:

1. No Chrome, clique no ícone de extensões à direita da barra de endereço.
2. Localize a extensão Web Vitals no menu suspenso.
3. Clique no ícone à direita para abrir as configurações da extensão.
4. Clique em Opções.
5. Ative a caixa de seleção Log do console na tela resultante e clique em Salvar.

Por fim, abra o console Chrome DevTools e comece a testar. Você receberá logs de console úteis, fornecendo informações de diagnóstico detalhadas para a interação.

• Grave um rastreamento com o Chrome DevTools

Para obter ainda mais informações sobre por que a interação é lenta, você pode usar o criador de perfil de desempenho no Chrome DevTools. Basta fazer o seguinte:

1. Abra o Chrome DevTools e vá para o painel Desempenho.
2. Clique no botão Gravar no canto superior esquerdo do painel para iniciar o rastreamento.
   
   
   
3. Realize a interação desejada.
4. Clique no botão Gravar novamente para interromper o rastreamento.

Para identificar rapidamente os problemas de desempenho, verifique o resumo da atividade na parte superior do criador de perfil quando o perfil for preenchido. Procure barras vermelhas no resumo da atividade, indicando instâncias de tarefas longas durante a gravação. Essas barras vermelhas ajudam você a identificar áreas problemáticas e focar sua investigação.

• Use intervalos de tempo do Farol

O modo de intervalos de tempo do Lighthouse é a alternativa menos intimidadora ao criador de perfil de desempenho do DevTools. Veja como usá-lo:

1. Vá para a guia Lighthouse no DevTools.
2. Na seção denominada Modo, selecione a opção Período de tempo.
3. Selecione o tipo de dispositivo desejado na seção Dispositivo.
4. Certifique-se de que pelo menos a caixa de seleção denominada Desempenho esteja selecionada no rótulo Categorias.
5. Clique no botão Iniciar intervalo de tempo.
   
   
   
6. Teste as interações desejadas na página.
7. Clique no botão End timespan e aguarde a exibição da auditoria
8. Depois que a auditoria for preenchida, filtre-a por INP.

Você será presenteado com uma lista de auditorias reprovadas e aprovadas. Ao clicar neles, um menu suspenso aparecerá e você poderá ver um detalhamento do tempo gasto durante a interação dividido por atraso de entrada, tempo de processamento e atraso de apresentação.

Fonte: Google

Agora que você sabe no que trabalhar, é hora de arregaçar as mangas e começar a otimizar.

Como otimizar o INP

Para garantir ao seu site umaboapontuação de INP, você precisa garantir que cada evento de interação seja executado o mais rápido possível. Veja como alcançá-lo:

Reduza o atraso de entrada

1. Evite cronômetros recorrentes que sobrecarregam o thread principal

setTimeout e setInterval são funções de timer JavaScript comumente usadas que podem contribuir para o atraso de entrada.

setTimeout agenda um retorno de chamada para ser executado após um tempo especificado e, embora possa ajudar a evitar tarefas longas, depende de quando o tempo limite ocorre e se coincide com as interações do usuário.

setInterval , por outro lado, agenda um retorno de chamada para ser executado repetidamente em um intervalo especificado. Por causa disso, é mais provável que interfira nas interações do usuário. Sua natureza recorrente aumenta o atraso de entrada e pode afetar a capacidade de resposta das interações.

Se você tiver controle sobre os cronômetros em seu código, avalie a necessidade deles e reduza a carga de trabalho o máximo possível.

2. Evite tarefas longas

Como você já sabe, tarefas longas bloqueiam a thread principal, impedindo que o navegador execute os eventos de interação.

Para melhorar a capacidade de resposta do seu site, é importante minimizar a carga de trabalho no thread principal e considerar a divisão de tarefas longas.

Ao dividir tarefas longas em partes menores, o thread principal tem a oportunidade de lidar com outras tarefas e responder às interações do usuário mais rapidamente.

Além disso, dividir tarefas longas ajuda a evitar o efeito "jank", em que as animações e transições na página ficam entrecortadas ou gaguejam devido ao thread principal sobrecarregado. Ao garantir que cada tarefa seja concluída em um prazo menor, a página pode manter uma experiência visual mais suave para o usuário.

3. Evite a sobreposição de interações

A sobreposição de interação significa que, após um visitante interagir com um elemento, ele faz outra interação com a página antes que a interação inicial tenha a chance de renderizar o próximo quadro.

Por exemplo, isso pode acontecer quando os usuários estão digitando em campos de formulário, levando a várias interações de teclado em um breve período de tempo. Você pode otimizar o processo por:

• Entradas de debounce para limitar o número de vezes que um retorno de chamada de evento é executado em um determinado período de tempo.
• Usando AbortController para cancelar solicitações de busca de saída para que o thread principal não fique sobrecarregado lidando com retornos de busca.
  

Otimizar callbacks de eventos (tempo de processamento)

1. Considere remover o retorno de chamada desnecessário

O retorno de chamada de evento caro é realmente necessário? Caso contrário, considere remover o código completamente ou, se isso não for possível, adie sua execução até um momento mais adequado.

2. Adie o trabalho de não renderização

Tarefas longas podem ser divididas cedendo ao thread principal. Quando você cede ao thread principal, basicamente pausa a tarefa atual e divide o trabalho restante em uma tarefa separada. Isso permite que o renderizador manipule atualizações na interface do usuário que foram processadas anteriormente no retorno de chamada do evento. Ao ceder, você permite que o renderizador execute alterações pendentes e garanta uma atualização suave e oportuna da interface do usuário.

Minimizar o atraso da apresentação

1. Reduza o tamanho do DOM

Um tamanho grande de DOM é uma maneira infalível de reprovar na avaliação do INP. Portanto, para garantir que isso não aconteça, você precisa reduzir o tamanho do DOM ou, em outras palavras, reduzir a profundidade do DOM.

Procure uma profundidade de DOM de no máximo 1.400 nós.

Você pode alcançá-lo incorporando as seguintes técnicas:

• Evite plugins e temas mal codificados
• Minimize nós DOM baseados em JavaScript
• Afaste-se dos construtores de páginas que geram HTML inchado
• Não copie/cole texto no editor WYSIWYG
• Divida seu site de uma página em várias páginas
• Não esconda elementos indesejados usando display:none
• Evite usar declarações CSS complicadas e JavaScript
  

2. Evite trabalho excessivo ou desnecessário em callbacks requestAnimationFrame

O método requestAnimationFrame informa ao navegador que você deseja executar uma animação e solicita que o navegador chame uma função especificada para atualizar uma animação antes da próxima repintura.

O retorno de chamada requestAnimationFrame() faz parte da fase de renderização no loop de eventos e precisa terminar antes que o próximo quadro possa ser exibido. Se você estiver utilizando requestAnimationFrame() para tarefas não relacionadas a alterações na interface do usuário, é essencial reconhecer que você pode estar causando um atraso na renderização do quadro subsequente.

Portanto, evite usá-los quando desnecessários.

3. Adie retornos de chamada do ResizeObserver

A interface ResizeObserver informa alterações nas dimensões do conteúdo de um elemento ou caixa de borda ou caixa delimitadora de um SVGElement.

Os retornos de chamada do ResizeObserver são executados antes da renderização e podem potencialmente adiar a apresentação do próximo quadro se envolverem tarefas com uso intensivo de recursos. Semelhante aos retornos de chamada de evento, é aconselhável adiar qualquer lógica desnecessária não necessária para o próximo quadro imediato.

Melhore o INP com NitroPack

Com base em todos os testes que realizamos nos últimos meses e em toda a documentação que o Google publicou no INP, podemos dizer que ele se parece muito com o Largest Contentful Paint (LCP).

Um Core Web Vital de várias camadas que possui muitas partes móveis.

Assim, desde que o Google anunciou pela primeira vez as novas métricas de capacidade de resposta, começamos a testar e trabalhar em recursos que melhorarão as pontuações de INP de nossos clientes.

E temos visto alguns resultados promissores:

Com o NitroPack, nossos clientes experimentam uma melhoria média de 36% no INP.

E isso aconteceu tudo no piloto automático. Apenas instalando o NitroPack e graças a recursos de otimização como:

• Reduzir CSS não utilizado
• Adiar o carregamento do JavaScript
• CDN integrado

Você também pode aumentar suas pontuações de INP e Core Web Vitals sem escrever uma única linha de código. Instale o NitroPack gratuitamente e experimente você mesmo as melhorias.

Corrija seus problemas de INP e passe no Core Web Vitals automaticamente. Obtenha o NitroPack agora →