Entenda como a nova métrica INP afeta a experiência dos sites criados com frameworks e bibliotecas JavaScript.
Recentemente, o Chrome apresentou uma nova métrica de responsividade experimental no Relatório de UX do Chrome. Essa métrica, que agora conhecemos como Interaction to Next Paint (INP), mede a capacidade de resposta geral em relação às interações do usuário na página. Hoje, queremos compartilhar insights sobre a posição dos sites criados com frameworks modernos de JavaScript em relação a essa métrica. Queremos discutir por que o INP é relevante para os frameworks e como o Aurora e os frameworks estão trabalhando para otimizar a capacidade de resposta.
Contexto
O Chrome usa o First Input Delay (FID) como parte das Core Web Vitals (CWV) para medir a capacidade de resposta de carregamento de sites. O FID mede o tempo de espera desde a primeira interação do usuário até o momento em que o navegador consegue processar os manipuladores de eventos conectados à interação. Ele não inclui o tempo para processar os gerenciadores de eventos, processar interações subsequentes na mesma página ou pintar o próximo frame após a execução dos callbacks de eventos. No entanto, a capacidade de resposta é crucial para a experiência do usuário ao longo do ciclo de vida da página, porque os usuários passam cerca de 90% do tempo em uma página depois que ela é carregada.
O INP mede o tempo que uma página da Web leva para responder às interações do usuário desde o início da interação até o momento em que o próximo frame é pintado na tela. Com o INP, esperamos ativar uma medida agregada para a latência percebida de todas as interações no ciclo de vida da página. Acreditamos que o INP vai fornecer uma estimativa mais precisa do carregamento e da capacidade de resposta de execução das páginas da Web.
Como o FID mede apenas o atraso de entrada da primeira interação, é provável que os desenvolvedores da Web não tenham otimizado proativamente as interações subsequentes como parte do processo de melhoria do CWV. Portanto, os sites, principalmente aqueles com um alto grau de interatividade, precisam trabalhar muito para ter bons resultados nessa métrica.
O papel dos frameworks
Como muitos sites dependem do JavaScript para oferecer interatividade, a pontuação de INP é afetada principalmente pela quantidade de JavaScript processada na linha de execução principal. Os frameworks JavaScript são uma parte essencial do desenvolvimento moderno da Web para front-end e oferecem aos desenvolvedores abstrações valiosas para roteamento, tratamento de eventos e compartimentalização do código JavaScript. Assim, eles têm um papel central na otimização da capacidade de resposta e da experiência do usuário dos sites que os usam.
Os frameworks podem ter tomado medidas para melhorar a capacidade de resposta melhorando a FID para sites mais cedo. No entanto, agora eles precisam analisar os dados de métrica de responsividade disponíveis e trabalhar para resolver as lacunas identificadas. Em geral, o INP tende a ter taxas de aprovação mais baixas, e a diferença no processo de medição exige uma otimização de código adicional. A tabela a seguir resume o motivo.
A equipe do Aurora no Chrome trabalha com frameworks da Web de código aberto para ajudar os desenvolvedores a melhorar diferentes aspectos da experiência do usuário, incluindo o desempenho e as métricas das CWVs. Com a introdução do INP, queremos estar preparados para a mudança nas métricas de CWV de sites baseados em framework. Coletamos dados com base na métrica de responsividade experimental nos relatórios do CrUX. Vamos compartilhar insights e itens de ação para facilitar a transição para a métrica INP em sites baseados em framework.
Dados da métrica de capacidade de resposta experimental
Um INP inferior ou igual a 200 milissegundos indica boa capacidade de resposta. Os dados do relatório CrUX e o CWV Technology Report (em inglês) de junho de 2023 fornecem as seguintes informações sobre a capacidade de resposta de frameworks JavaScript conhecidos.
A tabela mostra a porcentagem de origens em cada framework com uma boa pontuação de capacidade de resposta. Os números são encorajadores, mas mostram que há muito espaço para melhorias.
Como o JavaScript afeta o INP?
Os valores de INP no campo estão bem correlacionados com o tempo total de bloqueio (TBT, na sigla em inglês) observado no laboratório. Isso pode implicar que qualquer script que bloqueie a linha de execução principal por um longo período seria ruim para a INP. A execução pesada de JavaScript após qualquer interação pode bloquear a linha de execução principal por um período prolongado e atrasar a resposta a essa interação. Algumas das causas comuns que levam ao bloqueio de scripts são:
JavaScript não otimizado:código redundante ou estratégias de divisão e carregamento de código ruins podem causar inchaço do JavaScript e bloquear a linha de execução principal por longos períodos. A divisão do código, o carregamento progressivo e o divisão de tarefas longas podem melhorar consideravelmente os tempos de resposta.
Scripts de terceiros:scripts de terceiros, que às vezes não são necessários para processar uma interação (por exemplo, scripts de anúncios), podem bloquear a linha de execução principal e causar atrasos desnecessários. Priorizar scripts essenciais pode ajudar a reduzir o impacto negativo dos scripts de terceiros.
Vários gerenciadores de eventos:vários gerenciadores de eventos associados a cada interação, cada um executando um script diferente, podem interferir um no outro e causar atrasos longos. Algumas dessas tarefas podem não ser essenciais e podem ser programadas em um worker da Web ou quando o navegador está inativo.
Overhead do framework no processamento de eventos:os frameworks podem ter recursos/sintaxe adicionais para o processamento de eventos. Por exemplo, o Vue usa v-on para anexar listeners de eventos a elementos, enquanto o Angular envolve os manipuladores de eventos do usuário. A implementação desses recursos requer um código de framework adicional acima do JavaScript simples.
Hidratação:ao usar um framework JavaScript, não é incomum que um servidor gere o HTML inicial de uma página, que depois precisa ser aumentado com manipuladores de eventos e estado do aplicativo para que possa ser interativo em um navegador da Web. Chamamos esse processo de hidratação. Esse pode ser um processo pesado durante o carregamento, dependendo do tempo que o JavaScript leva para carregar e para a hidratação terminar. Isso também pode fazer com que as páginas pareçam interativas, quando não são. Muitas vezes, a hidratação ocorre automaticamente durante o carregamento da página ou de forma lenta (por exemplo, na interação do usuário) e pode afetar o INP ou o tempo de processamento devido à programação de tarefas. Em bibliotecas como o React, é possível usar
useTransitionpara que parte da renderização de um componente esteja no próximo frame e os efeitos colaterais mais caros sejam deixados para frames futuros. Portanto, as atualizações em uma transição que resultam em atualizações mais urgentes, como cliques, podem ser um padrão bom para a INP.Pré-busca:a pré-busca agressiva dos recursos necessários para navegações subsequentes pode ser uma vantagem de desempenho quando feita corretamente. No entanto, se você fizer precarregar e renderizar rotas de SPA de forma síncrona, poderá acabar afetando negativamente a INP, já que todas essas tentativas de renderização caras são concluídas em um único frame. Compare isso com não fazer o pré-carregamento da rota e, em vez disso, iniciar o trabalho necessário (por exemplo,
fetch()) e desbloquear a pintura. Recomendamos que você examine novamente se a abordagem do framework para pré-carregamento está oferecendo a melhor experiência do usuário e como isso pode afetar o INP.
A partir de agora, para uma boa pontuação de INP, os desenvolvedores vão precisar se concentrar na revisão do código que é executado após cada interação na página e otimizar o agrupamento, a reidratação, as estratégias de carregamento e o tamanho de cada atualização de renderização() para scripts próprios e de terceiros.
Como o Aurora e os frameworks estão resolvendo problemas de INP?
O Aurora trabalha com frameworks incorporando práticas recomendadas para fornecer soluções integradas para problemas comuns. Trabalhamos com Next.js, Nuxt.js, Gatsby e Angular em soluções que oferecem padrões fortes no framework para otimizar o desempenho. Confira a seguir os destaques do nosso trabalho nesse contexto:
React e Next.js:o componente de script do Next.js ajuda a resolver problemas causados pelo carregamento ineficiente de scripts de terceiros. O chunking granular foi introduzido no Next.js para permitir blocos de tamanho menor para código compartilhado. Isso ajuda a reduzir a quantidade de código comum não utilizado que é transferido por download em todas as páginas. Também estamos trabalhando com o Next.js para disponibilizar os dados do INP como parte do serviço de Analytics.
Angular:o Aurora está fazendo parceria com a equipe do Angular para explorar melhorias na renderização e hidratação do lado do servidor. Também planejamos analisar os refinamentos no processamento de eventos e na detecção de mudanças para melhorar o INP.
Vue e Nuxt.js:estamos explorando possibilidades de colaboração, principalmente em relação ao carregamento e renderização de scripts.
Como os frameworks estão pensando em melhorar o INP?
React e Next.js
O corte de tempo do React.js, implementado com startTransition e Suspense, permite ativar a hidratação seletiva ou progressiva. Isso significa que a hidratação não é um bloco síncrono. Ele é feito em pequenas fatias que podem ser interrompidas a qualquer momento.
Isso deve ajudar a melhorar a INP e permitir que você responda mais rapidamente a pressionamentos de tecla, efeitos de passar o cursor durante a transição e cliques. Ele também ajuda a manter os apps do React responsivos, mesmo para transições grandes, como a autocompletar.
O Next.js implementou um novo framework de roteamento que usa startTransition por padrão para transições de rota. Isso permite que os proprietários de sites do Next.js adotem o corte de tempo do React e melhorem a capacidade de resposta das transições de rota.
Angular
A equipe do Angular está analisando várias ideias que também devem ajudar com a INP:
- Sem zona:reduz o tamanho inicial do pacote e o código necessário que precisa ser carregado antes que um app possa renderizar algo.
- Hidratação:hidratação no estilo ilha para limitar o quanto do app precisa ser ativado para interação.
- Reduzir a sobrecarga de CD:por exemplo, tornar a detecção de mudanças menos cara, encontrar maneiras de verificar menos o app e aproveitar os indicadores reativos sobre o que mudou.
- Divisão de código mais granular:torne o pacote inicial menor.
- Melhor suporte a indicadores de carregamento: por exemplo, durante a renderização de SSR, durante a navegação de rotas e em operações de carregamento lento.
- Ferramentas de criação de perfil:ferramentas de desenvolvimento melhores para entender o custo da interação, principalmente em relação ao custo de detecção de mudanças para interações específicas.
Com essas melhorias, podemos resolver diferentes problemas que levam a uma experiência do usuário e uma capacidade de resposta ruins, além de aumentar as métricas de CWV e a nova métrica de INP para sites baseados em framework.
Conclusão
Esperamos que a pontuação de INP seja uma bússola melhor para que os sites melhorem a capacidade de resposta e o desempenho no futuro. Vamos usar nosso guia de INP atual para oferecer mais dicas práticas para desenvolvedores de frameworks em 2023. Para isso, vamos:
- Criação de canais para acesso fácil aos dados de campo no INP para frameworks e desenvolvedores da Web.
- Use frameworks para criar recursos que melhorem o INP por padrão.
Aceitamos feedback dos usuários do framework no início da jornada de otimização do INP.