Entenda como a nova métrica INP afeta a experiência de sites criados com bibliotecas e frameworks JavaScript.
Recentemente, o Chrome introduziu uma nova métrica experimental de capacidade de resposta 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 à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 funcionando para otimizar a capacidade de resposta.
Contexto
O Chrome usa a First Input Delay (FID) como parte das Core Web Vitals (CWV, na sigla em inglês) para medir a capacidade de resposta do carregamento dos sites. A FID mede o tempo de espera entre a primeira interação do usuário e 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 para pintar o frame seguinte após a execução dos retornos de chamada do evento. No entanto, a capacidade de resposta é crucial para a experiência do usuário durante 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.
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 é 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 a INP fornecerá uma estimativa mais precisa das a capacidade de resposta do tempo de execução e de carga.
Como a FID mede apenas o atraso de entrada da primeira interação, é provável que os desenvolvedores Web não tenham otimizado proativamente as interações subsequentes como parte do processo de melhoria das Core Web Vitals. Os sites, especialmente aqueles com alto grau de interatividade, precisam começar a se esforçar para ter um bom desempenho nessa métrica.
O papel dos frameworks
Como muitos sites dependem de JavaScript para oferecer interatividade, a pontuação de INP seria afetada principalmente pela quantidade de JavaScript processado 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 nos sites que os utilizam.
Os frameworks podem ter tomado medidas para melhorar a capacidade de resposta, melhorando antecipadamente a FID para sites. No entanto, agora eles teriam que analisar os dados de métricas de capacidade de resposta 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 requer uma otimização adicional do código. A tabela a seguir resume os motivos.
A equipe do Aurora no Chrome trabalha com estruturas 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 Core Web Vitals. Com a introdução do INP, queremos nos preparar para a mudança nas métricas das Core Web Vitals para sites com base em estruturas. Coletamos dados com base na métrica experimental de capacidade de resposta nos relatórios CrUX. Vamos compartilhar insights e ações necessárias para facilitar a transição dos sites baseados em framework para a métrica INP.
Dados de métrica de capacidade de resposta experimentais
Um INP menor ou igual a 200 milissegundos indica uma boa capacidade de resposta. Os dados do relatório CrUX e o Relatório de tecnologia das Core Web Vitals de junho de 2023 fornecem as seguintes informações sobre a capacidade de resposta de frameworks conhecidos do JavaScript.
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 há muito espaço para melhorias.
Como o JavaScript afeta a INP?
Os valores de INP no campo têm boa correlação 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 do JavaScript após qualquer interação pode bloquear a linha de execução principal por um longo período 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 carregamento e divisão de código inadequadas 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 desmembramento 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 manipuladores de eventos: vários manipuladores de eventos associados a cada interação, cada um executando um script diferente, podem interferir uns nos outros e causar atrasos longos. Algumas dessas tarefas podem não ser essenciais e podem ser agendadas em um web worker ou quando o navegador estiver inativo.
Sobrecarga de framework no tratamento de eventos:as estruturas podem ter outros recursos/sintaxe para o tratamento de eventos. Por exemplo, a Vue usa v-on para anexar listeners de eventos a elementos, enquanto o Angular envolve manipuladores de eventos do usuário. A implementação desses recursos requer um código de framework adicional acima do JavaScript básico.
Hidratação: ao usar um framework de JavaScript, não é incomum que um servidor gere o HTML inicial para uma página que, em seguida, precisa ser aumentada 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 pode ser um processo pesado durante o carregamento, dependendo de quanto tempo 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 lentamente (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 quaisquer efeitos colaterais mais caros sejam deixados para frames futuros. Por isso, atualizações em uma transição que produzem atualizações mais urgentes, como cliques, podem ser um padrão que pode ser bom para a INP.Pré-busca:fazer a pré-busca de forma agressiva dos recursos necessários para as navegações seguintes pode resultar em uma boa performance. No entanto, se você fizer a pré-busca e renderizar rotas de SPA de maneira síncrona, poderá ter um impacto negativo no INP, porque toda essa renderização cara tenta ser concluída em um único frame. Compare isso com não pré-buscar a rota e, em vez disso, iniciar o trabalho necessário (por exemplo,
fetch()) e desbloquear a pintura. Recomendamos reexaminar se a abordagem do framework para a pré-busca está oferecendo a UX ideal e como (se for o caso) isso pode afetar a INP.
A partir de agora, para uma boa pontuação INP, os desenvolvedores terão que se concentrar em revisar o código que é executado após cada interação na página e otimizar suas estratégias de divisão, reidratação, carregamento e o tamanho de cada atualização render() para scripts próprios e de terceiros.
Como o Aurora e os frameworks estão abordando os 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 Script Next.js ajuda a resolver problemas causados pelo carregamento ineficiente de scripts de terceiros. A divisão granular foi introduzida no Next.js para permitir blocos menores para o código compartilhado. Isso ajuda a reduzir a quantidade de código comum não utilizado que é baixado em todas as páginas. Também estamos trabalhando com a Next.js para disponibilizar os dados de INP como parte do serviço Analytics.
Angular:o Aurora está fazendo uma parceria com a equipe do Angular para testar melhorias de renderização e hidratação do lado do servidor. Também planejamos procurar refinamentos no tratamento de eventos e detecção de alterações para melhorar o INP.
Vue e Nuxt.js: estamos buscando formas de colaboração, principalmente em relação ao carregamento e à renderização de scripts.
Como as estruturas estão pensando em melhorar a INP?
React e Next.js
O fracionamento 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. 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. Isso também ajuda a manter os apps React responsivos até 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 fração de tempo do React e melhorem a capacidade de resposta das transições de rota.
Angular
A equipe do Angular está explorando várias ideias que também podem ajudar com o INP:
- Sem zona:reduz o tamanho do pacote inicial e exige o código que precisa ser carregado antes da renderização de um app.
- Hidratação:hidratação estilo ilha para limitar a quantidade de hidratação do app que precisa ser ativada para interação.
- Reduzir a sobrecarga da CD:por exemplo, torne a detecção de mudanças mais barata, encontre maneiras de verificar menos informações do app e aproveite os sinais reativos sobre o que mudou.
- Divisão de código mais granular:reduza o pacote inicial.
- Suporte aprimorado para indicadores de carregamento: por exemplo, durante a nova renderização de SSR, durante a navegação pelo trajeto e em operações de carregamento lento.
- Ferramentas de criação de perfil:melhores ferramentas de desenvolvimento para entender o custo de interação, especialmente em relação ao custo de detecção de mudanças para interações específicas.
Com essas melhorias, podemos resolver diferentes problemas que causam baixa capacidade de resposta e experiência do usuário, além de aumentar 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 traga um parâmetro melhor para que os sites melhorem a capacidade de resposta e o desempenho no futuro. Em 2023, vamos continuar usando nosso guia de INP para oferecer mais dicas úteis aos desenvolvedores de framework. Esperamos conseguir isso:
- Criar canais para fácil acesso a dados de campo no INP para frameworks e desenvolvedores Web.
- Trabalhe com estruturas para criar recursos que melhorarão o INP por padrão.
Agradecemos o feedback dos usuários do framework quando eles iniciam a jornada de otimização do INP.