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 sul rendimento 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 degli utenti reali con il tuo sito e forniscono una visione accurata del rendimento reale del CRP, così come sperimentato dagli utenti su una serie 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.

Controllo di una pagina con Lighthouse

Lighthouse è uno strumento di controllo delle app web che esegue una serie di test su una determinata pagina e poi mostra 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.

Instrumentazione 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 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 passaggio finale di ogni caricamento di pagina, il browser attiva un evento onload che può attivare una logica di applicazione aggiuntiva.

La specifica HTML definisce condizioni specifiche per ogni evento: quando deve essere attivato, quali condizioni devono essere soddisfatte e altre considerazioni importanti. Ai fini del nostro articolo, ci concentreremo su alcuni traguardi chiave relativi 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 potrebbe sembrare un po' complicato a prima vista, ma in realtà è abbastanza 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.onload

Dopo tutto, ora abbiamo alcuni traguardi specifici da monitorare e una funzione di base per visualizzare queste misurazioni. Tieni presente che, anziché stampare queste metriche nella pagina, puoi anche modificare il codice per inviarle a un server di analisi (Google Analytics esegue questa operazione automaticamente). Si tratta di un ottimo modo per monitorare il rendimento delle tue pagine e identificare le pagine candidate che possono trarre vantaggio da alcuni interventi di ottimizzazione.

E DevTools?

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

Feedback