Depurar o desempenho no campo

Saiba como atribuir seus dados de desempenho com informações de depuração para ajudar você a identificar e corrigir problemas reais dos usuários com o Analytics.

Philip Walton

O Google oferece duas categorias de ferramentas para medir e depurar a performance:

• Ferramentas do laboratório:ferramentas como o Lighthouse, onde a página é carregada em um ambiente simulado que imita várias condições (por exemplo, um ambiente e um dispositivo móvel de última geração).
• Ferramentas de campo:ferramentas como a Experiência do usuário do Chrome Relatório (CrUX), que é baseado em dados agregados de usuários reais do Chrome. (Observe que o dados de campo reportados por ferramentas como PageSpeed Insights e Pesquisa do console é proveniente de dados CrUX.)

Embora as ferramentas de campo ofereçam dados mais precisos, dados que na verdade representam experiência real dos usuários: as ferramentas de laboratório geralmente são melhores para ajudar a identificar e corrigir problemas.

Os dados CrUX representam melhor o desempenho real da página, mas saber é improvável que as pontuações CrUX ajudem você a descobrir como melhorar desempenho.

O Lighthouse, por outro lado, vai identificar problemas e fazer sugestões de melhorias. No entanto, o Lighthouse só fará sugestões para problemas de desempenho que descobre no tempo de carregamento da página. Ele não detecta problemas que só se manifestam como resultado da interação do usuário, como rolagem ou clique na página.

Isso levanta uma questão importante: como é possível capturar informações de depuração para Core Web Vitals ou outras métricas de desempenho de usuários reais em campo?

Esta postagem explicará em detalhes quais APIs você pode usar para coletar informações de depuração de cada uma das Core Web Vitals atuais ideias de como capturar esses dados na sua ferramenta de análise atual.

APIs para atribuição e depuração

Cumulative Layout Shift (CLS)

De todas as Core Web Vitals, é provável que a CLS seja a que coletar informações de depuração no campo é o mais importante. A CLS é medida durante toda a vida útil da página, de modo que a forma como o usuário interage com o até onde eles rolam, no que clicam, e assim por diante, pode ter um impacto significativo impactar se há trocas de layout e quais elementos estão mudando.

Considere o seguinte relatório do PageSpeed Insights:

O PageSpeed Insights mostra dados de campo e de laboratório quando disponíveis, que podem ser diferentes

O valor relatado para a CLS do laboratório (Lighthouse) comparado ao CLS do campo (dados CrUX) são bem diferentes, e isso faz sentido se você considerar que a página pode ter muito conteúdo interativo não está sendo usado quando testado no Lighthouse.

Mas mesmo que você entenda que a interação do usuário afeta os dados de campo, você ainda Precisa saber quais elementos da página estão mudando para resultar em uma pontuação de 0,28 no 75o percentil. A classe LayoutShiftAttribution interface possibilita isso.

Receber atribuição de troca de layout

A classe LayoutShiftAttribution é exposta em cada entrada layout-shift que Instability do layout API é emitida.

Para uma explicação detalhada sobre as duas interfaces, consulte Depurar layout muda. Para os fins a principal coisa que você precisa saber é que, como desenvolvedor, você pode observar cada mudança de layout que acontece na página, bem como quais elementos estão mudando.

Aqui está um exemplo de código que registra cada mudança de layout, bem como os elementos que mudou:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

Provavelmente não é prático medir e enviar dados para sua ferramenta de análise cada mudança de layout que ocorrer, No entanto, ao monitorar todos os turnos, pode acompanhar as piores mudanças e informar informações sobre elas.

O objetivo não é identificar e corrigir cada mudança de layout que ocorre para cada usuário; a meta é identificar as mudanças que afetam o maior número usuários e assim contribuem mais para a CLS da sua página no 75o percentil.

Além disso, você não precisa computar o maior elemento de origem sempre que houver um Shift, você só precisa fazer isso quando estiver pronto para enviar o valor de CLS para sua ferramenta de análise de dados.

O código a seguir usa uma lista de entradas layout-shift que contribuíram para isso. para a CLS e retorna o maior elemento de origem a partir da maior variação:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

Depois de identificar o maior elemento que contribui para a maior mudança, você pode informar isso para sua ferramenta de análise.

O elemento que mais contribui para a CLS para uma determinada página provavelmente será diferente de usuário a usuário, mas se agregar esses elementos em todos os usuários, conseguir gerar uma lista de elementos em constante mudança que afetam a maioria dos usuários.

Depois de identificar e corrigir a causa raiz das mudanças seu código de análise começará a registrar mudanças menores como as "pior" mudanças nas páginas. Eventualmente, todas as mudanças relatadas serão pequenas o suficiente que suas páginas estejam bem entre as seções limite de 0,1!

Alguns outros metadados que podem ser úteis para capturar junto com a maior mudança elemento de origem é:

• O horário da maior variação
• O caminho do URL no momento da maior mudança (para sites que fazem mudanças atualizar o URL, como aplicativos de página única).

Maior exibição de conteúdo (LCP)

Para depurar a LCP no campo, a principal informação necessária é qual era o maior elemento (o elemento candidato à LCP) para aquele determinado carregamento da página.

É possível (na verdade, é bastante comum) que a LCP elemento candidato será diferente de usuário para usuário, mesmo para exatamente o mesmo página.

Esse problema pode ocorrer por vários motivos:

• Os dispositivos dos usuários têm resoluções de tela diferentes, o que resulta layouts de página e, assim, diferentes elementos visíveis na janela de visualização.
• Os usuários nem sempre carregam páginas roladas até o topo. Muitas vezes, os links contêm identificadores de fragmentos ou até mesmo fragmentos de texto, o que significa que é possível para que suas páginas sejam carregadas e exibidas em qualquer posição de rolagem da página.
• O conteúdo pode ser personalizado para o usuário atual, de modo que o elemento candidato à LCP pode variar muito de usuário para usuário.

Isso significa que você não pode fazer suposições sobre qual elemento ou conjunto de elementos será o elemento candidato à LCP mais comum para uma página específica. Você precisa com base no comportamento real do usuário.

Observação : para mais detalhes sobre essas diferenças, consulte Por que os dados de laboratório e de campo podem ser diferentes (e o que fazer a respeito)

Identifique o elemento candidato à LCP

Para determinar o elemento candidato à LCP em JavaScript, use a coluna Maior API Contentful Paint, a a mesma API que você usa para determinar o valor de tempo da LCP.

Ao observar entradas largest-contentful-paint, é possível determinar elemento atual do candidato à LCP analisando a propriedade element da última entrada:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

Atenção : conforme explicado na documentação da métrica de LCP, o elemento candidato à LCP pode mudar durante o carregamento de página. Por isso, é necessário mais trabalho para identificar a versão "final" Elemento candidato à LCP. A maneira mais fácil de identificar e medir o resultado O elemento candidato à LCP é usar a biblioteca JavaScript web-vitals, conforme mostrado no exemplo.

Depois de conhecer o elemento do candidato à LCP, envie-o para sua ferramenta de análise junto do valor da métrica. Assim como na CLS, isso ajudará você a identificar é mais importante otimizar primeiro.

Além do elemento candidato à LCP, também pode ser útil medir o Subpartes horárias da LCP, que podem ser úteis. para determinar quais etapas de otimização específicas são relevantes para seu site.

Interação com a Next Paint (INP)

Dica : consulte o artigo Encontrar interações lentas no campo para mais informações sobre como depurar o INP com dados de campo.

As informações mais importantes a serem capturadas no campo para a INP são:

1. Com qual elemento houve uma interação
2. Por que o tipo de interação
3. Quando essa interação ocorreu

Uma das principais causas de interações lentas é uma linha de execução principal bloqueada, que pode comuns durante o carregamento do JavaScript. Saber se a maioria das interações lentas durante o carregamento da página é útil para determinar o que precisa ser feito para corrigir o problema.

A métrica INP considera a latência total interação, incluindo o tempo necessário para executar quaisquer listeners de eventos registrados como bem como o tempo que leva para pintar o próximo frame depois de todos os listeners de eventos antes que elas sejam executadas. Isso significa que, para a INP, é muito útil saber qual meta da nuvem tendem a resultar em interações lentas e que tipos de interações que existem.

O código a seguir registra o elemento de destino e a hora da entrada INP.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

Esse código não mostra como determinar qual entrada event é a INP entrada, já que essa lógica é mais envolvida. No entanto, a seção a seguir explica como conseguir essas informações usando o web-vitals.

Uso com a biblioteca JavaScript web-vitals

As seções anteriores oferecem algumas sugestões gerais e exemplos de código para capturar informações de depuração a serem incluídas nos dados enviados à sua ferramenta de análise.

A partir da versão 3, o web-vitals A biblioteca JavaScript inclui uma atribuição build mostra todas essas informações e mais algumas .

O exemplo de código a seguir mostra como você pode definir um evento adicional parâmetro (ou um parâmetro personalizado ) que tenham uma string de depuração útil para ajudar a identificar a causa raiz do desempenho problemas.

import {onCLS, onINP, onLCP} from 'web-vitals/attribution';

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Esse código é específico para o Google Analytics, mas a ideia geral deve ser traduzida a outras ferramentas de análise.

Esse código também mostra como relatar um único sinal de depuração, mas é útil coletar e gerar relatórios sobre vários indicadores diferentes por métrica.

Por exemplo, para depurar o INP, convém coletar o elemento que está sendo com que interagiu, o tipo de interação, o horário, o loadState, o tipo de interação fases e mais, como dados de frames de animação longos.

O build de atribuição web-vitals expõe outras informações de atribuição, como mostrado no exemplo a seguir para INP:

import {onCLS, onINP, onLCP} from 'web-vitals/attribution';

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

Consulte a atribuição web-vitals documentação para os lista completa de sinais de depuração expostos.

Gerar relatórios e visualizar os dados

Depois de começar a coletar informações de depuração com os valores de métrica, a próxima etapa é agregar os dados de todos os usuários para começar a procurar padrões e tendências.

Como mencionado anteriormente, você não precisa resolver todos os problemas pelos usuários, você deve resolver, principalmente no início, os problemas que afetam o maior número de usuários, e esses também são os problemas que têm o maior impacto negativo nas suas pontuações nas Core Web Vitals.

Para o GA4, consulte o artigo dedicado sobre como consultar e visualizar os dados usando no BigQuery.

Resumo

Espero que esta postagem tenha ajudado a definir as maneiras específicas de usar o as APIs de desempenho já existentes e a biblioteca web-vitals para receber informações de depuração para ajudar a diagnosticar o desempenho com base nas visitas de usuários reais em campo. Embora isso é focado nas Core Web Vitals, os conceitos também se aplicam à depuração qualquer métrica de desempenho mensurável em JavaScript.

Se você está começando a avaliar o desempenho e já é um usuário do Google Analytics, a ferramenta Relatório de Métricas da Web pode ser um bom ponto de partida. porque ele já é compatível com informações de depuração de relatórios Métricas vitais.

Se você é um fornecedor de análise e quer melhorar seus produtos fornecer mais informações de depuração aos usuários, considere algumas técnicas descritas aqui, mas não se limite apenas às ideias apresentadas aqui. Esta postagem deve ser usada de modo geral a todas as ferramentas de análise de dados. No entanto, as ferramentas de análise individuais provavelmente podem (e devem) capturar e relatar ainda mais informações de depuração.

Por fim, se você achar que há lacunas na sua capacidade de depurar essas métricas devido a recursos ou informações ausentes nas próprias APIs. Envie seu feedback para [e-mail].