Medição do caminho crítico de renderização

Ilya Grigorik

Toda estratégia de performance sólida precisa de uma boa medição e uma boa instrumentação. Não é possível otimizar o que não pode ser medido. Este documento explica as diferentes abordagens para medir o desempenho do CRP.

• A abordagem do Lighthouse executa uma série de testes automatizados na página e, em seguida, gera um relatório sobre o desempenho do CRP. Essa abordagem oferece uma visão geral rápida e fácil do desempenho do CRP de uma página específica carregada no navegador, permitindo testar, iterar e melhorar o desempenho rapidamente.
• A abordagem da API Navigation Timing captura métricas de monitoramento real do usuário (RUM, na sigla em inglês). Como o nome indica, essas métricas são capturadas a partir de interações reais do usuário com seu site e fornecem uma visão precisa do desempenho real do CRP, conforme a experiência dos usuários em diversos dispositivos e condições de rede.

Em geral, uma boa abordagem é usar o Lighthouse para identificar oportunidades óbvias de otimização do CRP e, em seguida, instrumentar seu código com a API Navigation Timing para monitorar o desempenho do app no geral.

Como auditar uma página com o Lighthouse

O Lighthouse é uma ferramenta de auditoria de apps da Web que executa uma série de testes em uma determinada página e exibe os resultados em um relatório consolidado. Você pode executar o Lighthouse como uma extensão do Chrome ou um módulo do NPM, o que é útil para integrar o Lighthouse a sistemas de integração contínua.

Acesse Como auditar apps da Web com o Lighthouse para começar.

Quando você executa o Lighthouse como uma extensão do Chrome, os resultados do CRP da sua página se parecem com a captura de tela abaixo.

Consulte Cadeias de solicitação críticas para mais informações sobre os resultados dessa auditoria.

Como instrumentar seu código com a API Navigation Timing

A combinação da API Navigation Timing e de outros eventos do navegador emitidos durante o carregamento da página permite capturar e registrar o desempenho do CRP real de qualquer página.

Cada um dos rótulos no diagrama acima corresponde a um carimbo de data/hora em alta resolução que o navegador rastreia para cada página carregada. Na verdade, neste caso específico, mostramos apenas uma fração de todos os carimbos de data/hora diferentes. Por enquanto, estamos pulando todos os carimbos de data/hora relacionados à rede, mas voltaremos a eles em uma lição futura.

O que essas marcações de tempo significam?

• domLoading: o carimbo de data/hora inicial de todo o processo. O navegador está prestes a começar a analisar os primeiros bytes recebidos do documento HTML.
• domInteractive: marca o ponto em que o navegador terminou de analisar toda a construção do HTML e DOM.
• domContentLoaded: marca o ponto em que o DOM está pronto e não há folhas de estilo bloqueando a execução do JavaScript, o que significa que agora podemos (possivelmente) construir a árvore de renderização.
  • Muitos frameworks JavaScript aguardam esse evento antes de começarem a executar a própria lógica. Por esse motivo, o navegador captura os carimbos de data/hora EventStart e EventEnd para acompanhar a duração dessa execução.
• domComplete: como o nome indica, todo o processamento foi concluído e o download de todos os recursos da página (imagens etc.) foi concluído. Em outras palavras, o ícone de carregamento parou de girar.
• loadEvent: como etapa final em cada carregamento de página, o navegador dispara um evento onload, que pode acionar uma lógica adicional do aplicativo.

A especificação HTML determina condições específicas para cada evento: quando ele deve ser disparado, quais condições devem ser atendidas e assim por diante. Para nossos propósitos, vamos nos concentrar em alguns marcos importantes relacionados ao caminho crítico de renderização:

• domInteractive marca quando o DOM está pronto.
• domContentLoaded normalmente marca quando o DOM e o CSSOM estão prontos (link em inglês).
  • Se nenhum analisador estiver bloqueando o JavaScript, a DOMContentLoaded será disparada imediatamente após domInteractive.
• domComplete marca quando a página e todos os sub-recursos dela estão prontos.

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent =
          'interactive: ' +
          interactive +
          'ms, ' +
          'dcl: ' +
          dcl +
          'ms, complete: ' +
          complete +
          'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Faça um teste

O exemplo acima pode parecer um pouco assustador à primeira vista, mas na verdade é muito simples. A API Navigation Timing captura todos os carimbos de data/hora relevantes, e nosso código simplesmente aguarda o disparo do evento onload (lembre-se de que o evento onload é disparado após domInteractive, domContentLoaded e domComplete) e calcula a diferença entre os vários carimbos de data/hora.

Dito isso, agora temos alguns marcos específicos para acompanhar e uma função simples para produzir essas medições. Em vez de exibir essas métricas na página, você também pode modificar o código para enviá-las a um servidor de análise (o Google Analytics faz isso automaticamente). Essa é uma ótima maneira de acompanhar o desempenho das suas páginas e identificar aquelas que podem se beneficiar de algum trabalho de otimização.

E o DevTools?

Embora esses documentos às vezes usem o painel Network do Chrome DevTools para ilustrar conceitos do CRP, o DevTools atualmente não é adequado para medições de CRP porque não tem um mecanismo integrado para isolar recursos críticos. Execute uma auditoria do Lighthouse para identificar esses recursos.

Feedback