Misurazione del percorso di rendering critico

Ilya Grigorik

Data di pubblicazione: 31 marzo 2014

La base di ogni solida strategia di rendimento è una buona misurazione e instrumentation. Non puoi ottimizzare ciò che non misuri. Questa guida illustra diversi approcci per misurare il rendimento delle CRP.

• L'approccio Lighthouse esegue una serie di test automatici su una pagina, quindi genera un report sulle prestazioni del CRP della pagina. Questo approccio fornisce una panoramica di alto livello rapida e di base sul rendimento del CRP di una determinata pagina caricata nel browser, consentendo di testare, eseguire l'iterazione e migliorare rapidamente il rendimento.
• L'approccio dell'API Navigation Timing acquisisce le metriche del monitoraggio dei real user (RUM). Come suggerisce il nome, queste metriche vengono acquisite dalle interazioni reali degli utenti con il tuo sito e forniscono una visione accurata delle prestazioni del CRP nel mondo reale, sperimentate dagli utenti su una varietà di dispositivi e condizioni di rete.

In generale, un buon approccio è utilizzare Lighthouse per identificare opportunità di ottimizzazione CRP evidenti, quindi per instrumentare il codice con l'API Navigation Timing per monitorare il rendimento dell'app in produzione.

Controllare una pagina con Lighthouse

Lighthouse è uno strumento di controllo delle app web che esegue una serie di test su una determinata pagina, quindi visualizza i risultati della pagina in un report consolidato. Puoi eseguire Lighthouse come estensione di Chrome o modulo NPM, il che è utile per integrare Lighthouse con i sistemi di integrazione continua.

Per iniziare, leggi l'articolo Eseguire controlli delle app web con Lighthouse.

Quando esegui Lighthouse come estensione di Chrome, i risultati del CRP della tua pagina sono simili allo screenshot seguente.

Per ulteriori informazioni sui risultati di questo controllo, consulta la sezione Catene di richieste critiche.

Strumentazione del codice con l'API Navigation Timing

La combinazione dell'API Navigation Timing e di altri eventi del browser emessi durante il caricamento della pagina consente di acquisire e registrare il rendimento CRP reale di qualsiasi pagina.

Ognuna delle etichette nel diagramma precedente corrisponde a un timestamp ad alta risoluzione monitorato dal browser per ogni singola pagina caricata. In effetti, in questo caso specifico mostriamo solo una frazione di tutti i diversi timestamp. Per il momento saltiamo tutti i timestamp relativi alla rete, ma torneremo su questo argomento in una lezione futura.

Che cosa significano questi timestamp?

• domLoading: questo è il timestamp iniziale dell'intera procedura, il browser sta per iniziare l'analisi dei primi byte ricevuti del documento HTML.
• domInteractive: indica il punto in cui il browser ha terminato di analizzare tutto il codice HTML e la compilazione del DOM è completata.
• domContentLoaded: indica il punto in cui il DOM è pronto e non ci sono stili che bloccano l'esecuzione di JavaScript, il che significa che ora possiamo (potenzialmente) costruire la struttura di rendering.
  • Molti framework JavaScript aspettano questo evento prima di iniziare a eseguire la propria logica. Per questo motivo, il browser acquisisce i timestamp EventStart e EventEnd per consentirci di monitorare il tempo di esecuzione.
• domComplete: come suggerisce il nome, l'elaborazione è completata e il download di tutte le risorse della pagina (immagini e così via) è terminato. In altre parole, l'indicatore di caricamento ha smesso di girare.
• loadEvent: come ultimo passaggio in ogni caricamento pagina, il browser attiva un evento onload che può attivare una logica dell'applicazione aggiuntiva.

La specifica HTML determina condizioni specifiche per ogni singolo evento: quando deve essere attivato, quali condizioni devono essere soddisfatte e altre considerazioni importanti. Per i nostri scopi, ci concentreremo su alcune tappe fondamentali relative al percorso di rendering critico:

• domInteractive indica quando il DOM è pronto.
• domContentLoaded in genere indica quando sia il DOM che il CSSOM sono pronti.
  • Se non è presente un parser che blocca JavaScript, DOMContentLoaded verrà attivato immediatamente dopo domInteractive.
• domComplete indica quando la pagina e tutte le relative risorse secondarie sono pronte.

<!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>

Prova

L'esempio precedente a prima vista può sembrare un po' scoraggiante, ma in realtà è piuttosto semplice. L'API Navigation Timing acquisisce tutti i timestamp pertinenti e il nostro codice attende l'attivazione dell'evento onload, che si verifica dopo domInteractive, domContentLoaded e domComplete, e calcola la differenza tra i vari timestamp.

Dopo tutto, ora abbiamo alcuni traguardi specifici da monitorare e una funzione di base per visualizzare queste misurazioni. Tieni presente che, invece di stampare queste metriche dalla pagina, puoi anche modificare il codice per inviarle a un server di analisi (Google Analytics lo fa automaticamente), il che è un ottimo modo per tenere sotto controllo il rendimento delle tue pagine e identificare quelle candidati che possono trarre vantaggio da alcune attività di ottimizzazione.

E DevTools?

Sebbene questi documenti a volte utilizzino il riquadro Network di Chrome DevTools per illustrare i concetti di CRP, DevTools non è adatto per le misurazioni CRP perché non ha un meccanismo integrato per isolare le risorse critiche. Esegui un controllo Lighthouse per identificare queste risorse.

Feedback