Le persone che visitano il vostro sito web odiano aspettare il caricamento delle pagine, sia su desktop che su dispositivi mobili. Le pagine lente da caricare possono farli scappare sul sito di un concorrente. Vi preoccupa anche l’impatto delle prestazioni del sito web sui risultati di ricerca.

Noi di Kinsta prendiamo sul serio la velocità e cerchiamo sempre di rendere i siti dei nostri clienti più veloci.

L’aggiunta di Kinsta Edge Caching ai nostri piani di hosting WordPress gestito nel dicembre del 2022 ha aggiunto nuovi strumenti per aiutare i clienti a far arrivare più velocemente le pagine dei loro siti ai browser.

Misurando il tempo di risposta al primo byte (TTFB), abbiamo riscontrato un tempo di risposta medio in tutti i test di 207 millisecondi con l’edge caching abilitato, contro i 402,59 millisecondi senza edge caching. Si tratta di un calo di quasi il 49%. Ma alcuni dei siti web del mondo reale che abbiamo testato hanno ottenuto risultati molto migliori, con prestazioni TTFB più veloci di quasi l’80% con l’edge caching. Analizzeremo più a fondo questi numeri qui di seguito.

Diamo un’occhiata a come le prestazioni del vostro sito web WordPress possono migliorare quando una buona parte dei suoi contenuti è “al limite”.

Cos’è l’Edge Caching?

Molti dei nostri clienti di hosting WordPress stanno già sfruttando la nostra integrazione con Cloudflare e i suoi server edge attraverso il CDN Kinsta. Questa rete di distribuzione dei contenuti colloca le risorse statiche di un sito – come immagini, font e file contenenti CSS e JavaScript – in 260+ posizioni sulla rete di Cloudflare in tutto il mondo. Ciò significa che tali risorse sono disponibili più vicino alla posizione fisica dei visitatori del vostro sito web. I percorsi più brevi per queste risorse si traducono in una minore latenza di rete.

Applicare l’Edge Caching all’HTML delle pagine di WordPress è molto simile alla gestione degli asset nel CDN. La differenza è che la gestione della cache di file come le immagini, che cambiano raramente, è relativamente semplice. È più difficile gestire i contenuti che vengono inizialmente generati dinamicamente da WordPress, messi in cache come contenuti statici e poi rigenerati ogni volta che vengono modificati.

Come Avviene la Memorizzazione dei Contenuti nella Cache Edge?

Le cache Edge sono popolate dalle richieste di pagine del vostro sito da parte dei browser. Se una pagina non è già presente nella cache, la richiesta viene inoltrata al vostro sito WordPress di origine, dove la pagina potrebbe trovarsi nella cache locale o essere generata nuovamente da WordPress. La pagina viene memorizzata nella cache edge durante il percorso di ritorno al browser. Le future richieste sullo stesso percorso beneficeranno della cache fino a quando non verrà cancellata.

Questo è anche il modo in cui vengono popolate le cache dei dispositivi mobili. Se la richiesta di una pagina proviene da un dispositivo mobile, il contenuto viene salvato in una cache mobile. (La cache mobile non distingue tra dispositivi iOS e Android. Le richieste provenienti da tablet vengono raggruppate con i contenuti desktop).

Local Cache ed Edge Cache WordPress

Kinsta offre un approccio senza plugin alla cache locale di WordPress sul server del vostro sito. L’approccio di Kinsta all’Edge Cache mantiene questa semplicità: gli stessi passaggi che avete fatto per cancellare la cache locale ora manterranno sincronizzata anche la cache edge.

Inoltre, il cruscotto MyKinsta include una funzionalità per cancellare la cache edge e solo quella.

La novità dell’Edge Caching è la possibilità di attivare una cache per i dispositivi mobili. Se il vostro sito web genera un markup unico per i dispositivi mobili, potete memorizzare nella cache l’HTML separatamente dai contenuti per i dispositivi desktop.

Kinsta Edge Caching È Uguale ad APO di Cloudflare?

Kinsta Edge Caching condivide la stessa potente rete di server edge utilizzata dal servizio Automatic Platform Optimization (APO) di Cloudflare. Anche APO è stato progettato per fornire il caching edge ai siti WordPress.

Ecco cosa distingue Kinsta Edge Caching:

  • Non ha costi aggiuntivi. (Edge Caching è gratuito con tutti i piani di hosting WordPress gestiti).
  • Non è necessario un plugin per la gestione della cache.
  • Integrazione perfetta con il cruscotto di MyKinsta.
  • Un’unica piattaforma per gestire CDN ed Edge Caching.

Mettere alla Prova Kinsta Edge Caching

Prima di rilasciare ufficialmente la funzione, abbiamo invitato alcuni dei nostri clienti a provare una versione Beta del nuovo servizio Edge Caching per raccogliere feedback. I siti web reali dei nostri tester Beta da tutto il mondo hanno rappresentato l’ambiente perfetto per testare la velocità della tecnologia.

Dal data center di Google noto come us-central1 a Council Bluffs, Iowa, gli strumenti automatizzati del nostro team hanno interrogato i siti web dei tester Beta e hanno registrato i tempi di risposta per tre scenari di caching:

  1. Quando una pagina è stata consegnata dalla cache di un server edge di Cloudflare.
  2. Quando una pagina non è stata trovata su un server Cloudflare edge ed è stata estratta dalla cache “locale” del server di origine.
  3. Quando non c’era alcuna pagina in cache e WordPress ha dovuto lanciare script PHP e lanciare query al database per creare la pagina dinamicamente.

L’obiettivo principale era la differenza dei tempi di risposta tra la cache locale e quella periferica.

Abbiamo misurato i tempi di risposta in due modi:

  1. Tempo al primo byte (Time to First Byte o TTFB): l’intervallo tra la richiesta di una pagina e l’arrivo del primo byte di dati.
  2. Tempo per scaricare un’intera pagina HTML.

La misurazione del TTFB si concentra sulla latenza della rete tra un server web e un browser, poiché è largamente indipendente dalla quantità di dati trasferiti per completare una pagina. La tempistica del trasferimento di una pagina completa è una misura utile che riflette il compito reale di fornire l’HTML ai browser.

Edge Caching in Cifre

Dopo centinaia di test condotti su siti WordPress in data center di tutto il mondo, abbiamo scoperto che, in media, Kinsta Edge Caching riduce di oltre il 50% il tempo necessario per consegnare pagine complete ai browser.

Date un’occhiata:

Grafico che mostra i miglioramenti nel TTFB e nella velocità di consegna delle pagine grazie a Edge Caching.
TTFB: 402,59 ms (cache locale), 207 ms (edge). Pagina completa: 490.99 ms (cache locale), 223,98 ms (edge).

In base ai nostri test, l’Edge Caching ha ridotto il TTFB in media di quasi il 48,6% e il tempo di trasferimento di pagine complete è diminuito di quasi il 54,4%.

Miglioramento Superiore all’80% su Lunghe Distanze

Sebbene le medie di tutti i test di velocità siano impressionanti, questa visione può nascondere dati importanti, soprattutto per chi si rivolge a un pubblico globale.

I nostri test hanno riscontrato un notevole miglioramento delle prestazioni quando Edge Caching ha ridotto il divario tra i browser e i server di origine più distanti.

Per esempio, Edge Caching ha ridotto il TTFB dell’83,6% e i tempi di trasferimento delle pagine dell’85,6% tra la nostra sede di test in Iowa e il data center di Google asia-southeast1 a Singapore:

Grafico che mostra le prestazioni di Edge Caching per il data center Jurong West.
TTFB: 672,01 ms (cache locale), 110,05 ms (edge). Pagina intera: 901.1 ms (cache locale), 129,79 ms (edge).

Collegandosi a siti WordPress nel data center australia-southeast1 di Sydney, il TTFB è diminuito di quasi il 73,6% e i tempi di trasferimento delle pagine sono scesi del 77,3%.

Grafico che mostra le prestazioni di Edge Caching per il data center di Sydney.
TTFB: 898,26 ms (cache locale), 237,21 ms (edge). Pagina intera: 1.130,48 ms (cache locale), 256,95 ms (edge).

Abbiamo riscontrato numeri simili presso il data center australia-southeast2 di Melbourne. I siti WordPress dei clienti Kinsta hanno visto Edge Caching ridurre il TTFB in media del 77,8% e il trasferimento delle pagine di quasi l’82,7%:

Grafico che mostra le prestazioni di Edge Caching per il data center di Melbourne.
TTFB: 607,37 ms (cache locale), 134,63 ms (edge). Pagina intera: 812.46 ms (cache locale), 140,62 ms (edge).

Collegandosi ai siti ospitati nel data center europe-north1 di Hamina, in Finlandia, il TTFB è diminuito di circa il 41,7% e i tempi di trasferimento delle pagine sono diminuiti di oltre il 56,3%.

Grafico che mostra le prestazioni di Edge Caching per il data center di Hamina.
TTFB: 579,81 ms (cache locale), 338,17 ms (edge). Pagina intera: 822.21 ms (cache locale), 358,89 ms (edge).

Per i siti ospitati a St. Ghislain, in Belgio, presso il data center europe-west1, i tempi di TTFB e di trasferimento delle pagine sono diminuiti del 69%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Ghislain.
TTFB: 464,64 ms (cache locale), 143,13 ms (edge). Pagina intera: 464.92 ms (cache locale), 143,38 ms (edge).

I siti web testati presso il data center europe-west2 di Londra, nel Regno Unito, hanno registrato una riduzione del TTFB del 58% e dei tempi di trasferimento delle pagine del 60,8%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Londra.
TTFB: 372,4 ms (cache locale), 156,17 ms (edge). Pagina intera: 458.18 ms (cache locale), 179,34 ms (edge).

Presso il data center europe-west3 di Francoforte, in Germania, il TTFB è diminuito di quasi il 64% e i tempi di trasferimento delle pagine del 67,5%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Francoforte.
TTFB: 409,27 ms (cache locale), 147,42 ms (edge). Pagina intera: 507.52 ms (cache locale), 164,98 ms (edge).

Collegandosi ai siti ospitati nel data center europe-west4 di Eemshaven, nei Paesi Bassi, il TTFB è sceso quasi del 56% e i tempi di trasferimento delle pagine del 63,6%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Eemshaven.
TTFB: 394,49 ms (cache locale), 173,76 ms (edge). Pagina intera: 538.84 ms (cache locale), 195,82 ms (edge).

Durante i test dei siti del centro dati northamerica-northeast1 di Montreal, in Canada, il TTFB è sceso di poco più del 10% e i tempi di trasferimento delle pagine sono diminuiti di poco più del 16,2%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Montreal.
TTFB: 325,3 ms (cache locale), 292,28 ms (edge). Pagina intera: 351.1 ms (cache locale), 294,15 ms (edge).

Nel data center us-east5 di Columbus, Ohio, i tempi di TTFB e di trasferimento delle pagine sono stati ridotti di quasi il 59%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Columbus.
TTFB: 326,69 ms (cache locale), 133,97 ms (edge). Pagina intera: 341.15 ms (cache locale), 140,5 ms (edge).

Presso il data center us-west4 di Las Vegas, Nevada, negli Stati Uniti, il TTFB è diminuito di poco più del 54,7% e il tempo di trasferimento della pagina è diminuito di quasi il 57,3%.

Grafico che mostra le prestazioni dell'Edge Caching per il data center di Las Vegas.
TTFB: 366,73 ms (cache locale), 165,88 ms (edge). Pagina intera: 413.39 ms (cache locale), 176,63 ms (edge).

Ma non è solo Kinsta a mettere alla prova l’Edge Caching.

Brian Jackson, co-fondatore dell’agenzia digitale forgemedia, ha cronometrato il TTFB e il rendering completo delle pagine di WordPress in un browser dopo Edge Caching. Ha anche analizzato il “largest contentful paint” (LCP), ovvero il punto in cui il contenuto principale di una pagina è stato reso in quantità sufficiente da essere percepito da un utente come utilizzabile. Ha pubblicato i suoi risultati su Twitter:

Schermata del tweet di Brian Jackson con i risultati dei suoi test: miglioramento del 91% sul TTFB, del 62% sul LCP e del 61% sui tempi di caricamento .
Twitter/Brian Jackson. (Guarda su Twitter.)

Simon Harper, di SRH Design, ha testato Kinsta Edge Caching esaminando TTFB e LCP, nonché il first contentful paint (FCP), ovvero la comparsa iniziale di qualsiasi contenuto su uno schermo, anche se non è il contenuto principale della pagina. Anche lui ne ha parlato via Twitter:

Schermata del tweet di Simon Harper: miglioramento del 35% sul TTFB, del 15% sul FCP e del 10% sul LCP.
Twitter/Simon Harper. (Visualizza su Twitter.)

La struttura delle pagine web e le risorse collegate, come JavaScript, CSS e immagini, possono avere un impatto su FCP e LCP, ma tutto inizia con l’invio dell’HTML di una pagina al browser.

Come Iniziare con Kinsta Edge Caching

L’Edge Caching è abilitato per impostazione predefinita quando create un sito WordPress nel cruscotto di MyKinsta. Ciò significa che non dovrete muovere un dito per sfruttare l’aumento di velocità dell’Edge Caching.

A partire da gennaio 2023, Kinsta abiliterà automaticamente l’Edge Caching sui siti esistenti compatibili con il servizio. Se volete che Edge Caching funzioni subito per il vostro sito esistente, potete attivarlo subito in questo modo:

  • Selezionate Siti WordPress nella navigazione a sinistra.
  • Selezionate il nome del sito per il quale volete abilitare l’Edge Caching.
  • Selezionate Edge Caching.
  • Fate clic sul pulsante Abilita Edge Caching.
Schermata di MyKinsta in cui è evidenziata l’opzione Edge Caching nel menu e il pulsante Abilita Edge Caching.
Abilitazione dell’Edge Caching nel cruscotto di MyKinsta.

Memorizzare nella Cache i Vostri Contenuti per Dispositivi Mobili

Se il vostro sito web rileva i browser mobili e genera pagine con un markup unico per questi dispositivi, potete attivare una cache mobile separata dai contenuti per gli utenti desktop.

Attivate la cache mobile in MyKinsta in questo modo:

  • Selezionate Siti WordPress nella barra di navigazione a sinistra.
  • Selezionate il nome di un sito per il quale è abilitato l’Edge Caching.
  • Selezionate Edge Caching.
  • Fate clic sul pulsante Abilita la cache mobile.
Schermata di MyKinsta in cui è evidenziata l’opzione Edge Caching nel menu e il pulsante Abilita cache mobile.
Abilitazione della cache Edge per i dispositivi mobili.

Non è necessario abilitare il caching per i dispositivi mobili se il design del vostro sito web supporta sia i browser desktop che quelli mobili con lo stesso markup HTML/CSS responsive.

Gestione dei Contenuti in Cache

Kinsta Edge Caching è stato progettato per funzionare perfettamente con gli strumenti di gestione della cache che la maggior parte dei nostri clienti già usa sui propri siti web WordPress. Potete anche selezionare i contenuti nella cache edge direttamente in MyKinsta:

  • Selezionate Siti WordPress nella navigazione a sinistra.
  • Selezionate il nome di un sito per il quale è abilitato l’Edge Caching.
  • Selezionate Edge Caching.
Schermata di MyKinsta in cui è evidenziata l’opzione Edge Caching nel menu e i due pulsanti Svuote la cache e Svuota cache URL.
Svuotare la cache edge nel cruscotto di MyKinsta.

Per svuotare la cache edge globale da tutte le pagine del vostro sito, fate clic sul pulsante Svuota cache.

Se avete bisogno di svuotare solo pagine o percorsi specifici, incollate un URL di destinazione nel campo Svuota Cache URL e fate clic sul pulsante Svuota cache URL. Svuotate la cache per tutti i contenuti di un percorso specifico selezionando l’opzione Cancella la cache di ogni sottodirectory sotto l’URL specificato.

Rinunciare all’Edge Caching

Se sapete già che Edge Caching non è adatto al vostro sito web, potete rinunciare prima che il servizio venga attivato per la maggior parte dei siti esistenti nel gennaio del 2023.

In MyKinsta:

  • Selezionate Siti WordPress nella navigazione a sinistra.
  • Selezionate il nome del vostro sito WordPress.
  • Selezionate Edge Caching.
  • Attivate l’opzione “Voglio rinunciare ad abilitare…“.
La scheda Edge Caching nel cruscotto MyKinsta: nel riquadro dallo sfondo color lilla, una freccia indica l’opzione toggle Voglio rinunciare ad abilitare automaticamente l'Edge Caching su questo sito.
Disattivare l’Edge Caching utilizzando il cruscotto di MyKinsta.

Se Edge Caching è già abilitato per un sito web, troverete un pulsante di disattivazione nell’angolo superiore destro della pagina:

La scheda Edge Caching nel cruscotto MyKinsta: una freccia indica il pulsante Disabilita in corrispondenza del campo Edge Caching.
Disabilitare l’Edge Caching

Risposte Rapide sull’Edge Caching

Vi starete chiedendo…

L’Edge Caching È Gratuito su Tutti i Piani?

Sì. L’Edge Caching è abilitato per impostazione predefinita su tutti i siti live creati nel cruscotto di MyKinsta. L’Edge Caching è disponibile anche sui siti di staging degli account Premium.

L’Edge Caching Migliora le Prestazioni della Versione Mobile del Mio Sito Web?

Potete attivare una cache specifica per i siti web che generano un markup adatto ai dispositivi mobili. Se il design del vostro sito web supporta sia i browser desktop che quelli mobili con lo stesso markup HTML/CSS responsive, la cache mobile non è necessaria.

Devo Usare dei Plugin per l’Ottimizzazione di WordPress?

No. La piattaforma di hosting WordPress gestito di Kinsta offre cache locale, Edge Caching e un CDN finemente ottimizzato per supportare il CMS più diffuso al mondo. Non sono necessari plugin WordPress di terze parti.

Posso Disattivare l’Edge Caching?

Sì. Potete disattivare l’Edge Caching in qualsiasi momento all’interno del cruscotto di MyKinsta. Se non avete la certezza che il vostro sito sia compatibile con l’Edge Caching, contattate il team di assistenza di Kinsta per ricevere un consiglio.

Riepilogo

La promessa di Internet è sempre stata quella di connettere le persone in tutto il mondo. Tuttavia, è emerso che la distanza fisica tra i server e i visitatori ha un impatto reale sulle prestazioni percepite dei siti web. L’Edge Caching avvicina i contenuti ai browser web e accelera il primo passo verso un caricamento più rapido delle pagine.

Kinsta fa dell’Edge Caching una componente fondamentale del suo servizio di hosting WordPress gestito, a complemento delle funzionalità di CDN e di sicurezza della rete offerte dall’integrazione con Cloudflare.

In media, Kinsta Edge Caching dimezza il tempo necessario per consegnare l’HTML delle pagine web ai visitatori del vostro sito. Per i siti web con un pubblico veramente globale, l’aumento di velocità può essere drasticamente superiore.

Edge Caching è disponibile per tutti i nostri clienti senza alcun costo aggiuntivo. Se siete ancora alla ricerca di un hosting per WordPress costruito tenendo conto della sicurezza, della facilità d’uso e delle prestazioni, abbiamo il piano di hosting che fa per voi.

Steve Bonisteel

Kinsta

Steve Bonisteel is a Technical Editor at Kinsta who began his writing career as a print journalist, chasing ambulances and fire trucks. He has been covering Internet-related technology since the late 1990s.