Lo speed test di Pingdom: guida definitiva

Oggi vogliamo approfondire come utilizzare e comprendere meglio i dati del popolare strumento di test della velocità dei siti Pingdom. Puoi usarlo per fare un’analisi a cascata del tuo sito web WordPress. Questo può aiutarti a individuare rapidamente i problemi di prestazioni ed evitare di formulare una diagnosi errata.

Vediamo spesso che gli utenti di WordPress interpretano male i dati dello speed test Pingdom, il che a volte porta a configurare un sito web in uno stato ancora peggiore di quello precedente. Ricorda che tutti gli strumenti di questo tipo devono essere utilizzati come guide. Non sono mai precisi al 100%. L’importante è essere coerenti e utilizzare lo stesso strumento per tutti i test.

Cos’è lo strumento per lo speed test di Pingdom?

Pingdom è un’azienda con sede in Svezia (ora di proprietà di SolarWinds) che offre diversi servizi, come il monitoraggio dei tempi di attività, il monitoraggio della velocità delle pagine, il monitoraggio delle transazioni, il monitoraggio dei server e l’analisi dei visitatori (RUM). Una delle cose per cui sono più conosciuti è il loro strumento gratuito per il test della velocità dei siti web. È uno degli strumenti di verifica delle prestazioni più popolari nella comunità di WordPress.

Perché è così popolare? Innanzitutto, è probabilmente lo strumento di test di velocità più facile da usare! Non tutti sono esperti di prestazioni web, per cui alcuni degli strumenti alternativi disponibili possono risultare piuttosto complicati per l’utente tipico di WordPress. A volte, meno è meglio, come si suol dire. In fondo, a te interessa solo sapere quanto è veloce il tuo sito web e come renderlo più veloce.

Attualmente Pingdom permette di testare la velocità di qualsiasi sito web da 7 diverse località (5 continenti) posizionate strategicamente in tutto il 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
• Sud America – Brasile – San Paolo

Nota: abbiamo notato che a volte non tutte le postazioni di prova sono disponibili. Ciò è dovuto probabilmente al fatto che il sito è stato interrotto per manutenzione o è stato sovraccaricato da troppe persone che hanno cercato di eseguire dei test. Se una postazione di prova che hai utilizzato non è più presente, torna a controllare dopo un’ora o due. Molto probabilmente riapparirà.

Il sito di test che scegli è fondamentale per la posizione fisica in cui è ospitato il tuo sito web. Qui entra in gioco una piccola cosa chiamata latenza di rete. Ma ne parleremo più in dettaglio qui di seguito.

Analisi a cascata con lo strumento di test della velocità di Pingdom

Una pagina web comprende diverse risorse, come HTML, JavaScript, CSS, immagini e video. Ognuno di questi genera richieste per il rendering di ciò che vedi sul tuo sito web. In genere, maggiore è il numero di richieste, più lento sarà il caricamento del sito web. Non è sempre così, ma nella maggior parte dei casi, sì.

Qui di seguito, suddivideremo ogni sezione di Pingdom e spiegheremo in modo più dettagliato il significato delle informazioni relative alle prestazioni complessive del tuo sito web e come effettuare un’analisi a cascata.

• Riepilogo Pingdom
• Approfondimenti sulle prestazioni
• Codici di risposta
• Dimensioni del contenuto e richieste per tipo di contenuto
• Dimensioni del contenuto e richieste per dominio
• Grafico a cascata
• Caso di studio Configurazione del dominio

Riepilogo di Pingdom

Quando esegui l’analisi del tuo sito WordPress tramite Pingdom, viene generato un voto sulle prestazioni, il tempo di caricamento totale, la dimensione totale della pagina e il numero di richieste del sito. Nel nostro esempio, si tratta di un sito di ecommerce con Easy Digital Downloads. È ospitato sui velocissimi server di Kinsta.

Come puoi vedere, abbiamo eseguito il nostro primo test e abbiamo ottenuto un punteggio di 88/100 su Pingdom, mentre il tempo di caricamento totale è di 541 ms. Ci permette di conoscere la dimensione totale delle nostre risorse combinate e il numero di richieste.

Abbiamo poi eseguito un ulteriore test e ora il nostro tempo di caricamento totale è di 392 ms con le stesse dimensioni di pagina e lo stesso numero di richieste! Ma cosa significa? Potresti notare la stessa cosa se esegui più volte il test di velocità di Pingdom sul tuo sito web. I siti più grandi noteranno differenze ancora maggiori.

I motivi principali per cui ciò accade sono tre: la cache DNS, la cache CDN e la cache di WordPress. Ecco perché dovresti sempre eseguire i test più volte. Naturalmente, anche le chiamate esterne a risorse e API di terze parti possono avere un impatto su questo aspetto. Scopri perché più avanti nella nostra analisi a cascata.

Vuoi ottenere un punteggio Pingdom migliore sul tuo sito WordPress? A seconda del sito e della configurazione, potrebbe non essere sempre possibile ottenere un punteggio perfetto di 100/100, soprattutto per chi gestisce siti di e-commerce e pixel di marketing. Tuttavia, passare un po’ di tempo a cercare di migliorare il proprio punteggio è un ottimo punto di partenza. L’importante è la velocità complessiva.

A volte l’esperienza dell’utente può avere la meglio su alcuni trucchi per le prestazioni web che si leggono in giro per il web. Non puoi dimenticarti dell’esperienza dell’utente! Ma non preoccuparti, più avanti condivideremo alcuni consigli e trucchi su come abbiamo portato il sito di cui sopra al punto in cui si trova, quindi continua a leggere.

WinningWP ha condotto dei test di velocità indipendentemente, confrontando Kinsta con altri importanti fornitori di hosting e ha scoperto che Kinsta è “molto più veloce”, con un tempo medio di appena 394 ms.

Migliorare le prestazioni delle pagine

La sezione delle prestazioni, ora “Improve page performance”, è stata aggiornata nel 2018, con la rimozione di alcuni vecchi elementi e l’aggiunta di nuovi. Molto probabilmente questo è dovuto al fatto che alcuni dei suggerimenti che venivano segnalati non sono più rilevanti come un tempo. Quando si parla di ottimizzazione delle prestazioni web, le cose cambiano continuamente. E a volte può essere problematico se le persone cercano semplicemente di ottenere il punteggio Pingdom perfetto.

Tuttavia, lasciamo tutta questa sezione nel nostro post, perché è fondamentale capire come vengono calcolati questi punteggi. Questi si basano essenzialmente sulle regole di Google PageSpeed Insight. In linea di massima, se migliori queste regole sul tuo sito, dovresti ridurre i tempi di caricamento complessivi.

Ecco alcune categorie della sezione “Migliora le prestazioni della pagina”:

• Utilizzare una rete di distribuzione dei contenuti (CDN)
• Evitare l’errore HTTP 404 (Not Found)
• Ridurre al minimo i reindirizzamenti
• Aggiungere gli header Expires
• Rimuovere le stringhe di query dalle risorse statiche
• Usare domini senza cookie
• Parallelizzare i download tra i vari nomi host
• Specificare un validatore di cache
• Specificare un’intestazione Vary: Accept-Encoding

Ora approfondiamo alcuni di questi aspetti e vediamo quali sono ancora attuali.

Utilizzare una rete di consegna dei contenuti (CDN)

Uno dei servizi più importanti da implementare sul tuo sito WordPress è il 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 distribuire copie dei contenuti statici (e talvolta dinamici) del tuo sito WordPress, come immagini, CSS, JavaScript e flussi video.

Se sei cliente Kinsta, includiamo un CDN nei nostri piani di hosting. Per attivarlo bastano pochi clic. I vantaggi di un CDN includono un aumento delle prestazioni (TTFB e latenza di rete più bassi), una riduzione dei costi di banda e di hosting e persino vantaggi SEO.

Importante: lo strumento Pingdom, recentemente aggiornato, presenta attualmente un bug nel rilevare correttamente qualsiasi provider CDN.

Alcuni fornitori di CDN di terze parti che consigliamo sono:

• KeyCDN (è quello che gestisce il CDN di Kinsta)
• Cloudflare
• CDN77

Nei nostri test sulla velocità dei CDN, abbiamo scoperto che un CDN può ridurre i tempi di caricamento delle pagine di oltre il 50% in alcuni casi!

Evitare l’errore HTTP 404 (Not Found)

Questa sezione si chiamava “avoid bad requests”. E questo è sempre importante! Questo avviso è esattamente quello che sembra: si tratta di una richiesta che non ha potuto essere completata con successo. In genere questo accade quando si collega manualmente una risorsa o un’immagine che nel frattempo è stata cancellata, con conseguente errore 404. Questo errore viene visualizzato come un cerchio arancione in Pingdom, insieme a un 404 nell’intestazione della risposta.

Assicurati sempre che ogni richiesta sul sito abbia uno stato di successo. In questo modo si eviterà che vengano generate query verso risorse che non esistono più.

Ridurre al minimo i reindirizzamenti

Un numero eccessivo di reindirizzamenti è sempre un aspetto da tenere sotto controllo. I reindirizzamenti semplici come un singolo reindirizzamento 301, da HTTP a HTTPS o da www a non-www (viceversa) sono accettabili. E spesso sono necessari in alcune aree del sito web. Tuttavia, ognuno di essi ha un costo sulle prestazioni del tuo sito. Se cominci ad accumulare redirect uno sopra l’altro, è fondamentale capire quale sia il loro impatto sulle prestazioni del sito. Questo vale per i reindirizzamenti di pagine e post, per i reindirizzamenti di immagini, per tutto.

Un reindirizzamento viene visualizzato come un cerchio blu in Pingdom, insieme a un 301 o 302 sullo stato dell’header della risposta.

Quanto incidono i reindirizzamenti sul tuo sito? Facciamo un piccolo test. Per prima cosa eseguiamo un test di velocità sulla nostra pagina di contatto. Il tempo di caricamento totale è di 417 ms, come puoi vedere qui sotto.

Modifichiamo poi leggermente l’URL ed eseguiamo un altro test di velocità per vedere l’impatto dei reindirizzamenti multipli. Come puoi vedere, la stessa pagina ora impiega 695 ms per essere caricata. Si tratta di un aumento del 66%.

Dai un’occhiata al nostro post di approfondimento sui reindirizzamenti di WordPress e alle best practice per ottenere prestazioni più veloci.

Aggiungere gli header Expires

Questo suggerimento prima si chiamava “leverage browser caching”. In parole povere, ogni script del tuo sito WordPress ha bisogno di un header HTTP di cache (o almeno dovrebbe). Questo determina quando la cache del file scade. Per risolvere questo problema, assicurati che il tuo host WordPress abbia impostato correttamente le intestazioni cache-control e expires. Kinsta dispone di queste intestazioni su tutti i nostri server.

Scopri come aggiungere gli header di cache al tuo server manualmente e leggi la nostra guida su come aggiungere le intestazioni di scadenza.

L’altro problema è che non hai la possibilità di aggiungere gli header di caching quando carichi script di terze parti, poiché non hai alcun controllo sui loro server web. I colpevoli più comuni sono lo script di Google Analytics e i pixel di marketing, come quelli di Facebook e Twitter. Per risolvere questo problema, puoi ospitare lo script di Google Analytics in locale (anche se non è ufficialmente supportato) con un plugin di terze parti. WP Rocket ha anche un’opzione per ospitare localmente il pixel di marketing di Facebook.

Lo spostamento degli script in locale può avere un impatto diverso sulle prestazioni del sito. L’unico vantaggio è che hai il controllo completo del file e puoi servirlo dal tuo CDN. Inoltre, in questo modo si elimina un’altra richiesta di DNS da parte di terzi. Tuttavia, è importante ricordare che questi file potrebbero essere già presenti nella cache dei browser degli utenti.

Consulta il nostro post di approfondimento su come risolvere l’avviso di cache del browser.

Rimuovere le stringhe di query dalle risorse statiche

Un altro problema comune è quello delle stringhe di query. I tuoi file CSS e JavaScript di solito hanno la versione del file alla fine dei loro URL, come ad esempio https://domain.com/file.min.css?ver=4.5.3. Alcuni server e proxy server non sono in grado di memorizzare nella cache le stringhe di query. Per questo motivo, rimuovendole, a volte è possibile migliorare la cache.

In alternativa, puoi aggiungere manualmente il seguente codice al file functions.php del tuo tema. Un’alternativa migliore è quella di utilizzare un plugin gratuito come Code Snippets per aggiungere il codice. In questo modo, non dovrai modificare direttamente il tuo 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 eliminare immediatamente le stringhe di query dal tuo sito, è importante sapere perché vengono utilizzate. Gli sviluppatori di WordPress utilizzano il versioning dei file per ovviare ai problemi di caching.

Ad esempio, se effettuano un aggiornamento e cambiano style.css da ?ver=4.6 a ?ver=4.7, questo verrà trattato come un URL completamente nuovo e non verrà memorizzato nella cache. Se rimuovi le stringhe di query e aggiorni un plugin, la versione in cache potrebbe continuare a essere utilizzata. In alcuni casi, questo potrebbe compromettere l’aspetto del tuo sito finché la risorsa in cache non scade o la cache non viene completamente svuotata.

Inoltre, alcuni CDN possono memorizzare nella cache le stringhe di query. Il CDN Kinsta può farlo e lo fa per impostazione predefinita. Quindi, se sei cliente di Kinsta, le stringhe di query sono già memorizzate nella cache delle tue risorse.

Consulta il nostro tutorial approfondito su come rimuovere le stringhe di query dalle risorse statiche.

Utilizzare domini senza cookie

Abbiamo un post approfondito su come gestire l’avviso di servire contenuti statici da un dominio senza cookie. Spesso puoi ignorare questo avviso perché i nuovi protocolli, come HTTP/2, lo rendono meno importante. Una nuova connessione è di solito più costosa rispetto allo streaming di tutto sulla stessa connessione. Tuttavia, due modi per risolvere questo problema sono l’utilizzo di un provider CDN che elimina i cookie o la creazione di un dominio o sottodominio separato.

Per maggiori informazioni, consulta il nostro post su come utilizzare i domini senza cookie.

Comprimere i componenti con GZIP

L’avviso “Compress Components with GZIP” si verifica quando Pingdom rileva una risorsa che non è stata compressa con GZIP. GZIP è un metodo di compressione utilizzato per ridurre le dimensioni dei file di testo come i documenti HTML e i file CSS/JS. La compressione GZIP viene attivata sul server e comprime le pagine web e le risorse prima di inviarle ai visitatori. Dai nostri test, abbiamo visto che l’attivazione della compressione GZIP ha ridotto le dimensioni dei file di una richiesta di oltre il 78%.

Con Kinsta non dovrai preoccuparti di abilitare GZIP perché ogni sito Kinsta beneficia già della compressione Brotli, un’alternativa più veloce alla compressione GZIP. Tutto questo grazie alla nostra esclusiva integrazione con Cloudflare. Ciò significa che il tuo sito ospitato su Kinsta è più veloce della concorrenza che utilizza GZIP e si carica rapidamente per chi utilizza dispositivi più piccoli.

Se dopo aver abilitato GZIP sul tuo server vedi ancora la scritta “Compress Components with GZIP”, è possibile che il server che ospita una risorsa esterna necessaria al tuo sito non abbia abilitato la compressione GZIP o Brotli. In questo caso, non c’è nulla che tu possa fare per modificare il comportamento del server.

Parallelizzare i download tra i vari hostname

L’avviso “Parallelize Downloads Across Hostnames” deriva da una limitazione di HTTP/1.1 e dal fatto che i browser web sono limitati nel numero di connessioni contemporanee che possono effettuare a un host; in genere si tratta di sei connessioni. Questo avviso viene visualizzato in genere sui siti web con un gran numero di richieste. In passato, l’unico modo per aggirare questa limitazione era quello di implementare quello che viene chiamato domain sharding.

Tuttavia, supponiamo che tu utilizzi un host web o un provider CDN che supporti HTTP/2. In questo caso, puoi tranquillamente ignorare questa limitazione perché ora è possibile caricare più risorse in parallelo su un’unica connessione. Ma puoi anche dare un’occhiata al nostro tutorial su come risolvere l’avviso di download parallelizzato tra nomi di host implementando il domain sharding.

Specificare un validatore di cache

Questo avviso si riferisce alle intestazioni mancanti della cache HTTP che dovrebbero essere incluse in ogni risposta del server di origine, in quanto convalidano e impostano la lunghezza della cache. Se gli header non vengono trovati, verrà generata ogni volta una nuova richiesta per la risorsa, aumentando il carico del tuo server. Questi header includono last-modified, ETag, Cache-Control ed Expires. Come nel caso dell’avviso di caching del browser, il tuo host WordPress dovrebbe aggiungere automaticamente queste intestazioni. Se hai delle richieste di terze parti per le quali stai riscontrando questo problema, non puoi fare nulla in quanto non hai il controllo sui loro server web.

Leggi il nostro post di approfondimento su come risolvere l’avviso di specificare un validatore di cache.

Specifica un header Vary: Accept-Encoding

Abbiamo un post approfondito su come risolvere l’avviso Specify a Vary: Accept-Encoding. Si tratta di un’intestazione HTTP che dovrebbe essere inclusa in ogni risposta del server di origine, in quanto indica al browser se il client è in grado di gestire versioni compresse del contenuto. Questo viene aggiunto automaticamente a tutti i server di Kinsta.

Codici di risposta Pingdom

La sezione seguente dello strumento di test della velocità di Pingdom è quella dei codici di risposta. I codici di risposta, noti anche come codici di stato HTTP, sono come una breve nota del server web che viene apposta in cima a una pagina web. Si tratta di un messaggio del server web che ti informa su come sono andate le cose quando è stata ricevuta la richiesta di visualizzare la pagina. Alcuni codici comuni sono:

• 200: “Tutto ok”. È il codice inviato quando una pagina web o una risorsa si comporta esattamente come ci si aspetta.

  

• 301: “La risorsa richiesta è stata spostata in modo permanente”. Questo codice viene fornito quando una pagina web o una risorsa è stata sostituita in modo permanente con una risorsa diversa. Viene utilizzato per il reindirizzamento permanente dell’URL.

  

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

  

Puoi leggere ulteriori informazioni sui diversi codici di risposta nel nostro post di approfondimento sui codici di stato HTTP.

Dimensioni del contenuto e richieste per tipo di contenuto

Le sezioni seguenti riguardano le dimensioni del contenuto per tipo di contenuto e le richieste per tipo di contenuto. Ognuna di queste sezioni è utile per vedere rapidamente cosa occupa più risorse nella tua pagina web. Secondo HTTP Archive, le immagini rappresentano generalmente il 43% delle dimensioni totali di una pagina web media. Anche noi vediamo che di solito è così. Tuttavia, come puoi vedere qui sotto su questo sito, non è sempre così.

Per ottimizzare le immagini, ti consigliamo di leggere il nostro post approfondito su come ottimizzare le immagini per il web e su WebP. Esistono molti ottimi strumenti e plugin per comprimere ulteriormente le immagini e fare in modo che non siano la maggior parte del carico della pagina del tuo sito web. Nel caso di cui sopra, il sito sta sfruttando l’utilizzo di icone di grandi dimensioni al posto delle immagini. Questa può essere un’ottima strategia che fa un’enorme differenza. E naturalmente, nella nostra guida sulla velocità delle pagine abbiamo altri consigli su come ridurre ulteriormente le dimensioni dei contenuti.

Dimensioni dei contenuti e richieste per dominio

La sezione Dimensione del contenuto e richieste per dominio è un modo eccellente per vedere rapidamente quali servizi e script esterni sono presenti sul tuo sito web. Nel nostro esempio, puoi vedere che tutte le risorse vengono caricate dal nostro CDN. C’è poi il caricamento iniziale del DOC HTML del sito web dal server web e una chiamata esterna al dominio di Google Analytics. A seconda del tuo sito, potresti avere altri servizi esterni, come Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, ecc.

In generale, meno richieste esterne puoi fare, meglio è perché ogni servizio esterno introduce latenza, ritardi nell’handshake TLS, DNS lookup, ecc. Assicurati di leggere il nostro post di approfondimento sull’identificazione e l’analisi dei servizi esterni sul tuo sito WordPress.

In generale, è meglio ridurre il più possibile il numero di richieste e ospitare le risorse in un unico luogo, ad esempio spostandole sul tuo server web o su un CDN. Un esempio potrebbe essere quello dei font awesome. Invece di collegarti allo script esterno del font awesome, scaricalo e servilo direttamente.

Grafico a cascata di Pingdom

Infine, abbiamo la sezione richieste dello strumento di test di velocità di Pingdom, che genera un grafico a cascata di tutte le singole richieste della tua pagina web (come mostrato di seguito). Puoi quindi analizzare ogni richiesta per capire cosa sta causando ritardi e problemi di prestazioni sul tuo sito. Quando diciamo che stiamo facendo un’analisi a cascata, intendiamo proprio questo. Di seguito troverai un riepilogo più approfondito e una definizione del significato di ogni colore di stato.

DNS (rosa)

Che cos’è il DNS? Beh, consideralo come un elenco telefonico. Ci sono dei server chiamati Domain Name Server che contengono le informazioni sul tuo sito web e su quale IP deve essere indirizzato. Quando il sito web viene lanciato per la prima volta su Pingdom, questo esegue una nuova ricerca e deve interrogare i record DNS per ottenere le informazioni sull’IP. Questo comporta un tempo di ricerca aggiuntivo. Anche la posizione del server DNS è importante.

Quando fai passare il tuo sito web attraverso Pingdom più di una volta, il DNS viene memorizzato nella cache perché conosce già le informazioni sull’IP e non deve eseguire nuovamente la ricerca. Questo è il motivo per cui il tuo sito web appare più veloce dopo essere stato sottoposto a Pingdom più volte.

Come puoi vedere nella schermata qui sotto, nel secondo test che abbiamo eseguito, il tempo di DNS lookup al caricamento iniziale del DOC era di 3,6 ms. In genere il tempo scende a 0 ms, come dovrebbe essere, dato che la richiesta è già memorizzata nella cache. Questo è un aspetto che molte persone interpretano male!

Inoltre, puoi ottimizzarlo ulteriormente utilizzando un servizio DNS premium, che offre molti vantaggi in più. Anche il DNS gratuito di Cloudflare è veloce! Scopri l’Ottimizzazione automatica della piattaforma di Cloudflare.

Ci sono altri motivi per cui il tuo sito web potrebbe apparire più veloce dopo diversi test. Uno di questi è l’utilizzo di una rete di distribuzione dei contenuti (CDN). Per chi non ha familiarità con i CDN, si tratta di una rete di server globali che mettono in cache i tuoi contenuti (JS, CSS, immagini, ecc.) in luoghi più vicini al visitatore. Quando esegui per la prima volta il tuo sito web con Pingdom, potresti dover prendere le risorse dalla CDN fresca fresca. La cache di un CDN funziona come il DNS. Una volta memorizzata nella cache, è molto più veloce nei caricamenti successivi.

Un altro consiglio per velocizzare il DNS è quello di utilizzare il DNS prefetching. Questo permette al browser di eseguire le ricerche DNS su una pagina in background. Puoi farlo aggiungendo alcune righe di codice all’intestazione del tuo sito WordPress. Vedi alcuni esempi qui sotto.

<!-- 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">

In alternativa, se utilizzi la versione 4.6 o più recente di WordPress, potresti voler utilizzare i suggerimenti per le risorse. Gli sviluppatori possono utilizzare il filtro wp_resource_hints per aggiungere domini e URL personalizzati per dns-prefetch, preconnect, prefetch o prerender.

SSL (viola)

Il colore di stato viola indica il tempo necessario al browser per effettuare un handshake SSL/TLS. Ogni volta che si esegue un sito web su HTTPS, è necessario un certificato SSL e un tempo supplementare per il 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 c’è un tempo di negoziazione SSL sia per il caricamento iniziale del documento HTML dal server web sia per le nostre risorse.

Sebbene il funzionamento dell’HTTPS comporti un leggero sovraccarico, ora non è più fondamentale grazie a HTTP/2, un nuovo protocollo che contribuisce a velocizzare il web! A causa del supporto dei browser, l’HTTPS è necessario per utilizzare l’HTTP/2. Scopri la nostra guida definitiva su HTTP/2.

È inoltre importante notare che, anche nel 2018, non tutti i provider supportano ancora HTTP/2. Questo vale sia per l’hosting web che per i CDN. Quindi, quando fai shopping di hosting e CDN, assicurati che entrambi lo supportino! Kinsta è orgogliosa di supportare HTTP/2 per tutti i suoi clienti WordPress.

A metà 2018, Pingdom ha finalmente aggiornato il suo strumento per utilizzare Chrome 60 e versioni successive. Puoi vedere l’user-agent utilizzato nell’intestazione della richiesta. In precedenza si utilizzava Chrome 39 e Chrome non supportava HTTP/2 fino alla versione 49. Siamo quindi felici di poter dire che lo strumento di Pingdom ora mostra tutti i vantaggi di HTTP/2 durante l’esecuzione dei test! 👏

Connessione (verde acqua)

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

Attesa (giallo)

Il tempo di attesa di Pingdom si riferisce al time to first byte, noto anche come TTFB in alcuni strumenti. Il TTFB è una misura utilizzata per indicare la reattività di un server web o di un’altra risorsa di rete. In genere, qualsiasi valore inferiore a 100 ms è accettabile e rappresenta un buon TTFB. Se ti avvicini ai 300-400 ms, potresti avere qualcosa di mal configurato sul tuo server o potrebbe essere arrivato il momento di passare a uno stack web migliore.

Il modo più semplice per ridurre il TTFB? I due modi migliori sono un efficace caching di WordPress e un CDN. Eseguiamo quindi un paio di test.

TTFB senza WordPress Host Cache

Per prima cosa abbiamo eseguito un test dopo aver cancellato la cache del nostro sito WordPress. Ciò significa che deve precaricare nuovamente la cache. Il tempo di caricamento totale è stato di 541 ms e il TTFB (tempo di attesa) per la nostra richiesta iniziale è stato di 185,2 ms.

TTFB con la cache di WordPress

Abbiamo quindi ripetuto il test. Ora viene servito direttamente dalla cache. Come puoi vedere, il tempo di caricamento totale è sceso a 392 ms e il TTFB della richiesta iniziale è ora di 52,8 ms! Questa è la differenza che fa la cache.

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

TTFB senza CDN

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

TTFB con CDN

Abbiamo quindi attivato il nostro CDN e ripetuto il test. I tempi di caricamento totali sono scesi a 1,21 s e il TTFB medio su un asset CDN è ora di 4,6 ms! Che differenza può fare un CDN.

Un’altra cosa fondamentale da notare è che abbiamo scelto la località “Pacifico – Australia – Sydney” per eseguire questo test. Perché? Perché volevamo mostrarti i reali miglioramenti che si possono ottenere. Il nostro sito WordPress in questo esempio è ospitato da Kinsta in una posizione centrale negli Stati Uniti. Eseguendo il test con l’Australia possiamo mostrare come la cache CDN di Kinsta aumenti la velocità e riduca il TTFB.

Naturalmente, anche avere un buon host WordPress con un’architettura ben studiata è fondamentale per ridurre il TTFB.

Invio (arancione) e ricezione (verde)

Gli stati di invio e ricezione in Pingdom non hanno bisogno di molte spiegazioni. Il tempo di invio è semplicemente il tempo necessario al browser web per inviare i dati al server. Il tempo di ricezione è il tempo necessario al browser web per ricevere i dati dal server. Entrambi i tempi saranno solitamente molto bassi o inesistenti nei tuoi test.

Header di risposta HTTP

Puoi anche cliccare su una singola richiesta durante l’analisi a cascata e vedere le intestazioni delle risposte HTTP. Questo fornisce informazioni preziose. Nella schermata qui sotto, possiamo vedere immediatamente cose come il fatto che gzip sia abilitato sul server web e che la richiesta venga servita dalla cache (HIT, che altrimenti mostrerebbe MISS), le intestazioni cache-control, le intestazioni expires, l’user-agent del browser e altro ancora.

Caso di studio sulla configurazione del dominio

Se hai letto fino a questo punto del nostro post sull’analisi a cascata, ti aspetta una bella sorpresa. È sempre frustrante vedere persone che condividono consigli e casi di studio ma non condividono come sono arrivati alla soluzione. Di seguito trovi la nostra configurazione esatta per il dominio del caso di studio utilizzato in precedenza!

Architettura

• Il dominio del caso di studio è ospitato da Kinsta negli Stati Uniti. Kinsta offre attualmente 27 diversi data center tra cui scegliere.
• Kinsta utilizza HTTP/2, Nginx e MariaDB, che contribuiscono alla velocità di caricamento.
• Il sito utilizza KeyCDN, che alimenta il CDN di Kinsta. La larghezza di banda CDN gratuita è inclusa in tutti i piani di hosting.
• Il sito non utilizza alcun plugin di caching. Kinsta memorizza tutto nella cache a livello di server, il che semplifica notevolmente le cose!
• Il sito utilizza PHP 7.3. Le nuove versioni di PHP hanno sempre mostrato grandi miglioramenti nelle prestazioni. Dai un’occhiata a questi benchmark PHP. Kinsta ti permette di passare da una versione all’altra cliccando su un pulsante.

Plugin e temi di WordPress

Ecco un elenco dei plugin che influiscono sulle prestazioni del sito ecommerce WordPress.

• Il plugin Imagify (premium) viene utilizzato per comprimere le immagini.
• Il plugin gratuito Safe SVG viene utilizzato per caricare le immagini SVG sul sito WordPress.
• Il tema premium GeneratePress WordPress è stato utilizzato per costruire il sito EDD.

Tutorial consigliati per ulteriori letture:

• Come eliminare i JavaScript e i CSS che bloccano il rendering
• Come disattivare le Emoji in WordPress
• Come disattivare gli embed in WordPress
• Come ottenere un punteggio di 100/100 in Google PageSpeed Insights con WordPress
• Come diagnosticare l’elevato utilizzo di Admin-Ajax nel tuo sito WordPress

Riepilogo

Come puoi vedere, conoscere meglio il funzionamento dello strumento di speed test di Pingdom e il significato di tutti i grafici può aiutarti a prendere una decisione più orientata ai dati quando si tratta di prestazioni.

Un’analisi a cascata è fondamentale per sapere come vengono caricate le risorse e come vengono influenzate dall’host WordPress, dalla posizione fisica, da un CDN, ecc. Speriamo che questo post ti abbia aiutato a risolvere meglio i problemi di velocità e prestazioni del tuo sito.

Hai altri fantastici consigli su Pingdom? Faccelo sapere qui sotto nei commenti!