La raccolta di dati relativi ai Segnali web del tuo sito è il primo passo per migliorarli. Un'analisi a tutto tondo raccoglierà dati sulle prestazioni sia da ambienti reali che da laboratorio. La misurazione di Web Vitals richiede modifiche minime al codice e può essere eseguita utilizzando strumenti senza costi.
Misurazione di Web Vitals utilizzando i dati RUM
I dati Real User Monitoring (RUM), noti anche come dati sul campo, mostrano le prestazioni percepite dagli utenti effettivi di un sito. I dati RUM vengono utilizzati da Google per determinare se un sito soddisfa le soglie consigliate per i Segnali web essenziali.
Come iniziare
Se non hai una configurazione RUM, i seguenti strumenti ti forniranno rapidamente dati sulle prestazioni reali del tuo sito. Questi strumenti si basano tutti sullo stesso set di dati sottostante (il Report sull'esperienza utente di Chrome), ma hanno casi d'uso leggermente diversi:
- PageSpeed Insights (PSI): PageSpeed Insights genera report sul rendimento aggregato a livello di pagina e di origine negli ultimi 28 giorni. Inoltre, fornisce suggerimenti su come migliorare il rendimento. Se sei alla ricerca di una singola azione da intraprendere per iniziare a misurare e migliorare i Segnali web del tuo sito, ti consigliamo di utilizzare PSI per verificare il tuo sito. PSI è disponibile sul web e come API.
- Search Console: Search Console registra i dati sul rendimento in base alla pagina. Ciò lo rende particolarmente adatto per identificare pagine specifiche che richiedono miglioramenti. A differenza di PageSpeed Insights, i report di Search Console includono dati sul rendimento storico. Search Console può essere utilizzata soltanto con i siti di tua proprietà di cui hai verificato la proprietà.
- Dashboard di CrUX: la dashboard di CrUX è una dashboard predefinita che mostra i dati CrUX per un'origine di tua scelta. Si basa su Data Studio e il processo di configurazione richiede circa un minuto. Rispetto a PageSpeed Insights e a Search Console, i report delle dashboard di CrUX includono più dimensioni: ad esempio, i dati possono essere suddivisi per dispositivo e tipo di connessione.
Vale la pena notare che, sebbene gli strumenti elencati sopra siano adatti a "iniziare" a misurare i Segnali web, possono essere utili anche in altri contesti. In particolare, sia CrUX che PSI sono disponibili come API e possono essere utilizzati per creare dashboard e altri report.
Raccolta di dati RUM
Sebbene gli strumenti basati su CrUX siano un buon punto di partenza per esaminare le prestazioni di Web Vitals, consigliamo vivamente di integrarli con il tuo RUM. I dati RUM che raccogli tu possono fornire un feedback più dettagliato e immediato sulle prestazioni del tuo sito. In questo modo è più facile identificare i problemi e testare le possibili soluzioni.
Puoi raccogliere i tuoi dati RUM utilizzando un provider RUM dedicato oppure configurando i tuoi strumenti.
I provider RUM dedicati sono specializzati nella raccolta e nella generazione di report sui dati RUM. Per utilizzare Segnali web essenziali con questi servizi, chiedi al tuo fornitore del RUM di attivare il monitoraggio dei Segnali web essenziali per il tuo sito.
Se non hai un provider RUM, potresti essere in grado di estendere la tua configurazione di analisi esistente per raccogliere e generare report su queste metriche utilizzando la libreria JavaScript web-vitals. Questo metodo è spiegato più dettagliatamente di seguito.
La libreria JavaScript Web-vitals
Se stai implementando la tua configurazione RUM per Web Vitals, il modo più semplice per raccogliere le misurazioni di Web Vitals è utilizzare la libreria JavaScript web-vitals. web-vitals è una piccola libreria modulare (circa 1 kB) che offre un'API comoda per raccogliere e generare report su ciascuna delle metriche di Segnali web misurabili sul campo.
Le metriche che costituiscono i Segnali web non sono tutte esposte direttamente dalle API per le prestazioni integrate nel browser, ma piuttosto basate su di esse. Ad esempio, la metrica Cumulative Layout Shift (CLS) viene implementata utilizzando l'API Layout Instability. Se utilizzi web-vitals, non devi preoccuparti di implementare queste metriche autonomamente, perché ti assicuri che i dati raccolti corrispondano alla metodologia e alle best practice per ogni metrica.
Per saperne di più sull'implementazione di web-vitals, consulta la documentazione e la guida Best practice per la misurazione di Web Vitals sul campo.
Aggregazione dei dati
È essenziale segnalare le misurazioni raccolte da web-vitals. Se questi dati vengono misurati ma non inseriti nei report, non li vedrai mai. La documentazione di web-vitals include esempi che mostrano come inviare i dati a un endpoint API generico, a Google Analytics o a Google Tag Manager.
Se hai già uno strumento di generazione dei report preferito, puoi utilizzarlo. In caso contrario, Google Analytics è senza costi e può essere utilizzato a questo scopo.
Nel valutare quale strumento utilizzare, è utile pensare a chi avrà accesso ai dati. Le aziende in genere ottengono i risultati migliori quando l'intera azienda, piuttosto che un solo reparto, è interessata a migliorare il rendimento. Consulta l'articolo Correggere la velocità del sito web in modo interfunzionale per scoprire come ottenere l'approvazione da diversi reparti.
Interpretazione dei dati
Quando analizzi i dati sul rendimento, è importante fare attenzione alle code della distribuzione. I dati RUM spesso rivelano che le prestazioni variano notevolmente: alcuni utenti hanno un'esperienza veloce, altri lenta. Tuttavia, l'utilizzo della mediana per riepilogare i dati può facilmente mascherare questo comportamento.
Per quanto riguarda i Segnali web, Google utilizza la percentuale di esperienze "buone" anziché statistiche come mediane o medie, per determinare se un sito o una pagina soddisfa le soglie consigliate. In particolare, affinché un sito o una pagina vengano considerati conformi alle soglie dei Segnali web essenziali, il 75% delle visite alle pagine dovrebbe soddisfare la soglia "buona" per ogni metrica.
Misurazione di Web Vitals utilizzando i dati di laboratorio
I dati di prova controllati, noti anche come dati sintetici, vengono raccolti da un ambiente controllato, anziché da utenti effettivi. A differenza dei dati RUM, i dati di laboratorio possono essere raccolti da ambienti di pre-produzione e quindi incorporati nei flussi di lavoro degli sviluppatori e nei processi di integrazione continua. Esempi di strumenti che raccolgono dati sintetici sono Lighthouse e WebPageTest.
considerazioni
Ci saranno sempre discrepanze tra i dati RUM e i dati di laboratorio, in particolare se le condizioni di rete, il tipo di dispositivo o la località dell'ambiente di laboratorio differiscono in modo significativo da quelle degli utenti. Tuttavia, quando si tratta di raccogliere i dati di laboratorio sulle metriche di Segnali web in particolare, ci sono un paio di considerazioni specifiche che è importante tenere a mente:
- Cumulative Layout Shift (CLS): la metrica Cumulative Layout Shift misurata negli ambienti di laboratorio può essere artificialmente inferiore al CLS osservato nei dati RUM. Per CLS si intende la "somma totale di tutti i singoli punteggi di variazione del layout per ogni variazione imprevista del layout che si verifica durante l'intera durata della pagina". Tuttavia, la durata di una pagina solitamente è molto diversa a seconda che venga caricata da un utente reale o da uno strumento sintetico per la misurazione del rendimento. Molti strumenti di lab caricano solo la pagina e non ci interagiscono. Di conseguenza, acquisiscono solo le variazioni del layout che si verificano durante il caricamento iniziale della pagina. Al contrario, il CLS misurato dagli strumenti RUM acquisisce le variazioni del layout impreviste che si verificano durante l'intera durata della pagina.
- First Input Delay (FID): non è possibile misurare First Input Delay negli ambienti di laboratorio perché richiede le interazioni degli utenti con la pagina. Di conseguenza, il Tempo di blocco totale (TBT) è il proxy del lab consigliato per il FID. TBT misura la "quantità di tempo totale tra la prima visualizzazione con contenuti e il tempo all'interattività durante il quale la pagina non risponde all'input dell'utente". Sebbene FID e TBT vengano calcolati in modo diverso, sono entrambi riflessi di un thread principale bloccato durante il processo di bootstrap. Quando il thread principale è bloccato, il browser risponde in ritardo alle interazioni degli utenti. Il FID misura l'eventuale ritardo che si verifica la prima volta che un utente tenta di interagire con una pagina.
Utensili
Questi strumenti possono essere utilizzati per raccogliere misurazioni di laboratorio dei Segnali web:
- Estensione di Chrome Web Vitals:l'estensione di Chrome Web Vitals misura e segnala i Core Web Vitals (LCP, FID e CLS) per una determinata pagina. Questo strumento è pensato per fornire agli sviluppatori un feedback in tempo reale sul rendimento mentre apportano modifiche al codice.
- Lighthouse: crea report Lighthouse su LCP, CLS e TBT e evidenzia anche possibili miglioramenti delle prestazioni. Lighthouse è disponibile in Chrome DevTools, come estensione di Chrome e come pacchetto npm. Lighthouse può anche essere incorporato in flussi di lavoro di integrazione continua tramite Lighthouse CI.
- WebPageTest: WebPageTest include Web Vitals come parte dei suoi report standard. WebPageTest è utile per raccogliere informazioni su Web Vitals in determinate condizioni del dispositivo e della rete.