Misurazione del percorso di rendering critico

Ilya Grigorik
Ilya Grigorik

Alla base di ogni solida strategia per il rendimento c'è una buona misurazione e strumentazione. Non puoi ottimizzare ciò che non puoi misurare. Questo documento illustra i diversi approcci per misurare le prestazioni CRP.

  • L'approccio Lighthouse esegue una serie di test automatici su una pagina, quindi genera un report sulle prestazioni CRP della pagina. Questo approccio fornisce una panoramica di alto livello rapida e semplice delle prestazioni CRP di una determinata pagina caricata nel tuo browser, in modo da poter testare, eseguire l'iterazione e migliorare rapidamente le relative prestazioni.
  • L'approccio dell'API Navigation Timing acquisisce le metriche Real User Monitoring (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 CRP reali, come sperimentate dagli utenti su una varietà di dispositivi e condizioni di rete.

In generale, un buon approccio è utilizzare Lighthouse per identificare evidenti opportunità di ottimizzazione del CRP e quindi instrumentare il codice con l'API Navigation Timing per monitorare le prestazioni della tua app sulla natura.

Controllare una pagina con Lighthouse

Lighthouse è uno strumento di controllo delle app web che esegue una serie di test su una determinata pagina e poi ne mostra i risultati in un report consolidato. Puoi eseguire Lighthouse come estensione di Chrome o modulo di Gestione dei partner di rete, utile per integrare Lighthouse con sistemi di integrazione continua.

Per iniziare, consulta Controllo delle app web con Lighthouse.

Quando esegui Lighthouse come estensione di Chrome, i risultati CRP della tua pagina saranno simili a quelli mostrati nello screenshot riportato di seguito.

Controlli CRP di Lighthouse

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

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

Navigation Timing

Ognuna delle etichette nel diagramma riportato sopra corrisponde a un timestamp ad alta risoluzione che il browser monitora per ogni pagina caricata. In questo caso specifico, infatti, mostriamo solo una frazione di tutti i diversi timestamp: per il momento ignoriamo tutti i timestamp relativi alla rete, ma ne parleremo in futuro.

Cosa significano questi timestamp?

  • domLoading: si tratta del timestamp di inizio dell'intero processo e il browser sta per iniziare ad analizzare i primi byte ricevuti del documento HTML.
  • domInteractive: indica il punto in cui il browser ha terminato l'analisi di tutta la creazione del codice HTML e del DOM.
  • domContentLoaded: indica il punto in cui il DOM è pronto e non sono presenti fogli di stile che bloccano l'esecuzione di JavaScript. Ciò significa che ora possiamo (potenzialmente) creare l'albero di rendering.
    • Molti framework JavaScript attendono 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 richiesto dall'esecuzione.
  • domComplete: come suggerisce il nome, l'intera elaborazione è completata e il download di tutte le risorse sulla pagina (immagini e così via) è terminato. In altre parole, la rotellina di caricamento ha smesso di girare.
  • loadEvent: come passaggio finale di ogni caricamento pagina, il browser attiva un evento onload che può attivare logica aggiuntiva dell'applicazione.

La specifica HTML stabilisce le condizioni specifiche per ogni singolo evento: quando deve essere attivato, quali condizioni devono essere soddisfatte e così via. Per il nostro scopo, ci concentreremo su alcune tappe fondamentali relative al percorso di rendering critico:

  • domInteractive segna quando il DOM è pronto.
  • In genere domContentLoaded contrassegna quando sia il DOM che il CSSOM sono pronti.
    • Se non è presente alcun codice JavaScript che blocca l'analizzatore sintattico, DOMContentLoaded si attiverà subito 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 riportato sopra può sembrare un po' scoraggiante a prima vista, ma in realtà è piuttosto semplice. L'API Navigation Timing acquisisce tutti i timestamp pertinenti e il nostro codice attende semplicemente l'attivazione dell'evento onload (ricorda che l'evento onload si attiva dopo domInteractive, domContentLoaded e domComplete) e calcola la differenza tra i vari timestamp.

Demo di NavTiming

Detto e fatto, ora abbiamo alcuni traguardi specifici da monitorare e una semplice funzione per ottenere queste misurazioni. Tieni presente che, anziché stampare queste metriche sulla pagina, puoi anche modificare il codice per inviarle a un server di analisi (Google Analytics esegue questa operazione automaticamente), il che rappresenta un ottimo modo per tenere sotto controllo il rendimento delle pagine e identificare le pagine candidati che possono beneficiare di un'ottimizzazione.

E per quanto riguarda DevTools?

Anche se questi documenti a volte usano il riquadro Network (Rete) di Chrome DevTools per illustrare i concetti di CRP, DevTools non è al momento adatto per le misurazioni CRP perché non dispone di un meccanismo integrato per l'isolamento delle risorse critiche. Esegui un controllo Lighthouse per identificare più facilmente queste risorse.

Feedback