Lo Speed Test di Pingdom: Guida Definitiva Per il 2024

Oggi vogliamo analizzare approfonditamente il modo di utilizzare e comprendere al meglio i dati del popolare strumento di test della velocità dei siti web Pingdom. Pingdom può essere utilizzato per fare ciò che chiamiamo un’analisi a cascata del vostro sito WordPress. Questa vi consente di diagnosticare velocemente i problemi di prestazioni, ed anche a non sbagliare diagnosi.

Molte volte vediamo che gli utenti di WordPress interpretano i dati in modo errato nello speed test tool di Pingdom, e questo a volte porta a configurare i siti peggio di com’erano prima. Ricordate che tutti gli strumenti come questo andrebbero utilizzati come guide, e non sono mai precisi al 100%. La cosa importante è essere coerenti e utilizzarli allo stesso modo in tutti i test.

Pingdom

Pingdom è un’azienda con sede in Svezia (ora di proprietà di SolarWinds) che offre una varietà di servizi diversi, come monitoraggio dei tempi di attività, monitoraggio della page speed, monitoraggio delle transazioni, monitoraggio del server e caratteristiche dei visitatori. Probabilmente una delle cose per cui sono più conosciuti è lo strumento gratuito di test della velocità dei siti web. È uno dei più popolari strumenti di test delle prestazioni nella comunità di WordPress.

Perché è così popolare? Bene, prima di tutto è più semplice speed test che potete utilizzare! Non tutti sono esperti di prestazioni web, e per l’utente medio di WordPress, alcuni degli strumenti alternativi potrebbero essere anche un po’ eccessivi. A volte meno è meglio, come suol dire. Dopo tutto, a voi interessano solo due cose: quanto è veloce il vostro sito web e come potete renderlo più veloce..

Pingdom al momento vi permette di testare la velocità di qualsiasi sito web da 7 diverse località (5 continenti) collocati strategicamente nel mondo:

• Asia – Giappone – Tokyo
• Europa – Germania – Francoforte
• Europa – Regno Unito – Londra
• Nord America – USA – Washington D.C.
• Nord America – USA – San Francisco
• Pacifico – Australia – Sydney
• Sus America – Brasile – San Paolo

Nota: Abbiamo notato che occasionalmente non sono disponibili tutte le località di test. Ciò avviene, molto probabilmente, uno dei server è andato giù per manutenzione a causo di un sovraccarico dovuto al numero eccessivo di persone che cercano di eseguire i test. Se una località di test che avete utilizzato non è disponibile, riprovate dopo un’ora o due. Probabilmente riapparirà.

La località di testing che scegliete è in realtà molto importante in quanto riguarda la posizione fisica in cui il vostro sito web è realmente ospitato. Ed è qui che entra in gioco una piccola cosa chiamata latenza di rete. Ma di questo parleremo più in dettaglio più avanti.

Analisi a Cascata con il Test di Velocità di Pingdom

Una pagina web è composta da diverse risorse, come HTML, JavaScript, CSS, immagini e video. Ognuna di queste risorse genera richieste al fine di rendere a video ciò che vedete sul vostro sito web. In genere, più richieste avete, più lento sarà il caricamento del sito. Non è sempre così, ma è vero la maggior parte delle volte.

Qui di seguito analizzeremo ogni sezione di Pingdom e spiegheremo più in dettaglio che cosa significano le informazioni relative alle prestazioni generali del vostro sito web e come eseguire un’analisi a cascata.

• Sommario di Pingdom
• Analisi delle performance
• Codici di risposta
• Dimensioni del contenuto e richieste per tipo di contenuto
• Dimensioni del contenuto e richieste per dominio
• Diagramma a cascata
• Un caso di studio – Configurazione del dominio

Sommario di Pingdom

Quando eseguite il vostro sito WordPress tramite Pingdom, questo genera una valutazione della performance, un tempo di caricamento totale, la dimensione complessiva della pagina e il numero di richieste che avete sul vostro sito web. Nel nostro esempio, utilizziamo il nostro dominio di prova perfmatters.io, un sito di ecommerce su cui gira Easy Digital Download. Il sito è ospitato sui velocissimi server di Kinsta.

Come potete vedere, abbiamo eseguito il nostro primo test e abbiamo ottenuto un punteggio di 88/100 su Pingdom, e il tempo di caricamento complessivo è inferiore a 541 ms. Questo ci fa conoscere la dimensione totale delle nostre risorse combinate e il numero di richieste.

Abbiamo quindi eseguito un test aggiuntivo e ora il nostro tempo di caricamento totale è di 392 ms, con la stessa dimensione di pagina e numero di richieste! Di cosa si tratta? 🤔 Potreste notarlo anche se eseguite più volte il vostro sito web attraverso lo speed test tool di Pingdom. Con siti più grandi si noterebbero differenze ancora maggiori.

Ci sono tre ragioni principali per cui questo accade. caching DNS, caching CDN e caching di WordPress.
Questo è il motivo per cui dovreste sempre eseguire i test più volte. Naturalmente, chiamate esterne a risorse di terze parti e API possono avere la loro influenza. Scoprite perché più in basso nella nostra analisi a cascata.

Volete ottenere un punteggio Pingdom migliore per il vostro sito web WordPress? A seconda del sito e della configurazione, potrebbe non essere sempre possibile ottenere un perfetto punteggio di 100/100, specialmente per coloro che hanno siti di ecommerce e pixel di marketing. Ma dedicare un po’ di tempo a migliorare il punteggio è sufficiente per iniziare. Quello che importa realmente è la velocità complessiva.

A volte l’esperienza utente potrebbe aggirare alcuni trucchi relativi alle prestazioni di cui potreste leggere sul Web. Non potete dimenticarvi della user experience! Ma siatene certi, stiamo per condividere con voi alcuni trucchi e suggerimenti su come abbiamo portato il sito di cui sopra fin dove è arrivato, quindi continuate a leggere.

Analisi delle Performance di Pingdom

La sezione dedicata all’analisi delle prestazioni (Performance insights), ora denominata “Improve page performance” è stata aggiornata nel 2018, sono stati eliminati vecchi elementi e aggiunti di nuovi. Ciò è stato fatto molto probabilmente perché alcuni suggerimenti che riportavano non erano più rilevanti come prima. Quando si tratta di ottimizzazione delle prestazioni, le cose sono in continuo cambiamento. E potrebbe essere a volte fastidioso se la gente sta cercando di raggiungere il punteggio massimo di Pingdom.

Tuttavia, lasciamo questa intera sezione nel nostro post (parti vecchie e nuove) perché è importante comprendere come vengono calcolati questi punteggi. Questi sono tutti basati sulle regole di Google PageSpeed Insight. In genere, se riuscite a migliorare queste regole sul vostro sito, dovreste vedere una diminuzione dei tempi di caricamento complessivi.

Ecco alcune delle categorie di cui si compone la sezione dedicata al miglioramento delle prestazioni delle pagine:

• Utilizzare un Content Delivery Network (CDN)
• Evitare l’Errore HTTP 404 (Not Found)
• Ridurre i Redirect
• Aggiungere gli Header Expires
• Rimuovere le Query Strings dalle Risorse Statiche
• Utilizzare Domini Cookie-Free
• Parallelizzare i Download tra gli Hostname
• Specificare un Cache Validator
• Specify a Vary: Accept-Encoding header

Immergiamoci in alcune di queste e vediamo quali sono ancora rilevanti per noi.

Utilizzare un Content Delivery Network (CDN)

Uno dei servizi più importanti da implementare oggi sul vostro sito WordPress è un Content Delivery Network (CDN). Si tratta di una rete di server (noti anche come POP) situati in tutto il mondo. Sono progettati per ospitare e consegnare copie dei contenuti statici (e talvolta dinamici) del vostro sito WordPress, come immagini, CSS, JavaScript e stream video.

Ai clienti di Kinsta, offriamo un CDN su tutti i nostri piani di hosting. Abilitarlo richiede solo pochi clic. Alcuni vantaggi di un CDN includono un aumento delle prestazioni (minore TTFB e latenza di rete), una minore larghezza di banda e costi di hosting inferiori. Ed anche vantaggi SEO.

I clienti di Kinsta possono anche godere di un impulso rapido e facile all’ottimizzazione generale del loro sito minificando il codice: per farlo potete usare la funzione di minificazione del codice che è integrata nel cruscotto di MyKinsta. Questo permette ai clienti di abilitare la minificazione automatica di CSS e JavaScript con un semplice clic, velocizzando efficacemente i loro siti con zero sforzo manuale.

Importante: il tool appena aggiornato di Pingdom ha un bug che rileva correttamente qualsiasi provider CDN.

Tra i provider di terze parti che consigliamo ci sono:

• KeyCDN (this is what powers the Kinsta CDN)
• Cloudflare
• StackPath
• CDN77

Nei nostri speed test del CDN, abbiamo rilevato che in alcuni casi un CDN può ridurre i tempi di caricamento delle pagine di oltre il 50%!

Evitare l’Errore HTTP 404 (Not Found)

Questa sezione era precedentemente denominata “avoid bad requests”. E questo è sempre importante! Questo avviso è proprio quello che sembra, è una richiesta che non può essere completata con successo. In genere, si verifica quando si collega manualmente un asset o un’immagine che era stata precedentemente eliminata, causando un errore 404. Questo si presenta come un cerchio arancione in Pingdom, insieme a un 404 sullo stato dell’header della risposta.

Assicuratevi sempre che ogni richiesta sul vostro sito ritorni con lo stato di successo. Ciò garantirà che non vengano generate query verso risorse che non esistono più.

Ridurre i Redirect

Bisogna sempre prestare attenzione ai reindirizzamenti eccessivi. I redirect semplici come un singolo redirect 301, da HTTP a HTTPS o da www a non-www (e viceversa) vanno bene. E spesso sono necessari in alcune aree del vostro sito web. Tuttavia, ognuno di questi ha un peso sulle prestazioni del vostro sito. E se iniziate ad aggiungere reindirizzamenti uno sull’altro, è importante capire in che modo questi influiscono sul rendimento del vostro sito. Questo vale per i reindirizzamenti di pagine e post, i reindirizzamenti delle immagini, e per tutto il resto.

Un redirect si presenta come un cerchio blu in Pingdom, insieme a un 301 o 302 sullo stato dell’header di risposta.

Quanto influiscono i reindirizzamenti sul vostro sito? Facciamo un piccolo test. Innanzitutto, eseguiamo un test di velocità sulla nostra pagina di contatto: https://perfmatters.io/contact/. Come potete vedere di seguito, otteniamo un tempo di caricamento totale di 417 ms.

Quindi modifichiamo leggermente l’URL ed eseguiamo un altro test di velocità per vedere l’impatto di reindirizzamenti multipli. http://www.perfmatters.io/contact. Come potete vedere, la stessa pagina ora richiede 695 ms per essere caricata. È un aumento del 66%. Yikes!

Date un’occhiata al nostro post approfondito sui redirect di WordPress e sulle migliori pratiche per avere prestazioni migliori.

Aggiungere gli Header Expires

Questo suggerimento era prima definito “leverage browser caching” (sfrutta il caching del browser). Per dirla da profani, ogni script del vostro sito WordPress ha bisogno HTTP cache header collegato (dovrebbe averlo). Questo stabilisce il momento in cui la cache sul file scade. Per evitare questo avviso, accertatevi che il vostro host WordPress abbia impostato gli header cache-control e expires giusti. Kinsta predispone questi header su tutti i server: date un’occhiata ai passaggi necessari per aggiungere manualmente gli header di caching sul vostro server e leggere la nostra guida su come aggiungere gli expire headers.

L’altro problema è che quando si caricano script di terze parti non si ha accesso per aggiungere le intestazioni della cache, in quanto non si ha alcun controllo sui propri server web. Tra i colpevoli più comuni ci sono lo script di Google Analytics e i pixel di marketing, come Facebook e Twitter. Per risolvere questo problema potete ospitare localmente il vostro script di Google Analytics (anche se questo non è supportato ufficialmente) con un plugin come Perfmatters. Anche WP Rocket ora dispone di un’opzione per ospitare localmente il vostro pixel di marketing di Facebook.

Spostare in locale gli script può avere un effetto diverso sul rendimento del vostro sito. L’unico vantaggio è che avrete il controllo completo sul file e potrete servirlo dal vostro CDN. Ciò elimina anche una richiesta DNS di terze parti. Tuttavia, è importante anche ricordare che questi file potrebbero essere già memorizzati nella cache nei browser dei visitatori.

Leggete il nostro post approfondito su come eliminare l’avviso “leverage browser caching” (sfrutta la cache del browser).

Rimuovere le Query Strings dalle Risorse Statiche

Un altro problema comune è avere a che fare con le query string. I vostri file CSS e JavaScript di solito hanno la versione del file alla fine dei loro URL, come https://domain.com/file.min.css?ver=4.5.3. Alcuni server e proxy server non sono in grado di memorizzare nella cache le query string. Quindi, rimuovendole, è possibile a volte migliorare la cache.

È possibile usare un plugin premium come Perfmatters che ha una facile opzione con un solo clic per rimuovere le query string.

Oppure potete aggiungere il seguente codice manualmente al file functions.php del vostro tema. Un’alternativa migliore sarebbe quella di usare un plugin gratuito come Code Snippets per aggiungere il codice. In questo modo non dovrete modificare direttamente il vostro tema.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
}
add_action('init', 'remove_query_strings');

Tuttavia, prima di andare immediatamente a eliminare le query string sul vostro sito, è importante sapere perché si usano. Il versioning sui file è di solito usato da chi sviluppa in WordPress per aggirare i problemi di caching.

Per esempio, se viene lanciato un aggiornamento e cambiano style.css da ?ver=4.6 a ?ver=4.7, sarà trattato come un URL completamente nuovo e non sarà memorizzato nella cache. Se si rimuovono le query string e si aggiorna un plugin, questo potrebbe far sì che la versione in cache continui a essere servita. In alcuni casi, questo potrebbe rompere l’aspetto del sito fino a quando la risorsa nella cache scade o la cache viene completamente svuotata.

Inoltre, alcuni CDN possono memorizzare nella cache le query string. Il CDN Kinsta può e lo fa per impostazione predefinita. Se siete clienti Kinsta, le query string si trovano già nella cache delle vostre risorse.

Leggete anche il nostro tutorial approfondito cu come rimuovere le strings dalle risorse statiche.

Utilizzare Domini Cookie-Free

Abbiamo un post approfondito su come gestire l’avviso servi il contenuto statico da un dominio senza cookie (Serve static content from a cookieless domain). Molte volte è possibile ignorare questo avviso perché i nuovi protocolli come HTTP/2 lo rendono meno importante. Il costo di una nuova connessione è in genere maggiore rispetto alla trasmissione di tutto sulla stessa connessione. Tuttavia, due soluzioni per risolvere questo problema sono quella di utilizzare un provider CDN che rimuova i cookie, oppure creare un dominio separato e/o un sottodominio.

Comprimere i componenti con GZIP

L’avviso “Compress Components with GZIP” si verifica quando Pingdom rileva un asset che non è stato compresso con GZIP. GZIP è un metodo di compressione usato per ridurre la dimensione di file come i documenti HTML e i file CSS/JS. La compressione GZIP è abilitata sul server e comprime le pagine web e le risorse prima di inviarle a un visitatore. Dai nostri test, abbiamo visto che l’abilitazione della compressione GZIP ha ridotto le dimensioni dei file di una richiesta di oltre il 78%.

Su Kinsta, non dovrete preoccuparvi di abilitare GZIP manualmente perché è già abilitato di default su tutti i nostri server. Se notate che il vostro web host non ha abilitato GZIP, vi consigliamo di contattare il loro team di supporto per abilitarlo immediatamente perché può avere un enorme impatto sulla velocità delle vostre pagine. Se vedete ancora l’avviso “Compress Components with GZIP” dopo aver abilitato GZIP sul vostro server, è possibile che un server che ospita un asset esterno richiesto dal vostro sito non abbia GZIP abilitato. In questo caso, non c’è nulla che si possa fare per cambiare il comportamento del server.

Parallelizzare i Download tra gli Hostname

L’avviso “Parallelize Downloads Across Hostnames” viene generato a causa di un limite di HTTP/1.1 e dei browser web che non possono superare un certo numero di connessioni simultanee verso un host; in genere sono 6 connessioni. Questo avviso viene generalmente visualizzato su siti web con un numero elevato di richieste. In passato, l’unico modo per aggirare questo limite era implementare quello che chiamano sharding del dominio. Tuttavia, se si utilizza un host web o un provider CDN che supporta HTTP/2, è possibile ignorare questo avviso in quanto ora è possibile caricare più risorse in parallelo su una singola connessione. Su questo argomento potete leggere anche il nostro tutorial su come eliminare l’avviso Parallelize Downloads Across Hostnames implementando il domain sharding.

Specificare un Cache Validator

Questo avviso si riferisce a header di cache HTTP mancanti, i quali dovrebbero essere inclusi in ogni risposta del server di origine, poiché convalidano e impostano l’ampiezza della cache. Se le intestazioni non vengono trovate, sarà generata una nuova richiesta per la stessa risorsa ogni volta, il che aumenta il carico sul server. In queste intestazioni sono comprese last-modified, ETag, Cache-Control e Expires. Allo stesso modo dell’avviso “leverage browser caching”, questi header dovrebbero essere aggiunti automaticamente dall’host di WordPress. Se avete richieste di terze parti su cui vedete questo avviso, non c’è niente che possiate fare dato che non avete il controllo dei loro server.

Si legga il nostro post approfondito su come eliminare l’avviso specify a cache validator.

Specify a Vary: Accept-Encoding header

Abbiamo un post approfondito su come eliminare l’avviso Specify a Vary: Accept-Encoding header. Questa è un’intestazione HTTP che dovrebbe essere inserita in ogni risposta del server di origine, in quanto indica al browser se il client può gestire le versioni compresse del contenuto. Questa intestazione è aggiunta automaticamente su tutti i server di Kinsta.

I Codici di Risposta di Pingdom

La sezione successiva del tool di Pingdom riguarda i codici di risposta. Questi, anche noti come HTTP status code, sono una specie di breve nota inviata dal server web che viene aggiunta all’inizio di una pagina web. È un messaggio del server che vi dice come vanno le cose quando si riceve una richiesta di visualizzazione di una pagina. Alcuni codici frequenti sono:

• 200: “É tutto OK”. Questo è il codice che viene consegnato quando una pagina web o una risorsa si comporta esattamente come previsto.

  

• 301: “La risorsa richiesta è stata spostata permanentemente”. Questo codice viene consegnato quando una pagina web o una risorsa sono state sostituite in modo permanente con una risorsa diversa. Viene utilizzato per il reindirizzamento permanente delle URL.

  

• 404: “La risorsa richiesta non è stata trovata”. Il messaggio di errore più frequente di tutti. Questo codice indica che la risorsa richiesta non esiste e che il server non sa nemmeno se sia mai esistita.

  

Potete leggere di più su tutti i diversi codici di risposta nel nostro post approfondito sui codici di stato HTTP.

Dimensioni del contenuto e richieste per tipo di contenuto

Le sezioni successive riguardano le dimensioni del contenuto e le richieste per tipo di contenuto. Ognuna di queste informazioni è utile per individuare rapidamente cosa assorbe più risorse sulla vostra pagina web. Secondo HTTP Archive, le immagini in genere rappresentano in media il 43% delle dimensioni totali di una pagina web. Anche noi possiamo testimoniare che normalmente è così. Comunque, come potete vedere nel sito qui sotto, non è proprio sempre così.

Per ottimizzare le vostre immagini, vi consigliamo vivamente di leggere il nostro post approfondito su come ottimizzare le immagini per il web e su WebP. In giro ci sono molti ottimi strumenti e plugin per comprimere le vostre immagini e assicurarvi che non costituiscano il grosso del carico delle pagine del vostro sito web. E nel caso riportato qui sopra, il sito perfmatters.io si avvantaggia molto dell’uso di grandi icone di Font Awesome al posto delle immagini. Questa può essere un’ottima strategia che può fare una grande differenza. E, naturalmente, abbiamo alcuni suggerimenti aggiuntivi nella nostra guida sulla page speed su come ridurre ulteriormente la dimensione dei contenuti.

Dimensioni del contenuto e richieste per dominio

La sezione dedicata alla dimensione del contenuto e alle richieste per dominio costituisce un ottimo strumento per individuare rapidamente i servizi esterni e gli script presenti nel vostro sito web. Nel nostro esempio, potete vedere che tutte le nostre risorse sono caricate dal nostro CDN. Poi c’è il caricamento iniziale HTML DOC per il sito dal server web, e una chiamata esterna al dominio di Google Analytics. Nel vostro sito potreste avere molti più servizi esterni, come Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, ecc.

Generalmente, è meglio avere il minor numero possibile di richieste esterne, perché ogni servizio esterno aggiunge la propria latenza, ritardi di handshake TLS, risoluzione del DNS, ecc. Ricordatevi di leggere il nostro post approfondito su come identificare e analizzare i servizi esterni sul vostro sito WordPress.

In genere, è meglio ridurre il più possibile il numero di richieste e ospitare le risorse in un’unica posto, ad esempio spostandole sul vostro server o sulla vostra CDN. Un esempio è Font Awesome. Invece di creare un collegamento allo script esterno, scaricatelo e servitelo direttamente.

Diagramma a cascata di Pingdom

E, ultimo ma non meno importante, abbiamo la sezione delle richieste dello strumento di speed test di Pingdom, che genera un diagramma a cascata di tutte le singole richieste relative alla vostra pagina web (come mostrato di seguito). Qui potete analizzare ciascuna richiesta per vedere cosa causa ritardi e problemi di prestazioni sul vostro sito. Questo è quanto intendiamo quando diciamo che stiamo facendo un’analisi a cascata. Di seguito è riportato un riepilogo e/o una descrizione più approfondita di ciò che significano i colori di ogni stato.

DNS (Rosa)

Allora, cos’è il DNS? Beh, immaginatelo come un elenco telefonico. Ci sono dei server chiamati Domain Name Server che contengono le informazioni che riguardano il vostro sito web e su quale IP questo debbae essere indirizzato. Quando eseguite per la prima volta il vostro sito web su Pingdom, questo esegue una nuova ricerca e deve interrogare i record DNS per ottenere le informazioni sull’IP. Ciò rende necessario un po’ di tempo in più per la risoluzione. Anche la località del server DNS è importante.

Quando eseguite il vostro sito web tramite Pingdom più di una volta, questo memorizza 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 appare più veloce quando lo eseguite più volte su Pingdom.

Come potete vedere nella schermata qui sotto, nel secondo test che abbiamo eseguito, il tempo di risoluzione del DNS sul caricamento del DOC iniziale è pari a 3,6 ms. Normalmente questo scende a 0 ms, e dovrebbe farlo, dato che la richiesta è già nella cache. Questo è un punto che molti non comprendono bene!

É possibile ottimizzare questo valore utilizzando un servizio di DNS premium, che tra l’altro viene fornito con molti vantaggi aggiuntivi. Anche il nostro DNS gratuito di Cloudflare è veloce! Dai un’occhiata all’ottimizzazione automatica della piattaforma di Cloudflare.

Ci sono anche altri motivi per cui il vostro sito web potrebbe apparire più veloce dopo numerosi test. Uno di questi è l’utilizzo di un Content Delivery Network (CDN). Per chi non ha familiarità con i CDN, si tratta di una rete di server globali che memorizzano i contenuti nella cache (JS, CSS, Immagini, ecc.) in località più prossime al visitatore. Quando eseguite per la prima volta il vostro sito web su Pingdom, questo potrebbe dover prelevare risorse fresche dal CDN. Una cache di CDN funziona in modo simile al DNS: una volta che una risorsa è nella cache, è molto più veloce nei caricamenti successivi.

Un altro consiglio su come accelerare il DNS è usare il prefetching del DNS. Questo 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 utilizzare i Resource Hints. Gli sviluppatori possono utilizzare il filtro wp_resource_hints per aggiungere domini personalizzati e URL per dns-prefetch, preconnect, prefetch o prerender.

SSL (viola)

Il colore di stato viola indica il tempo impiegato dal browser per eseguire un handshake SSL/TLS. Ogni volta che si esegue un sito web su HTTPS, significa che è coinvolto un certificato SSL, e sono necessari tempi supplementari dovuti al processo di crittografia (handshake SSL/TLS). Nel nostro dominio di esempio, abbiamo un certificato sia sul nostro server web di Kinsta che sul nostro CDN, KeyCDN. Quindi esiste un tempo di negoziazione SSL sia sui documenti HTML iniziali caricati dal server, sia sulle nostre risorse.

Sebbene ci sia un leggero sovraccarico nell’esecuzione di HTTPS, questo è ora trascurabile grazie ad HTTP/2, che è un nuovo protocollo che aiuta ad accelerare il web! Dato che i browser supportano HTTPS, è necessario utilizzare HTTP/2. Consultate la nostra guida definitiva ad HTTP/2.

È anche importante notare che non tutti i provider supportano ancora HTTP/2. Questo sia dal lato del web hosting, che dal lato del CDN. Quindi, quando fate acquisti in giro alla ricerca di hosting e CDN, accertatevi che sia supportato! Kinsta è orgogliosa di offrire il supporto di HTTP/2 per tutti i suoi client WordPress.

A metà del 2018, Pingdom ha finalmente aggiornato il tool per l’utilizzo di Chrome 60 e vesioni superiori. Potete vedere lo user-agent in funzione nell’header della richiesta. In precedenza utilizzavano Chrome 39, e Chrome non ha supportato HTTP/2 fino alla versione 49. Così siamo proprio contenti di poter affermare che il tool di Pingdom ora mostra tutti i vantaggi di HTTP/2 quando si eseguono i test!

Connect (turchese)

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

Wait (giallo)

Il tempo di attesa in Pingdom si riferisce in realtà al tempo al primo byte, noto in altri tool anche come TTFB. Il TTFB è una misura utilizzata come indice della reattività di un server Web o di un’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’aggiornamento a una tecnologia web superiore.

Qual è il modo più semplice per ridurre il proprio TTFB? I due modi migliori sono una cache di WordPress efficace e un CDN. Facciamo un paio di test.

TTFB Senza la Cache dell’Host di WordPress

Per prima cosa abbiamo eseguito un test dopo aver svuotato la cache sul nostro sito WordPress. Questo significa che Pingdom doveva caricare la cache di nuovo. Come potete vedere, il nostro tempo complessivo di caricamento è stato di 541ms e il TTFB (tempo di attesa) della nostra richiesta iniziale è stato di 185,2 ms.

TTFB Con la Cache dell’Host di WordPress

Abbiamo quindi eseguito di nuovo il test. Ora il sito viene servito direttamente dalla cache. Come potete vedere, i nostri tempi di caricamento totali sono scesi a 392 ms e il TTFB della nostra richiesta iniziale è adesso di 52,8 ms! Questa è la differenza che fa la cache.

Se avete un sito web che serve visitatori in diverse parti del paese, o del mondo, un altro semplice modo di ridurre drasticamente il vostro TTFB è utilizzare un CDN. Anche in questo caso abbiamo eseguito alcuni test per mostrarvi la differenza.

TTFB senza CDN

Per prima cosa abbiamo eseguito un test con il nostro CDN disattivato e, come potete vedere, il nostro tempo di caricamento complessivo è stato di 1,93 s e il nostro TTFB medio su una risorsa è stato di circa 176 ms.

TTFB con CDN

Abbiamo quindi abilitato il nostro CDN e abbiamo eseguito di nuovo il test. Come potete vedere, i nostri tempi di caricamento totali sono scesi a 1,21 s e il nostro TTFB medio su una risorsa sul CDN è ora di 4,6 ms! Che differenza può fare una CDN.

Un’altra cosa importante da notare è che abbiamo scelto la località “Pacific – Australia – Sydney” per eseguire questo test. Perché? Perché volevamo mostrarvi il miglioramento concreto che si può ottenere. Il nostro sito WordPress in questo esempio è ospitato da Kinsta su Google Cloud e si trova in una posizione centrale negli Stati Uniti. Eseguendo il test sull’Australia, siamo stati in grado di mostrare come la memorizzazione nella cache del CDN di Kinsta aumenta la velocità e riduce il TTFB.

E, naturalmente, anche avere un buon host WordPress con un’architettura attentamente studiata è fondamentale per ridurre il tuo TTFB.

Send (arancione) e Receive (verde)

Gli stati di invio e ricezione in Pingdom non necessitano in realtà di molte spiegazioni. Il tempo di invio è semplicemente il tempo impiegato dal browser per inviare dati al server. E il tempo di ricezione è il tempo necessario al browser web per ricevere dati dal server. Entrambi saranno in genere molto bassi o inesistenti nei test.

HTTP Response Headers

Potete anche fare clic su una singola richiesta mentre fate la vostra analisi a cascata e vedere gli header delle risposte HTTP. Questo vi permette di ottenere informazioni preziose. Nella schermata che segue, possiamo vedere immediatamente se gzip è abilitato sul server web, se viene servito dalla cache (HIT, mostrerebbe MISS in caso contrario), gli header cache-control, gli header expires, lo user-agent del browser e altro ancora.

Un caso di studio – Configurazione del dominio

Se siete arrivati fin qui nel nostro post di analisi a cascata, allora siete pronti per una sorpresa. È sempre fastidioso che qualcuno condivida consigli e casi di studio, ma poi non condivida il modo in cui è arrivato a quei risultati. Quindi qui sotto è riportata l’esatta configurazione del dominio del case study riportato sopra! Sentitevi liberi di replicarla.

Architettura

• Il dominio del case study (perfmatters.io) è ospitato da Kinsta su Google Cloud Platform negli Stati Uniti (Council Bluffs, Iowa, USA – us-central1). Kinsta offre al momento 37 diversi data center tra cui scegliere. Il network di livello premium di GCP è compreso in tutti i nostri piani e garantisce una latenza di rete estremamente veloce.
• Kinsta utilizza HTTP/2, Nginx, MariaDB, i quali contribuiscono tutti alla riduzione dei tempi di caricamento.
• Il sito utilizza KeyCDN, che alimenta il CDN di Kinsta. Ampiezza di banda del CDN gratuita è in tutti i nostri piani.
• Il sito non utilizza alcun plug-in di caching. Kinsta memorizza tutto nella cache a livello del server, che semplifica enormemente le cose!
• Il sito utilizza PHP 7.3. Le nuove versioni di PHP mostrano sempre grandi miglioramenti nelle prestazioni. Date un’occhiata a questi benchmark PHP. Kinsta vi permette di cambiare versione con il click di un pulsante.

Plugin e Temi di WordPress

E qui c’è una lista dei plugin che influenzano le performance e che sono stati utilizzati nel sito ecommerce WordPress.

• Perfmatters, sviluppato da un membro del team di Kinsta. Questo si sbarazza di richieste HTTP non necessarie, come gli embed e gli emojis, e dispone anche di uno script manager che permette di attivare/disattivare script specifici dal caricamento in base al post, alla pagina o a livello di intero sito.
• Il plugin premium Imagify viene utilizzato per comprimere le immagini.
• Il plugin gratuito Safe SVG è utilizzato per caricare immagini SVG sul sito WordPress.
• Il tema premium GeneratePress è stato utilizzato nello sviluppo del sito EDD.

Tutorial di Approfondimento:

• Come Eliminare JavaScript e CSS che Boccano la Visualizzazione della Pagina
• Come Disattivare gli Emojis in WordPress
• Come Disabilitare gli Embeds in WordPress
• Come ottenere 100/100 in Google PageSpeed Insights con WordPress
• Come Individuare un Alto Utilizzo di Admin-Ajax nel Vostro Sito WordPress

Riepilogo

Come potete vedere, sapere un po’ meglio come funziona lo speed test di Pingdom e cosa si può desumere da tutti quei grafici può aiutare a prendere una decisione maggiormente basata sui dati per quello che riguarda le performance. Quella che viene definita analisi a cascata è fondamentale per sapere di più sul caricamento delle singole risorse e come questo viene influenzato dal vostro host WordPress, dalla collocazione fisica, da un CDN, ecc. Avete altri buoni consigli su Pingdom?

Se desiderate leggere altri articoli di approfondimento come questo, vi preghiamo di farcelo sapere nei commenti qui sotto!