Un sito veloce influenza la SEO!

,

Partiamo con una bella premessa: il mio non vuole essere un semplice articolo sul perché un sito deve essere veloce per la SEO, tutt’altro: con questo articolo vorrei far capire perché un sito deve essere veloce a prescindere dalla SEO, come user experience dell’utente.

Riccardo qualche settimana fa ha già parlato di AMP, ma la velocità è una cosa diversa dall’implementare un sistema che mi toglie tutto, crea un doppione di pagina senza praticamente nulla se non pochi css, pochissimi o nessun JS, alcune immagini e via dicendo. Quello che voglio dirti è che se prendiamo una pagina che pesa 2Mb e la facciamo diventare di 200Kb, è molto più semplice che sia una pagina veloce.

Voglio spiegarti come prendere un sito con tutte le caratteristiche che deve avere un sito e farlo diventare veloce e dimostrarti che questo influenzerà la SEO e anche le conversioni in generale: infatti una navigazione più fluida e veloce fa sì che l’utente rimanga più volentieri e per più tempo nel sito.

Di cosa parleremo in questo articolo:

  1. Tempo di elaborazione vs tempo di erogazione
  2. Velocità per la SEO
  3. Risultati della velocità sulla SEO
  4. Il tempo di download di una pagina VS tempo di rendering
  5. Cosa devo fare per avere un sito veloce
  6. Http VS Http/2
  7. Immagini Webp vs Jpeg

 

Tempo di elaborazione vs tempo di erogazione

Vediamo nella foto qui a fianco un esempio di quello che voglio chiarire, tralasciamo il tempo di richiesta, il tempo di risoluzione DNS e tutto il resto che per adesso non prendiamo in considerazione.

Prendiamo solo in esame i due parametri che ho evidenziato, cioè il tempo di Waiting (attesa) e il Content Download, cioè il tempo per il download dei dati.

Come puoi vedere il tempo di attesa è molto, molto più alto rispetto al tempo effettivo di download quindi, per deduzione, secondo te dove devo intervenire prima?

La risposta è scontata: se questa risorsa fosse una risorsa statica (css, js , jpg), cioè immediatamente disponibile sul server, il tempo per erogarla sarebbe molto basso.

Ma spesso le nostre risorse sono dinamiche, cioè file che devono essere generati, ad esempio pagine php, e magari con interrogazioni a database, e quindi ecco che ci ritroviamo il tempo di “Waiting” cioè il tempo che il server ci mette per generare quella pagina, elaborando il php e interrogando il mysql prima che sia pronta per essere erogata.

Velocità per la SEO

Bene: adesso che ho chiarito il concetto del tempo di elaborazione di una pagina, ti spiego perché è così importante abbassarlo il più possibile per far in modo che un sito si posizioni meglio per la SEO.

Il concetto chiave di partenza è semplice e lo vediamo subito: ogni sito ha un punteggio e Google gli associa – tramite vari parametri – un tempo di aggiornamento ben preciso. Mettiamo che il mio sito abbia a disposizione da parte di Google 2 minuti ad ogni passaggio dello spyder: in quei 2 minuti devo fare in modo che Google possa vedere il maggior numero di pagine possibili, quindi banalmente se le mie pagine html in media ci mettono, come vedi nella foto sopra, 2,07s + 0,121s = 2,191s, facendo il conto della serva Google in 120 secondi scansionerà 120/2,191=54,76 pagine.

Di seguito propongo una schermata della “search console” in modo da farti capire cosa succede: partiamo da un sito che non era ottimizzato e vediamone il comportamento dopo l’ottimizzazione.

Grafico verde, all’inizio il sito aveva in media tempi di risposta di oltre 3000 ms, cioè 3 secondi per pagina e cresceva in proporzione alle pagine scansionate, guarda i picchi nel grafico BLU.

Poi abbiamo ottimizzato il sito con dei sistemi di cache applicativa e con un Reverse Proxy e guardiamo cos’è successo.

Il grafico Verde è sceso e si è stabilizzato con tempi di erogazione medi di 208 ms, cosa significa solo a livello di conteggio in pagine scansionate? Riproviamo a fare il conto di prima: 120/0,208 = 576,9, quindi nello stesso tempo Google riusciva a scansionare prima 54 pagine, adesso 576, non male come differenza!

Guardiamo il Grafico Blu: man mano che Google ha capito che poteva scansionare più pagine senza mettere in difficoltà il sito, ha iniziato ad aumentare le pagine scansionate, arrivando a scansionarne 1500 ad ogni passaggio.

Ma come mai il Grafico Rosso ad un certo punto ha un picco, se non ci sono picchi di pagine? Semplice, perché Google non scansiona solo html ma, per esempio, anche immagini, e quindi in quelle scansioni ha scaricato di conseguenza molti più dati.

Bene, adesso che hai capito quali sono i valori ottenibili, entra anche tu nella Search Console e fammi sapere che parametri ti dà il Grafico Verde.

Clicca qui per mandarmi i tuoi valori

 

Risultati della velocità sulla SEO

Vediamo cos’è successo, però, alla parte organica di questo progetto: posto che abbiamo migliorato la velocità del sito, questa azione quanto ha influenzato la SEO?

Nel grafico sopra vediamo come siamo passati da 400 a 1200 click, mantenendo tutto immutato: significa che ho triplicato le performance organiche del sito lavorando sulle performance di velocità del sito. E allora, abbiamo ancora dubbi sul fatto di avere un sito veloce?

In questo grafico metto a confronto la crescita tra febbraio e aprile.

Il tempo di download di una pagina VS tempo di rendering

Poco sopra abbiamo visto il grafico verde che indica il “tempo trascorso per il download di una pagina”, ma è possibile avere un sito lento nonostante il grafico verde sia attorno ai 200-250 ms? La risposta, purtroppo, è SI.

Il tempo di download di una pagina, infatti, è solo il tempo che ci ha messo ad essere scaricata sul nostro pc, e in una pagina ci sono decine di risorse come immagini, javascript, css che influiscono sul tempo di visualizzazione di quella pagina. E influiscono ancora di più a livello mobile, tanto che si parla di Mobile First proprio per questo, cioè “il Mobile prima di tutto”.

Sul tempo di rendering parleremo tra qualche settimana con un nuovo post dedicato qui nel blog.

Cosa devo fare per avere un sito veloce?

La prima risposta banale è: ad ognuno il suo lavoro, quindi non improvvisarti e contatta dei professionisti.

Ti posso dire, però, come ragiono io: non in tutti i siti si fanno le stesse cose, ci sono moltissime variabili in gioco e bisogna conoscerle bene per fare la scelta migliore, anche perché un errore su questo punto porta a delle catastrofi vere e proprie che poi io e i miei colleghi ci troviamo molto spesso a dover risolvere.
Quindi, cerchiamo di evitarle a monte, così la strada è più semplice.

Se hai un sito istituzionale, un sito di e-commerce, un sito corporate o un blog, queste sono le cose che vanno valutate:

  • tipo di sito e campagne attive
  • grandezza del sito in numero di pagine
  • traffico stimato
  • tecnologia utilizzata: php, asp, .net, java, ruby, altro
  • tipo di database: mysql, mongo DB, oracle, altro
  • CMS utilizzato

In alcuni casi è sufficiente poco tempo per risolvere molti problemi, ma ovviamente non mi riferisco a chi ha il “sitino” wordpress semplice, sto parlando di chi ha un’azienda strutturata, con interfacciato l’ERP aziendale, che utilizzi un sistema CMS Enterprise tipo Drupal 7 o 8, oppure per chi ha una struttura Custom e la vuole rendere performante o a chi utilizza un Magento con all’interno migliaia di prodotti e le pagine ci mettono secondi per aprirsi.

In tutti questi casi ci sono diverse soluzioni, ti elenco alcune di quello che metto in campo quotidianamente per clienti mediamente strutturati.

Sistemi di cache applicativa:

  • opcache
  • full page cache
  • object cache

Sistemi di cache esterna:

  • Reverse proxy
  • DB cache come Redis
  • Elasticsearch per implementare sistemi di ricerca avanzati

Tipologia di Server:

  • Server VPS ad elevate prestazioni
  • Server Cloud
  • Server amazon con sistemi di cache distribuita

 

Http VS Http/2

Ti lascio una chicca, negli ultimi mesi sto implementato sempre di più i sistemi HTTP/2 che non sono altro che un nuovo protocollo, praticamente l’evoluzione del sistema http e la versione aggiornata e rivista di SPDY.

A cosa serve? Dando per scontato che adesso le tue risorse vengono generate alla velocità della luce, questi dati devono essere mandati verso l’utente dal server, e il protocollo HTTP normale serviva questi dati uno alla volta, come se dentro al server ci fosse un uomo che serve i clienti uno alla volta.

Il protocollo HTTP/2, invece, serve tutte le risorse contemporaneamente abbassando notevolmente i tempi di latenza e quindi dando un boost ancora maggiore al tuo sito. L’immagine è sicuramente utile per capire meglio quello che voglio dirti:

Questo nuovo protocollo è utilizzabile da poco, infatti i browser hanno implementato le compatibilità molto di recente e – ad oggi – con una retro compatibilità rassicurante: infatti, se il browser non supporta HTTP/2, si puòtranquillamente continuare a dialogare con il vecchio protocollo HTTP. Qui puoi vedere una tabella di compatibilità HTTP/2

ATTENZIONE! L’ho inserito alla fine dell’articolo per un motivo ben preciso, se non fai le cose scritte prima, implementare questo nuovo protocollo non serve a nulla.

Immagini Webp vs Jpeg

Finalmente si inizia a vedere e a distribuire questo nuovo formato di immagini: eravamo fermi al Jpeg, una cosa inventata 20 anni fa, secondo te erano ancora utilizzabili al giorno d’oggi? Ora si sta facendo strada Webp che, tanto perchè tu lo sappia, è un formato inventato da Google, quindi secondo te Google a chi darà la precedenza a parità di forza? Non ho ancora dati che supportano questa tesi, ma potrei rischiare di espormi, sono quasi certo che la precedenza sarà data alle sue immagini.

Il problema è che molti editor grafici non lo supportano ancora, Photoshop compreso, quindi per adesso esiste un plug-in per photoshop da installare a parte, assieme ad altre librerie.

Le caratteristiche di Webp sono le seguenti:

  • Compressione: la compressione è basata sulla codifica di frame chiave VP8.
    VP8 è un formato di compressione video creato da On2 Technologies come successore dei formati VP6 e VP7.
  • Compressione senza perdita: il formato di compressione senza perdita viene sviluppato dal team WebP.
  • Trasparenza: il canale alfa a 8 bit è utile per immagini grafiche. Il canale Alpha può essere utilizzato insieme a RGB lossy, una funzionalità che non è attualmente disponibile in qualsiasi altro formato.
  • Animazione: supporta immagini animate a colori vivaci.
  • Metadati: può avere metadati EXIF e XMP (ad esempio, utilizzati da fotocamere).
  • Profilo colore: può avere un profilo ICC incorporato.

La compatibilità dei browser è ancora limitata, per cui a supporto puoi consultare questo testo: compatibilità di webp e questa guida su come rendere compatibili i siti con Webp

 

Entra a far parte dei pochi eletti che hanno un sito veloce! Clicca qui