Che cosa si intende per cronometro di rete di Google e che cosa influenza ogni intervallo di tempo?

Question

Stavo cercando gli strumenti di sviluppo chrome # resource network timing per rilevare le richieste che devono essere migliorate. Nel link prima c'è una definizione per ciascun timing, ma non capisco quali processi vengano presi dietro le quinte che influenzano la durata del periodo.

Di seguito sono 3 immagini diverse e qui è la mia comprensione di cosa sta succedendo, per favore correggimi se sbaglio.

Stallato: Perché ci sono tempi in cui la richiesta viene arrestata per 1,17 mentre gli altri ne prendono meno?

richiesta inviata: è il momento che la nostra richiesta ha portato a raggiungere il server

TTFB: Ora prese fino a quando il server risponde con il primo byte di dati

Content Scarica: Il tempo fino a quando l'intera risposta raggiunge il cliente

Grazie

Answer 1

rete è un settore in cui le cose possono variare notevolmente. Ci sono un sacco di numeri diversi che entrano in gioco con questi e variano tra posizioni diverse e anche la stessa posizione con diversi tipi di contenuti.

Ecco qualche dettaglio in più sulle zone è necessario più comprensione con:

stallo: questo dipende da cos'altro sta accadendo nello stack di rete. Una cosa non può essere bloccata affatto, mentre altre richieste potrebbero essere bloccate perché 6 connessioni alla stessa posizione sono già aperte. Ci sono più motivi per lo stallo, ma il limite massimo di connessione è un modo semplice per spiegare perché potrebbe verificarsi.

Lo stato di stallo indica che non è possibile inviare la richiesta in questo momento, , è necessario attendere per qualche motivo. Generalmente, questo non è un grosso problema. Se lo vedi molto e tu sei non sul protocollo HTTP2, allora dovresti cercare di minimizzare il numero di risorse estratte da una determinata posizione. Se si utilizza HTTP2, non preoccuparsi troppo di ciò poiché gestisce in modo diverso numerose richieste.

Guardarsi intorno e vedere quante richieste stanno per un singolo dominio. È possibile utilizzare la casella filtro per ridurre la vista. Se hai molte richieste che vanno nello stesso dominio, è molto probabile che si raggiunga il limite di connessione. La condivisione del dominio è un metodo per gestirlo con HTTP 1.1, ma con HTTP 2 è una prestazione anti-pattern e fa male.

Se non si raggiunge il limite massimo di connessione, il problema è più sfumato e richiede un approccio di debug più pratico per capire cosa sta succedendo.

Richiesta inviata: Questo non è il momento di raggiungere il server, ovvero il Time To First Byte. Tutta la richiesta inviata significa che la richiesta è stata inviata e che è stato necessario il tempo di stack X della rete per eseguirlo.

Nulla di ciò che si può fare per accelerare, è più per scopi informativi e di debug interno.

Time to First Byte (TTFB): Questo è il tempo totale per la richiesta inviata per arrivare a destinazione, poi per la destinazione per elaborare la richiesta, e, infine, per la risposta per attraversare le reti di nuovo alla cliente.

Un TTFB alto rivela uno dei due problemi. Il primo è una cattiva connessione di rete tra client e server. Quindi i dati sono lenti per raggiungere il server e tornare indietro. La seconda causa è un server lento che elabora la richiesta. Questo perché l'hardware è debole o l'esecuzione dell'applicazione è lenta. Oppure, entrambi questi problemi possono esistere contemporaneamente.

Per indirizzare un TTFB alto, innanzitutto ritagliare il maggior numero di reti possibile. Idealmente, ospitare l'applicazione localmente su una macchina virtuale con risorse limitate e vedere se c'è ancora un grande TTFB. Se c'è, allora l'applicazione deve essere ottimizzata per la velocità di risposta. Se il TTFB è localmente super basso, allora le reti tra il client e il server sono il problema. Ci sono vari modi per gestire questo problema in cui non entrerò poiché è un'area di competenza a sé stante. Ricerca l'ottimizzazione della rete e persino prova a spostare gli host e vedere se la rete dei tuoi fornitori di server è il problema.

Ricordare che l'intero stack di server entra in gioco qui. Quindi se nginx o apache sono configurati male, o il tuo database impiega molto tempo per rispondere, o la tua cache ha problemi, questi possono causare ritardi. Sono anche difficili da rilevare localmente, dal momento che il server locale potrebbe variare nella configurazione dallo stack remoto.

Download contenuto: Questo è il tempo totale dalla risoluzione TTFB per il client per ottenere il resto del contenuto dal server. Questo dovrebbe essere breve se non stai scaricando un file di grandi dimensioni. Dovresti dare un'occhiata alle dimensioni del file, alle condizioni della rete, e quindi giudicare quanto tempo ci vorrà.