Avete molte opzioni come proprietari di siti web quando dovete eseguire degli speed test per verificarne le prestazioni. In precedenza abbiamo già analizzato approfonditamente lo Pingdom. Oggi scopriremo come utilizzare e analizzare i dati del popolare tool di test delle prestazioni dei siti web GTmetrix. Strumenti come questo si basano su sistemi di valutazione e punteggi, con messaggi di avvertimento di possibili anomalie del vostro sito. A volte questi messaggi possono essere decisamente complicati da decifrare, quindi, dedicare un po’ di tempo alla comprensione del loro significato effettivo può aiutarvi non solo ad aumentare i vostri punteggi, ma anche a migliorare le prestazioni del vostro sito, che è la cosa che conta davvero.

Sapere come funziona @GTmetrix è fondamentale per i proprietari dei siti WordPress! ⏱ Click to Tweet

GTmetrix

GTmetrix è stato sviluppato da GT.net, una società con sede in Canada, come strumento per i loro clienti del servizio di hosting per misurare facilmente le prestazioni del proprio sito. A parte Pingdom, è probabilmente uno degli strumenti di speed test più conosciuti e utilizzati oggi sul web! Infatti, la ragione per cui scriviamo questo articolo è che abbiamo molti clienti di Kinsta che ci chiedono sempre come mettere in partica i consigli che vedono nei loro report GTmetrix. Rispetto ad altri strumenti di sviluppo, GTmetrix è piuttosto semplice da usare e i principianti possono appropriarsene abbastanza rapidamente. GTmetrix utilizza una combinazione di Google PageSpeed Insights e YSlow per produrre i punteggi e le raccomandazioni.

Speed test di GTmetrix

Speed test di GTmetrix

La versione base di GTmetrix è completamente gratuita e potete accedere ad una serie di opzioni semplicemente creando un account. Offrono anche piani premium, ma per il post di oggi useremo la versione gratuita. Se avete un account potete specificare un numero di opzioni di analisi aggiuntive. La prima si riferisce alla possibilità di scegliere la località da cui si desidera testare il proprio URL. La posizione fisica scelta è molto importante in quanto si riferisce alla posizione in cui il vostro sito web è effettivamente ospitato. Minore è la latenza, minore è il tempo di caricamento. Le posizioni attualmente disponibili sono:

  • Dallas, USA
  • Hong Kong, China
  • London, UK
  • Mumbai, India
  • Sydney, Australia
  • São Paulo, Brazil
  • Vancouver, Canada

È possibile scegliere il browser che si desidera utilizzare. Potete provare con Chrome (desktop) e Firefox (desktop). Le versioni mobili sono disponibili nei piani premium. Consentono anche di modificare la velocità di connessione, il che significa che è possibile simulare vari tipi di connessione per vedere in che modo influiscono sul caricamento della pagina.

Opzioni formato test in GTmetrix

Opzioni formato test in GTmetrix

Un’altra opzione è la possibilità di creare un video. Questo può aiutarvi a risolvere delle anoimalie, dato che potete vedere come la pagina esegue il rendering. Adblock Plus è un’altra bella funzionalità. Se utilizzate una rete pubblicitaria di terze parti come Google Adsense, potete abilitare questa opzione per vedere qual è l’impatto complessivo sui tempi di caricamento. Ecco un ottimo comparison report sul sito di Smashing Magazine. Non sorprende che il sito con le pubblicità sia stato di 2,3 secondi più lento.

Opzioni aggiuntive di GTmetrix

Opzioni aggiuntive di GTmetrix

Le opzioni aggiuntive comprendono l’arresto del test onload (che approfondiremo di seguito), la possibilità di inviare un cookie insieme alla richiesta, l’utilizzo dell’autenticazione HTTP e la possibilità di inserire gli URL in whitelist e blacklist.

Analisi con lo Speed Test Tool di GTmetrix

Una pagina web è composta da diverse risorse, come HTML, JavaScript, CSS e immagini. Ognuna di queste genera richieste per rendere ciò che vedete sul vostro sito web. In genere, più richieste avete, più lento sarà il caricamento del vostro sito. Non è sempre così, ma è vero nella maggior parte dei casi. Di seguito analizzeremo ogni sezione di GTmetrix e spiegheremo più in dettaglio che cosa significano le informazioni relative alle prestazioni generali del vostro sito e cosa fare in merito alle raccomandazioni. Ricordate di non farvi ossessionare troppo dai punteggi, ma di concentrarvi piuttosto sui miglioramenti reali alle prestazioni del vostro sito.

Riepilogo di GTmetrix (Punteggi e Dati delle Prestazioni)

Quando eseguite il vostro sito WordPress tramite GTmetrix, questo genera un report sulle performance che comprende il vostro punteggio PageSpeed, il punteggio YSlow, il tempo di caricamento completo, le dimensioni totali della pagina e il numero di richieste sul sito. Nel nostro esempio, utilizzeremo il nostro dominio di studio perfmatters.io, che è ospitato su Kinsta. Nel nostro primo test di velocità, il tempo di caricamento completo è stato di 1,1 secondi.

Report performance GTmetrix

Report performance GTmetrix

Abbiamo quindi eseguito un ulteriore test e il nostro tempo di caricamento totale è stato di 485 ms! Come mai? Potreste notarlo anche se eseguite il vostro sito attraverso lo speed test di GTmetrix più volte. Uno dei motivi è il caching, sia del DNS che del server. Scoprite perché più in basso, nella nostra analisi a cascata.

Tempo caricamento completo in GTmetrix

Tempo caricamento completo in GTmetrix

Un’altra domanda che ci viene fatta molto spesso è: perché GTmetrix mostra sempre una velocità inferiore a quella di Pingdom? Ad esempio, abbiamo eseguito lo stesso sito tramite un test di Pingdom, ed ha dimostrato di essere molto più veloce.

Confronto tra Pingdom e GTmetrix

Confronto tra Pingdom e GTmetrix

Dopo aver eseguito migliaia di test di velocità, possiamo dirvi che Pingdom mostrerà quasi sempre velocità più elevate di GTmetrix. E non sono sbagliati. Calcolano semplicemente le velocità in modi diversi, quindi non dovreste confrontare i due strumenti. Quando si tratta di utilizzare strumenti di test della velocità dei siti web, dovreste scegliere quello che preferite e utilizzare sempre lo stesso. Questo vi fornirà una buona metrica di base per poi confrontarla con test aggiuntivi. Inoltre, a partire dall’8 febbraio 2017, GTmetrix utilizza quello che chiamano tempo di caricamento completo.

Secondo GTmetrix, il tempo di caricamento completo è il momento successivo all’esecuzione dell’evento Onload e senza attività di rete per 2 secondi. Per dirla in modo semplice, aspettano che la vostra pagina interrompa il trasferimento dei dati prima di completare un test, con tempi di caricamento delle pagine più coerenti. In precedenza si riferivano al tempo di Onload, che in alcuni casi dava risultati non visualizzati nei rapporti sulle performance, come ad esempio gli annunci caricati in modo asincrono o gli screenshot mancanti.

Page Speed

GTmetrix utilizza le regole di Google PageSpeed ​​Insight per dare un punteggio al vostro sito web. Le valutazioni vanno da 0 a 100 (da F ad A). Ci sono oltre 25 raccomandazioni. Cercheremo di analizzare le più comuni e popolari con cui si trovano più spesso alle prese i proprietari di siti WordPress. Non dimenticate di aggiungere questo post ai segnalibri perché lo aggiorneremo costantemente. In genere, se seguite queste raccomandazioni, dovreste vedere una diminuzione dei tempi di caricamento complessivi.

Punteggi PageSpeed GTmetrix

Punteggi PageSpeed GTmetrix

Servite Immagini in Scala

Quando dovete lavorare con le immagini sul vostro sito web, dovete sempre provare a caricarle in scala e non far sì che vengano ridimensionate da CSS. Se non lo fate, finirete col visualizzare la raccomandazione serve scaled images. Se utilizzate WordPress, di default questo ridimensiona le immagini al momento del caricamento nella libreria multimediale. Queste impostazioni sono disponibili in “Impostazioni > Media”. Dovrete assicurarvi che la larghezza massima sia vicina alla larghezza del vostro sito. In questo modo il CSS non cercherà di ridimensionare l’immagine perché si adatti. Potreste anche ridimensionarle automaticamente con un plugin di ottimizzazione delle immagini.

Servire immagini ridotte (Serve scaled images)

Servire immagini ridotte (Serve scaled images)

Inserite i Piccoli CSS in Linea

In genere, non è consigliabile inserire il codice CSS in linea, in quanto aumenterà la dimensione complessiva del download della richiesta di pagina. Tuttavia, se il vostro sito è di piccole dimensioni, con richieste minime questa soluzione potrebbe migliorare le vostre prestazioni.

Inserite CSS piccoli in linea

Inserite CSS piccoli in linea

Per inserire facilmente inline i vostri CSS, potete utilizzare un plugin gratuito come Autoptimize. È sufficiente selezionare l’opzione “Inline all CSS?” e assicurarsi di aver escluso i file CSS aggiuntivi che non volete integrare.

CSS in linea con Autoptimize

CSS in linea con Autoptimize

Inserite i Piccoli JavaScript in Linea

Proprio come l’inserimento in linea di piccoli CSS, la stessa cosa vale per l’inserimento in linea di piccoli JavaScript. Di solito non è consigliato, in quanto aumenterà la dimensione complessiva del download della vostra richiesta di pagina. Tuttavia, se il vostro sito è di piccole dimensioni, con richieste minime le prestazioni potrebbero migliorare. Di nuovo, potete usare un plugin gratuito come Autoptimize.

Inserite JavaScript piccoli in linea

Inserite JavaScript piccoli in linea

Sfruttare il Caching del Browser

Quella di sfruttare il caching del browser è una delle raccomandazioni con cui la gente ha a che fare più spesso. Viene generata quando sul sito web non ci sono le intestazioni HTTP della cache corrette. Date un’occhiata al nostro post approfondito su come risolvere il problema dell’avviso relativo all’utilizzo della cache del browser. Potete eliminare l’avviso solo sulle risorse di cui avete il controllo. Ad esempio, se lo vedete su reti pubblicitarie di terze parti, non potete farci niente.

Sfrutta il caching del browser

Sfrutta il caching del browser

Servire le Risorse da un URL Coerente

Se rilevate l’avviso che avverte di servire le risorse da un URL coerente, è molto probabile che abbiate risorse identiche che vengono servite dallo stesso URL. Molto spesso accade quando ci sono di mezzo delle query string. Scoprite come rimuovere le query string dalle risorse statiche. Una volta che sono state eliminate, non dovrebbe più caricarle due volte.

Servire le risorse da un URL coerente

Servire le risorse da un URL coerente

Differire il Parsing JavaScript

JavaScript e CSS sono di default risorse che bloccano il rendering. Ciò significa che possono impedire la visualizzazione della pagina web fino a quando non vengono scaricati ed elaborati dal browser. L’attributo defer dice al browser di attendere il download della risorsa fino al completamento del parsing HTML. Alcune semplici soluzioni per risolvere questo problema sono quelle di utilizzare i plugin gratuiti Autoptimize o Async JavaScript. Non perdete il nostro post approfondito su come eliminare JavaScript e CSS che bloccano il rendering.

Rinviare il parsing di JavaScript

Rinviare il parsing di JavaScript

Minimizzare CSS e JavaScript

La minimizzazione consiste essenzialmente nel rimuovere tutti i caratteri non necessari dal codice sorgente senza modificarne la funzionalità. Ciò può riguardare interruzioni di riga, spazi vuot, rientri, ecc. In questo modo è possibile risparmiare byte di dati e accelerare download, analisi e tempi di esecuzione.

Minimizzare CSS e JavaScript

Minimizzare CSS e JavaScript

Il plugin gratuito Autoptimize è ottimo anche per questo. Assicuratevi semplicemente che sia selezionato “Ottimizza codice JavaScript” e “Ottimizza codice CSS”. Se disponete di un sito di grandi dimensioni, potreste anche voler giocare un po’ con le impostazioni avanzate, in quanto alcune potrebbero danneggiare le prestazioni del vostro sito. In genere non è consigliabile integrare o combinare CSS e JavaScript su siti di grandi dimensioni. È qui che entra in gioco la potenza di HTTP/2.

Minimizzare CSS e JavaScript in Autoptimize

Minimizzare CSS e JavaScript in Autoptimize

Ottimizzare le Immagini

Secondo HTTP Archive, ad aprile 2017, le immagini rappresentavano in media il 66% del peso totale di una pagina web. Quindi, quando si tratta di ottimizzare il vostro sito WordPress, le immagini sono di gran lunga la prima cosa da affrontare! Più importante degli script e dei font.

Ottimizzare le immagini

Ottimizzare le immagini

In un mondo perfetto, ogni immagine dovrebbe essere compressa e ottimizzata prima di essere caricata in WordPress. Ma, sfortunatamente, questo non è realistico. Per questo motivo, vi consigliamo di utilizzare un buon plugin per l’ottimizzazione delle immagini. Ciò vi aiuterà a comprimere automaticamente le vostre immagini, a ridimensionarle e ad assicurarvi che siano leggere e veloci sul vostro sito. Date un’occhiata al nostro post approfondito su come ottimizzare le immagini per il web.

Minimizzare HTML

Proprio come CSS e JavaScript, anche HTML può essere minimizzato per eliminare caratteri non necessari e per risparmiare byte di dati e accelerare i tempi di esecuzione.

Minimizzare HTML

Minimizzare HTML

Il plugin gratuito Autoptimize è ottimo anche per questo. Abilitate semplicemente l’opzione “Ottimizza codice HTML”.

Ottimizzare il codice HTML in Autoptimize

Ottimizzare il codice HTML in Autoptimize

Abilitare la compressione GZIP

GZIP è un formato di file e un’applicazione software utilizzata per la compressione e la decompressione dei file. La compressione GZIP è abilitata lato server e consente un’ulteriore riduzione delle dimensioni di HTML, fogli di stile e file JavaScript. Non funzionerà sulle immagini in quanto queste sono già compresse in un modo diverso. Alcuni hanno registrato riduzioni fino al 70% per la compressione. È probabilmente una delle ottimizzazioni più facili da implementare per quel che riguarda WordPress. Nota: la compressione GZIP è abilitata di default su tutti i server Kinsta.

Abilitare la compressione GZIP

Abilitare la compressione GZIP

Per abilitare la compressione GZIP in Apache, è sufficiente aggiungere il seguente codice al file .htaccess.

# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

Se utilizzate NGINX, vi basta aggiungere quanto segue al vostro file nginx.conf.

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_vary on;
gzip_types text/plain text/css text/javascript image/svg+xml image/x-icon application/javascript application/x-javascript;

E ricordate anche di leggere il nostro post approfondito su come abilitare la compressione GZIP.

Ridurre al Minimo i Redirect

Riducendo al minimo i reindirizzamenti HTTP da un URL all’altro, si eliminano ulteriori RTT e tempi di attesa per gli utenti. Date un’occhiata al nostro post sui reindirizzamenti di WordPress, in cui abbiamo scoperto che 2 redirect errati aumentavano i tempi di caricamento del sito del 58%! Chiaro e semplice, i redirect di WordPress rallentano il vostro sito. Ecco perché vale la pena dedicare del tempo a ridurre al minimo il numero dei redirect incontrati dai visitatori del vostro sito.

Minimizzare i redirect

Minimizzare i redirect

Specificare un Cache Validator

La raccomandazione di specificare un cache validator appare quando mancano le intestazioni HTTOP della cache. Queste dovrebbero essere incluse in ogni risposta del server di origine, in quanto convalidano e impostano la lunghezza della cache. Se le intestazioni non vengono trovate, sarà generata ogni volta una nuova richiesta per la stessa risorsa, il che aumenta il carico sul server. L’utilizzo delle intestazioni di cache garantisce che le richieste successive non debbano essere caricate dal server, risparmiando così la larghezza di banda e migliorando le prestazioni per l’utente. E ricordate, non potete eliminare questo avviso su risorse di terze parti che non controllate. Nota: le intestazioni HTTP della cache vengono automaticamente aggiunte su tutti i server Kinsta.

Specificare un cache validator

Specificare un cache validator

Esistono diverse intestazioni HTTP della cache che possono essere utilizzate per correggere questa raccomandazione. Leggete il nostro post approfondito su come specificare un cache validator.

Specificare le Dimensioni delle Immagini

Proprio come non dovreste permettere ai CSS di ridimensionare le vostre immagini, dovreste anche specificarne le dimensioni. Ciò significa includere la larghezza e l’altezza nel codice HTML.

Sbagliato

Corretto

Specificare le dimensioni delle immagini

Specificare le dimensioni delle immagini

Rimuovere le Query String dalle Risorse Statiche

I file CSS e JavaScript di solito recano la versione del file alla fine dei loro URL, come domain.com/style.css?ver=4.6. Alcuni server e proxy server non sono in grado di memorizzare le query string, anche se è presente un’intestazione cache-control:public. Quindi, rimuovendole, potreste migliorare la memorizzazione nella cache. Questoa operazione può essere fatta facilmente con del codice o con plugin gratuiti di WordPress. Date un’occhiata al nostro post approfondito su come rimuovere le query string dalle risorse statiche. E ricordate, non puoi eliminare questo avviso su risorse di terze parti su cui non avete controllo.

Rimuovere le query string dalle risorse statiche

Rimuovere le query string dalle risorse statiche

Specificare un Header Vary: Accept-Encoding

È un’intestazione HTTP che dovrebbe essere inclusa in ogni risposta del server di origine, in quanto indica al browser se il client può gestire le versioni compresse del contenuto. Di solito, quando la compressione GZIP è abilitata, anche questo avviso è rimosso. Ma assicuratevi di dare un’occhiata al nostro post approfondito su come eliminare la raccomandazione di specificare un header vary: accept-encoding. E, ancora, non potete risolvere questo problema con risorse di terze parti.

Specificare un header Vary: Accept-Encoding

Specificare un header Vary: Accept-Encoding

YSlow

GTmetrix utilizza anche YSlow per dare un punteggio al vostro sito web. Ci sono più di 15 raccomandazioni. Cercheremo di le più comuni con cui si trovano alle prese i proprietari di siti WordPress. Alcune di queste sono già stati descritte nelle raccomandazioni relative a PageSpeed viste ​​sopra. Non dimenticate di aggiungere questo post ai segnalibri perché lo aggiorneremo costantemente. Normalmente, se migliorate questi aspetti del vostro sito, dovreste registrare una riduzione dei tempi di caricamento complessivi.

Punteggi YSlow in GTmetrix

Punteggi YSlow in GTmetrix

Fate Meno Richieste HTTP

È solo un po’ di buon senso, ma tutto ciò che carica sul vostro sito web, plugin, immagini, caratteri, ecc. genera una richiesta HTTP. Questo è uno dei motivi per cui non si dovrebbero installare 100 plugin contemporaneamente, perché molto probabilmente invocheranno CSS e JavaScript che a loro volta potrebbero generare centinaia di richieste HTTP. Meno sono e meglio è.

Generare meno richieste HTTP

Generare meno richieste HTTP

Aggiungete gli Header Expires

In base a questo articolo di Google Developers, l’header HTTP Caching: Cache-Control è stato definito come parte della specifica HTTP/1.1 e sostituisce le precedenti intestazioni (in questo caso l’header Expires) utilizzate per definire le politiche di caching della risposta. Tutti i browser moderni supportano Cache-Control, e questo è tutto ciò che serve. Tuttavia non sarà un male avere entrambi, ma ricordate che ne verrà utilizzato solo uno. L’intestazione Expires utilizza una data effettiva, mentre l’intestazione Cache-Control vi consente di specificare un intervallo di tempo prima della scadenza. Ricordate però che, per quanto riguarda gli header, non avete alcun controllo su risorse di terze parti. Nota: gli header Expires vengono automaticamente aggiunti su tutti i server Kinsta.

Aggiungere header Expires

Aggiungere header Expires

Per aggiungere l’intestazione Expires in Apache, è sufficiente inserire il seguente codice nel file .htaccess.

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 7 days"

## EXPIRES HEADER CACHING ##

Per aggiungere le intestazioni Expires in NGINX, aggiungete semplicemente questo codice al vostro file di configurazione.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
}

Utilizzate un Content Delivery Network (CDN)

È abbastanza auto-esplicativo. Consigliamo sempre di utilizzare un CDN, soprattutto se si hanno visitatori da tutto il mondo. Un CDN conserva una copia dei vostri contenuti nella cache su POP situati più vicino al visitatore, cosa che accelera il tempo di caricamento riducendo la latenza. Cloudflare e KeyCDN sono entrambi dei provider CDN altamente raccomandati che potete utilizzare facilmente sul vostro sito WordPress.

Utilizzare un content delivery network

Utilizzare un content delivery network

Utilizzate Domini Senza Cookie

Generalmente, quando offrite contenuti come immagini, JavaScript, CSS, non c’è motivo di associarvi un cookie HTTP, in quanto crea un sovraccarico aggiuntivo. Una volta che il server imposta un cookie per un determinato dominio, tutte le successive richieste HTTP per quel dominio devono includere il cookie. Questo avviso viene generalmente visualizzato su siti che hanno una grande quantità di richieste. Tra i modi che abbiamo per risolvere questo problema, ricordiamo l’utilizzo di un provider CDN che elimina i cookie o imposta un dominio separato o un sottodominio per servire i cookie. Date un’occhiata al nostro post approfondito su come eliminare l’avvisoì sull’utilizzo dei domini senza cookie.

Utilizzare domini cookie-free

Utilizzare domini cookie-free

Riducete i Lookup DNS

Ogni dominio richiesto genera una ricerca DNS la prima volta, fino a quando non viene memorizzato nella cache. Ad esempio, supponete di caricare 10 risorse dalla vostra rete CDN, 2 dai web font di Google e 5 da un singolo inserzionista di terze parti. Ciò comporterebbe 3 risoluzioni DNS, in quanto ciascuno di questi gruppi sta interrogando un singolo dominio. Le ricerche DNS possono rapidamente sfuggire al controllo quando si aggiungono servizi esterni. Un modo per ridimensionare il problema è ospitare i font di Google sul proprio CDN, che si traduce nel liberarsi dei lookup del DNS indirizzandoli verso Google.

Ridurre i lookup del DNS

Ridurre i lookup del DNS

Riducete le Dimensioni delle Favicon e Rendetele Memorizzabili nella Cache

Una favicon, o favicon.ico, è un piccolo file immagine di icona associato al vostro sito web e visualizzato nella barra degli indirizzi del vostro browser (oppure quando lo salvate tra i segnalibri). Anche se le favicon sono molto piccole, dovreste sempre ottimizzarle. Ogni bit risparmiato è di aiuto. KeyCDN ha un ottimo tutorial approfondito su come rendere la vostra favicon piccola e memorizzabile nella cache.

Ridurre la favicon e memorizzarla nella cache

Ridurre la favicon e memorizzarla nella cache

Configurare gli Entity Tag (ETags)

L’header ETag è molto simile all’header last-modified. Anche questo viene utilizzato per convalidare la cache di un file. Se avete in esecuzione Apache 2.4 o versione successiva, l’intestazione ETag viene già aggiunta automaticamente utilizzando la direttiva FileETag. E per quanto riguarda NGINX, dal 2016 l’intestazione ETag è abilitata di default. Se visualizzate questo avvertimento, vi consigliamo di contattare il vostro provider di hosting.

Configurare gli Entity tags (ETags)

Configurare gli Entity tags (ETags)

Diagramma a Cascata di GTmetrix

Il grafico a cascata di GTmetrix mostra tutte le singole richieste presenti sulla vostra pagina web (come mostrato qui sotto). Grsazie a questo diagramma, potrete analizzare ciascuna richiesta per vedere cosa causa ritardi e problemi di prestazioni sul vostro sito. Di seguito sono riportate le definizioni e descrizioni più dettagliate di ciò che significano ciascuno dei colori su ciascuna richiesta.

Diagramma a cascata di GTmetrix

Diagramma a cascata di GTmetrix

Bloccante (Marrone)

Quando un browser carica una pagina web, le risorse JavaScript e CSS di solito impediscono la visualizzazione della pagina finché non vengono scaricate ed elaborate dal browser. Questo ritardo si manifesta come bloccante nel grafico a cascata di GTmetrix. Date un’occhiata al nostro post approfondito su come eliminare JavaScript e CSS che bloccano il rendering per maggiori informazioni.

Bloccante

Bloccante

Ricerca DNS (Verde Acqua)

Potete pensare alla ricerca del DNS come a una ricerca in una rubrica telefonica. Ci sono server chiamati Domain Name Servers che contengono le informazioni del vostro sito web e l’IP su cui deve essere indirizzato. Quando eseguite per la prima volta il vostro sito web tramite GTmetrix, questo esegue una nuova ricerca e deve interrogare i record DNS per ottenere le informazioni sugli IP. Ciò si traduce in un maggior tempo di ricerca.

Primo lookup del DNS in GTmetrix

Quando eseguite il vostro sito tramite GTmetrix una seconda volta, questo avrà memorizzato nella cache il DNS perché conosce già le informazioni sull’IP e non deve eseguire nuovamente la ricerca. Questo è uno dei motivi per cui il vostro sito web potrebbe sembrare più veloce dopo averlo eseguito più volte tramite GTmetrix. Come potete vedere nella schermata qui sotto, al 2° test che abbiamo eseguito, il tempo di ricerca del DNS sul caricamento del DOC iniziale è di 0 ms. Questa è un concetto che molti non comprendono bene! Vi consigliamo di eseguire il test più volte e di fare poi la media, a meno che non vogliate che il DNS faccia parte del vostro report, nel qual caso potete prendere per buono il primo test.

Secondo lookup del DNS in GTmetrix

Secondo lookup del DNS in GTmetrix

Lo stesso vale per le vostre risorse (JavaScript, CSS, immagini) nel caso in cui utilizziate un CDN. Una cache CDN funziona in modo simile al DNS: una volta memorizzata nella cache, è molto più veloce in caricamenti consecutivi. Un altro consiglio su come accelerare il DNS è quello di utilizzare il prefetching del DNS. Ciò consente al browser di eseguire ricerche DNS su una pagina in background. Potete farlo aggiungendo alcune righe di codice all’intestazione del vostro sito WordPress. Ecco alcuni esempi.

<!-- Prefetch DNS for external assets -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.google-analytics.com"> 
<link rel="dns-prefetch" href="//cdn.domain.com">

Oppure, se state utilizzando la versione 4.6 o successiva di WordPress, potreste usare i suggerimenti sulle risorse. Gli sviluppatori possono utilizzare il filtro wp_resource_hints per aggiungere domini e URL personalizzati per dns-prefetch, preconnect, prefetch o prerender.

Connessione (Verde)

Il tempo di connessione in GTmetrix si riferisce alla connessione TCP o al tempo totale necessario per creare una connessione TCP. Non c’è in realtà bisogno di capire come funziona, si tratta semplicemente di un metodo di comunicazione che deve avere luogo tra l’host/client e il server.

Connessione

Connessione

Invio (rosso)

Il tempo di invio è semplicemente il tempo impiegato dal browser per inviare i dati al server.

Invio

Invio

In attesa (Viola)

Il tempo di attesa in GTmetrix si riferisce in realtà al tempo del primo byte, denominato in alcuni strumenti anche come TTFB. Il TTFB è una misura utilizzata come indicatore della reattività di un server web o altra risorsa di rete. Generalmente, qualsiasi valore sotto i 100 ms è accettabile ed è un buon TTFB. Se ci si avvicina all’intervallo di 300-400 ms, è possibile che si sia verificato un errore di configurazione sul server o potrebbe essere il momento di eseguire l’upgrade ad uno stack web superiore. Come potete vedere nel nostro test riportato di seguito, il TTFB è stato di circa 100 ms, che è un risultato ottimo.

Attesa

Attesa

Alcuni semplici modi per ridurre il vostro TTFB sono quello di assicurarvi che il vostro host abbia una corretta memorizzazione nella cache e utilizzi un CDN. Date un’occhiata al nostro post approfondito su tutti le soluzioni utili per ridurre il TTFB sul vostro sito WordPress.

Ricezione (Grigio)

Il tempo di ricezione è semplicemente il tempo impiegato dal browser per ricevere dati dal server.

Ricevimento

Ricevimento

Tempistica degli Eventi

Ogni volta che richiedete una pagina, c’è una tempistica degli eventi durante la quale le risorse vengono caricate e visualizzate.

  • First Paint (Linea Verde): il primo punto in cui il browser esegue qualsiasi tipo di rendering sulla pagina, ad esempio la visualizzazione del colore di sfondo.
  • DOM Loaded (Linea Blu): il punto in cui il DOM (Document Object Model) è pronto.
  • Onload (Linea Rossa): quando l’elaborazione della pagina è completa e tutte le risorse sulla pagina (immagini, CSS, ecc.) hanno completato il download.
  • Fully Loaded (Linea Viola): il momento dopo l’attivazione dell’evento Onload senza che vi sia stata attività di rete per 2 secondi.
Calcolo tempi degli eventi

Calcolo tempi degli eventi

Header di Risposta HTTP

Potete anche fare clic su una singola richiesta per individuare quelle che vengono definite intestazioni delle risposte HTTP. Questo fornisce informazioni preziose. Nella schermata sottostante possiamo vedere immediatamente se gzip è abilitato sul server web, se è in esecuzione su HHVM, se viene servita dalla cache (HIT, sarebbe MISS altrimenti), gli header cache-control, l’architettura del server (questa non è sempre visibile), gli header expires, il browser user-agent e altro ancora.

Header risposta HTTP in GTmetrix

Header risposta HTTP in GTmetrix

Un’altra cosa a cui prestare attenzione è che GTmetrix supporta HTTP/2, a differenza di Pingdom, perché al momento utilizza Chrome 58+ per eseguire i suoi test. Chrome ha aggiunto il supporto HTTP/2 nella versione 49. Quindi tenetelo presente quando scegliete lo strumento di speed test da utilizzare.

Storia

Nella scheda Cronologia potete vedere tutti i vostri test di velocità passati. C’è un limite al numero di quelli che possono essere memorizzati negli account gratuiti. È inoltre possibile monitorare un URL, cosa che permette di tenere traccia delle prestazioni nel tempo e vedere eventuali modifiche quando si verificano.

Storico

Storia

Una funzionalità davvero interessante è quella che vi permette di selezionare i report precedenti e confrontarli fianco a fianco. Questo può essere molto utile, specialmente perché permette di per vedere se ci sono miglioramenti quando si lavora all’ottimizzazione del sito. Ricordate, a volte potete anche ottimizzare troppo.

Confronto report in GTmetrix

Confronto report in GTmetrix

Case Study della Configurazione del Dominio

Se siete arrivati fin qui nella nostra analisi approfondita di GTmetrix, allora siete pronti per una sorpresa. È sempre fastidioso vedere persone condividere consigli e casi di studio, ma poi non condividere il modo in cui ci sono arrivati. Quindi, qui sotto è riportata la nostra esatta configurazione per il dominio del case study utilizzato sopra! Sentitevi liberi di replicarla.

Architettura

  • Il dominio del caso di studio (perfmatters.io) è ospitato su Kinsta su Google Cloud Platform negli USA (Central location). Kinsta utilizza HTTP/2, NGINX, MariaDB, tecnologie che contribuiscono tutte ad ottenere tempi di caricamento rapidi.
  • Il sito utilizza HHVM. PHP 7.3 è ora disponibile su Kinsta, che è persino più veloce di HHVM! È possibile passare alle versioni PHP con la semplice pressione di un pulsante.
  • Il sito non utilizza alcun plugin di caching. Kinsta memorizza tutto nella cache a livello di server, cosa che semplifica enormemente le cose e nella maggior parte dei casi è più veloce!

Plugin di WordPress

E qui c’è una lista dei plugin usati sul sito di WordPress.

  • Il plugin gratuito CDN Enabler è utilizzato per implementare KeyCDN.
  • Il plugin gratuito CAOS è utilizzato per sincronizzare Google Analytics localmente.
  • Il plugin premium perfmatters plugin è utilizzato per far pulizia delle richieste HTTP non necessarie e disattivare cose come gli Emojis e gli Embeds.
  • Il plugin premium Gonzalez è utilizzato per disattivare il caricamento di alcuni script.
  • Il plugin premium Imagify è utilizzato per comprimere le immagini.

Tutorial Consigliati per Approfondire:

Riepilogo

Come potete vedere, sapere come funziona il tool di test della velocità di GTmetrix e conoscere il significato di tutti i grafici può aiutarvi a prendere una decisione basata sui dati per quel che riguarda le prestazioni. Un’analisi a cascata è fondamentale per sapere come vengono caricate le singole risorse. E ricordate, se pensate di metterlo a confronto con Pingdom, che sono strumenti diversi e quindi è meglio utilizzare l’uno o l’altro in quanto effettuano i loro calcoli in modo diverso. Avete altri buoni suggerimenti per GTmetrix?

Se desiderate leggere altri articoli di approfondimento come questo, fatecelo sapere qui sotto nei commenti

51
Condivisioni