Entenda como a nova métrica INP afeta a experiência de sites criados com estruturas e bibliotecas JavaScript.
O Chrome lançou recentemente uma nova métrica experimental de capacidade de resposta no relatório Chrome UX Report. Essa métrica, que agora conhecemos como Interação com a próxima exibição (INP, na sigla em inglês), mede a capacidade de resposta geral à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. Vamos mostrar 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 a latência na primeira entrada (FID, na sigla em inglês) como parte das Core Web Vitals (CWV) para medir a capacidade de resposta do carregamento dos sites. A 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 manipuladores 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 em todo o ciclo de vida da página, porque os usuários passam cerca de 90% do tempo em uma página após o carregamento.
A 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 é exibido 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 das páginas da Web em tempo de execução.
Como a 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 das CWV. Por isso, os sites, especialmente aqueles com alto grau de interatividade, precisam trabalhar bastante para aproveitar bem essa métrica.
O papel das estruturas
Como muitos sites dependem do JavaScript para oferecer interatividade, a pontuação INP seria afetada principalmente pela quantidade de JavaScript processada na linha de execução principal. Frameworks JavaScript são uma parte essencial do desenvolvimento moderno de front-end da Web e fornecem aos desenvolvedores abstrações valiosas para roteamento, manipulação 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 utilizam.
As estruturas podem ter tomado medidas para melhorar a capacidade de resposta ao melhorar a FID nos sites mais cedo. No entanto, eles teriam que analisar os dados da métrica de capacidade de resposta disponíveis e trabalhar para abordar 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 requer maior otimização do código. 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 métricas de desempenho e CWV. Com a introdução do INP, queremos estar preparados para a mudança nas métricas das Core Web Vitals para sites baseados em framework. Coletamos dados com base na métrica de capacidade de resposta experimental nos relatórios CrUX. Vamos compartilhar insights e ações necessárias 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 Relatório de tecnologia do CWV de junho de 2023 dão 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 nos dizem que ainda há espaço para melhorias.
Como o JavaScript afeta o INP?
Os valores de INP no campo se correlacionam bem 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 muito tempo seria ruim para o INP. A execução pesada do 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ódigos redundantes ou estratégias inadequadas de divisão e carregamento de código podem causar sobrecarga do JavaScript e bloquear a linha de execução principal por longos períodos. A divisão de código, o carregamento progressivo e a separação de tarefas longas podem melhorar consideravelmente os tempos de resposta.
Scripts de terceiros:eles, 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 de scripts de terceiros.
Vários manipuladores de eventos: diversos manipuladores de eventos associados a cada interação, cada um executando um script diferente, podem interferir uns nos outros e resultar em longos atrasos. Algumas dessas tarefas podem não ser essenciais e podem ser programadas em um web worker ou quando o navegador está inativo.
Sobrecarga de framework no processamento de eventos: as estruturas podem ter recursos/sintaxes adicionais para gerenciamento de eventos. Por exemplo, o Vue usa v-on para anexar listeners de eventos a elementos, enquanto o Angular envolve manipuladores de eventos de usuário. A implementação desses recursos requer código adicional de estrutura acima do JavaScript básico.
Hidratação:ao usar um framework de JavaScript, é comum que um servidor gere o HTML inicial de uma página, que precisa ser aumentado com manipuladores de eventos e o estado do aplicativo para que possa ser interativo em um navegador da Web. Chamamos esse processo de hidratação. Esse processo pode ser pesado durante o carregamento, dependendo do tempo que o JavaScript leva para carregar e da hidratação terminar. Isso também pode fazer com que as páginas pareçam interativas quando não são. Geralmente, a hidratação ocorre de forma automática durante o carregamento da página ou lentamente (por exemplo, na interação do usuário) e pode afetar o INP ou o tempo de processamento devido ao agendamento de tarefas. Em bibliotecas como o React, você pode usar
useTransitionpara que parte da renderização de um componente esteja no próximo frame e quaisquer efeitos colaterais mais caros sejam deixados para frames futuros. Por isso, as atualizações em uma transição que produzem atualizações mais urgentes, como cliques, podem ser um padrão bom para o INP.Pré-busca:fazer a pré-busca agressiva dos recursos necessários para navegações subsequentes pode resultar em uma melhora de desempenho quando feita corretamente. No entanto, se você fizer a pré-busca e renderizar rotas de SPA de maneira síncrona, poderá afetar negativamente o INP, já que toda essa renderização cara tenta ser concluída em um único frame. Compare isso a não pré-buscar a rota, em vez de iniciar o trabalho necessário (por exemplo,
fetch()) e desbloquear a pintura. Recomendamos reexaminar se a abordagem de pré-busca do seu framework oferece a UX ideal e como isso pode afetar o INP.
A partir de agora, para conseguir uma boa pontuação de INP, os desenvolvedores terão que se concentrar em revisar o código executado após cada interação na página e otimizar a divisão, a reidratação, as estratégias de carregamento e o tamanho de cada atualização render() para scripts próprios e de terceiros.
Como o Aurora e o Frameworks estão lidando com problemas de INP?
O Aurora trabalha com frameworks incorporando práticas recomendadas para fornecer soluções predefinidas 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. Veja a seguir os destaques do nosso trabalho nesse contexto:
React e Next.js:o componente Script Next.js ajuda a resolver problemas causados devido ao carregamento ineficiente de scripts de terceiros. O agrupamento granular foi introduzido no Next.js para permitir blocos menores para o código compartilhado. Isso ajuda a reduzir a quantidade de códigos comuns não utilizados transferidos por download em todas as páginas. Também estamos trabalhando com o Next.js para disponibilizar os dados INP como parte do serviço Analytics da empresa.
Angular:a Aurora está em parceria com a equipe do Angular para analisar as melhorias na renderização e na hidratação do lado do servidor. Também planejamos melhorar o gerenciamento de eventos e a detecção de mudanças para melhorar o INP.
Vue e Nuxt.js:estamos analisando formas de colaboração, principalmente em relação ao carregamento e à renderização de scripts.
Como as estruturas estão pensando em melhorar o INP?
React e Next.js
O fração de tempo do React.js, implementado usando startTransition e Suspense, permite ativar a hidratação seletiva ou progressiva. Isso significa que a hidratação não é um bloco síncrono. Isso é feito em pequenas frações que podem ser interrompidas a qualquer momento.
Isso deve ajudar a melhorar o 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 React responsivos mesmo para transições grandes, como o preenchimento automático.
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 a redução 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 podem ajudar com o INP:
- Sem zona:reduz o tamanho inicial do pacote e o código obrigatório que precisa ser carregado antes que um app possa renderizar algo.
- Hidração:hidratação no estilo ilha para limitar quanto do app precisa ser ativado para interação.
- Reduzir a sobrecarga da CD: por exemplo, torne a detecção de mudanças mais barata, encontre maneiras de verificar menos o app e aproveite os sinais reativos sobre o que mudou.
- Divisão de código mais granular:reduza o pacote inicial.
- Suporte aprimorado a indicadores de carregamento: por exemplo, durante a nova renderização da SSR, durante a navegação da rota e em operações de carregamento lento.
- Ferramentas de criação de perfil:melhores ferramentas para desenvolvedores para entender o custo de interação, principalmente o custo de detecção de mudanças para interações específicas.
Com essas melhorias, podemos resolver vários problemas que prejudicam a capacidade de resposta e a experiência do usuário, além de impulsionar as métricas das Core Web Vitals e a nova métrica de INP para sites baseados em framework.
Conclusão
Esperamos que a pontuação INP forneça uma bússola melhor para que os sites melhorem a capacidade de resposta e o desempenho no futuro. Em 2023, vamos usar nosso guia do INP atual para oferecer mais dicas práticas para desenvolvedores de frameworks. Esperamos conseguir isso da seguinte forma:
- Criar canais para facilitar o acesso a dados de campo sobre INP para estruturas e desenvolvedores da Web.
- Trabalhe com frameworks para criar recursos que vão melhorar a INP por padrão.
Queremos receber o feedback dos usuários do framework na jornada de otimização de INP.