Encontrar interações lentas no campo

Saiba como encontrar interações lentas nos dados de campo do seu site para que você possa encontrar oportunidades para melhorar a interação com a próxima exibição.

Jeremy Wagner

Os dados de campo são a fonte autorizada quando se trata de como os usuários reais estão interagindo com seu site. Ele identifica problemas que talvez você não encontre apenas nos dados de laboratório. Embora as interações possam ser simuladas em ferramentas baseadas em laboratório, você não conseguirá reproduzir todas as interações no laboratório da mesma forma que os usuários em campo. A coleta de dados de campo para Interaction to Next Paint (INP) é fundamental para entender a responsividade da sua página aos usuários reais. Além disso, ela contém pistas para melhorar ainda mais a experiência desses usuários.

O que você deve coletar no campo e por que

Ao coletar dados INP em campo, capture o seguinte para dar contexto sobre o motivo da lentidão nas interações:

• O valor do INP. Esses são os principais dados que você precisará coletar. A distribuição desses valores vai determinar se a página atende aos limites de INP.
• String do seletor de elementos responsável pelo INP da página. Conhecer o INP de uma página é bom, mas não é suficiente por si só. Sem saber qual foi o elemento responsável por isso, você estará no escuro. Ao registrar strings de seletor de elemento, você saberá exatamente 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. Quando uma página está carregando, é razoável supor que há mais atividades da linha de execução principal ocorrendo que podem resultar em uma maior latência de interação. Durante o carregamento da página, há análise de HTML e de folha de estilo, além de avaliação e execução de JavaScript. Saber se uma interação ocorreu durante ou depois do carregamento da página ajuda você a descobrir se precisa otimizar para uma inicialização mais rápida, para que as interações tenham mais espaço na linha de execução principal para serem executadas rapidamente ou se a interação responsável pelo INP da página é lenta independentemente disso.
• O startTime da interação. Registrar o startTime da interação permite saber exatamente quando ela ocorreu na linha do tempo de desempenho.
• O tipo de evento. É bom saber o tipo de evento, já que ele informa se a interação foi resultado de um click, keypress ou de outro tipo de evento qualificado. Uma interação do usuário pode conter vários callbacks e ajudar você a identificar exatamente qual callback de evento da interação levou mais tempo para ser executado.

Embora tudo isso pareça muito a ser levado em conta, você não precisa reinventar a roda para chegar lá. Felizmente, esses dados estão expostos na biblioteca JavaScript web-vitals, e você vai aprender a coletá-los na próxima seção.

Medir as interações no campo com a biblioteca JavaScript web-vitals

A biblioteca JavaScript web-vitals é uma ótima maneira de encontrar interações lentas no campo, em grande parte, graças à capacidade de fornecer atribuição sobre o que as causa. O INP pode ser coletado em navegadores compatíveis com a API Event Timing e a propriedade interactionId dela.

Compatibilidade com navegadores

• 96
• 96
• x
• x

Origem

Usar um provedor de monitoramento real do usuário (RUM, na sigla em inglês) para receber o INP é o mais conveniente, mas nem sempre é uma opção. Se esse for seu caso, por exemplo, use a biblioteca JavaScript web-vitals para coletar e transmitir dados INP ao Google Analytics para avaliação posterior:

// Be sure to import from the attribution build:
import {onINP} from 'web-vitals/attribution';

function sendToGoogleAnalytics ({name, value, id, attribution}) {
  // Destructure the attribution object:
  const {eventEntry, eventTarget, eventType, loadState} = attribution;

  // Get timings from the event timing entry:
  const {startTime, processingStart, processingEnd, duration, interactionId} = eventEntry;

  const eventParams = {
    // The page's INP value:
    metric_inp_value: value,
    // A unique ID for the page session, which is useful
    // for computing totals when you group by the ID.
    metric_id: id,
    // The event target (a CSS selector string pointing
    // to the element responsible for the interaction):
    metric_inp_event_target: eventTarget,
    // The type of event that triggered the interaction:
    metric_inp_event_type: eventType,
    // Whether the page was loaded when the interaction
    // took place. Useful for identifying startup versus
    // post-load interactions:
    metric_inp_load_state: loadState,
    // The time (in milliseconds) after page load when
    // the interaction took place:
    metric_inp_start_time: startTime,
    // When processing of the event callbacks in the
    // interaction started to run:
    metric_inp_processing_start: processingStart,
    // When processing of the event callbacks in the
    // interaction finished:
    metric_inp_processing_end: processingEnd,
    // The total duration of the interaction. Note: this
    // value is rounded to 8 milliseconds of granularity:
    metric_inp_duration: duration,
    // The interaction ID assigned to the interaction by
    // the Event Timing API. This could be useful in cases
    // where you might want to aggregate related events:
    metric_inp_interaction_id: interactionId
  };

  // Send to Google Analytics
  gtag('event', name, eventParams);
}

// Pass the reporting function to the web-vitals INP reporter:
onINP(sendToGoogleAnalytics);

Importante : quando se trata da atribuição de elementos, nem todas as interações podem ser atribuídas a um elemento específico. Isso ocorre devido a uma limitação da API Event Timing, que é usada para calcular o INP da página. Nesta API, o destino do evento pode estar ausente se o elemento responsável pela interação tiver sido desconectado do DOM ou se o elemento estiver no shadow DOM.

Se você tiver o Google Analytics e executar o código anterior no seu site, vai receber um relatório detalhado não apenas do INP da página, mas também informações contextuais úteis que podem dar uma noção melhor de onde começar a otimizar as interações lentas.

Monitore toda a duração da sessão, não apenas onload

Usar a biblioteca JavaScript web-vitals, conforme mencionado anteriormente, pode fazer com que vários eventos de análise sejam enviados ao Google Analytics. Isso não é um problema, já que o ID que web-vitals gera para a página atual permanece o mesmo, e o Google Analytics permite que você substitua os dados anteriores.

No entanto, nem todos os provedores de RUM operam dessa maneira. Portanto, se você estiver criando sua própria solução de coleta de RUM, precisará levar isso em consideração. Se seu provedor de análise atual não permitir a substituição de registros existentes, será necessário registrar todos os valores delta, ou seja, a diferença entre os estados passado e atual de uma métrica, e transmiti-los usando o mesmo ID fornecido pela biblioteca web-vitals. Em seguida, você poderá somar essas alterações agrupando essas alterações no ID. Para saber mais, consulte a seção sobre como lidar com deltas na documentação do web-vitals.

Acesse dados de campo rapidamente com o CrUX

O Chrome UX Report (CrUX, na sigla em inglês) é o conjunto de dados oficial do programa Web Vitals. Embora os dados do CrUX sozinhos não forneçam todas as informações necessárias para solucionar problemas específicos de INP, primeiro eles informam se você tem algum problema. Mesmo que você já esteja coletando dados de campo por um provedor de RUM, compare-os com os dados CrUX do seu site (se disponíveis), porque existem diferenças nas metodologias que eles usam.

Avalie o INP do seu site e veja os dados do CrUX usando o PageSpeed Insights (PSI). O PageSpeed Insights pode fornecer dados de campo no nível da página para sites incluídos no conjunto de dados CrUX. Para auditar um URL com o PageSpeed Insights, acesse https://pagespeed.web.dev/, insira o URL a ser testado e clique no botão Analisar.

Importante : o URL inserido pode não estar qualificado para o CrUX. Se esse for o caso, você precisará coletar seus próprios dados de campo, o que é explicado na seção anterior. Além disso, quando os dados no nível da página não estiverem disponíveis para o URL especificado no PageSpeed Insights, os dados de campo fornecidos serão agregados em todo o site.

Quando a avaliação começar, os dados do CrUX serão disponibilizados instantaneamente durante a execução do Lighthouse, uma ferramenta de laboratório.

A distribuição de experiências de INP observada no PageSpeed Insights.

Quando o Lighthouse terminar de executar a avaliação, o PSI preencherá a avaliação com as auditorias do Lighthouse.

Importante : como o PageSpeed Insights não tem um script para interagir com a página, não há auditorias relevantes para o INP. No entanto, o Tempo total de bloqueio (TBT, na sigla em inglês) é altamente correlacionado com o INP. Portanto, é possível filtrar auditorias por TBT para encontrar oportunidades de reduzir o tempo que uma página bloqueia a linha de execução principal durante o teste.

Auditorias de tempo total de bloqueio

E se eu não tiver dados de campo?

Você pode estar em uma situação em que não tem ou não pode nem mesmo coletar dados de campo. Se isso descreve sua situação, você vai depender totalmente das ferramentas do laboratório para encontrar interações lentas. Para mais informações sobre testes de laboratório, consulte Como diagnosticar manualmente o que está causando um INP ruim no laboratório (link em inglês).

Conclusão

Os dados de campo são a melhor fonte de informação para entender quais interações são problemáticas para usuários reais no campo. Ao aproveitar as informações disponíveis no PageSpeed Insights ou usar ferramentas de coleta de dados de campo, como a biblioteca JavaScript web-vitals ou seu provedor RUM, você pode ter mais confiança sobre quais interações são mais problemáticas e, em seguida, reproduzir interações problemáticas no laboratório e, em seguida, corrigi-las.

Imagem principal do Unsplash, por Federico Respini.