Il tempo al primo byte (TTFB) è una metrica fondamentale per misurare il tempo di configurazione della connessione e la reattività del server Web sia in laboratorio che sul campo. Aiuta a identificare quando un server Web è troppo lento per rispondere alle richieste. Nel caso delle richieste di navigazione, ovvero richieste di un documento HTML, precede ogni altra metrica significativa delle prestazioni di caricamento.

Cos’è TTFB?

TTFB è una metrica che misura il tempo che intercorre tra la richiesta di una risorsa e quando inizia ad arrivare il primo byte di una risposta.

TTFB è la somma delle seguenti fasi di richiesta:

• Tempo di reindirizzamento
• Tempo di avvio dell’operatore di servizio (se applicabile)
• Ricerca DNS
• Connessione e negoziazione TLS
• Richiesta, fino al punto in cui è arrivato il primo byte della risposta

La riduzione della latenza nel tempo di configurazione della connessione e sul back-end contribuirà a ridurre il TTFB.

Qual è un buon punteggio TTFB? 

Poiché TTFB precede metriche incentrate sull’utente come First Contentful Paint (FCP) e Largest Contentful Paint (LCP) , è consigliabile che il server risponda alle richieste di navigazione abbastanza rapidamente in modo che il 75° percentile degli utenti sperimenti un FCP entro la soglia “buona” . Come guida approssimativa, la maggior parte dei siti dovrebbe cercare di avere un tempo per il primo byte di 0,8 secondi o meno.

Come misurare TTFB 

Il TTFB può essere misurato in laboratorio o sul campo nei seguenti modi.

Strumenti sul campo 

• Rapporto sull’esperienza utente di Chrome
• web-vitalsLibreria JavaScript

Strumenti di laboratorio 

• Nel pannello di rete di DevTools di Chrome
• Pagina WebTest

Misura TTFB in JavaScript 

Puoi misurare il TTFB delle richieste di navigazione nel browser con l’ API Navigation Timing . L’esempio seguente mostra come creare un PerformanceObservermessaggio che ascolti una navigationvoce e la registri sulla console:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

La web-vitalslibreria JavaScript può anche misurare TTFB nel browser con meno complessità:

import {getTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
getTTFB(console.log);

Misurare le richieste di risorse 

TTFB si applica a tutte le richieste, non solo alle richieste di navigazione. In particolare, le risorse ospitate su server multiorigine possono introdurre latenza a causa della necessità di impostare connessioni a tali server. Per misurare il TTFB per le risorse sul campo, utilizza l’ API Resource Timing all’interno di PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

Il frammento di codice sopra è simile a quello utilizzato per misurare il TTFB per una richiesta di navigazione, tranne per il fatto che invece di eseguire query per 'navigation'le voci, esegui invece una query per le 'resource'voci. Tiene inoltre conto del fatto che alcune risorse caricate dall’origine primaria possono restituire un valore di 0, poiché la connessione è già aperta o una risorsa viene recuperata istantaneamente da una cache.

Come migliorare TTFB 

Il miglioramento di TTFB dipende in gran parte dal tuo provider di hosting e dallo stack di applicazioni back-end. Valori TTFB elevati potrebbero essere dovuti a uno o più dei seguenti problemi:

• Servizi di hosting con infrastruttura inadeguata per gestire carichi di traffico elevati
• Server Web con memoria insufficiente che può causare thrashing
• Tabelle di database non ottimizzate
• Configurazione del server di database non ottimale

La riduzione al minimo di TTFB viene spesso eseguita scegliendo un provider di hosting adatto con un’infrastruttura per garantire tempi di attività e reattività elevati. Questo, in combinazione con un CDN, può aiutare.

Altre opportunità per migliorare i tempi TTFB elevati e i relativi ritardi percettivi includono:

• Evita reindirizzamenti di più pagine .
• Preconnettersi alle origini richieste per le risorse tra origini diverse.
• Invia la tua origine all’elenco di precaricamento HSTS per eliminare la latenza di reindirizzamento da HTTP a HTTPS.
• Usa HTTP/2 o HTTP/3 .
• Prendi in considerazione il prelettura predittiva per la navigazione veloce delle pagine per gli utenti che non hanno specificato una preferenza per l’utilizzo ridotto dei dati .
• Utilizzare la generazione lato server (SSG) per il markup anziché SSR ove possibile e appropriato.

Largest Contentful Paint (LCP) è una metrica importante e incentrata sull’utente per misurare la velocità di caricamento percepita perché segna il punto nella sequenza temporale di caricamento della pagina in cui è probabile che il contenuto principale della pagina sia stato caricato:

Un LCP veloce aiuta a rassicurare l’utente sull’utilità della pagina.

Storicamente, è stata una sfida per gli sviluppatori Web misurare la velocità con cui il contenuto principale di una pagina Web viene caricato ed è visibile agli utenti.

Le metriche precedenti come load o DOMContentLoaded non sono buone perché non corrispondono necessariamente a ciò che l’utente vede sul proprio schermo. E le metriche delle prestazioni più recenti e incentrate sull’utente come First Contentful Paint (FCP) catturano solo l’inizio dell’esperienza di caricamento. Se una pagina mostra una schermata iniziale o mostra un indicatore di caricamento, questo momento non è molto rilevante per l’utente.

In passato abbiamo consigliato metriche delle prestazioni come First Meaningful Paint (FMP) e Speed ​​Index (SI) (entrambi disponibili in Lighthouse) per aiutare a catturare più esperienza di caricamento dopo la pittura iniziale, ma queste metriche sono complesse e difficili da spiegare e spesso sbagliati, nel senso che non si identificano ancora quando il contenuto principale della pagina è stato caricato.

A volte più semplice è meglio. Sulla base delle discussioni del W3C Web Performance Working Group e della ricerca condotta presso Google, abbiamo scoperto che un modo più accurato per misurare quando viene caricato il contenuto principale di una pagina è guardare quando è stato visualizzato l’elemento più grande.

Cos’è l’LCP?

La metrica Largest Contentful Paint (LCP) riporta il tempo di rendering dell’immagine o del blocco di testo più grande visibile all’interno del viewport, rispetto a quando è iniziato il caricamento della pagina .

Che cos’è un buon punteggio LCP?

Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere il contenuto più grande di 2,5 secondi o meno. Per assicurarti di raggiungere questo obiettivo per la maggior parte dei tuoi utenti, una buona soglia da misurare è il 75° percentile dei caricamenti di pagina, segmentato tra dispositivi mobili e desktop.

Per ulteriori informazioni sulla ricerca e la metodologia alla base di questa raccomandazione, vedere: Definizione delle soglie delle metriche di Core Web Vitals

Quali elementi vengono presi in considerazione?

Come attualmente specificato nella Largest Contentful Paint API , i tipi di elementi presi in considerazione per Largest Contentful Paint sono:

• <img>elementi
• <image>elementi all’interno di un <svg>elemento
• <video>elementi (viene utilizzata l’immagine del poster)
• Un elemento con un’immagine di sfondo caricata tramite la url()funzione (al contrario di un gradiente CSS )
• Elementi a livello di blocco contenenti nodi di testo o altri elementi di testo a livello di inline figli.

Nota, limitare gli elementi a questo set limitato era intenzionale per mantenere le cose semplici all’inizio. Ulteriori elementi (ad es <svg>. , <video>) possono essere aggiunti in futuro man mano che vengono condotte ulteriori ricerche.

Come viene determinata la dimensione di un elemento?

La dimensione dell’elemento riportato per Largest Contentful Paint è in genere la dimensione visibile all’utente all’interno della finestra. Se l’elemento si estende al di fuori della finestra, o se uno qualsiasi degli elementi è ritagliato o ha un overflow non visibile , quelle porzioni non contano ai fini della dimensione dell’elemento.

Per gli elementi dell’immagine che sono stati ridimensionati dalla loro dimensione intrinseca , la dimensione che viene segnalata è la dimensione visibile o la dimensione intrinseca, a seconda di quale sia la più piccola. Ad esempio, le immagini che vengono ridotte a una dimensione molto più piccola della loro dimensione intrinseca riporteranno solo la dimensione in cui sono visualizzate, mentre le immagini che vengono allungate o espanse a una dimensione maggiore riporteranno solo le loro dimensioni intrinseche.

Per gli elementi di testo, viene considerata solo la dimensione dei relativi nodi di testo (il rettangolo più piccolo che racchiude tutti i nodi di testo).

Per tutti gli elementi non viene considerato alcun margine, riempimento o bordo applicato tramite CSS.

Determinare quali nodi di testo appartengono a quali elementi a volte può essere complicato, specialmente per elementi i cui figli includono elementi inline e nodi di testo normale ma anche elementi a livello di blocco. Il punto chiave è che ogni nodo di testo appartiene (e solo a) il suo elemento antenato a livello di blocco più vicino. In termini di specifica : ogni nodo di testo appartiene all’elemento che genera il blocco che lo contiene .

Quando viene segnalata la vernice più ricca di contenuti?

Le pagine Web spesso vengono caricate in più fasi e, di conseguenza, è possibile che l’elemento più grande della pagina cambi.

Per gestire questo potenziale cambiamento, il browser invia un messaggio PerformanceEntrydi tipo largest-contentful-paintche identifica l’elemento di contenuto più grande non appena il browser ha dipinto il primo frame. Ma poi, dopo aver eseguito il rendering dei frame successivi, ne invierà un altro PerformanceEntryogni volta che l’elemento di contenuto più grande cambia.

Ad esempio, in una pagina con testo e un’immagine eroe il browser potrebbe inizialmente eseguire il rendering del testo, a quel punto il browser invierebbe una largest-contentful-paintvoce la cui elementproprietà probabilmente farebbe riferimento a <p>o <h1>. Successivamente, una volta terminato il caricamento dell’immagine dell’eroe, largest-contentful-paintverrà inviata una seconda voce e la sua elementproprietà farà riferimento a <img>.

È importante notare che un elemento può essere considerato l’elemento di contenuto più grande solo dopo che è stato eseguito il rendering ed è visibile all’utente. Le immagini non ancora caricate non sono considerate “renderizzate”. Né i nodi di testo utilizzano i caratteri Web durante il periodo di blocco dei caratteri . In questi casi un elemento più piccolo può essere segnalato come l’elemento di contenuto più grande, ma non appena l’elemento più grande termina il rendering, verrà segnalato tramite un altro PerformanceEntryoggetto.

Oltre al caricamento tardivo di immagini e caratteri, una pagina può aggiungere nuovi elementi al DOM man mano che nuovi contenuti diventano disponibili. Se uno di questi nuovi elementi è più grande del precedente elemento di contenuto più grande, PerformanceEntryne verrà segnalato anche uno nuovo.

Se un elemento che è attualmente l’elemento di contenuto più grande viene rimosso dal viewport (o addirittura rimosso dal DOM), rimarrà l’elemento di contenuto più grande a meno che non venga visualizzato un elemento più grande.

Prima di Chrome 88, gli elementi rimossi non erano considerati elementi di contenuto più grandi e la rimozione dell’attuale candidato attiverebbe l’ largest-contentful-paintinvio di una nuova voce. Tuttavia, a causa dei modelli dell’interfaccia utente popolari come i caroselli di immagini che spesso rimuovevano elementi DOM, la metrica è stata aggiornata per riflettere in modo più accurato ciò che gli utenti sperimentano. Vedere il CHANGELOG per maggiori dettagli.

Il browser interromperà la segnalazione di nuove voci non appena l’utente interagisce con la pagina (tramite tocco, scorrimento o pressione di un tasto), poiché l’interazione dell’utente spesso cambia ciò che è visibile all’utente (il che è particolarmente vero con lo scorrimento).

A scopo di analisi, dovresti segnalare solo l’ultimo inviato PerformanceEntryal tuo servizio di analisi.

Attenzione

Poiché gli utenti possono aprire le pagine in una scheda in background, è possibile che la pittura più ricca di contenuti non si verifichi fino a quando l’utente non mette a fuoco la scheda, il che può essere molto più tardi rispetto a quando l’hanno caricata per la prima volta.

Tempo di caricamento e tempo di rendering

Per motivi di sicurezza, il timestamp di rendering delle immagini non viene esposto per le immagini multiorigine prive Timing-Allow-Origindell’intestazione. Invece, viene esposto solo il loro tempo di caricamento (poiché questo è già esposto tramite molte altre API Web).

L’ esempio di utilizzo seguente mostra come gestire gli elementi il ​​cui tempo di rendering non è disponibile. Ma, quando possibile, è sempre consigliabile impostare l’ Timing-Allow-Originintestazione, in modo che le tue metriche siano più accurate.

Come vengono gestite le modifiche al layout e alle dimensioni degli elementi?

Per mantenere basso il sovraccarico di prestazioni del calcolo e dell’invio di nuove voci di prestazioni, le modifiche alle dimensioni o alla posizione di un elemento non generano nuovi candidati LCP. Vengono considerate solo la dimensione e la posizione iniziali dell’elemento nella finestra.

Ciò significa che le immagini che inizialmente vengono visualizzate fuori dallo schermo e poi passano allo schermo potrebbero non essere riportate. Significa anche che gli elementi inizialmente renderizzati nella finestra che poi vengono spinti verso il basso, fuori dalla vista riporteranno comunque la loro dimensione iniziale nella finestra.

Esempi

Ecco alcuni esempi di quando il più grande contenuto pittorico si verifica su alcuni siti Web popolari:

In entrambe le linee temporali sopra, l’elemento più grande cambia durante il caricamento del contenuto. Nel primo esempio, il nuovo contenuto viene aggiunto al DOM e questo cambia l’elemento più grande. Nel secondo esempio, le modifiche al layout e il contenuto che in precedenza era il più grande viene rimosso dalla finestra.

Anche se spesso accade che i contenuti caricati in ritardo siano più grandi dei contenuti già presenti nella pagina, non è necessariamente così. I prossimi due esempi mostrano il disegno di contenuto più grande che si verifica prima del caricamento completo della pagina.

Nel primo esempio, il logo di Instagram viene caricato relativamente presto e rimane l’elemento più grande anche se vengono mostrati progressivamente altri contenuti. Nell’esempio della pagina dei risultati di ricerca di Google, l’elemento più grande è un paragrafo di testo che viene visualizzato prima del completamento del caricamento di qualsiasi immagine o logo. Poiché tutte le singole immagini sono più piccole di questo paragrafo, rimane l’elemento più grande durante tutto il processo di caricamento.

Nel primo fotogramma della timeline di Instagram, potresti notare che il logo della fotocamera non ha un riquadro verde attorno. Questo perché è un <svg>elemento e <svg>gli elementi non sono attualmente considerati candidati LCP. Il primo candidato LCP è il testo nel secondo frame.

Come misurare LCP

L’ LCP può essere misurato in laboratorio o sul campo ed è disponibile nei seguenti strumenti:

Strumenti sul campo

• Rapporto sull’esperienza utente di Chrome
• Approfondimenti sulla velocità della pagina
• Search Console (rapporto Core Web Vitals)
• web-vitalsLibreria JavaScript

Strumenti di laboratorio

• Strumenti di sviluppo di Chrome
• Faro
• Pagina WebTest

E se l’elemento più grande non fosse il più importante?

In alcuni casi l’elemento (o gli elementi) più importanti della pagina non è lo stesso dell’elemento più grande e gli sviluppatori potrebbero essere più interessati a misurare i tempi di rendering di questi altri elementi. Ciò è possibile utilizzando l’ API Element Timing , come descritto nell’articolo sulle metriche personalizzate .

Come migliorare LCP

L’LCP è principalmente influenzato da quattro fattori:

• Tempi di risposta del server lenti
• JavaScript e CSS che bloccano il rendering
• Tempi di caricamento delle risorse
• Rendering lato client

Per un approfondimento su come migliorare l’LCP, vedere Ottimizza LCP . Per ulteriori indicazioni sulle tecniche di performance individuali che possono anche migliorare l’LCP, vedere:

• Applicare il caricamento istantaneo con il pattern PRPL
• Ottimizzazione del percorso di rendering critico
• Ottimizza il tuo CSS
• Ottimizza le tue immagini
• Ottimizza i caratteri web
• Ottimizza il tuo JavaScript (per i siti con rendering client)
• Fonte: https://web.dev/lcp/

Max Potential First Input Delay (FID) è una delle metriche monitorate nella sezione Performance del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Lighthouse mostra il FID potenziale massimo in millisecondi:

Cosa misura il potenziale massimo FID

Max Potential FID misura il primo ritardo di input nel caso peggiore che i tuoi utenti potrebbero riscontrare. First Input Delay misura il tempo da quando un utente interagisce per la prima volta con il tuo sito, ad esempio facendo clic su un pulsante, al momento in cui il browser è effettivamente in grado di rispondere a tale interazione.

Lighthouse calcola il FID potenziale massimo trovando la durata dell’attività più lunga dopo il primo dipinto contenuto . Le attività prima di First Contentful Paint sono escluse perché è improbabile che un utente tenti di interagire con la tua pagina prima che qualsiasi contenuto sia stato visualizzato sullo schermo, che è ciò che First Contentful Paint misura.

In che modo Lighthouse determina il tuo punteggio FID potenziale massimo

Il tuo punteggio Max Potential FID è un confronto del tempo Max Potential FID della tua pagina e dei tempi Max Potential FID per siti Web reali, sulla base dei dati dell’archivio HTTP . Ad esempio, se il tuo punteggio FID Max Potential in Lighthouse è verde, significa che la tua pagina ha prestazioni migliori del 90% dei siti Web reali.

Questa tabella mostra come interpretare il tuo punteggio FID potenziale massimo:

Come migliorare il tuo punteggio FID potenziale massimo

Se stai cercando di apportare miglioramenti sostanziali al tuo punteggio FID Max Potential, vedi Come migliorare il tuo punteggio TTI . Le strategie per il miglioramento sostanziale del Max Potential FID sono sostanzialmente le stesse delle strategie per il miglioramento del TTI.

Se vuoi ottimizzare il tuo punteggio Max Potential FID in modo specifico, devi ridurre la durata delle tue attività più lunghe, poiché questo è ciò che misura tecnicamente Max Potential FID. La strategia Idle Until Urgent è un modo per farlo.

Come acquisire i dati del campo FID

La misurazione di Lighthouse di Max Potential FID è data da laboratorio . Per acquisire dati FID reali mentre i tuoi utenti caricano le tue pagine, utilizza la libreria First Input Delay di Google . Una volta acquisiti i dati FID, puoi segnalarli come evento al tuo strumento di analisi preferito.

Poiché FID misura quando gli utenti effettivi interagiscono per la prima volta con la tua pagina, è più intrinsecamente variabile rispetto alle tipiche metriche di rendimento. Vedere Analisi e reportistica sui dati FID per indicazioni su come valutare i dati FID raccolti.

Come migliorare il tuo punteggio di Performance complessivo

A meno che tu non abbia un motivo specifico per concentrarti su una metrica particolare, di solito è meglio concentrarti sul miglioramento del tuo punteggio di Performance complessivo.

Utilizza la sezione Opportunità del rapporto Lighthouse per determinare quali miglioramenti avranno più valore per la tua pagina. Più significativa è l’opportunità, maggiore sarà l’effetto che avrà sul tuo punteggio di Performance. Ad esempio, lo screenshot di Lighthouse di seguito mostra che l’ eliminazione delle risorse che bloccano il rendering produrrà il miglioramento maggiore:

Testa ora la velocità del tuo sito e ottieni 1 mese di Hosting Bhoost GRATIS.

Fonte / Source: https://web.dev/lighthouse-max-potential-fid/