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 puoi misurare. Questa guida illustra i diversi approcci per misurare le prestazioni del CRP.

• L'approccio Lighthouse esegue una serie di test automatici su una pagina, e poi genera un report sul rendimento CRP della pagina. Questo approccio fornisce una panoramica generale e rapida delle prestazioni del CRP di un pagina specifica caricata nel browser, consentendoti di testare rapidamente, eseguire l'iterazione e migliorarne le prestazioni.
• 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 vengono visualizzati come nell'immagine di seguito.

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 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: si tratta del timestamp di inizio dell'intero processo, il browser sta per iniziare ad analizzare i primi byte ricevuti del codice HTML documento.
• domInteractive: segna il punto in cui il browser ha terminato l'analisi di tutti della creazione dell'HTML e del DOM.
• 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 una Evento onload che può attivare logica aggiuntiva dell'applicazione.

La specifica HTML impone condizioni specifiche per ogni 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 alcun parser che blocca JavaScript, DOMContentLoaded si attiverà subito dopo il giorno domInteractive.
• domComplete contrassegna 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' scoraggiante 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.

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