Misurazione e ottimizzazione per Google Core Web Vitals: una guida tecnica SEO

La raccolta di dati sulle prestazioni del tuo sito è il primo passo verso l'offerta di un'ottima esperienza utente. Nel corso degli anni, Google ha fornito vari strumenti per valutare e generare report sulle prestazioni web.

Tra questi ci sono i Core Web Vitals, un insieme di indicatori di performance che Google ritiene fondamentali per tutte le esperienze web.

Questo articolo copre l'attuale serie di Core Web Vitals e suggerimenti e strumenti chiave per migliorare le prestazioni web e offrire agli utenti una buona esperienza sulla pagina.

Uno sguardo all'evoluzione delle web performance

Sono finiti i giorni in cui migliorare le prestazioni del sito era semplice.

In passato, le risorse eccessive e le connessioni lente spesso bloccavano i siti web. Ma potresti superare la concorrenza comprimendo alcune immagini, abilitando la compressione del testo o minimizzando i tuoi fogli di stile e moduli JavaScript.

Oggi le velocità di connessione sono più elevate. La maggior parte delle risorse sono compresse per impostazione predefinita e molti plugin gestiscono la compressione delle immagini, l'implementazione della cache, ecc.

La ricerca di Google per un web più veloce persiste. PageSpeed ​​Insights (PSI) è ancora attivo su web.dev e funge da strumento migliore per valutare i caricamenti delle singole pagine.

Anche se molti ritengono che le valutazioni PSI siano inutilmente punitive, è comunque la cosa più vicina a come Google potrebbe pesare e classificare i siti tramite segnali di velocità della pagina.

Per superare l'ultima iterazione del test di velocità della pagina di Google, dovrai soddisfare il Core Web Vitals Assessment.

Comprendere i Core Web Vitals

I Core Web Vitals sono un insieme di metriche integrate nei segnali di ricerca più ampi sull'esperienza della pagina introdotti nel 2021. Ogni metrica "rappresenta un aspetto distinto dell'esperienza utente, è misurabile sul campo e riflette l'esperienza nel mondo reale di un utente critico". risultato centrato”, secondo Google.

L'attuale serie di metriche Core Web Vitals include:

• Prima pittura ricca di contenuti
• Primo ritardo di ingresso (da sostituire con l'interazione con la pittura successiva)
• Interazione con la vernice successiva
• Tempo al primo byte
• La più grande vernice contenuta
• Spostamento cumulativo del layout

Web.dev spiega come funziona ciascuna metrica come segue.

Primo Contentful Paint (FCP)

“La metrica First Contentful Paint (FCP) misura il tempo da quando la pagina inizia a caricarsi a quando qualsiasi parte del contenuto della pagina viene visualizzata sullo schermo. Per questa metrica, "contenuto" si riferisce a testo, immagini (comprese le immagini di sfondo), elementi <svg> o elementi <canvas> non bianchi.

Cosa significa questo per i SEO tecnici

FCP è abbastanza facile da capire. Quando una pagina web viene caricata, alcuni elementi arrivano (o “vengono dipinti”) prima di altri. In questo contesto, “pittura” significa rendering sullo schermo.

Una volta che una qualsiasi parte della pagina è stata renderizzata – diciamo che la barra di navigazione principale viene caricata prima degli altri elementi – l'FCP verrà registrato a quel punto.

Consideralo come la velocità con cui la pagina inizia a caricarsi visibilmente per gli utenti. Il caricamento della pagina non sarà completo, ma sarà iniziato.

Ritardo primo ingresso (FID)

"Il FID misura il tempo che intercorre da quando un utente interagisce per la prima volta con una pagina (ovvero, quando fa clic su un collegamento, tocca un pulsante o utilizza un controllo personalizzato basato su JavaScript) al momento in cui il browser è effettivamente in grado di iniziare elaborazione dei gestori di eventi in risposta a tale interazione.

Cosa significa questo per i SEO tecnici

FID è una metrica di reattività dell'interazione dell'utente che verrà sostituita da Interaction to Next Paint (INP) a marzo 2024.

Se un utente interagisce con un elemento della pagina (ad esempio un collegamento, l'ordinamento di una tabella o l'applicazione della navigazione a faccette), quanto tempo impiega il sito per iniziare a elaborare tale richiesta?

Interazione con Paint successivo (INP)

“INP è una metrica che valuta la reattività complessiva di una pagina alle interazioni dell'utente osservando la latenza di tutti i clic, i tocchi e le interazioni con la tastiera che si verificano durante la visita di un utente a una pagina. Il valore INP finale è l’interazione più lunga osservata, ignorando i valori anomali”.

Cosa significa questo per i SEO tecnici

Come accennato, INP sostituirà FID come Core Web Vital nel marzo 2024.

INP tiene conto di informazioni più profonde (apparentemente risalenti alla tastiera) ed è probabilmente più dettagliato e sofisticato.

Tempo al primo byte (TTFB)

“TTFB è una metrica che misura il tempo che intercorre tra la richiesta di una risorsa e il momento in cui inizia ad arrivare il primo byte di una risposta.”

Cosa significa questo per i SEO tecnici

Una volta richiesta una "risorsa" (ad esempio un'immagine incorporata, un modulo JavaScript, un foglio di stile CSS, ecc.), quanto tempo occorrerà al sito per iniziare a fornire tale risorsa?

Supponiamo che tu visiti una pagina Web e in quella pagina sia presente un'immagine incorporata. Inizia a caricarsi ma non ha ancora finito di caricarsi. Quanto tempo ci vuole prima che il primo byte di quell'immagine venga consegnato dal server al client (browser web)?

Pittura con contenuto più grande (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 la pagina ha iniziato a caricarsi."

Cosa significa questo per i SEO tecnici

LCP è uno dei parametri più importanti ma anche il più difficile da soddisfare.

Una volta caricata la porzione più grande di media visivi (ad esempio testo o immagine), viene registrato l'LCP.

Puoi leggerlo come: quanto tempo impiega il caricamento della maggior parte dei contenuti principali di una pagina?

Forse ci sono ancora piccoli frammenti che vengono caricati più in basso nella pagina e cose che la maggior parte degli utenti non noterà.

Ma, nel momento in cui viene registrato l'LCP, la parte ampia ed evidente della tua pagina è stata caricata. Se ciò richiede troppo tempo, fallirai il controllo LCP.

Spostamento cumulativo del layout (CLS)

“Il CLS misura il più grande incremento di punteggi di spostamento del layout per ogni spostamento di layout inaspettato che si verifica durante l’intera durata di vita di una pagina.

Uno spostamento del layout si verifica ogni volta che un elemento visibile cambia la sua posizione da un fotogramma sottoposto a rendering a quello successivo. (Vedi di seguito per i dettagli su come vengono calcolati i punteggi dei turni di layout individuali.)

Un'esplosione di turni di layout, nota come finestra di sessione, si verifica quando uno o più turni di layout individuali si verificano in rapida successione con meno di 1 secondo tra ogni turno e un massimo di 5 secondi per la durata totale della finestra.

Il burst più grande è la finestra della sessione con il punteggio cumulativo massimo di tutti i cambiamenti di layout all'interno di quella finestra."

Cosa significa questo per i SEO tecnici

In passato, quando l'ottimizzazione della velocità della pagina era più semplice, molti proprietari di siti si sono resi conto che potevano ottenere valutazioni di velocità della pagina incredibilmente elevate semplicemente rinviando tutte le risorse di blocco della visualizzazione (comunemente fogli CSS e moduli JavaScript).

Questo è stato ottimo per accelerare il caricamento delle pagine, ma ha reso il Web un'esperienza di navigazione più glitch e fastidiosa.

Se il tuo CSS, che controlla tutto lo stile della tua pagina, viene posticipato, i contenuti della pagina possono essere caricati prima che vengano applicate le regole CSS.

Ciò significa che i contenuti della tua pagina verranno caricati senza stile e poi salteranno leggermente durante il caricamento del CSS.

Questo è davvero fastidioso se carichi una pagina e fai clic su un collegamento, ma poi il collegamento salta e fai clic sul collegamento sbagliato.

Se sei un po' affetto da disturbo ossessivo compulsivo come me, tali esperienze sono assolutamente esasperanti (anche se costano solo pochi secondi di tempo).

Dato che i proprietari dei siti tentavano di “giocare” con le valutazioni della velocità della pagina rinviando tutte le risorse, Google aveva bisogno di una contrometrica, che compensasse tutti i guadagni di velocità della pagina con il deficit di esperienza dell’utente.

Inserisci lo spostamento cumulativo del layout (CLS). Questo è un cliente complicato, che è pronto a rovinarti la giornata se provi ad applicare aumenti di velocità della pagina a grandi linee senza pensare ai tuoi utenti.

CLS analizzerà sostanzialmente i caricamenti delle tue pagine per individuare spostamenti difettosi e regole CSS ritardate.

Se ce ne sono troppi, non supererai la valutazione Core Web Vitals nonostante tu abbia soddisfatto tutti i parametri relativi alla velocità.

Valutare i tuoi Core Web Vitals per ottenere risultati UX e SEO migliori

Uno dei modi migliori per analizzare le prestazioni di una singola pagina web è caricarla in PageSpeed ​​Insights. La vista è suddivisa in una combinazione di:

• Dati a livello di URL.
• Dati di origine (a livello di dominio).
• Dati di laboratorio.
• Campo dati.

Per capirlo dobbiamo fare un esempio:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Qui possiamo vedere le valutazioni e le metriche della velocità della pagina per la home page di TechCrunch.

Sopra puoi vedere che il Core Web Vitals Assessment non è riuscito.

In un Web mobile-first, è importante selezionare la scheda Risultati per dispositivi mobili , che dovrebbe essere visualizzata per impostazione predefinita (questi sono i risultati che contano davvero).

Seleziona l'interruttore Origin in modo da visualizzare la media dei dati generali nel dominio del tuo sito anziché solo nella home page (o in qualsiasi pagina inserita per la scansione).

Più in basso nella pagina, vedrai la vecchia e familiare valutazione numerica della velocità della pagina:

Quindi, qual è la differenza tra la nuova valutazione Core Web Vitals e la vecchia valutazione della velocità della pagina?

Essenzialmente, la nuova valutazione Core Web Vitals (Pass/Fail) si basa su dati sul campo (utenti reali).

La vecchia valutazione numerica si basa su scansioni mobili simulate e dati di laboratorio, che sono solo stime.

In sostanza, Google è passato alla valutazione Core Web Vitals in termini di modifica delle classifiche di ricerca.

Per essere chiari, i dati di laboratorio simulati possono fornire una bella ripartizione in termini di cosa non va, ma Google non utilizza quella valutazione numerica nei propri algoritmi di classificazione.

Al contrario, la valutazione Core Web Vitals non offre molte informazioni granulari. Tuttavia, questa valutazione viene presa in considerazione negli algoritmi di ranking di Google.

Pertanto, il tuo obiettivo principale è utilizzare la diagnostica di laboratorio più completa in modo da superare eventualmente la valutazione Core Web Vitals (derivata tramite dati sul campo).

Ricorda che quando apporti modifiche al tuo sito, mentre la valutazione numerica può immediatamente osservare le modifiche, dovrai attendere che Google estragga più dati dal campo prima di poter eventualmente superare la valutazione Core Web Vitals.

Noterai che sia la valutazione Core Web Vitals che la vecchia valutazione della velocità della pagina utilizzano alcune delle stesse metriche.

Ad esempio, entrambi fanno riferimento al First Contentful Paint (FCP), al Largest Contentful Paint (LCP) e al Cumulative Layout Shift (CLS).

In un certo senso, i tipi di parametri esaminati da ciascun sistema di rating sono abbastanza simili. Ciò che è diverso è il livello di dettaglio e la fonte dei dati esaminati.

È necessario mirare a superare la valutazione Core Web Vitals sul campo. Tuttavia, poiché i dati non sono troppo ricchi, potresti voler sfruttare i tradizionali dati di laboratorio e la diagnostica per progredire.

La speranza è che tu possa superare la valutazione Core Web Vitals affrontando le opportunità e la diagnostica del laboratorio. Ma ricorda, questi due test non sono intrinsecamente collegati.

Valutazione dei tuoi CWV tramite PageSpeed ​​Insights

Ora che conosci i principali parametri Core Web Vitals e come possono essere tecnicamente soddisfatti, è il momento di fare un esempio.

Torniamo al nostro esame di TechCrunch:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

In questo caso, il FID è soddisfatto e l’INP fallisce solo con un margine ristretto.

CLS ha alcuni problemi, ma i problemi principali riguardano LCP e FCP.

Vediamo cosa ha da dire PageSpeed ​​Insights in termini di opportunità e diagnostica .

Dobbiamo ora passare dai dati sul campo ai dati di laboratorio e tentare di isolare eventuali modelli che potrebbero influire sui Core Web Vitals:

Sopra, puoi vedere una piccola navigazione secondaria nell'angolo in alto a destra riquadrata in verde.

Puoi utilizzarlo per restringere le diverse opportunità e la diagnostica a determinate metriche Core Web Vitals.

In questo caso, però, i dati raccontano una storia molto chiara senza restringere il campo.

Innanzitutto, ci viene detto di ridurre i JavaScript inutilizzati. Ciò significa che a volte JavaScript viene caricato senza essere eseguito.

Ci sono anche note per ridurre i CSS inutilizzati. In altre parole, vengono caricati alcuni stili CSS che non vengono applicati (problema simile).

Ci viene anche detto di eliminare le risorse che bloccano la visualizzazione, che sono quasi sempre correlate a moduli JavaScript e fogli CSS.

Le risorse di blocco del rendering devono essere rinviate per impedire loro di bloccare il caricamento di una pagina. Tuttavia, come abbiamo già esplorato, ciò potrebbe alterare il rating CLS.

Per questo motivo, sarebbe saggio iniziare a creare sia un percorso di rendering CSS critico che un percorso di rendering JavaScript critico. In questo modo inlineerai JavaScript e CSS necessari Above the Fold rinviando il resto.

Questo approccio consente al proprietario del sito di soddisfare le richieste di caricamento della pagina bilanciandosi con la metrica CLS. Non è una cosa facile da fare e di solito richiede uno sviluppatore web senior.

Poiché abbiamo trovato anche CSS e JavaScript inutilizzati, possiamo anche eseguire un controllo generale del codice JavaScript per vedere se JavaScript può essere distribuito in modo più intelligente.

Torniamo a Opportunità e Diagnostica :

Ora vogliamo concentrarci sulla diagnostica. Google limita deliberatamente questi controlli a causa di connessioni 4G scadenti, quindi elementi come il lavoro del thread principale sembrano così lunghi (17 secondi).

Ciò è deliberato per soddisfare gli utenti con larghezza di banda ridotta e/o dispositivi lenti comuni in tutto il mondo.

Voglio attirare la tua attenzione qui su "Ridurre al minimo il lavoro del thread principale". Questa singola voce è spesso una miniera d'oro di approfondimenti.

Per impostazione predefinita, la maggior parte delle attività di rendering ed esecuzione di script (JavaScript) di una pagina Web vengono inviate tramite il thread di elaborazione principale del browser Web del client (un singolo thread di elaborazione). Puoi capire come ciò causi colli di bottiglia significativi nel caricamento della pagina.

Anche se tutto il tuo JavaScript è perfettamente minimizzato e inviato rapidamente al browser dell'utente, deve attendere in una coda di elaborazione a thread singolo per impostazione predefinita, il che significa che è possibile eseguire un solo script alla volta.

Pertanto, inviare rapidamente carichi di JavaScript al tuo utente equivale a sparare con una manichetta antincendio contro un muro di mattoni con uno spazio di un centimetro.

Ottimo lavoro, ma non tutto andrà a buon fine!

Google sta spingendo sempre di più la reattività della velocità lato client come nostra responsabilità. Piaccia o no, ecco com'è (quindi faresti meglio a familiarizzarti).

Potresti dire con frustrazione: “Perché è così!? I browser Web hanno avuto accesso a più thread di elaborazione per anni, anche i browser mobili hanno recuperato terreno. Non c'è bisogno che le cose siano così imbarazzanti, vero?"

Attualmente si. Alcuni script si basano sull'output di altri script prima di poter essere eseguiti.

Con ogni probabilità, se tutti i browser iniziassero improvvisamente a elaborare tutti i JavaScript in parallelo, fuori sequenza, la maggior parte del web probabilmente si bloccherebbe e brucerebbe.

Quindi, c'è una buona ragione per cui l'esecuzione sequenziale degli script è il comportamento predefinito per i browser Web moderni. Continuo a sottolineare la parola “default”. Perché?

È perché ci sono altre opzioni. Il primo è impedire al browser del client di elaborare eventuali script elaborandoli per conto dell'utente. Questo è noto come rendering lato server (SSR).

È uno strumento potente per districare i nodi di esecuzione JavaScript lato client ma anche molto costoso.

Il tuo server deve elaborare tutte le richieste di script (da tutti gli utenti) più velocemente di quanto il browser dell'utente medio elabori un singolo script. Lascia che quello affondi per un momento.

Non sei un fan di questa opzione? OK, esploriamo la parallelizzazione di JavaScript. L'idea di base è quella di sfruttare i web work per definire quali script verranno caricati in sequenza rispetto a quali potrebbero essere caricati in parallelo.

Sebbene sia possibile forzare il caricamento di JavaScript in parallelo, farlo per impostazione predefinita è estremamente sconsigliabile. L’integrazione di una tecnologia come questa attenuerebbe ampiamente la necessità di SSR nella maggior parte dei casi.

Tuttavia, sarà molto complicato da implementare e richiederà (avete indovinato!) il tempo di uno sviluppatore web senior.

Lo stesso ragazzo che assumi per eseguire la verifica completa del codice JavaScript potrebbe essere in grado di aiutarti anche in questo. Se combini la parallelizzazione JavaScript con un percorso di rendering JavaScript critico, allora stai davvero volando.

In questo esempio, ecco la cosa davvero interessante:

Puoi immediatamente vedere che mentre il thread principale è occupato per 17 secondi, l'esecuzione di JavaScript dura 12 secondi.

Ciò significa che 12 secondi dei 17 secondi di lavoro del thread sono esecuzione JavaScript? Questo è altamente probabile.

Sappiamo che tutto il JavaScript viene inviato attraverso il thread principale per impostazione predefinita.

WordPress, il CMS attivo, è impostato di default così.

Dato che su questo sito è in esecuzione WordPress, tutti quei 12 secondi di tempo di esecuzione di JavaScript probabilmente derivano dai 17 secondi di lavoro del thread principale.

Si tratta di un'ottima intuizione perché ci dice che la maggior parte del tempo del thread di elaborazione principale viene impiegato nell'esecuzione di JavaScript. E guardando il numero di script citati, non è difficile da credere.

Portare la crociata verso Chrome Dev Tools

È ora di diventare tecnici e rimuovere le ruote da allenamento.

Apri una nuova istanza di Chrome. Dovresti aprire un profilo ospite per assicurarti che non ci siano confusione o plugin abilitati a gonfiare i nostri risultati.

Ricorda: esegui queste azioni da un profilo Chrome ospite pulito.

Carica il sito che desideri analizzare. Nel nostro caso, è TechCrunch.

Accetta i cookie secondo necessità. Una volta caricata la pagina, apri Chrome DevTools (fai clic con il pulsante destro del mouse su una pagina e seleziona Ispeziona ).

Passare a Prestazioni > Schermate.

Premi il pulsante di ricarica per registrare il caricamento della pagina. Verrà quindi generato un report:

È qui che dobbiamo tutti fare un respiro profondo e cercare di non farci prendere dal panico.

Sopra, in un riquadro verde, puoi vedere un sottile riquadro che illustra le richieste nel tempo.

All'interno di questa casella puoi trascinare il mouse per selezionare un intervallo di tempo e il resto della pagina e l'analisi si adatteranno automaticamente.

La regione che ho selezionato manualmente è l'area coperta da un riquadro blu semitrasparente.

È qui che avviene il caricamento della pagina principale e ciò che mi interessa esaminare.

In questo caso, ho selezionato approssimativamente l'intervallo di tempo ed eventi compreso tra 32 ms e 2,97 secondi. Concentriamo lo sguardo sull'interno del filo conduttore:

Sai come prima stavo dicendo che la maggior parte delle attività di rendering e delle esecuzioni JavaScript sono costrette a superare il collo di bottiglia del thread principale?

Bene, ora stiamo esaminando l'interno di quel thread principale nel tempo. E sì, in giallo puoi vedere molte attività di scripting.

Nelle prime due righe, col passare del tempo, ci sono sempre più blocchi giallo scuro che confermano tutti gli script in esecuzione e il tempo necessario per l'elaborazione. È possibile fare clic sui singoli blocchi della barra per ottenere una lettura per ciascun elemento.

Sebbene si tratti di un'immagine potente, ne troverai una più potente nella sezione Riepilogo :

Questo riassume tutti i dati granulari, suddivisi in semplici sezioni tematiche (ad esempio, Scripting , Caricamento , Rendering ) tramite il mezzo visivo facile da digerire di un grafico a ciambella.

Come puoi vedere, lo scripting (esecuzione dello script) assorbe la maggior parte del caricamento della pagina. Quindi, la nostra precedente supposizione basata sul mix di dati sul campo e di laboratorio di Google, che puntava il dito contro i colli di bottiglia nell'esecuzione di JavaScript nel thread principale, sembra essere stata accurata.

Nel 2023, questo è uno dei problemi più diffusi, con poche soluzioni semplici e pronte all’uso.

È complesso creare percorsi di rendering JavaScript critici. Ci vuole esperienza per eseguire controlli del codice JavaScript e non è così semplice adottare la parallelizzazione JavaScript o SSR.

Andiamo ora a guardare il Call Tree :

Call Tree è spesso più utile di Bottom-Up .

I dati sono simili, ma Call Tree raggrupperà tematicamente le attività in pratici contenitori come Evaluate Script (esecuzione di script).

È quindi possibile fare clic su un gruppo, espanderlo e vedere gli script e quanto tempo hanno impiegato per caricarsi. L'11% delle volte è stato impiegato per caricare pubads_impl.jsm mentre il 6% delle volte è stato impiegato per caricare opus.js .

Non so cosa siano questi moduli (e potresti non saperlo nemmeno tu), ma è qui che spesso inizia il percorso di ottimizzazione.

Possiamo ora fare un passo indietro:

• Google questi script e vedi se fanno parte di librerie di terze parti, cosa fanno e qual è l'impatto.
• Consultare lo sviluppatore per informazioni su come questi potrebbero essere distribuiti in modo più intelligente.
• Restringere il problema alle risorse individuali e cercare alternative.
• Affrontare il deficit di prestazioni (o, in alternativa, lottare per maggiori risorse/larghezza di banda, un ambiente di hosting forte, se ciò è effettivamente necessario).

Altri strumenti per la misurazione e l'ottimizzazione dei Core Web Vitals

Se sei riuscito a restare con me fino ad ora, congratulazioni. In termini di Core Web Vitals e analisi della velocità della pagina, abbiamo utilizzato solo:

• PageSpeed ​​Insights
• Chrome DevTools (scheda Prestazioni )

Sì, puoi davvero essere così magro. Tuttavia, ci sono altri strumenti che potrebbero esserti di grande aiuto:

• GTMetrix : particolarmente utile per il suo grafico a cascata (richiede un account gratuito per cascata), che puoi imparare a leggere qui. Non dimenticare che GTMetrix funzionerà senza limitazioni per impostazione predefinita, fornendo risultati eccessivamente favorevoli. Assicurati di impostarlo su una connessione LTE.
• Google Search Console : se imposti questa opzione e verifichi il tuo sito, puoi visualizzare molti dati sulle prestazioni e sull'usabilità nel tempo, incluse le metriche Core Web Vitals su più pagine (aggregate).
• Screaming Frog SEO Spider : può essere collegato all'API page speed, per consentire il recupero in blocco dei voti Core Web Vitals Pass o Fail (per più pagine). Se stai utilizzando l'API gratuita per la velocità della pagina, non martellarla in modo irragionevole

In passato, migliorare la valutazione della velocità della pagina era semplice come comprimere e caricare alcune immagini.

Al giorno d'oggi? È una complessa crociata sui Core Web Vitals.

Preparati a impegnarti pienamente. Qualunque cosa di meno andrà incontro al fallimento.