In breve: Google cerca da sempre di offrire il miglior servizio per i propri utenti, in modo che continuino ad usare il suo motore di ricerca e quindi che Google resti il numero uno al mondo.

Core Web Vitals: cosa sono

A maggio 2020 sono stati introdotti i famosi Core Web Vitals, una serie di parametri per valutare quella che viene definita "Esperienza Utente". A parte il contenuto della pagina e altre informazioni che sono ovviamente importanti (termini di ricerca, se cerco "samsung" Google mi va a mostrare contenuti inerenti a quella ricerca), anche questi parametri diventano fattore di ranking ovvero una volta che Google stabilisce i risultati pertinenti ad una determinata ricerca, nell'ordinamento (ranking) viene tenuto conto dei Core Web Vitals, sia mobile sia desktop, oggi sempre di più!

In particolare, abbiamo:

  • LCP: Largest Contentful Paint (velocità di caricamento del contenuto principale della pagina)
  • FID: First Input Delay (prima risposta di interattività della pagina), sostituito da INP a marzo 2024
  • INP: Interaction to Next Paint (reattività della pagina, come la pagina si carica in modo veloce e fluido sulla base delle interazioni con gli utenti)
  • CLS: Cumulative Layout Shift (stabilità visiva, fastidiosissimo quando clicchi, poi la struttura della pagina cambia e ti fa cliccare dove non volevi)

Questi vengono definiti segnali web essenziali. Ovviamente poi altri parametri importanti sono la presenza di HTTPS (dai, oggi è d'obbligo), ottimizzazione mobile, assenza di annunci invasivi (banner pubblicitari AdSense, popup di vario tipo... Non siamo più negli anni 90, lasciamo perdere queste porcherie di programmazione).

Core Web Vitals: quindi perché cambiano nel tempo?

Arriviamo al punto: i valori dei Core Web Vitals possono cambiare nel tempo. Si intende, senza modifiche al codice o del server, ovvio :) Il servizio di Google, Page Speed Insights consente di analizzare un sito web, velocità mobile e desktop (esistono poi tutta una serie di altri servizi, pregi e difetti, qui occorre almeno una discussione a parte); sono compresi anche questi famosi Core Web Vitals. In particolare:

  • differenza mobile / desktop (devo spiegare cosa significa? ahah)
  • this URL / origin: sia per mobile che desktop, "this URL" indica l'URL esatto (esempio, Hompepage o altra pagina) mentre "origin" indica i valori di tutto il dominio (possono essere anche molto diversi, ad esempio in genere l'Homepage carica di più dati, immagini ecc è più pesante)

Per quale motivo i Core Web Vitals cambiano nel tempo? Nel corso del tempo, un sito web viene visitato da più utenti diversi, con dispositivi diversi, connessione diversa (negli anni, si spera migliore, ma nel medio-breve periodo ovviamente è piuttosto random); i loro valori di "esperienza utente" raccolti da Google, quindi saranno in genere diversi.

Poi per quanto riguarda Google Lighthouse e Page Speed Insights, abbiamo la distinzione fra "Field Data" (dati raccolti dagli utenti che visitano il sito web) e "Lab Data" (dati simulati da Google, es. smartphone con velocità di connessione 3G, solitamente valori sempre più scadenti rispetto ai reali visitatori); anche in questo secondo caso, nella simulazione c'è una variabilità random (appunto per simulare la possibilità di avere utenti di tipo diverso).

Anche a parità di condizioni, il server in quel momento potrebbe essere un po' sovraccarico, o comunque la risposta non sarà mai precisa al millisecondo, quindi anche questa è un'altra variabilità random (con Page Speed Insights, misuro i valori adesso e fra qualche minuto, posso ottenere dei risultati un pochino differenti; l'ideale è sempre fare una media, in realtà anche combinando altri strumenti, che vedremo in futuro in un'altra discussione).

NB: i valori reali per il proprio sito web, conviene guardarli all'interno di Google Search Console! Per siti web di altre proprietà, questi strumenti "pubblici" vanno bene per avere un'idea di base.

La cosa fondamentale di tutto ciò, comunque è capire nonostante tutto l'importanza dei Core Web Vitals, avere un sito web veloce, con stabilità visuale, ovviamente sicuro (HTTPS) e senza annunci fastidiosi, è sempre più importante ed è già fattore di ranking piuttosto rilevante.

Curiosità: SearchEngineJournal riporta una ciriosità interessante, ovvero: <<Google Claims Core Web Vitals Saved Over 10,000 Years In Load Times>>. Ottimizzare i Core Web Vitals, visto l'enorme numero di siti web che vengono visitati globalmente dalle persone, consentirebbe in un anno di risparmiare circa 10.000 anni in termini di tempo di caricamento complessivo. Un dato che lascia stupidi.

In conclusione, ci si augura che le persone, webmaster, capiscano l'importanza dei Core Web Vitals, tempo di caricamento ma non solo, in modo da poter offrire agli utenti un servizio sempre migliore.

Approfondimenti:
differenza Core Web Vitals fra Page Speed Insights e Search Console
Web Vitals - web.dev
Esperienza Pagine di Google - developers.google.com
Core Web Vitals Score Change - searchenginejournal.com

    Giulio_M Interessante ( soprattutto i " contenuti " del secodo link). 👌

      Vladimir certo, è Google stessa che fornisce le indicazioni da seguire, dato che ha tutto l'interesse nel migliorare la qualità dei risultati di ricerca, per i propri stessi utenti.

      2 anni dopo

      Core Web Vitals a fine 2023: il punto per il 2024

      Da SearchEngineJournal vediamo i risultati di uno studio, come sono cambiati i siti web nel corso del 2023, per seguire i Core Web Vitals (fattori di ranking per Google, dato che velocità di caricamento, stabilità visuale ecc, sono positive per l'esperienza utente). Nel corso dell'ultimo anno (quindi da fine 2022 a fine 2023) è risultato un +8,13% dei siti web che hanno superato i Core Web Vitals, dato mobile e +8,25% per l'ambito desktop. In particolare i dati si concentrano su siti web creati con WordPress, il CMS enormemente più diffuso.

      Facciamo queste considerazioni:

      • a livello generale, se molti siti web migliorano lato User Experience (in particolare LCP, la velocità di caricamento) è una cosa positiva per l'uso generale e la "qualità" di internet, troppi siti web erano/sono scarsamente ottimizzati quando basterebbero piccoli accorgimenti (vedi ad esempio ottimizzazione delle immagini)
      • i Core Web Vitals, superati o non superati, sono in termini percentuali (miglior 25%, peggior 25%, ecc). Quindi attenzione, se tutti migliorano, in proporzione anche noi dobbiamo cercare di migliorare; ricordiamo che la SEO è "un gioco a somma zero" (se tu migliori rispetto a me, significa che io peggioro rispetto a te! Quindi uno vince e l'altro perde)
      • come già detto nella discussione Page Speed Insights: nuove metriche per la UX, a marzo 2024 il parametro FID (First Input Delay) dei Core Web Vitals verrà sostituito da INP (Interaction to Next Paint), per valutare la reattività della pagina alle interazioni dell'utente piuttosto che valutare solo la prima interazione
      un anno dopo

      Ottimizzazione LCP: i consigli nel 2025

      Come abbiamo visto l'elemento LCP, il Largest Contentful Paint indica la velocità di caricamento del contenuto principale della pagina e diciamo che assume maggior peso in termini di "velocità di navigazione". I Core Web Vitals vengono misurati con una stima tramite Google Page Speed Insights (LCP, CLS, FID INP, quest'ultimo da marzo 2024) e dati reali degli utenti dal proprio pannello in Search Console. Vediamo i nuovi consigli di ottimizzazione relativamente a LCP, da searchengineland.com:

      • speculation rules: il concetto è quello di precaricare in una pagina, altre pagine; ad esempio dalla Home posso precaricare la pagina "contatti" oppure "offerte", se penso che molto probabilmente verranno visitate quelle pagine; da valutare con attenzione se e quando convenga precaricarla o meno (concetto simile a preload, anche se quest'ultimo riguarda risorse da caricare nella stessa pagina, senza preload la pagina inizia a caricarsi e poi un elemento alla volta a seconda della dimensione, con il preload attendi all'inizio e si carica tutto assieme, pro e contro); il template di codice per speculation rules è il seguente:
        <script type="speculationrules">
         {
           "prerender": [
             {
               "urls": ["/", "/signup"]
             }
           ]
         }
        </script>
      • ottimizzare LCP con i dati reali degli utenti: infatti Page Speed Insights così come altri strumenti, vanno bene per studiare i competitor o per avere un'idea generale; ovviamente la scelta migliore per il nostro dominio è quella di vedere i dati reali dei nostri utenti (e non una semplice stima con dati medi, di laboratorio!), tramite Search Console; il dato di LCP può variare molto fra desktop e mobile, connessione, dimensione dello schermo, ecc
      • identificare componenti di LCP: il risultato totale di LCP è dato dalla somma delle componenti: Time to First Byte: (risposta del server), Resource Load Delay (identificazione elemento chiave per l'LCP, es. immagine principale), Resource Load Time (tempo per scaricare l'elemento chiave), Render Delay (tempo per il rendering dopo che il download dell'elemento è completato); quindi studiare le varie componenti ci permette di capire quale sia la criticità su cui conviene intervenire
      • preload dell'elemento (es. immagine) critico per LCP: come accennato nel primo punto, differenza fra speculation rules e preload, dobbiamo valutare se valga la pena o meno; ad esempio possiamo precaricare un'immagine e quindi ad esempio script esterni JavaScript (per l'interazione dinamica con la pagina) avranno caricamento traslato nel tempo (analogamente, anche il Lazy Loading per differire il caricamento di elementi non critici, non "above-the-fold"); appunto valutiamo se convenga o meno e possiamo anche usare l'attributo fetchpriority: <img src="immagine.jpg" fetchpriority="high">; di fondamentale importanza ovviamente l'ottimizzazione delle immagini per la SEO
      • continuare a monitorare i risultati: ovviamente, trattandosi di dati reali degli utenti, anche se non facciamo modifiche è opportuno continuare a monitorare (problemi, criticità o anche idee di ottimizzazione ci possono venire in mente in futuro); inoltre i Core Web Vitals con "green", "yellow", "red" per indicare il risultato buono, migliorabile o scadente, si basano non su dati assoluti ma in relazione al totale degli utenti, quindi percentile migliore, percentile peggiore, ecc. Se nel tempo gli altri siti web evolvono, si adattano, così come i dispositivi e connessione degli utenti, anche le nostre percentuali in relazione al totale possono cambiare

      Powered by: FreeFlarum.
      (remove this footer)