Con performance di norma si intende circoscrivere quella parte della SEO che riguarda la velocità di caricamento del sito in relazione agli standard espressi da Google.

Sebbene ci sia un’interpretazione più ampia del termine che comprende i KPI di un progetto SEO, performance viene usato da Google per indicare all’interno di Pagespeed Insight, Lighthouse e Web.Dev, i due strumenti ufficiali che forniscono un’analisi sullo stato del sito.

Cosa sono gli strumenti di Google che riguardano la performance?

Pagespeed Insight è sicuramente lo strumento più semplice dei tre, perché è interamente dedicato all’analisi della velocità del sito.

Lighthouse è integrato all’interno di Chrome e permette all’utente di ricevere informazioni sulla qualità del sito, i cui parametri sono divisi all’interno di cinque categorie, di cui una riguardante le PWA, ed utile anche per le TWA naturalmente.

Web.Dev è molto simile al precedente, se prendiamo in considerazione i parametri visibili, ma cambia la modalità espressiva che è più contratta per Lighthouse, e che invece qui trova spazio per segnalare la criticità degli errori o delle modifiche da effettuare.

Per semplicità di lettura e per attinenza con il titolo dell’articolo, ci concentreremo sulla lettura dei dati forniti da Pagespeed Insight.

Aree critiche dell’ottimizzazione

In linea di massima tutti i neofiti hanno preso in considerazione almeno una volta il valore che va da 0 a 100 e che indica la performance del sito.

Il valore è sicuramente importante, ma ricevere per una volta una scansione numericamente rilevante significa poco: quando il sito comincia a guadagnare un certo traffico Google comincerà a fornire dei dati più precisi sulla performance media del sito.

Quando effettuiamo una scansione non facciamo altro che prendere nota di un piccolo intervallo di performance all’interno di un insieme più grande, che può essere la giornata o il mese. Google non tiene conto solo di un intervallo, ma continua ad apprendere in merito alle reazioni del nostro sito sotto stress, se così possiamo dire, ossia quando riceviamo un maggior numero di visite.

Per avere un quadro più chiaro delle operazioni da compiere le divideremo in tre grandi blocchi, gli stessi utilizzati dal tool preso in considerazione:

• Lab data
• Opportunities
• Diagnostics

Un esempio di Lab Data

Lab Data

Si tratta delle informazioni riguardanti i tempi di interazione e visualizzazione dei contenuti del sito. L’analisi comprende sei diverse sezioni, ognuna delle quali prende in considerazione un aspetto differente della performance:

• First Contentful Paint: tiene in considerazione quanti secondi sono necessari prima che sia visibile il primo testo o la prima immagine.
• Speed Index: indica il tempo necessario a rendere visibili e non solo caricati i contenuti della pagina.
• Time to Interactive: il tempo in cui i contenuti caricati diventano realmente interattivi.
• First Meaningful Paint: indica quando il main content di una pagina è stata caricata, ossia quando
• First CPU Idle: si tratta del calcolo del momento in cui il caricamento e la visibilità dei dati è finita ed inizia una fase di quiete, ossia in cui non c’è bisogno di caricare altro nella pagina.
• Max Potential First Input Delay: tiene conto di quando è possibile effettuare la prima interazione (click, scroll) all’interno del sito.

All’interno di Pagespeed, alla fine di ognuna delle voci indicate troverete delle informazioni specifiche su come migliorare la qualità di ognuno di questi elementi, anche se di solito la maggior parte dei lavori di ottimizzazione riguarda la seconda sezione dei dati della scansione.

Opportunities

Si tratta del campo di analisi più mutevole, visto che fornisce spunti sugli aspetti meno performanti dell’ottimizzazione del sito. In teoria comprende molte voci che compaiono qualora ci fosse una reale subottimizzazione, ma molto spesso alcune voci sono più presenti di altri, come esplicate da questo elenco:

• Reduce server response times (TTFB): indica un particolare carico di lavoro del server, scaturito dall’utilizzo di macchine poco potenti o da un eccessivo carico causato da programmi (o plugin) installati che, seppur non visibili nel front-end, occupano potenziali risorse utilizzabili altrove.
• Defer offscreen images: si tratta di un problema comune e facile da realizzare, visto che basta utilizzare la tecnica di lazy loading per le immagini.
• Serve images in next-gen formats: è una voce abbastanza comune, visto che pochi utilizzano i formati proprietari di Google / Chrome per servire le immagini, come i file .webp. In genere si tratta di un formato conveniente, ma che richiede un tool che permetta di mostrare le immagini tradizionali nel caso in cui l’utente non stia accedendo dai browser che ne contemplano l’utilizzo.
• Eliminate render-blocking resources: di solito riguarda la mancanza dell’attributo async da inserire negli script di Javascript manualmente o tramite un software. Si tratta forse di una delle voci più semplici da risolvere (almeno su WordPress, in altri ambienti richiede una certa manualità), visto che applicando un semplice parametro agli script viene risolta.

Diagnostics

Si tratta del segmento più tecnico, perché tiene conto dell’impatto degli script di terze parti che influenzano negativamente il caricamento della pagina, la gestione della policy della cache (legiferare sul file .htaccess dopo quanto tempo scade la cache di un determinato tipo di file), la minificazione del thread-work, ossia riuscire a compattare i DOM che vengono caricati e razionalizzare il numero di script, in modo da diminuire i tempi di caricamento di quest’ultimi.

Infine, ottimizzare la critical request chain, ossia i caricamenti prioritari di elementi che influenzano la velocità di usabilità della pagina, escludendo quei caricamenti che sono necessari all’interno del sito, ma non è detto che servano per questo caricamento specifico.