TAB PAGESPEED

By
Raffaele Visintin
-
0
417

Oggigiorno le performance di un sito web sono vitali per il posizionamento organico nella Serp di Google, questa tendenza viene ancora di più avvalorata dai nuovi Core Web Vitals entrati tra i fattori di Ranking da maggio 2021.

La scheda “PageSpeed” del Seo Spider ti aiuta a collezionare i dati da due fonti:

  • PageSpeed Insights che utilizza Lighthouse per verificare la velocità delle pagine web mediante “dati di laboratorio”;
  • Chrome User Experience Report (CrUX, o “dati sul campo”) che ti permette di ottenere dati reali di navigazione. 

Per popolare i dati della tab “PageSpeed” è necessario connettere le API di PSI.

Configuration > API > PageSpeed Insights

Dalla scheda Pagespeed hai a disposizione diverse metriche generiche:

  • Total Size Savings.
  • Total Time Savings.
  • Total Requests.
  • Total Page Size.
  • HTML Size.
  • HTML Count.
  • Image Size.
  • Image Count.
  • CSS Size.
  • CSS Count.
  • JavaScript Size.
  • JavaScript Count.
  • Font Size.
  • Font Count.
  • Media Size.
  • Media Count.
  • Other Size.
  • Other Count.
  • Third Party Size.
  • Third Party Count.

Ulteriori metriche più specifiche a disposizione sono divise fra “CrUX Metrics” che corrispondono ai dati sul campo di Chrome e “Lighthouse Metrix” con dati di laboratorio rilasciati da PageSpeed Insight.

CrUX Metrics

  • CrUX Performance.
  • CrUX First Contentful Paint Time (sec).
  • CrUX First Contentful Paint Category.
  • CrUX First Input Delay Time (sec).
  • CrUX First Input Delay Category.
  • CrUX Origin Performance.
  • CrUX Origin First Contentful Paint Time (sec).
  • CrUX Origin First Contentful Paint Category.
  • CrUX Origin First Input Delay Time (sec).
  • CrUX Origin First Input Delay Category.

Lighthouse Metrics:

  • Performance Score.
  • Time to First Byte (ms).
  • First Contentful Paint Time (sec).
  • Speed Index Time (sec).
  • Time to Interactive (sec).
  • First Contentful Paint Score.
  • First Meaningful Paint Time (sec).
  • First Meaningful Paint Score.
  • Speed Index Score.
  • Estimated Input Latency (ms).
  • Estimated Input Latency Score.
  • First CPU Idle (sec).
  • First CPU Idle Score.
  • Time to Interactive Score.

La Tab, oltre alle metriche comprende i seguenti filtri:

  • Eliminate Render-Blocking Resources: sono visualizzate tutte le pagine con risorse che stanno bloccando il “First Paint” della pagina, insieme al potenziale risparmio.
  • Properly Size Images: il filtro evidenzia tutte le pagine che contengono immagini non correttamente dimensionate ed evidenzia il potenziale risparmio di dati se venissero corrette.

Idealmente la tua pagina web non dovrebbe servire immagini più grandi della versione resa sullo schermo dell’utente. La strategia più consona è quella di  servire “responsive images” generando più versioni e specificando quali usare nel tuo Html o CSS mediante le media queries, le dimensioni della viewport etc. 

Altre soluzioni possono essere l’uso di CDN immagini o utilizzare formati di immagini vettoriali SVG per scalare a qualsiasi dimensione ad esempio le icone.

  • Defer Offscreen Images: identifica tutte le pagine che contengono immagini nascoste o fuori dallo schermo assieme al potenziale risparmio. Per ovviare al problema puoi considerare il “Lazy-loading” di queste immagini dopo le risorse critiche per abbassare l’indice “Time to Interactive”. 
  • Minify CSS: tutte le pagine che presentano file CSS non minificati, insieme al risparmio potenziale se venissero minificati correttamente.

Minificare i CSS permette di migliorare il tempo di caricamento delle pagine perché normalmente i CSS utilizzati sono più grandi di quanto serve. I file CSS possono contenere caratteri non necessari, come ad esempio i commenti, gli spazi bianchi e l’indentazione. 

Al momento della messa online, questi caratteri possono essere tranquillamente rimossi, per ridurre le dimensioni del file senza influenzare il modo in cui il browser elabora gli stili. Questa tecnica è chiamata minificazione.

Esempio Minificazione

/* Header background should match brand colors. */
h1 {

background-color: #000000;

}
h2 {

background-color: #000000;

}

Questo codice può venir minificato in una sola riga che permette al browser di utilizzare un numero di bytes inferiore.

h1,h2 { background-color: #000000; }
  • Minify JavaScript: mostra tutte le pagine con file JavaScript non minificati, insieme al potenziale risparmio. Minificare i file JavaScript può ridurre le dimensioni del payload e il tempo di analisi dello script.
    La minificazione è il processo di rimozione degli spazi bianchi e di qualsiasi codice che non è necessario per creare un file di codice più piccolo ma perfettamente valido. Ad esempio Terser è un popolare strumento di compressione JavaScript. webpack v4 include di default un plugin per questa libreria per creare file di build minificati.
  • Remove Unused CSS: identifica le pagine con CSS inutilizzati, insieme al potenziale risparmio in bytes. Di solito gli sviluppatori utilizzano <link> per aggiungere i fogli di stile di una pagina:
<!doctype html>
<html>
<head>
<link href=”main.css” rel=”stylesheet”>

Il file main.css che il browser scarica è definito foglio di stile esterno e viene memorizzato separatamente dall’HTML che lo include nel codice. In questo modo ogni qual volta un browser incontra questa condizione dovrà scaricare, analizzare ed elaborare tutti i fogli di stile esterni che incontra prima di poter servire qualsiasi contenuto sullo schermo dell’utente.

  • Efficently Encode Images: il filtro visualizza le pagine con immagini non ottimizzate, insieme al potenziale risparmio. Lighthouse raccoglie tutte le immagini JPEG o BMP sulla pagina, imposta il livello di compressione di ogni immagine a 85, e poi confronta la versione originale con quella compressa. Se il risparmio potenziale è di 4 KiB o maggiore, Lighthouse segnala l’immagine come ottimizzabile.
  • Serve Images in Next-Gen Formats: evidenzia le pagine con immagini servite in vecchi formati come jpeg e png. Il consiglio è quello di utilizzare formati come AVIF e WebP che hanno caratteristiche di compressione e qualità superiori. 
  • Enable Text Compression: tutte le pagine con risorse basate sul testo che non sono state compresse, insieme al potenziale risparmio.
  • Preconnect to Required Origin : il filtro identifica tutte le pagine che presentano delle connessioni a domini diversi dal tuo ma non stanno ancora dando priorità alle richieste di fetch con link rel=preconnect, insieme al potenziale risparmio. Il Browser prima di richiedere una risorsa ad un server necessita di stabilire una connessione con lo stesso per cercare il nome dominio e definirlo in un indirizzo IP, per impostare una connessione al server e per crittografare la connessione. In tutti questi steps il browser invia dati e riceve risposte dal server, questo processo si definisce “Round Trip” e, in base alle condizioni della rete richiede del tempo che influisce inesorabilmente sulle performance. 

Per ottimizzare questo aspetto puoi avvalerti del “preconnect” delle risorse esterne (connessioni verso altri domini) che istruisce il browser su quali risorse connettersi in prima istanza perché considerate prioritarie.

<head>
<link rel=preconnect href= “https://dominio.com”>
</head>

Questi suggerimenti sono applicabili anche attraverso l’HTTP Header

Link: <https://dominio.com; rel=preconnect...

ESEMPIO PRECONNECT

Un esempio di applicazione del “preconnect” potrebbe essere per Google Tag Manager o Google Analytics

Link: <https://www.google-analytics.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://www.googletagmanager.com>; rel=preconnect; crossorigin; probability=1.0;

Le “critical chain requests” corrispondono a una serie di richieste di reti dipendenti e importanti per il corretto rendering del documento html.

  • Reduce Server Response Times (TTFB): la velocità di caricamento è essenziale per una user-experience adeguata e gli utenti sono molto sensibili su questo aspetto. Un sito che impiega molti secondi per caricarsi ha delle percentuali di abbandono direttamente proporzionali. Una delle cause più comuni è legata alle risposte lente dei server nel restituire il contenuto della pagina al browser. Questo filtro identifica tutte le pagine in cui il browser ha dovuto aspettare più di 600 ms per la risposta del server nella richiesta del documento principale. 
  • Avoid Multiple Redirects: visualizza le pagine che hanno risorse che reindirizzano, e il potenziale risparmio usando l’URL diretto. I reindirizzamenti rallentano la velocità di caricamento della pagina. Quando un browser richiede una risorsa che è stata reindirizzata, il server di solito restituisce una risposta HTTP come questa:
HTTP/1.1 301 Moved Permanently
Location: /path/to/new/location

e il browser è costretto a fare un’altra richiesta HTTP per recuperare la risorsa nella nuova posizione. Questa considerazione non vuole mettere al bando l’utilizzo dei 3xx ma quando si creano delle catene di reindirizzamenti o reindirizzamenti multipli nella stessa pagina.
Da evitare sempre i redirect nelle risorse necessarie al “Critical Rendering Path”.

  • Preload Key Requests: identifica le pagine html che presentano elementi che potrebbero essere gestiti con il “preload”.
    Quando viene richiesta una pagina il browser richiede al server la pagina html analizzando il contenuto e inviando delle richieste distinte per ogni risorsa di riferimento inserita nel documento. Per migliorare le performance è consigliato accelerare questo processo richiedendo le risorse critiche in anticipo.
    Un esempio di applicazione potrebbe essere la richiesta di un font in un file CSS dato che il browser lo scoprirebbe solamente dopo la lettura del foglio di stile. Utilizzando la funzione “Preload” andrai a precaricare e recuperare una risorsa che il browser considererebbe solamente in una fase successiva ad esempio nelle critical chain request.
    Ricorda che il browser memorizza nella cache la risorsa in “preload” senza eseguire script ma avendoli già considerati li servirà immediatamente una volta richiesti.
    Questa funzionalità è molto indicata per dipendenze come JS, Font e CSS.

Questa funzionalità è una direttiva per il browser che non blocca il caricamento del documento html. Per implementare la direttiva “Preload” è sufficiente aggiungere il tag <link> nella sezione <head> dell’html o utilizzare l’intestazione HTTP Link.

Sezione Head

<link rel=”stylesheet” href=”styles/main.css”>
<link rel=”preload” href=”main.js” as=”script”>

HTTP Header

Link: </css/style.css>; rel=”preload”; as=”style”
  • Use Video Format for Animated Images: identifica le pagine con GIF animate, insieme al potenziale risparmio se convertite in video.
  • Avoid Excessive DOM size: identifica tutte le pagine che presentano una dimensione del DOM che supera i 1.500 nodi totali raccomandati. Considerare il DOM è di vitale importanza perché potrebbe influire negativamente sulle performance e sul rendimento in diversi modi:
    • spesso il DOM include molti nodi non visibili all’utente nel caricamento della pagina per la prima volta; questa condizione aumenta inutilmente il volume di dati da servire agli utenti e rallenta il tempo di caricamento (prestazioni di carico).
    • durante la navigazione ci sono numerose interazioni con la pagina web da parte degli utenti e degli script che portano il browser a riorganizzare la posizione e lo stile dei nodi del DOM creando rallentamenti per il rendering (prestazioni di runtime).
    • Se il JavaScript usa selettori di query generali come document.querySelectorAll(‘li’), potrebbe inconsapevolmente memorizzare riferimenti a un numero molto grande di nodi, il che può sovraccaricare le capacità di memoria dei dispositivi degli utenti (prestazioni di memoria).
  • Reduce Javascript Execution Time: filtro che segnala le pagine con un tempo di esecuzione JavaScript medio o lento. Quando una pagina html impiega molto tempo nell’esecuzione degli script Javascript rallenta le prestazioni:
    • aumentando il costo della rete: utilizzando più byte aumenta il tempo di download.
    • Il Javascript viene analizzato e compilato nel thread principale che non rimane a disposizione per l’interazione dell’utente.
    • Occupando il thread principale Javascript si ritarda anche il TTI (Time to Interactive) penalizzando la Ux della pagina e il web vitals dedicato.
    • Se il Javascript contiene molti riferimenti potrebbe consumare inesorabilmente molta memoria penalizzando la consultazione della pagina da parte dell’utente.


Per migliorare le performance di esecuzione dei Javascript si consiglia in linea generale di “minificare” e comprimere il codice, rimuovere quello inutilizzato e memorizzarlo in cache.

  • Serve Static Assets With An Efficient Cache Policy:  restituisce tutte le pagine con risorse che non sono “cachate”, insieme al potenziale risparmio. Quando un browser richiede una risorsa, il server che fornisce la risorsa può dire al browser per quanto tempo dovrebbe memorizzare temporaneamente o mettere in cache la risorsa. Per ogni successiva richiesta di quella risorsa, il browser usa la sua copia locale piuttosto che ottenerla dalla rete. Nelle valutazioni di Lighthouse vengono considerati i font, i media, le immagine o fogli di stile che rispondono con status code 2xx e non hanno dichiarato in modo esplicito la “no-cache policy”.

Ecco un esempio di cache tramite intestazione HTTP:

Cache-Control: max-age=31536000

La direttiva “max-age” istruisce il browser su quanto tempo una risorsa rimarrà in cache. Per gli “static assets” si consiglia un tempo non inferiore ad un anno.

  • Minimize Main-Thread Work: identifica tutte le pagine con tempi di esecuzione medi o lenti sul thread principale che penalizzano il rendering del documento html. Il processo di rendering del browser trasforma il tuo codice in una pagina web con cui gli utenti possono interagire. Per impostazione predefinita, il thread principale del processo di rendering gestisce la maggior parte del codice: analizza l’HTML e costruisce il DOM, analizza il CSS e applica gli stili specificati, ed analizza, valuta ed esegue il JavaScript. 

Il thread principale elabora anche gli eventi utente. Quindi, ogni volta che il thread principale è occupato a fare qualcos’altro, la pagina web potrebbe non rispondere alle interazioni dell’utente, portando ad una cattiva esperienza. Per migliorare questo processo si consiglia di ottimizzare javascript di terze parti, eliminare codice non utilizzato, ridurre i riferimenti CSS e semplificarli (minificarli), posticipare i CSS non critici, splittare il javascript payloads. 

  • Ensure Text Remains Visible During Webfont Load: tutte le pagine con font che possono lampeggiare o diventare invisibili durante il caricamento della risorsa.

ESPORTARE I DATI SULLE PERFORMANCE

Tutte i dati relativi alle performance, le pagine sorgente e gli URL delle risorse che potrebbero essere ottimizzate li puoi esportare in blocco tramite il menu PageSpeed.

Reports > PageSpeed