Guarda il caricamento del tuo sito attraverso gli occhi del tuo visitatore
Fatti un'idea di ciò che i tuoi visitatori stanno effettivamente sperimentando quando visitano il tuo sito web.
Noti qualcosa che si carica lentamente o fuori posto? Questo può aiutarti a identificare importanti ritardi e problemi di conversione riscontrati dai tuoi visitatori.
Screenshot che mostra il risultato di un test delle prestazioni web di DebugBear, ottobre 2022 La sequenza temporale mostra l'andamento del rendering del sito web nel tempo.
Ad esempio, questa pagina inizia il rendering dopo 0,7 secondi e l'immagine principale viene visualizzata dopo 1,3 secondi.
Il sito Web è completamente visualizzato, noto anche come Visually Complete, quando il widget della chat viene visualizzato dopo 3,7 secondi.
Screenshot di DebugBear che mostra l'avanzamento del rendering di un sito Web nel tempo, ottobre 2022 All'interno dello strumento, puoi anche guardare una registrazione video del processo di rendering.
Questo è un ottimo modo per dimostrare l'impatto dei problemi di prestazioni ai clienti o ad altri membri del tuo team.
Screenshot che mostra una registrazione video di un sito Web parzialmente renderizzato in DebugBear, ottobre 2022 Testa le modifiche alla velocità del sito vedendo le tue statistiche di caricamento reali
Diciamo che hai ottimizzato il tuo sito web e vuoi capire se queste modifiche avranno un impatto.
Questo strumento esegue un "test di laboratorio" in un ambiente ottimale per scoprire se stai ottimizzando correttamente il tuo sito.
Quando esegui il test del tuo sito, otterrai un "Punteggio lab" ufficiale, che è un riepilogo di sei metriche delle prestazioni che derivano dal punteggio delle prestazioni dello strumento Faro di Google:
- Primo Contentful Paint (10% del punteggio complessivo).
- Indice di velocità (10%).
- La più grande vernice contenta (25%).
- Tempo per interattivo (10%).
- Tempo di blocco totale (30%).
- Spostamento cumulativo del layout (15%).
Utilizzando questi dati, scoprirai quanto è stato utile il tuo ultimo ciclo di ottimizzazioni e cosa potresti dover modificare.
A questo punto, probabilmente ti starai chiedendo cosa devi cambiare. Impariamo come ottimizzare il tuo sito utilizzando ogni metrica chiave della Panoramica delle metriche.
Come ottimizzare la velocità del sito web
L'esecuzione di un test di velocità è la prima parte del percorso di ottimizzazione del tuo sito web.
Una volta che hai le tue metriche, dovrai sapere come interpretarle e cosa fare per risolverle.
Nell'area Panoramica delle metriche del rapporto sulla velocità del tuo sito web, vedrai le metriche chiave su cui ci concentreremo per velocizzare il tuo sito:
- Primo Contentful Paint : questo può essere accelerato riparando la velocità di comunicazione del server.
- Il più grande contenuto di pittura : questo può essere accelerato ottimizzando i media e le risorse.
Inoltre, puoi utilizzare la cascata delle richieste per vedere quanto tempo impiegano le richieste e in che modo ciò influisce su tali metriche.
Come velocizzare il First Contentful Paint (FCP)
Iniziamo facendo in modo che il tuo sito web venga visualizzato prima per i tuoi visitatori; per prima cosa affronteremo First Contentful Paint.
Qual è la prima vernice contenta?
First Contentful Paint misura la prima volta che il contenuto di una pagina inizia ad apparire dopo che il tuo visitatore è passato a quella pagina.
È importante che i tuoi contenuti chiave vengano visualizzati rapidamente per impedire al tuo visitatore di lasciare il tuo sito web. Più velocemente un utente lascia il tuo sito web, più velocemente Google apprende che l'esperienza della pagina potrebbe essere negativa.
Ma come fai a sapere esattamente cosa sta causando un caricamento lento del tuo sito web?
Come scopri quali problemi del server stanno rallentando il tuo sito web? Scopriamolo.
Perché la mia prima pittura soddisfacente impiega così tanto tempo?
Il tuo FCP potrebbe essere influenzato dalla velocità di connessione del server, dalle richieste del server, dalle risorse di blocco del rendering e altro ancora.
Sembra molto, ma c'è un modo semplice per vedere esattamente cosa sta rallentando il tuo FCP : la cascata delle richieste.
Questo utile strumento mostra quali richieste vengono fatte dal tuo sito web e quando ogni richiesta inizia e finisce.
Ad esempio, in questa schermata, vediamo prima una richiesta per il documento HTML e poi due richieste per caricare fogli di stile a cui si fa riferimento nel documento.
Screenshot che mostra i dati di debug per la metrica First Contentful Paint in DebugBear, ottobre 2022 Perché il primo Contentful Paint si verifica dopo 0,6 secondi? Possiamo analizzare ciò che sta accadendo sulla pagina per capirlo.
Capire cosa succede prima di una prima pittura contenta
Prima che i primi contenuti possano essere caricati sulla tua pagina web, il browser dell'utente deve prima connettersi al tuo server e recuperare il contenuto.
Se questo processo richiede molto tempo, il tuo utente impiega molto tempo per vedere il tuo sito web.
Il tuo obiettivo è scoprire cosa sta succedendo prima che il tuo sito web inizi a caricarsi in modo da poter individuare i problemi e velocizzare l'esperienza.
Caricamento della pagina Parte 1: il browser crea una connessione al server
Prima di richiedere un sito Web da un server, il browser del tuo visitatore deve stabilire una connessione di rete a quel server.
Questo in genere richiede tre passaggi:
- Controllo dei record DNS per cercare l'indirizzo IP del server in base al nome di dominio.
- Stabilire una connessione server affidabile (nota come connessione TCP).
- Stabilire una connessione sicura al server (nota come connessione SSL).
Questi tre passaggi vengono eseguiti dal browser, uno dopo l'altro. Ogni passaggio richiede un viaggio di andata e ritorno dal browser del tuo visitatore al server del tuo sito web.
In questo caso, sono necessari circa 251 millisecondi per stabilire la connessione al server.
Schermata di DebugBear che mostra i round trip di rete utilizzati per stabilire una connessione al server, ottobre 2022 Caricamento della pagina Parte 2: Il browser richiede il documento HTML (qui accade il tempo per il primo byte)
Una volta stabilita la connessione al server, il browser del tuo visitatore può richiedere il codice HTML che contiene il contenuto del tuo sito web. Questa è chiamata richiesta HTTP.
In questo caso, la richiesta HTTP impiega 102 millisecondi. Questa durata include sia il tempo trascorso sul viaggio di andata e ritorno della rete sia il tempo trascorso in attesa che il server generi una risposta.
Dopo 251 millisecondi per creare la connessione e 102 millisecondi per effettuare la richiesta HTTP, il browser del tuo visitatore può finalmente iniziare a scaricare la risposta HTML.
Questa pietra miliare è chiamata Time to First Byte (TTFB). In questo caso, ciò accade dopo un totale di 353 millisecondi.
Dopo che la risposta del server è pronta, il browser del tuo visitatore trascorre un po' di tempo aggiuntivo per scaricare il codice HTML. In questo caso, la risposta è piuttosto ridotta e il download richiede solo 10 millisecondi aggiuntivi.
Screenshot di DebugBear che mostra i diversi componenti di una richiesta HTTP, ottobre 2022 Caricamento della pagina Parte 3: il tuo sito Web carica ulteriori risorse per il blocco del rendering
I browser non visualizzano o visualizzano le pagine subito dopo il caricamento del documento. Invece, di solito ci sono risorse aggiuntive per il blocco del rendering.
La maggior parte delle pagine sembrerebbe brutta senza alcuno stile visivo, quindi i fogli di stile CSS vengono caricati prima che una pagina inizi il rendering.
Il caricamento dei 2 fogli di stile aggiuntivi in questo esempio di test di velocità del sito Web richiede 137 millisecondi.
Tieni presente che queste richieste non richiedono una nuova connessione al server. I file CSS vengono caricati dallo stesso dominio di prima e possono riutilizzare la connessione esistente.
Screenshot di DebugBear che mostra risorse aggiuntive per il blocco del rendering caricate dopo il documento HTML, ottobre 2022 Caricamento della pagina Parte 4: Il browser esegue il rendering della pagina
Infine, una volta caricate tutte le risorse necessarie, il browser del tuo visitatore può iniziare a visualizzare la pagina. Tuttavia, fare questo lavoro richiede anche una certa quantità di tempo di elaborazione, in questo caso 66 millisecondi. Ciò è indicato dall'indicatore di attività CPU arancione nella vista a cascata.
Schermata di DebugBear che mostra i passaggi che portano dal caricamento del documento HTML al rendering della pagina Web, ottobre 2022 Ora capiamo perché l'FCP si verifica dopo 632 millisecondi:
- 364 millisecondi per la richiesta del documento HTML.
- 137 millisecondi per caricare i fogli di stile.
- 66 millisecondi per eseguire il rendering della pagina.
- 65 millisecondi per altri lavori di elaborazione.
L'altro lavoro di elaborazione include piccoli lavori come l'esecuzione di script inline o l'analisi del codice HTML e CSS una volta scaricato. Puoi vedere questa attività come piccole linee grigie appena sotto la pellicola di rendering.
Come ottimizzare First Contentful Paint (FCP)
Ora che capisci cosa porta al rendering del tuo sito web, puoi pensare a come ottimizzarlo.
- Il server può rispondere più rapidamente alla richiesta HTML?
- Le risorse possono essere caricate sulla stessa connessione invece di crearne una nuova?
- Ci sono richieste che possono essere rimosse o modificate per non bloccare più il rendering?
Ora che le parti iniziali del tuo sito Web vengono caricate prima, è tempo di concentrarti sul caricamento dell'intero sito più velocemente.
Come velocizzare il Largest Contentful Paint (LCP) con i consigli di DebugBear
Ci sono molti modi per velocizzare il tuo LCP.
Per semplificare, DebugBear ci offre ottimi passaggi successivi nella sezione Raccomandazioni.
Diamo un'occhiata ad alcuni esempi di raccomandazioni e impariamo come velocizzare l'LCP di questo sito web.
Raccomandazione 1: avviare le richieste di immagini LCP dal documento HTML
Se l'elemento di contenuto più grande della tua pagina è un'immagine, la procedura migliore è assicurarsi che l'URL sia contenuto direttamente nel documento HTML iniziale. Ciò consentirà di avviare il caricamento il prima possibile.
Tuttavia, questa procedura consigliata non viene sempre utilizzata e, a volte, è necessario molto tempo prima che il browser scopra che è necessario scaricare l'immagine principale.
Nell'esempio seguente, il contenuto più grande, che è un'immagine, viene aggiunto alla pagina utilizzando JavaScript. Di conseguenza, il browser deve scaricare ed eseguire uno script da 200 kilobyte prima che scopra l'immagine e inizi a scaricarla.
Schermata di DebugBear che mostra una catena di richieste sequenziale che porta a una richiesta di immagine, ottobre 2022 Come risolvere: a seconda del sito Web ci sono due possibili soluzioni.
Soluzione 1: se si utilizza JavaScript per caricare in modo lento un'immagine di grandi dimensioni, ottimizzare le dimensioni dell'immagine e rimuovere lo script di caricamento lento o sostituirlo con l'attributo moderno loading=”lazy”, che non richiede JavaScript.
Soluzione 2: in altri casi, il rendering lato server impedirebbe di dover scaricare l'app JavaScript prima che la pagina possa essere visualizzata. Tuttavia, questo a volte può essere complesso da implementare.
Raccomandazione 2: assicurarsi che le immagini LCP siano caricate con priorità elevata
Dopo aver caricato il codice HTML di una pagina, i browser dei tuoi visitatori potrebbero scoprire che, oltre alla tua immagine principale, potrebbe essere necessario caricare un gran numero di risorse aggiuntive come i fogli di stile.
L'obiettivo qui è assicurarsi che l'immagine principale più grande venga caricata per soddisfare il requisito di Google Contentful Paint più grande.
Altre risorse, come gli script di analisi di terze parti, non sono importanti quanto la tua immagine principale.
Inoltre, la maggior parte delle immagini a cui si fa riferimento nell'HTML del tuo sito sarà below the fold una volta che la pagina è stata visualizzata. Alcuni potrebbero essere completamente nascosti in una navigazione di intestazione nidificata.
Per questo motivo, i browser inizialmente impostano la priorità di tutte le richieste di immagini su Bassa. Una volta che la pagina è stata renderizzata, il browser scopre quali immagini sono importanti e cambia la priorità. Puoi vederne un esempio nello screenshot qui sotto, come indicato dall'asterisco nella colonna della priorità.
Schermata di DebugBear che mostra un'immagine LCP caricata con una priorità iniziale bassa, ottobre 2022 La cascata mostra che mentre il browser conosceva l'immagine all'inizio, non ha iniziato a scaricarla, come indicato dalla barra grigia.
Come risolvere: per risolvere questo problema puoi utilizzare una nuova funzionalità del browser chiamata suggerimenti di priorità. Se aggiungi l'attributo fetchpriority="high" a un elemento img, il browser inizierà a caricare l'immagine dall'inizio.
Raccomandazione 3: non nascondere il contenuto della pagina utilizzando i CSS
A volte potresti guardare una cascata di richieste e tutte le risorse di blocco del rendering sono state caricate, ma non viene visualizzato alcun contenuto della pagina. Cosa sta succedendo?
Gli strumenti di test A/B spesso nascondono il contenuto della pagina fino a quando le variazioni del test non sono state applicate agli elementi di contenuto della pagina. In questi casi, il browser ha reso la pagina ma tutto il contenuto è trasparente.
Cosa puoi fare se non riesci a rimuovere lo strumento di test A/B?
Come risolvere: controlla se puoi configurare lo strumento per nascondere solo i contenuti interessati dai test A/B. In alternativa, puoi verificare se esiste un modo per caricare più rapidamente lo strumento di test A/B.
Schermata di DebugBear che mostra una sequenza di rendering in cui il contenuto è nascosto da uno strumento di test A/B, ottobre 2022 Monitora la velocità del tuo sito con DebugBear
Vuoi testare continuamente il tuo sito web? Prova il nostro strumento di monitoraggio a pagamento con una prova gratuita di 14 giorni.
In questo modo, puoi verificare se le tue ottimizzazioni delle prestazioni funzionano e ricevere avvisi di eventuali regressioni delle prestazioni sul tuo sito.
Screenshot che mostra le tendenze della velocità del sito per un sito Web in DebugBear, ottobre 2022 
Screenshot che mostra i dati di Core Web Vitals in DebugBear, ottobre 2022