Perché una Pagina Sembra Lenta Quando Tutte le Metriche del Server Dicono che è Veloce

Qualcuno ti dice che il tuo sito è lento. Apri la dashboard e tutto è verde. I tempi di risposta sono pochi centinaia di millisecondi, nessun errore, nessuna saturazione, niente al di sopra della soglia.

Avete entrambi ragione, e il motivo non è sottile una volta che lo vedi: le tue metriche del server e il tuo visitatore misurano due cose diverse, e l’intersezione tra di loro è molto più piccola di quanto quasi chiunque si aspetti.

Due orologi, avviati in momenti diversi

L’orologio del tuo server inizia quando arriva una richiesta e si ferma quando finisce di scrivere una risposta. Questo intervallo è quello che il tuo monitoraggio segnala, e è una misurazione reale di una cosa reale.

L’orologio del visitatore inizia quando fa clic, e non si ferma fino a quando la pagina non ha disegnato qualcosa che è venuto a cercare. Tra quei due momenti ci sono: una ricerca DNS, una connessione TCP, un handshake TLS, il lavoro del tuo server, la risposta che torna indietro, l’analisi HTML, i fogli di stile e i caratteri e gli script che HTML richiede, ognuno dei quali ripete la maggior parte di quanto sopra, e infine il rendering.

Il tuo server è stato coinvolto in un solo passaggio di questo. Una pagina può passare 80 millisecondi sul tuo server e quattro secondi per diventare utile, e non c’è nulla di sbagliato nel tuo monitoraggio dell’applicazione quando dice 80 millisecondi.

Il numero che descrive il server e quelli che descrivono l’esperienza

Il numero del lato server è Time to First Byte, che Google descrive come misurazione “del tempo tra l’inizio della navigazione di una pagina e quando il primo byte di una risposta inizia ad arrivare”. La loro guida è che “la maggior parte dei siti dovrebbe cercare di avere un TTFB di 0.8 secondi o meno”.

Ma sono espliciti sui suoi limiti: “Poiché TTFB non è una metrica Core Web Vitals, non è assolutamente necessario che i siti raggiungano la soglia TTFB ‘buona’, purché non ostacoli la loro capacità di ottenere un buon punteggio sulle metriche che contano.”

Le metriche che contano sono i tre Core Web Vitals, e ognuna risponde a una domanda che una persona riconoscerebbe effettivamente.

Largest Contentful Paint è quando l’elemento più grande sullo schermo finisce di disegnarsi, il che è il proxy della macchina più vicino a “la pagina è apparsa”. L’obiettivo è che “LCP dovrebbe verificarsi entro 2.5 secondi da quando la pagina inizia a caricarsi”.

Interaction to Next Paint è quanto tempo la pagina impiega per rispondere visibilmente dopo che qualcuno interagisce con essa: “le pagine dovrebbero avere un INP di 200 millisecondi o meno”. Ha sostituito First Input Delay come Core Web Vital stabile nel 2024, e il cambiamento conta, perché FID misurava solo il ritardo prima dell’inizio dell’elaborazione mentre INP misura tutto il percorso fino al prossimo disegno. Una pagina che accettava il tuo clic istantaneamente e poi si congelava otteneva un buon punteggio sulla metrica precedente.

Cumulative Layout Shift non riguarda la velocità affatto. Misura quanto la pagina si muove durante il caricamento, e l’obiettivo è “0.1 o meno”. È in questo elenco perché una pagina che salta sotto il tuo dito sembra rotta in un modo che si legge come lento, anche quando non lo era.

Il dettaglio che risolve la maggior parte di questi argomenti

I Core Web Vitals sono valutati al “75° percentile dei caricamenti della pagina, segmentati su dispositivi mobili e desktop”.

Non la media. Il 75° percentile, il che significa che uno su quattro visitatori è peggio del numero che stai guardando, ed è deliberato: una media è dominata da persone che stavano già avendo un buon momento. Le tue stesse visite sono in quella comoda maggioranza quasi per costruzione, poiché sei vicino ai tuoi server, su una buona connessione, su una macchina veloce, con una cache calda.

Quindi, quando un visitatore dice che il sito è lento e il tuo dashboard dice che è veloce, la lettura onesta non è che uno di voi sia sbagliato. È che stai guardando la media di una distribuzione la cui coda è l’intera lamentela.

Debole

"Il sito è lento." Ho controllato la dashboard, tempo di risposta p50 90ms, chiuso come impossibile da riprodurre.

Migliore

"Lento sulla pagina del prodotto, circa 6 secondi prima che appaia qualcosa, su dati mobili." LCP è la metrica; TTFB era corretto, quindi il tempo sta andando da qualche parte dopo l'arrivo della risposta.

Dove va effettivamente il tempo

Una volta accettato che il divario è reale, ci sono solo pochi posti dove si nasconde, e sono gli stessi pochi ogni volta.

Risorse di blocco del rendering. L’HTML è arrivato velocemente e poi ha chiesto un foglio di stile, e il browser non renderizza fino a quando non lo ha. Ogni richiesta di blocco nell’head viene aggiunta al tempo prima che appaia qualcosa.

Font. Un font web che non è precaricato può lasciare il testo invisibile o ridisegnato ben dopo che il layout è altrimenti completato, il che ritarda sia il disegno più grande che, se causa un reflow, alimenta lo spostamento del layout.

Immagini senza dimensioni. La causa singola più comune dello spostamento del layout. Il browser non può riservare lo spazio, quindi tutto ciò che è sotto si muove quando arriva l’immagine.

JavaScript, su un dispositivo lento. Questo è invisibile su una macchina di sviluppo per costruzione. L’analisi e l’esecuzione di un bundle grande costa una frazione di secondo su un laptop e diversi secondi su un telefono di fascia media, e la pagina non risponde ai tocchi per tutto il tempo.

La distanza. Un visitatore dall’altra parte del mondo paga il viaggio di andata e ritorno più volte prima che il tuo server veloce sia anche chiesto, che è la stessa ragione per cui il degrado upstream atterra su di te piuttosto che su chi l’ha causato.

Cosa chiedere invece di “puoi essere più specifico”

“È lento” non può essere attuato, ma le tre cose che lo rendono attuabile sono tutte facili da chiedere, e nessuna di esse richiede al segnalatore di comprendere quanto sopra.

• Quale pagina, e cosa stavano aspettando. Lento a comparire, lento a rispondere dopo un tocco, o movimento durante il caricamento. Quelle sono tre metriche diverse e tre cause diverse.
• Su cosa, e su quale connessione. Un Android di cinque anni su dati mobili e un desktop su fibra non sono lo stesso sito.
• Pressappoco quanto tempo, e se è sempre. La differenza tra “sempre circa sei secondi” e “a volte si blocca” è la differenza tra una pagina pesante e un guasto intermittente, e non condividono correzioni.

E quello che elimina completamente le congetture è una registrazione delle richieste come si sono effettivamente verificate sulla loro macchina, perché il network log mostra dove sono andati i secondi piuttosto che dove pensi che siano andati.

Cosa trarne

Una dashboard verde non è prova che il sito sia veloce. È prova che la parte che hai strumentato è veloce, e quella parte è un solo passaggio in una sequenza che il visitatore sperimenta interamente.

Misura ciò che i tuoi utenti sperimentano, al percentile dove vivono i reclami piuttosto che alla media, e considera la tua stessa esperienza del tuo sito come il punto dati meno rappresentativo a cui hai accesso.