Come e perchè facciamo siti unici

Perchè li facciamo come li facciamo

Se il tuo sito web è veloce, avrai più tempo per passeggiare con le tartarughe.

Premessa

Tutte le considerazioni ed i dati che snoccioleremo in seguito, non vanno male interpretati. Per quel che ci riguarda, anche il sito più veloce e tecnicamente ben fatto, se non ha contenuti di qualità, esaustivi e ben formulati, generosi e sinceri, pensati per un visitatore curioso e senziente e non semplicemente per un "cliente", non ci interessa.
Però, costruire un sito veloce ed ottimizzato, quindi sicuramente fatto con cura, che impiega meno risorse ed energia, è una condizione necessaria (ma non sufficiente) per rendere il web uno strumento migliore.

Considerazioni

La maggioranza dei siti web in rete, piccoli o grandi, commerciali o no, vengono attualmente realizzati con software "preconfezionato" .

Il che vuol dire che vengono creati a partire da moduli software preesistenti, poi adattati, modificati e assemblati in base alle esigenze (CMS, librerie javascript, framework, ecc.). Questo approccio accorcia i tempi di realizzazione del sito e diminuisce le conoscenze tecniche necessarie alla sua creazione; di contro:

• uniforma scelte grafiche e tecniche.
• rende dipendenti da aggiornamenti e da software di terze parti (quasi mai disinteressati elargitori di software) su cui si ha poco o nessun controllo.
• aumenta la complessità e la pesantezza del sito.
• diminuisce drasticamente le possibilità di ottimizzazione.

Questo si traduce in siti pachidermici, graficamente molto simili l'uno all'altro, lenti e vulnerabili. O, almeno, così ci pare: vediamo perchè.

Numeri (o della pesantezza)

I dati della Fig.1 si riferiscono ai valori mediani (in chilobyte) delle risorse richieste da una pagina web ed al numero di richieste necessarie a scaricare ogni componente della pagina su computer desktop e su dispositivi mobili (smartphone, tablet, ecc.). Il 50% di tutti i valori è inferiore a quello mediano (o 50° percentile) i valori restanti, superiori.

Per esempio: su desktop il valore mediano di una pagina web è di:

• Totale: 2080,2 kB con 76 richieste . Di cui:
• Immagini: 1026,3 kB (49%) con 30 richieste
• Javascript:: 450,4 kB (22%) con 21 richieste

Riportiamo anche, nella Tab.1, le distribuzioni percentili attorno al valore mediano dei valori precedenti, arrotondati all'unità (qui e nel seguito i dati riguardanti i dispositivi mobili verranno indicati con "mob"):

Il percentile è una misura statistica che indica il minimo valore sotto al quale ricade una data percentuale degli altri elementi del campione. Per esempio, p10, o decimo percentile, indica il valore al di sotto del quale, si trovano il 10% di tutti i valori.

Alcune considerazioni su questi ed altri dati; Per es, per il desktop:

• Solo il 10% delle pagine ha un peso minore di 489 kB ed il 25% ha addirittura un peso maggiore di 3988 kB. Nel 2019 il peso delle pagine è aumentato del 10% rispetto all'anno precedente (fonte: httparchive.org).
• Le immagini danno il contributo più importante al peso totale della pagina.
• Solo il 10% delle pagine utilizza meno di 27 richieste. Più è alto il numero delle richieste, più è lento il caricamento della pagina.
• JavaScript e la risorsa più costosa da inviare al browser (in particolar modo per i dispositivi mobili): deve essere scaricato, parsificato, compilato ed eseguito (si veda, per es.: The cost of JavaScript in 2019).
  Solo il 10% delle pagine utilizza meno di 105 kB di JavaScript. La mediana del suo tempo di esecuzione è di 0,85 secondi su desktop e 2,44 secondi su mobile (fonte: httparchive.org).
• Il 94% circa delle pagine utilizza una qualche risorsa di "terze parti", cioè fuori dal controllo del titolare del sito ( per es. Facebook Ads, Google Analytics, ecc.) (fonte: httparchive.org).
  Circa il 73% di JavaScript, proviene da "terze parti" (fonte: httparchive.org).
  L'81% delle pagine su mobile, ha una vulnerabilità dovuta a JavaScript di terze parti (fonte: httparchive.org).
• Il 40% circa delle pagine web è costituito da CMS (Content Management System) e WordPress è il CMS più utilizzato con una percentuale di circa il 30%. Il valore mediano di una pagina web di un CMS è di 2,3MB totali (desktop e mobile - fonte: httparchive.org).
• jQuery, la più popolare libreria JavaScript, viene usata nell'85% delle pagine (83% su mobile) (fonte: httparchive.org).

Altri numeri (o della lentezza)

Nella Fig.2 troviamo i valori mediani di alcuni parametri utili a capire quanto velocemente si carichi una pagina web; nel dettaglio:

• First Contentful Paint (FCP) - il tempo necessario alla visualizzazione del primo testo o della prima immagine: 2,2 s su PC e 5,7 s su mobile
• DOMContentLoaded (DCL) - il tempo necessario affinchè il file HTML iniziale sia scaricato e processato: 2,9 secondi su PC e 7,4 s su mobile
• onLoad - tempo necessario al file html e a tutte le risorse della pagina per essere scaricati: 6,6 secondi su PC e 19,6 secondi su mobile
• First CPU Idle (FCI) - il tempo necessario affinchè la pagina diventi minimamente interattiva: 7,5 secondi su mobile
• Time to Interactive (TTI) - il tempo necessario affinchè la pagina sia completamente interattiva: 9,3 secondi su mobile.

Vediamone anche le distribuzioni attorno alla mediana su desktop e mobile:

Secondo uno dei tanti studi, il 53% dei visitatori abbandona una pagina su dispositivo mobile se occorrono più di 3 secondi per caricarla (fonte: www.hobo-web.co.uk). Fino a 3 secondi l'abbandono è del 32%, oltre i 5 secondi del 90% (fonte: Google data measurement).

I nostri numeri

“Ero così veloce che potevo alzarmi dal letto, attraversare la stanza, girare l'interruttore e tornare a letto prima che la luce si fosse spenta.”
Muhammad Ali

Abbiamo effettuato su due dei nostri siti, lunariaweb.it (cioè il sito che hai davanti) e giuseppepatane.it, dei test con gli stessi strumenti e metodologie (quando possibile), utilizzati da http archive per ricavare i dati visti in precedenza. Per brevità, di quei dati, riporteremo solo quelli relativi al decimo percentile ed alla mediana, per poterli così confrontare con quelli trovati per lunariaweb.it (indicato in tabella con "LUNARIA") su desktop e su mobile e i dati trovati per giuseppepatane.it (indicato in tabella con "GP") su desktop e su mobile .

(* il test non ha rilevato i valori di JavaScript in quanto inline, cioè inserito all'interno della pagina stessa e non in un file esterno. I valori riportati sono stati rilevati con il tool Pagespeed)

Si noti che il numero delle richieste e l'ammontare di JavaScript dei nostri siti, siano veramente esigui anche confrontati con il 10° percentile del campione.

Confrontiamo questa volta i valori relativi alle prestazioni ottenuti per lunariaweb.it e per giuseppepatane.it

Come si vede, i nostri siti, hanno tutti i parametri relativi alle prestazioni, migliori di quelli del decimo percentile, a volte, sopratutto per i dispositivi mobili, anche significativamente.

In parole povere: i nostri siti si caricano in un battibaleno!

Come detto, per tutti i test precedenti, abbiamo utilizzato le stesse metodologie utilizzate per i siti campione, cioè utilizzando WebPageTest e settando il server americano di riferimento (Dulles VA, USA).

Così facendo, dato che la distanza tra il server ed il visitatore influenza la velocità di caricamento della pagina, pur ottenento ottimi risultati, ci siamo messi nelle condizioni più sfavorevoli.

Rifacendo gli stessi test per lunariaweb.it ma impostando, questa volta, un server europeo (Paris - EC2), abbiamo ottenuto risultati ancora migliori (Tab.5).

Come li facciamo

• HTML, CSS: sono gli ingredienti principali del nostro lavoro e tentiamo di utilizzarli il più possibile senza ricorrere ad altro. Il loro utilizzo, anche in modi inusuali, creativi e, a nostro avviso, poco esplorati (radio controlled web design, Css lightbox ecc.) ci permette di creare siti web snelli e veloci. Evitiamo framework o template. I nostri siti funzionano anche con JavaScript disabilitato.
• Ibrid Single Page Application: l'interfaccia utente ed i contenuti principali desiderati, vengono caricati all'istante, il resto quando necessario o in background. Senza utilizzare pesanti framework (Angular, React, Vue, ecc.), riusciamo, con pochi KB di Javascript, a creare interfacce utente, dalla più semplice alla più complessa, veloci e modulari. E in caso di supporto Javascript disabilitato o assente, si passa automaticamente alla navigazione classica senza perdere nessun contenuto!
• JavaScript: solo una spruzzatina, quello indispensabile, grazie. Evitiamo il più possibile, ogni libreria, in particolar modo quelle di terze parti. Preferiamo piccole porzioni di codice personalizzato per ogni progetto.
• Ottimizzazione: è una delle nostre priorità. Utilizziamo ogni tecnica (compressione, sprite images, lazy loading, inline Css e Javascript, ottimizzazione cache ecc.) per ottenere siti che si caricano nel minor tempo possibile.
• Innovazione e sperimentazione: è una parte cospicua del nostro lavoro (Css grid, immagini WebP, Fluid typography ecc.). E poi c'è I.V.A. (Interfaccia Vocale Avanzata), la nostra ultima creatura. Permetterà ai vostri visitatori di navigare nel vostro sito solo con la voce. Un'esclusiva Lunaria!
• CMS: non è che ci stiano antipatici (chi è senza WordPress scagli il primo byte), anzi, svolgono egregiamente il loro lavoro. Spesso, però, utilizzarli, ci sembra simile ad voler usare un elefante per trasportare una coccinella. Solo quando e dove necessario.
• Sicurezza: forniamo connessioni cifrate sicure (https) e utilizziamo tutti gli accorgimenti tecnici necessari a tutelare i visitatori (Content Security Policy, Strict-Transport-Security, ecc.).
• Privacy: gli eventuali dati raccolti dai siti dei nostri clienti, sono in forma totalmente anonima e utilizzati esclusivamente per il miglioramento del sito. Evitiamo assolutamente software tracciante di terze parti (Google analitics, snipset Facebook, ecc.).