Core Web Vital: Wix vs. WordPress, Shopify vs. Shopware. Chi è il più veloce?

Johannes Beus
Johannes Beus
Johannes Beus ist Gründer und Geschäftsführer von SISTRIX.

Abbiamo analizzato i tempi di caricamento di 18,5 milioni di domini per imparare di più sul loro Page Speed. In questo articolo scoprirai perché Wix non ha di sfortunato solo il nome, dove si classifica Wordpress, e tanti altri dati interessanti.

La velocità di caricamento dei siti diventerà ufficialmente un fattore di ranking di Google il prossimo anno: data la complessità di un simile argomento, il nostro consiglio è di affrontarlo fin da subito.

Se non hai molto tempo per dedicarti alla lettura, di seguito abbiamo riassunto i punti più salienti della nostra analisi.

Riassunto dell’analisi

  • Il 34% dei siti italiani non soddisfa ancora le aspettative di Google per quanto riguarda i tempi di caricamento, superando i 2,5 secondi.
  • La tendenza sta però pian piano migliorando: a partire da marzo 2020 i siti italiani con tempi di caricamento positivi sono aumentati dell’1,4%.
  • L’Italia è al trentesimo posto per quanto riguarda la velocità di connessione internet, subito dopo al Vietnam e alla Spagna. Il primato va a Cina, Corea del Sud e Giappone.
  • Jimdo è la prova che i CMS basati su Cloud comportano valori migliori per quanto riguarda i Core Web Vital. Anche le soluzioni Open Source non sono da meno: Typo3 segue con un punteggio leggermente minore.
  • Nessun CMS è più lento di Wix: il fanalino di coda della categoria dei CMS (persino più lento di WordPress) mostra chiaramente che il Cloud non è veloce di per sé.
  • Lightspeed offre una piattaforma di e-commerce straordinariamente veloce, mentre Shopify appare solo nella seconda metà della classifica. La più lenta è WooCommerce, il plugin di WordPress.
  • Il linguaggio di programmazione non sembra fare la differenza per le tecnologie web: esistono Framework veloci come Ruby (on Rails), PHP (Yii & Laravel), Python (Django) e altri linguaggi. Solo Angular è molto lento.
  • Utilizzare AMP non significa automaticamente avere un sito più veloce: solo circa il 70% delle pagine AMP soddisfa i valori ideali dei Core Web Vital.

Se hai a disposizione più tempo per leggere l’analisi completa, di seguito troverai tutti i dati e le valutazioni che abbiamo rilevato sui tempi di caricamento, sui sistemi più o meno veloci e sulle correlazioni che si nascondono dietro di essi.

Perché il tempo di caricamento di un sito è così importante?

L’esperienza dell’utente (User Experience) è uno dei fattori più importanti per il successo di un sito, e il tempo di caricamento ne è a sua volta la base. Infatti, se un utente è costretto ad attendere (troppo) a lungo il caricamento di una pagina, è probabile che la abbandoni e ne cerchi un’altra.

Sulla base di uno studio di benchmarking, Google ha dichiarato che l’aumento del tempo di caricamento da uno a tre secondi accresce il bounce rate del 32%. Se il sito impiega fino a cinque secondi per caricarsi, la probabilità che l’utente abbandoni la pagina sale addirittura al 90%.

Come viene misurata la performance di un sito?

Esistono tool e approcci differenti per misurare l’esperienza utente di un sito: Google mette a disposizione i Core Web Vital, tre metriche uniformi e confrontabili, che prossimo anno diventeranno un fattore di ranking e influenzeranno il posizionamento dei siti nelle pagine dei risultati.

In un altro articolo abbiamo già trattato il tema dei Core Web Vital, così come il loro calcolo e miglioramento, per cui di seguito li riassumeremo solo velocemente:

  • Largest Contentful Paint (LCP): il tempo impiegato dalla pagina per mostrare il blocco di contenuto maggiore. Performance ottimale: meno di 2,5 secondi.
  • First Input Delay (FID): l’arco di tempo che deve passare prima che l’utente possa interagire con la pagina. Performance ottimale: meno di 0,1 secondo.
  • Cumulative Layout Shift (CLS): l’indicatore che specifica quanto si modifica il layout della pagina durante il caricamento. Performance ottimale: meno di 0,1.

Ad eccezione del primo grafico, in questa analisi abbiamo considerato la metrica del Largest Contenful Paint (LCP): confrontando i tre Core Web Vital, si tratta infatti del valore più elementare per misurare il tempo di caricamento di una pagina.

Italia: il 34% dei siti non è ancora abbastanza veloce

Per prima cosa abbiamo analizzato quanti siti italiani raggiungono effettivamente i valori ottimali dei Core Web Vital indicati da Google. Questi ultimi sono suddivisi in:

  • Buono (verde): il valore rientra nelle aspettative di Google;
  • Migliorabile (giallo): il valore non rientra nelle aspettative di Google, ma non se ne discosta troppo;
  • Scarso (rosso): il valore è molto lontano dalle aspettative di Google.

Per l’Italia la nostra analisi ha ottenuto i risultati seguenti:

Risultati dei Core Web Vitals per l'Italia

Per quanto riguarda il Largest Contentful Paint (LCP), il 65% dei risultati totali ha una performance positiva, mentre il 16% viene considerato da Google non soddisfacente. Il valore LCP è il cuore dei Core Web Vital, poiché riflette al meglio il tempo di caricamento effettivo.

Il First Input Delay (FID), cioè il tempo per la prima interazione, è quello che ha i voti migliori: l’86% dei risultati è positivo e solo il 2% scarso. Chi quindi deve ancora mettersi in carreggiata su questo campo dovrebbe affrettarsi per non essere superato dai concorrenti.

Infine, per quanto riguarda il Cumulative Layout Shift (CLS), cioè il dinamismo del layout durante il caricamento, vediamo che non esistono vie di mezzo: i risultati o superano il test a pieni voti (verde), o fanno completamente cilecca (rosso). Solo pochi di essi necessitano di miglioramenti (giallo).

Tendenza positiva: i siti diventano sempre più veloci col passare dei mesi

Per capire meglio come si sono sviluppati i tempi di caricamento, vediamo lo sviluppo temporale del Largest Contentful Paint negli ultimi mesi.

Largest Contentful Paint, sviluppo temporale per l'Italia

Non si tratta di enormi progressi, ma certamente si può notare una leggera tendenza positiva: a partire da marzo 2019 la quantità di risultati negativi è scesa di 1,4 punti percentuali, mentre quelli positivi sono cresciuti dal 64% al 65%. La direzione è quindi quella giusta: i siti italiani diventano più veloci di mese in mese.

I tablet sono solo dei desktop peggiori

Passiamo alla prossima analisi, cioè la valutazione del tipo di dispositivo: desktop, Smartphone e tablet. Di seguito i risultati.

Core Web Vitals per dispositivo (Italia)

Non sorprende che i siti si carichino più velocemente su desktop che su mobile, generalmente grazie alla connessione via cavo e alla maggiore potenza del dispositivo. In realtà la differenza tra desktop e Smartphone è minore di quanto avessimo pensato.

È interessante invece la performance negativa dei tablet: questo deriva probabilmente dal fatto che questo dispositivo richiede la versione desktop dei siti, ma il suo hardware è più simile a quello degli Smartphone. Ciò comporta dei tempi di caricamento significativamente maggiori.

Italia al 30° posto per velocità di connessione

I valori dei Core Web Vital degli utenti finali dipendono parzialmente dalla performance dei singoli siti: la velocità, la portata e la latenza della connessione internet dell’utente influiscono a loro volta sul risultato finale.

I webmaster non hanno la possibilità di ottimizzare la connessione internet dei propri utenti, ma vediamo delle grandi differenze nell’analisi dei Core Web Vital per i singoli Paesi. Di seguito abbiamo riportato quelli più rilevanti.

Largest Contentful Pain per Paese (EN)

In Cina e Corea del Sud l’82% dei siti rispetta le aspettative di Google: un valore eccezionale e molto distante dal resto del mondo. Seguono poi i Paesi nordici (Svezia, Norvegia, Danimarca), ma anche il Giappone e Taiwan.

L’Italia è al trentesimo posto, con valori molto simili a Vietnam e Israele: il 65% dei siti italiani ha un valore LCP buono, il 18% necessita miglioramenti, mentre il 16% non raggiunge le aspettative di Google. Si tratta di uno dei Paesi europei più lenti, seguito solo dalla Grecia.

I tempi di caricamento di Russia e USA sono in un certo senso comparabili. Tailandia e Vietnam mostrano invece che non tutta l’Asia possiede una connessione così veloce.

Kiribati, un’isola-stato del Pacifico, dimostra gli effetti di un’ubicazione estremamente remota e di un collegamento internet via satellite: solo circa un quarto di tutti i risultati è positivo, mentre quasi il 60% risulta scarso.

CMS: Jimdo il più veloce, Wix ancora più lento di WordPress

I Content Management System (CMS) sono la spina dorsale del web: la maggior parte dei siti viene gestito usando questi software, che si tratti del parrucchiere all’angolo, dell’azienda di medie dimensioni, o del sito con milioni di visitatori al giorno.

Abbiamo combinato la nostra banca dati delle tecnologie web con la misurazione dei Core Web Vital per valutare la velocità di caricamento dei CMS più utilizzati. Andiamo subito all’analisi.

Largest Contentful Pain per CMS

Jimdo, il kit di costruzioni per homepage con sede ad Amburgo, riporta i risultati migliori per quanto riguarda il Largest Contentful Paint. L’82% dei siti che usa questo CMS soddisfa i valori indicati da Google.

Il fatto che anche un CMS auto-ospitato possa fornire prestazioni molto buone è dimostrato da Typo3, al secondo posto della classifica. Chi ha già sviluppato con Typo3 ricorderà probabilmente con orrore la sua complessità, ma la velocità di questo CMS basato su PHP è sicuramente un bel vantaggio.

WordPress, il CMS più utilizzato in assoluto, è solo al penultimo posto. Circa la metà di tutti i siti utilizza WordPress, ma molti di essi non stanno dando particolare attenzione alla velocità di caricamento. Google classifica negativamente circa il 20% di questi risultati, mentre un altro 21% risulta migliorabile.

WordPress non è il fanalino di coda solo grazie a Wix, la piattaforma dal nome meno apprezzato di tutti (almeno in Germania). Solo la metà dei siti che utilizzano questo CMS soddisfa i criteri dei Core Web Vital di Google, mentre circa un quarto di essi viene bocciato.

Questa triste performance è particolarmente degna di nota considerando che sia il vincitore di questa analisi (Jimdo), che il perdente (Wix) hanno le stesse condizioni di partenza: soluzioni Cloud per le quali l’utente controlla l’intero sistema, con la possibilità di ottimizzare ogni singola parte (possibilità, a quanto pare, non sempre sfruttata).

E-commerce: Shopify solo mediocre, WooCommerce il fanalino di coda

Già nel 2006 Amazon aveva dichiarato che per ogni 0,1 secondo di caricamento si perde un 1% di fatturato, e negli ultimi 14 anni la situazione non è sicuramente migliorata. Il fatto di caricare le pagine velocemente è una condizione fondamentale per gli e-commerce.

Combinando il nostro database sulle tecnologie con i dati sui tempi di caricamento, abbiamo effettuato l’analisi seguente, incentrata sui sistemi di e-commerce che vediamo più frequentemente nel selvaggio web.

Largest Contentful Pain per E-commerce

Lightspeed è all’altezza del suo nome: i domini che lo usano raggiungono per il 93% gli standard di Google, mentre solo il 2% viene considerato scarso. Si tratta dei valori migliori di tutte le valutazioni che abbiamo visto finora.

Lightspeed ha il vantaggio intrinseco di essere una soluzione Cloud: l’utente controlla quindi l’intero sistema, con la possibilità di ottimizzare la velocità dei singoli settori. Tuttavia, la soluzione Open Source osCommerce dimostra che anche gli shop self-hosted possono riuscire nell’impresa, con un buon 84% di risultati positivi.

La star Shopify si posiziona solo nella seconda parte della classifica. Nonostante le possibilità siano principalmente le stesse di Lightspeed (completamente ospitato dal fornitore stesso), questo vantaggio non si traduce in tempi di caricamento migliori.

Molto più indietro troviamo il plugin di WordPress WooCommerce, all’ultimo posto. Solo circa la metà degli e-commerce WooCommerce raggiungono attualmente le aspettative di Google, mentre uno spaventoso 26% è addirittura definibile scarso. È qui che diventa evidente come i fornitori di massa che usano l’hosting autogestito di questo CMS spesso abbiano basse prestazioni.

Tecnologie web: il formato AMP più lento di quanto si pensi

Concentriamoci ora sulle tecnologie web: da quelle backend (per la creazione di siti), alle librerie JavaScript e CSS (per la progettazione e l’interazione), fino a Google AMP.

Nella tabella seguente abbiamo elencato solo le tecnologie che, secondo i nostri dati, vengono maggiormente utilizzate. Naturalmente è stato possibile valutare solo i siti raggiungibili pubblicamente. Di seguito i risultati.

Largest Contentful Pain per tecnologie

Ruby On Rails, il framework sviluppato dal fondatore di Basecamp e basato su Ruby, è di gran lunga il vincitore: quasi l’85% dei siti che usa questa tecnologia rientra nei limiti di Google per quanto riguarda il Largest Contentful Paint.

Anche i PHP Framework come Yii (74%) e Laravel (73%) hanno buoni risultati. Ma, per evitare che qualcuno si senta messo da parte, possiamo dire che Python, insieme al framework Django, si trova a sua volta vicino alla vetta (75%), mentre ASP.NET addirittura al secondo posto (77%). La lezione, dunque, è che la velocità di caricamento non dipende dal linguaggio di programmazione, bensì dalla sua corretta implementazione.

Colpisce inoltre che AMP non sia una delle tecnologie più veloci. Le Accelerated Mobile Pages (AMP) sono un derivato di HTML principalmente appoggiato da Google, le cui pagine dovrebbero caricare più velocemente su mobile rispetto alle classiche pagine HTML.

I risultati però non convincono: meno del 70% dei domini AMP soddisfa i valori richiesti. A quanto pare Google lo ha già riconosciuto e in futuro lascerà in eredità i privilegi AMP nel box news anche a tutti i siti non-AMP, a patto che abbiano dei buoni Core Web Vital.

AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page.

Google Webmaster Central BlogEvaluating page experience for a better web

L’unica tecnologia che proprio non riesce a raggiungere gli standard di Google (con più della metà dei domini) è Angular. Se pensiamo che si tratta di un framework per le applicazioni di front-end sviluppato e fornito da Google…

CDN: i siti più veloci usano Fastly

I Content Delivery Networks (CDN) forniscono server distribuiti a livello globale, in modo che i contenuti possano essere trasmessi al visitatore del sito in modo più breve e quindi più veloce. Oltre agli specialisti come Akamai, anche i grandi fornitori di servizi Cloud offrono CDN ormai.

Essenzialmente i CDN funzionano tutti in modo simile, ma non possono modificare i limiti fisici. Questo è il motivo per cui, per la prossima valutazione, è necessario distinguere la causalità dalla correlazione.

Non bisogna partire dalla convinzione che i CDN più veloci portino un particolare vantaggio, bensì dal fatto che i webmaster orientati verso le prestazioni si orientano più verso questi CDN.

Largest Contentful Pain per CDN

I domini che usano Fastly caricano in media molto più velocemente rispetto ad altri CDN. Google atterra al secondo posto, ma anche Amazon e Microsoft (Azure) non sono così tanto indietro.

Il fatto che Akamai si trovi tra gli ultimi dipende dai tipici clienti che lo usano, cioè grandi aziende transnazionali con (spesso) lenti sistemi di legacy. Non proprio la miglior garanzia per avere un sito veloce e moderno.

Fireblade, il fanalino di coda dell’analisi, non offre un classico CDN, bensì un Web Application Firewall: l’applicazione filtra il traffico internet per le richieste potenzialmente pericolose e le blocca. Chi si serve di un’offerta di questo tipo, in media, tende anche a far funzionare applicazioni web più vecchie e non ottimizzate. Questa caratteristica è quindi già considerabile uno svantaggio strutturale per la nostra analisi.

Dietro le quinte: cosa (e come) abbiamo valutato

La misurazione dei tempi di caricamento ha una lunga storia: a partire dalla misurazione della prima comparsa del puro HTML (TTFB, Time To First Byte), al First Contentful Paint, fino ai tre valori attuali chiamati Core Web Vital, e quindi alla metrica principale del Largest Contentful Paint.

Per l’analisi abbiamo considerato le basi di calcolo indicate da Google per i Core Web Vital. Nello specifico, esistono principalmente due metodi di misurazione: i Lab Data (cioè i dati misurati autonomamente in un proprio ambiente) e i Field Data (misurati attraverso uno User Panel). Per questa analisi abbiamo utilizzato solo questi ultimi, anche se su SISTRIX puoi trovare sia i Lab Data, sia i Field Data. In totale abbiamo analizzato 18,5 milioni di domini.

Eccetto le prime tre valutazioni (incentrate sui siti italiani), tutte le analisi prendono in considerazione i valori mondiali, per tutti i tipi di dispositivi (desktop, mobile, tablet).

Questi valori sono stati combinati con il riconoscimento delle tecnologie di SISTRIX, che ci ha permesso di estrapolare i dati per i software e gli stack tecnologici. Per il riconoscimento delle tecnologie scansioniamo estesi settori del web, confrontando i dati trovati (“Fingerprint”) con la nostra lista contenente più di 1.000 tecnologie web rilevanti. Per le valutazioni finali contenute in questo articolo abbiamo considerato solo le combinazioni tecnologia/Core Web Vital che comparivano in un certo numero di domini e che risultavano rilevanti dal punto di vista statistico.

Conclusione

Nominando ufficialmente i Core Web Vital come fattore di ranking, Google mette sotto ai riflettori l’esperienza utente. Grazie alla nostra analisi abbiamo potuto dimostrare quanto sia ancora esteso lo spettro di valori misurati. A seconda del software e della tecnologia in uso, i risultati possono oscillare tra “Perfetto” e “C’è ancora parecchio lavoro da fare”.

Come per molti altri aspetti della SEO, il miglioramento dei tempi di caricamento dev’essere un processo continuativo: non un incarico una tantum, bensì una procedura a lungo termine ben monitorata. Si tratta di un compito che richiede costante attenzione e i cui obiettivi dovranno essere calibrati di volta in volta.

L’ottimizzazione dei tempi di caricamento non è una classica “attività SEO”, ma può influire fortemente sulla performance organica di un sito all’interno delle pagine dei risultati. La SEO deve quindi essere intesa come una funzione trasversale che deve avvicinare i diversi settori di un’azienda.

Noi stessi abbiamo trascurato a lungo i tempi di caricamento del nostro sito: durante le ultime settimane abbiamo riaffrontato l’argomento e notato come sia dispendioso (in termini di risorse) raggiungere i valori considerati (molto) positivi. Eppure ne vale la pena, non solo per rendere felice Google, ma anche per soddisfare gli utenti reali. Il nostro consiglio è quindi di non nascondere la testa sotto la sabbia e di fronteggiare questo tema: meglio occuparsi di quest’incombenza quest’anno, piuttosto che rimandarla al prossimo.

Articoli correlati
Commenti
Avatar Marco Panichi   
15. Settembre 2020, 11:20

Le conclusioni tratte nell’ambito dei CMS sono inutili e fuorvianti.

Non avete rilevato la velocità di Wix o di WordPress, ma bensì dei siti web realizzati con queste piattaforme.

Se usato bene, WordPress, può dare risultati prossimi al 100% su pagespeed. Il problema è che poi tanti utenti con scarse conoscenze ci caricano sopra Elementor o anche AdSense (ma basta anche un video incorporato di Youtube), e la velocità crolla.

State facendo brutta pubblicità a WordPress, alle persone che lo sviluppano, e a quelli che ci lavorano seriamente.

Questo articolo è da pollice basso per me.

Elisa Paesante   
15. Settembre 2020, 16:24

Buongiorno Marco,
grazie del tuo commento.
Certamente hai ragione: come per i CDN, bisogna distinguere tra causalità e correlazione.
La nostra analisi non ha l’obiettivo di denigrare nessuno, bensì di mostrare dei dati di siti reali per fare il punto della situazione su un tema rilevante ed attuale.
Noi stessi usiamo WordPress per il nostro sito e ci troviamo benissimo 😉

Avatar davide rampoldi   
15. Settembre 2020, 15:28

Ottimo post e riflessioni. Personalmente uso wordpress e ho notato, pur cambiando più temi e testando 5 domini/siti diversi, un LCP decente da desktop ma terrificante da mobile (anche disabilitando la gran parte dei plugin).

Avete idea da cosa possa dipendere questa enorme differenza?

P.S. Verrebbe davvero voglia di fare qualche test su Jimdo 😉

Cordialmente.

Avatar Angelo Ch   
15. Settembre 2020, 18:33

Marco Panichi ha ragione.
Mi soffermo sulla sezione “Tecnologie web”. Cito: “Concentriamoci ora sulle tecnologie web: da quelle backend (per la creazione di siti), alle librerie JavaScript e CSS (per la progettazione e l’interazione), fino a Google AMP.” ovvero confrontare mele, pere ed arance.
Avente confrontato (prendo solo i primi): Ruby on Rails con, AMP, con Bootstrap con Vue.js
Ma dividiamole in gruppi: secondo questa classifica RoR è un fulmine di guerra ma servono 4 data center per fare scalare 4 utenti.
Angular e React sono nella parte bassa delle “classifica” ma guarda caso sono tra i due framework più diffusi.
Siamo certi che il problema sono i framework e non ci scrivi le web app?
Questo articolo me lo ha condiviso un collega per supportare che React è meglio di Angular. Ho risposte che da domani si usa ASP.NET, allora, oppure Bootstrap: scriviamo tutta una web app in CSS.

Elisa Paesante   
17. Settembre 2020, 08:29

Buongiorno Angelo,
grazie del tuo commento.
Hai certamente ragione: le tecnologie confrontate sono differenti.
Tuttavia bisogna sempre ricordare che l’obiettivo di questa analisi è l’utente: a lui non importa quale tecnologia viene utilizzata, bensì poter vedere ed interagire con il sito nel minor tempo possibile.
Gli utenti e i motori di ricerca misurano il risultato finale, non il modo con cui viene raggiunto.