Quanto è veloce il tuo negozio online? Se non lo sai, verificalo subito!

Google annunciato che cambierà i suoi algoritmi e valuterà i siti su tre parametri aggiuntivi:

  • caricamento
  • interattività
  • stabilità visiva

Queste metriche, chiamate Core Web Vitals, stanno diventando nuovi segnali di ranking che sono entrati in azione a maggio 2021.

Core Web Vitals: Cosa sono?

I Core Web Vitals o Segnali Web Esseniali sono stati progettati per aiutare Google a comprendere l’esperienza che gli utenti hanno quando accedono alle tue pagine web. Essenzialmente, si tratta di una valutazione dell’esperienza utente basata su tre pilastri:

  • caricamento (LCP)
  • interattività (FID)
  • stabilità visiva (CLS)

Le metriche del Core Web Vitals per Google, si basano su questi criteri o meglio su queste domande:

  • Quanto velocemente appare il contenuto sullo schermo? (LCP)
  • Quanto velocemente reagisce la pagina all’interazione dell’utente? (FID)
  • Il contenuto si sposta sullo schermo durante il caricamento del sito? (CLS)

Ecco che quindi i Core Web Vitals può diventare anche un vantaggio per il tuo store. Ad esempio, se tu e il tuo concorrente avete contenuti simili e pertinenti, Google premierà un sito che si carica più velocemente.

Ma vediamo ora nel dettagli le singolarità di ogni metrica.

Velocità e SEO

I tempi in cui la SEO si riduceva semplicemente a riempire il tuo sito web con un lungo elenco di parole chiave e backlink sono finiti. Oggi infatti, Google inizia a prestare maggiore attenzione ad un nuovo fatto: la Web Performance.

Nel maggio 2020, Google ha infatti effettuato un studio dal quale è emerso che gli utenti richiedono una user experience migliore, con siti veloci e bassi tempi di attesa. La velocità è  comunque sempre stata un indicatore importante per una buona esperienza utente e ora più che mai, sarà un fattore discriminante per la SEO.

A partire da maggio 2021, infatti oltre a influire sul tasso di conversione, la velocità e quindi anche le prestazioni web, verranno conteggiate per la SEO. Il tutto verrà misurato su una serie di nuove metriche, note come Core Web Vitals.

Largest Contentful Paint (LCP)

Molte persone confondono questa metrica con il tempo necessario per il caricamento completo della pagina. Tuttavia, tieni presente che l’ LCP non è semplicemente il tempo di caricamento di una pagina, ma piuttosto il tempo necessario affinché il contenuto più pesante, appaia effettivamente sullo schermo.

Mi spiego meglio…Quando tu entri all’interno di un Ecommerce e clicchi su un articolo, arrivi sulla pagina di prodotto. Questa pagina contiene; intestazione, logo, testo e immagine. Le immagini molto spesso sono piuttosto pesanti e occupano più spazio sullo schermo. L’ LCP sarebbe quindi il tempo necessario per caricare completamente l’immagine.

Quindi in sostanza, come è possibile controllare l’LCP?

Google offre una serie di strumenti che ti aiutano a identificare l’elemento più grande presente in una pagina web. Ci sono anche molti altri strumenti per verificare questo. Se vuoi sapere quali sono, leggi il nostro articolo 4 Tool per misurare la velocità di Magento e ottimizzarne le performance.

Troverai tante info per poter verificare la velocità del tuo store e soprattutto un’ utile panoramica sulle criticità  presenti.

Dopo aver controllato il tuo punteggio LCP, confrontalo con i dati di Google. Secondo la società del motore di ricerca infatti, non dovresti essere oltre 2,5 secondi.

Come ottimizzare l’ LCP?

Per cercare di ottimizzare l’ LCP, ecco un piccolo elenco che può esserti utile:

  • Ottimizza le immagini. Precarica, comprimi e riduci il peso di tutti gli elementi visivi che sono presenti nel tuo sito. Più basso è il numero di MB, minore sarà il tempo necessario per il caricamento.
  • Ottimizza il server. Memorizza nella cache tutti i file statici o utilizza soluzioni CDN pronte per l’uso. Il vantaggio della CDN è che fornisce contenuti dal server più vicino all’utente. Quindi le immagini e le descrizioni dei prodotti vengono caricate più velocemente.
  • Ottimizza JavaScript e CSS. Rivedi e taglia qualsiasi codice non necessario dai file CSS o JS. È meglio dedicare un file CSS / JS separato per ogni blocco invece di scrivere tutta la logica e gli stili JS in un file ingombrante.
  • Ottimizza il rendering lato client. Non utilizzare molte operazioni di nidificazione dei componenti nella struttura ad albero DOM. Prova a utilizzare meno funzioni setTimeout per eseguire il rendering e aggiungere elementi al DOM nel caso di eventi “document.ready” e “window.onload”.

First Input Delay (FID)

Questa metrica riflette la reattività del tuo sito: in sostanza, misura il tempo necessario per rispondere a qualsiasi interazione dell’utente.

Ad esempio, se l’utente entra nel tuo negozio di E-commerce, tocca un pulsante e … non succede nulla, c’è qualcosa che non va! L’utente è scontento e va via dal tuo sito.

Ma come mai accade?

Tutto questo succede quando il browser sta ancora eseguendo altre operazioni in background e semplicemente non è pronto per eseguire un comando. Questo tipo di ritardi sono abbastanza comuni per i siti in Magento. Questo dipende dal fatto che si chiede ai browser di eseguire troppi comandi JavaScript e i browser semplicemente non sono in grado di eseguirli rapidamente. Di conseguenza, gli utenti rimangono in attesa fino a quando, facendo clic sul pulsante, selezionando un’opzione o immettendo un testo, cambierà qualcosa sullo schermo.

Cos’è il FID?

È una misura di tutte le interazioni dell’utente che si verificano quando il tuo sito è ancora in fase di caricamento. Google desidera che il tuo sito risponda all’interazione dell’utente anche quando non ha ancora terminato il caricamento. Le uniche due eccezioni sono lo zoom e lo scorrimento: questi input dell’utente non sono incorporati nel punteggio FID.

Ecco una ripartizione di ciò che Google considera reattivo:

Una cosa speciale del FID è che non può essere misurato senza che gli utenti interagiscano effettivamente con il tuo sito. Questo significa che Google non può stimare il tuo punteggio FID basandosi esclusivamente su dati teorici. Prenderanno dati da utenti reali, noti anche come dati sul campo.

Migliorare FID significa ridurre JavaScript inutilizzato (il linguaggio di codifica responsabile dell’esecuzione dei comandi utente). Se tagli il JavaScript non necessario e riduci il tempo necessario per eseguire le sue attività, farai molta strada con il tuo punteggio FID.

Tuttavia, l’ottimizzazione di JavaScript è complicata. A volte, dovrai sacrificare alcune delle funzionalità del tuo sito, per vedere salti di prestazione.

Cumulative Layout Shift (CLS)

A differenza delle due metriche precedenti, il Cumulative Layout Shift, risolve un problema diverso, direttamente legato alla sensazione dell’utente.

Il CLS infatti, misura tutti i cambiamenti di layout del tuo sito durante il caricamento. Mi spiego, se sei in un negozio online di smartphone, clicchi su un prodotto e anziché essere reindirizzato verso la scheda prodotto, entri su una scheda differente, con un diverso layout, che magari è legata ad un altro prodotto o addirittura ad una pubblicità!

E’ chiaro che quel punto, sono sicuro che sarai piuttosto infastidito e che probabilmente non concluderai l’acquisto.

Perché gli elementi del tuo sito possono cambiare?

Questo può accedere per esempio, quando tutto il contenuto della pagina, sembra essere completamente caricato e visibile, ma il download di un elemento di grandi dimensioni non è ancora terminato. Nel momento in cui accade, tutti gli altri contenuti vengono “spinti”, il che si traduce in improvvisi cambi di layout.

Un altro fattore importante che può far saltare il layout dei tuoi contenuti sono gli annunci. Spesso occupano molto spazio sullo schermo e si caricano più lentamente del resto del contenuto. E non appena vengono caricati, tutto il contenuto del sito è soggetto a modifiche.

Ecco, il CLS viene calcolato in base a quanto si sono spostati gli elementi del tuo sito e all’impatto che il movimento ha portato al cliente. Google ritiene che qualsiasi valore inferiore a 0,1 sia “buono”, come puoi vedere in base ai criteri CLS di seguito:

Ovviamente, Google considera solo i movimenti imprevisti. Questo significa che se un acquirente fa clic sul menu e alcuni elementi della tua pagina si spostano, questo non influirà sul tuo punteggio CLS.

Per avere un buon punteggio CLS è importante anche la questione  delle immagini del prodotto. Molti sviluppatori dimenticano di specificare gli attributi di larghezza e lunghezza delle immagini, lasciando che sia il browser a decidere come devono apparire sullo schermo. Poiché la descrizione del prodotto di solito viene caricata prima delle immagini, gli acquirenti online iniziano a leggerla per primi. Tuttavia, non appena un’immagine viene caricata, spinge il testo in alto o in basso e interrompe il processo di lettura. Se specifichi le dimensioni dell’immagine tramite CSS o HTML, lo spazio per quell’immagine verrà riservato durante i tempi di caricamento e i clienti potranno navigare nel tuo sito senza interruzioni.

AMP e PWA

La cosa interessante del nuovo aggiornamento di Google è che l’ AMP non è più un requisito per essere incluso nella sezione Top Stories. A partire da maggio 2021, tutti i negozi online che soddisfano i criteri di Core Web Vitals sarebbero idonei ad entrare nella sezione.

Questa è una notizia molto interessante perché dimostra come Google stia davvero facendo il possibile per garantire un’ottima user experience. Questa è anche un’ottima notizia per tutti i siti Web PWA! Nel 2015, Google stesso ha introdotto la tecnologia PWA per creare siti con una migliore esperienza utente.

Ora con chiari vantaggi per gli utenti mobili e un approccio incentrato sull’utente, i negozi PWA hanno un’alta probabilità di vincere la battaglia contro AMP e siti tradizionali.

Vuoi strumenti utili per Core Web Vitals?

Molti strumenti sono già a portata di mano. Google si è assicurata che i proprietari dei siti dispongano di tutte le risorse necessarie per adattarsi ai nuovi cambiamenti. Ecco 6 modi essenziali per analizzare e migliorare il tuo sito su Core Web Vitals.

  • Speed Bhoost. Il nuovo tool di Bhoost che ti consente di verificare prestazioni, velocità e punti critici del tuo store.
  • Chrome UX Report. La nuovissima API di Chrome ti consente di controllare il rendimento del tuo sito negli ultimi 28 giorni.
  • Search Console. Utilizza il report Core Web Vitals per identificare le pagine che necessitano di miglioramenti.
  • PageSpeed ​​Insights. Un ottimo strumento per ottenere una rapida panoramica di tutti i punteggi di Core Web Vitals.
  • Lighthouse. Ottieni indicazioni pratiche su come ottimizzare le metriche di Core Web Vitals.
  • Chrome DevTools. Proprio come Lighthouse, lo strumento gratuito fornisce istruzioni su come migliorare i tuoi punteggi CWV.
  • Web Vitals Extension. Utilizza questa estensione di qualità per visualizzare le metriche chiave sull’esperienza utente per qualsiasi sito che visiti.

Conclusioni

I merchants quindi competeranno sulla velocità. Ma una cosa importante da ricordare è che questi cambiamenti non vengono introdotti per rendere il mondo online più competitivo. L’obiettivo di Core Web Vitals è migliorare l’esperienza online. Usa quindi queste metriche come indicatori per la buona riuscita del tuo store online.

La chiave del successo è cercare di fornire sempre le migliori esperienze online ai tuoi clienti.

Vuoi saperne di più?

Scarica subito gratuitamente il nostro e-book e scoprirai alcuni consigli che ti saranno molto utili per migliorare le performance del tuo sito.

banner-ebook-core-web-vitals

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 

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/

Il tempo di blocco totale (TBT) è una delle metriche monitorate nella sezione Prestazioni del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Il rapporto Lighthouse mostra TBT in millisecondi:

Cosa misura TBT

TBT misura la quantità totale di tempo in cui una pagina è bloccata dal rispondere all’input dell’utente, come clic del mouse, tocchi dello schermo o pressioni della tastiera. La somma viene calcolata sommando la parte di blocco di tutte le attività lunghe tra First Contentful Paint e Time to Interactive . Qualsiasi attività eseguita per più di 50 ms è un’attività lunga. La quantità di tempo dopo 50 ms è la parte di blocco. Ad esempio, se Lighthouse rileva un’attività di 70 ms, la porzione di blocco sarebbe di 20 ms.

In che modo Lighthouse determina il tuo punteggio TBT

Il tuo punteggio TBT è un confronto tra il tempo TBT della tua pagina e il TBT per milioni di siti reali caricati su dispositivi mobili. Consulta Come vengono determinati i punteggi delle metriche per sapere come vengono impostate le soglie del punteggio di Lighthouse.

Questa tabella mostra come interpretare il tuo punteggio TBT:

Tempo TBT

(in millisecondi)

Codificazione del colore
0–200 Verde (veloce)
200-600 Arancio (moderato)
Oltre 600 Rosso (lento)

Consulta il post sul punteggio delle prestazioni di Lighthouse per sapere come viene calcolato il punteggio delle prestazioni complessive della tua pagina.

Come migliorare il tuo punteggio TBT

Vedi Qual è la causa delle mie lunghe attività? per scoprire come diagnosticare la causa principale di attività lunghe con il pannello Prestazioni di Chrome DevTools.

In generale, le cause più comuni di compiti lunghi sono:

  • Caricamento, analisi o esecuzione JavaScript non necessari. Durante l’analisi del codice nel pannello Prestazioni, potresti scoprire che il thread principale sta eseguendo un lavoro che non è realmente necessario per caricare la pagina. La riduzione dei payload JavaScript con la suddivisione del codice , la rimozione del codice non utilizzato o il caricamento efficiente di JavaScript di terze parti dovrebbe migliorare il tuo punteggio TBT.
  • Dichiarazioni JavaScript inefficienti. Ad esempio, dopo aver analizzato il codice nel pannello Prestazioni, supponiamo di visualizzare una chiamata document.querySelectorAll(‘a’)che restituisce 2000 nodi. Il refactoring del codice per utilizzare un selettore più specifico che restituisce solo 10 nodi dovrebbe migliorare il punteggio TBT.

Il caricamento, l’analisi o l’esecuzione di JavaScript non necessari è solitamente un’opportunità molto più grande di miglioramento sulla maggior parte dei siti.

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-total-blocking-time/

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:

Tempo FID potenziale massimo

(in millisecondi)

Codificazione del colore
0–130 Verde (veloce)
130-250 Arancio (moderato)
Oltre 250 Rosso (lento)

 

 

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/

Time to Interactive (TTI) è una delle sei metriche monitorate nella sezione Performance del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

La misurazione del TTI è importante perché alcuni siti ottimizzano la visibilità dei contenuti a scapito dell’interattività. Questo può creare un’esperienza utente frustrante: il sito sembra essere pronto, ma quando l’utente tenta di interagire con esso, non succede nulla.

Il faro mostra il TTI in pochi secondi:

Cosa misura TTI

TTI misura quanto tempo impiega una pagina per diventare completamente interattiva. Una pagina è considerata completamente interattiva quando:

  • La pagina mostra contenuti utili, misurati dal First Contentful Paint ,
  • I gestori di eventi sono registrati per gli elementi della pagina più visibili e
  • La pagina risponde alle interazioni dell’utente entro 50 millisecondi.

Sia la prima CPU inattiva che il TTI misurano quando la pagina è pronta per l’input dell’utente. First CPU Idle si verifica quando l’utente può iniziare a interagire con la pagina; TTI si verifica quando l’utente è pienamente in grado di interagire con la pagina. 

In che modo Lighthouse determina il tuo punteggio TTI

Il punteggio TTI è un confronto tra il TTI della tua pagina e il TTI per i siti Web reali, basato sui dati dell’Archivio HTTP . Ad esempio, i siti con prestazioni nel novantanovesimo percentile rendono TTI in circa 2,2 secondi. Se il TTI del tuo sito web è di 2,2 secondi, il tuo punteggio TTI è 99.

Questa tabella mostra come interpretare il tuo punteggio TTI:

Metrica TTI

(in secondi)

Codificazione del colore
0–3,8 Verde (veloce)
3.9–7.3 Arancio (moderato)
Oltre 7.3 Rosso (lento)

 

Come migliorare il tuo punteggio TTI

Un miglioramento che può avere un effetto particolarmente importante su TTI è il rinvio o la rimozione del lavoro JavaScript non necessario. Cerca opportunità per ottimizzare il tuo JavaScript . In particolare, considera la possibilità di ridurre i payload JavaScript con la suddivisione del codice e l’applicazione del pattern PRPL . L’ottimizzazione di JavaScript di terze parti produce anche miglioramenti significativi per alcuni siti.

Questi due audit diagnostici offrono ulteriori opportunità per ridurre il lavoro su JavaScript:

  • Riduci al minimo il lavoro del thread principale
  • Riduci il tempo di esecuzione di JavaScript

Tracciamento di TTI sui dispositivi di utenti reali

Per informazioni su come misurare quando si verifica effettivamente il TTI sui dispositivi dei tuoi utenti, consulta la pagina sulle metriche delle prestazioni incentrate sull’utente di Google. La sezione Tracking TTI descrive come accedere in modo programmatico ai dati TTI e inviarli a Google Analytics.

TTI può essere difficile da rintracciare in natura. Il monitoraggio del primo ritardo di input può essere un buon proxy per TTI.

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/interactive/

Attenzione

La prima CPU inattiva è deprecata in Lighthouse 6.0. Mentre alcuni hanno scoperto che First CPU Idle offre una misurazione più significativa rispetto a Time To Interactive , la differenza non è abbastanza significativa da giustificare il mantenimento di due metriche simili. Andando avanti, considera invece l’utilizzo di Total Blocking Time e Time To Interactive .

La prima CPU inattiva è una delle sei metriche monitorate nella sezione Prestazioni del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Lighthouse mostra la prima CPU inattiva in pochi secondi:

Cosa misura la prima CPU inattiva #

La prima CPU inattiva misura quanto tempo impiega una pagina per diventare minimamente interattiva. Una pagina è considerata minimamente interattiva quando:

  • La maggior parte, ma non necessariamente tutti, gli elementi dell’interfaccia utente sullo schermo sono interattivi e
  • La pagina risponde, in media, alla maggior parte degli input degli utenti in un ragionevole lasso di tempo.

Sia First CPU Idle che Time to Interactive misurano quando la pagina è pronta per l’input dell’utente. First CPU Idle si verifica quando l’utente può iniziare a interagire con la pagina; TTI si verifica quando l’utente è pienamente in grado di interagire con la pagina. Vedi il primo interattivo e coerentemente interattivo di Google se sei interessato al calcolo esatto per ogni metrica.

In che modo Lighthouse determina il punteggio della prima CPU inattiva #

Il punteggio della prima CPU inattiva è un confronto tra il tempo di inattività della prima CPU della tua pagina e il tempo di inattività della prima CPU per i siti Web reali, in base ai dati dell’archivio HTTP . Ad esempio, i siti con prestazioni nel novantacinquesimo percentile rendono la prima CPU inattiva in circa 3 secondi. Se la prima CPU inattiva del tuo sito Web è di 3 secondi, il punteggio della prima CPU inattiva è 95.

Questa tabella mostra come interpretare il punteggio della prima CPU inattiva:

Prima metrica CPU inattiva

(in secondi)

Codificazione del colore Primo punteggio di inattività della CPU

(percentuale di archivio HTTP)

0–4,7 Verde (veloce) 75-100
4.8–6.5 Arancio (moderato) 50–74
Oltre 6,5 Rosso (lento) 0–49

Consulta il post sul punteggio delle prestazioni di Lighthouse per sapere come viene calcolato il punteggio delle prestazioni complessive della tua pagina.

Come migliorare il tuo punteggio di inattività della prima CPU #

Vedi Come migliorare il tuo punteggio TTI . Le strategie per migliorare l’inattività della prima CPU sono sostanzialmente le stesse delle strategie per migliorare il TTI.

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/first-cpu-idle/

Attenzione

La prima pittura significativa (FMP) è deprecata in Lighthouse 6.0. In pratica FMP è stato eccessivamente sensibile alle piccole differenze nel caricamento della pagina, portando a risultati incoerenti (bimodali). Inoltre, la definizione della metrica si basa su dettagli di implementazione specifici del browser, il che significa che non può essere standardizzata né implementata in tutti i browser web. Andando avanti, considera invece l’utilizzo di Largest Contentful Paint .

La prima pittura significativa (FMP) è una delle sei metriche monitorate nella sezione Prestazioni del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Il faro mostra FMP in pochi secondi:

Cosa misura FMP

FMP misura quando il contenuto principale di una pagina è visibile all’utente. Il punteggio grezzo per FMP è il tempo in secondi tra l’utente che avvia il caricamento della pagina e la pagina che esegue il rendering del contenuto above-the-fold principale. FMP mostra essenzialmente la tempistica della vernice dopo la quale si verifica il più grande cambiamento di layout above-the-fold. Scopri di più sui dettagli tecnici di FMP in Time to First Meaningful Paint di Google: un approccio basato sul layout .

First Contentful Paint (FCP) e FMP sono spesso gli stessi quando il primo contenuto visualizzato nella pagina include il contenuto above the fold. Tuttavia, queste metriche possono differire quando, ad esempio, sono presenti contenuti above the fold all’interno di un iframe. FMP si registra quando il contenuto all’interno dell’iframe è visibile all’utente, mentre FCP non include il contenuto dell’iframe.

In che modo Lighthouse determina il tuo punteggio FMP

Proprio come FCP, FMP si basa sui dati reali delle prestazioni del sito Web dall’archivio HTTP .

Quando FMP e FCP sono gli stessi, i loro punteggi sono identici. Se si verifica FMP dopo FCP, ad esempio quando una pagina contiene contenuto iframe, il punteggio FMP sarà inferiore al punteggio FCP.

Ad esempio, supponiamo che il tuo FCP sia di 1,5 secondi e il tuo FMP sia di 3 secondi. Il punteggio FCP sarebbe 99, ma il punteggio FMP sarebbe 75.

Questa tabella mostra come interpretare il tuo punteggio FMP:

Metrica FMP

(in secondi)

Codificazione del colore Punteggio FMP

(percentuale archivio HTTP FCP)

0–2 Verde (veloce) 75-100
2–4 Arancio (moderato) 50–74
Oltre 4 Rosso (lento) 0–49

Consulta il post sul punteggio delle prestazioni di Lighthouse per sapere come viene calcolato il punteggio delle prestazioni complessive della tua pagina.

Come migliorare il tuo punteggio FMP

Vedi Come migliorare la pittura di contenuto più grande sul tuo sito . Le strategie per migliorare FMP sono in gran parte le stesse strategie per migliorare Largest Contentful Paint.

Tracciamento FMP sui dispositivi di utenti reali

Per informazioni su come misurare quando si verifica effettivamente FMP sui dispositivi dei tuoi utenti, consulta la pagina delle metriche delle prestazioni incentrate sull’utente di Google. La sezione Tracking FMP using hero elements descrive come accedere a livello di codice ai dati FCP e inviarli a Google Analytics.

Per ulteriori informazioni sulla raccolta delle metriche degli utenti reali, consulta Google Valutazione delle prestazioni di caricamento nella vita reale con navigazione e tempistica delle risorse . I contrassegni e le misure di temporizzazione utente L’audit Lighthouse ti consente di visualizzare i dati di temporizzazione utente nel tuo rapporto.

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/first-meaningful-paint/

First Contentful Paint (FCP) è una delle sei metriche monitorate nella sezione Performance del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Il faro mostra FCP in pochi secondi:

Cosa misura FCP

FCP misura quanto tempo impiega il browser per eseguire il rendering del primo contenuto DOM dopo che un utente ha navigato sulla tua pagina. Immagini, elementi non bianchi <canvas>e SVG sulla tua pagina sono considerati contenuti DOM; nulla all’interno di un iframe non è incluso.

In che modo Lighthouse determina il tuo punteggio FCP

Il tuo punteggio FCP è un confronto tra il tempo FCP della tua pagina e i tempi FCP per siti Web reali, basato sui dati dell’archivio HTTP . Ad esempio, i siti con prestazioni nel novantanovesimo percentile rendono FCP in circa 1,2 secondi. Se l’FCP del tuo sito web è di 1,2 secondi, il tuo punteggio FCP è 99. Consulta Come vengono determinati i punteggi delle metriche per sapere come vengono impostate le soglie del punteggio di Lighthouse.

Questa tabella mostra come interpretare il tuo punteggio FCP:

Tempo FCP

(in secondi)

Codificazione del colore
0–1,8 Verde (veloce)
1.8–3 Arancio (moderato)
Oltre 3 Rosso (lento)

Consulta il post sul punteggio delle prestazioni di Lighthouse per sapere come viene calcolato il punteggio delle prestazioni complessive della tua pagina.

Come migliorare il tuo punteggio FCP

Un problema particolarmente importante per FCP è il tempo di caricamento dei caratteri. Dai un’occhiata alla sezione Assicurati che il testo rimanga visibile durante il caricamento del webfont per i modi per accelerare il caricamento dei font.

Tracciamento di FCP sui dispositivi di utenti reali

Per informazioni su come misurare quando si verifica effettivamente l’FCP sui dispositivi dei tuoi utenti, consulta la pagina sulle metriche delle prestazioni incentrate sull’utente di Google. La sezione Tracking FP/FCP descrive come accedere a livello di codice ai dati FCP e inviarli a Google Analytics.

Per ulteriori informazioni sulla raccolta delle metriche degli utenti reali, consulta Google Valutazione delle prestazioni di caricamento nella vita reale con navigazione e tempistica delle risorse .

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:

Consulta la pagina di destinazione Audit delle prestazioni per scoprire come affrontare le opportunità identificate nel rapporto Lighthouse.

Fonte / Source: https://web.dev/first-contentful-paint/

L’ indice di velocità è una delle sei metriche monitorate nella sezione Performance del rapporto Lighthouse. Ogni metrica cattura alcuni aspetti della velocità di caricamento della pagina.

Lighthouse mostra l’indice di velocità in pochi secondi:

Cosa misura l’indice di velocità

L’indice di velocità misura la velocità con cui il contenuto viene visualizzato visivamente durante il caricamento della pagina. Lighthouse acquisisce prima un video del caricamento della pagina nel browser e calcola la progressione visiva tra i fotogrammi. Lighthouse utilizza quindi il modulo Speedline Node.js per generare il punteggio dell’indice di velocità.

Speedline si basa sugli stessi principi dell’indice di velocità originale introdotto da WebpageTest.org .

In che modo Lighthouse determina il punteggio dell’indice di velocità

Il punteggio dell’indice di velocità è un confronto tra l’indice di velocità della tua pagina e gli indici di velocità di siti Web reali, basato sui dati dell’archivio HTTP .

Questa tabella mostra come interpretare il punteggio dell’indice di velocità mobile:

Indice di velocità

(in secondi)

Codificazione del colore
0–3,4 Verde (veloce)
3.4–5.8 Arancio (moderato)
Oltre 5.8 Rosso (lento)

Consulta il post sul punteggio delle prestazioni di Lighthouse per sapere come viene calcolato il punteggio delle prestazioni complessive della tua pagina.

Come migliorare il punteggio dell’indice di velocità

Sebbene qualsiasi cosa tu faccia per migliorare la velocità di caricamento della pagina migliorerà il tuo punteggio dell’indice di velocità, la risoluzione di eventuali problemi scoperti da questi audit diagnostici dovrebbe avere un impatto particolarmente grande:

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/speed-index/