Chi ha iniziato a fare siti a fine anni ’90 si ricorda bene che quelli, per molte persone, sono stati gli ultimi anni in cui per collegarsi ad internet si staccava il doppino dal telefono e lo si collegava al modem.

Era quando per scaricare una canzone con Napster ci voleva almeno mezz’ora e le web performance non erano un’opzione ma un obbligo.

Ovviamente qui nessuno ha mai scaricato una canzone da Napster.
A causa della lentezza delle connessioni e della mancanza di strumenti per lavorare sull’aspetto grafico (come ad esempio i CSS per citarne uno fra tanti) il web era più semplice, le pagine erano decisamente più scarne e l’uso dei media era un aspetto da valutare approfonditamente per evitare di rendere snervante l’esperienza di navigazione.

Poi è arrivato Flash. Tutto sembrava possibile.

Mini game in Flash

Per fare un sito internet si poteva anche non saper scrivere mezza riga di codice, bastava saper disegnare e usare la timeline. File .swf da decine di MB e pagine che non si caricavano mai.
Certo c’era anche un altro modo di usarlo: grazie alle sue potenzialità Flash era alla base di migliaia di mini game, del player video di YouTube e delle prime applicazioni di realtà aumentata.

Ma eravamo pur sempre negli anni in cui la stragrande maggioranza delle connessioni a internet era più lenta di quella di uno smartphone di oggi quando lo usi in cantina.

Per questo motivo chi sapeva usare bene Flash aveva sempre in mente le performance e usava il mitico loadMovie e i preload per garantire un’esperienza di navigazione fluida. Oltretutto con Flash dovevi anche stare attento a non usare troppa CPU altrimenti navigare un sito sarebbe stato come guardare un film al rallentatore e con l’audio fuori sincrono – cosa che a Ghezzi sarebbe piaciuta tantissimo ma all’utente medio decisamente no.

Sembrerà senza senso ma la considerazione che ho per le web performance arriva proprio da lì.

Su progetti complessi potevi inventarti stratagemmi maniacali per non perdere il visitatore e il più delle volte realizzavi dei preload con animazioni che ancora oggi staresti a guardare per dei minuti.

La tecnologia poi si è evoluta e Flash è stato rottamato; potrei scrivere un trattato sul suo funerale annunciato ma non è questo il posto giusto per farlo.

Mi limiterò a dire che il principale problema di Flash era di non essere un progetto Open Source. Tutte le altre considerazioni inerenti l’utilizzo esagerato di risorse o la sicurezza derivano proprio dal non essere open. Probabilmente se non fosse stato ostracizzato si sarebbe trovato anche un modo per risolvere questi problemi ma ormai è andata così.

Beh ma quindi cosa stai cercando di raccontarmi in questo articolo? Che ti manca Flash?

Non esattamente. Flash però mi manca, lo ammetto.

Internet è diventata sempre di più la strada da percorrere per il self-publishing,

creando quella che è stata una delle principali rivoluzioni nel modo di fruire contenuti. Inizialmente i blog erano strumenti semplici che facevano poco più che mostrare al resto del mondo un ipertesto; nel giro di qualche anno però la richiesta di potersi differenziare ed emergere ha portato alla nascita di layout più complessi e in grado di gestire al meglio tutti i media necessari a comunicare. Col passare degli anni questo aumento di complessità è spesso andato a discapito delle web performance.

Siti completamente personalizzabili che nella maggior parte dei casi vengono usati per fare poche cose ma si portano comunque dietro librerie e fogli di stile infiniti.

Anche l’ottimizzazione delle immagini e degli altri media – che è un procedimento semplice – è spesso un grande assente.

Certo, una giustificazione c’è:

oggi abbiamo talmente tanta banda a disposizione che nessuno reputa un problema scaricare una pagina da 5MB piuttosto che una versione ottimizzata da 500Kb.

Nella pratica però questa valutazione ha dei limiti.

Navigando da telefono le tariffe sono a consumo. È lecito far usare ad un utente 20MB di traffico dati per guardare un video – un po’ meno lecito e corretto è invece avere l’home page del proprio sito che pesa 5MB e si limita a farmi vedere uno slideshow di immagini. Non solo si spreca traffico ma si utilizzano più risorse – sia per la quantità di dati che lato utente vanno ad occupare la memoria di uno smartphone sia per lo spazio che viene occupato lato server e che, oltre ad avere un costo economico, ha anche un costo ambientale.
Se poi hai un target più ampio c’è da aggiungere che in molti paesi emergenti la velocità media delle connessioni è la stessa di cui parlavo all’inizio dell’articolo.
A proposito di target e di marketing ci sono molte teorie su quali tempi di caricamento siano accettabili e su come le web performance possono essere un valido strumento di marketing.
Non pensare che grandi player tengano necessariamente in considerazione questo aspetto: qui puoi torvare un’analisi di uno dei principali siti di informazione sportiva italiani – anche per chi non esperto è facile capire che c’è qualche problema di performance.

Quello che vorrei fare è darti degli elementi per capire perchè è importante che il tuo sito sia performante e come valutare queste “web performance”.

Non voglio spiegrati nulla di troppo tecnico, non preoccuparti. Preferisco darti un paio di indicazioni che possono interessarti a prescindere dalle tue competenze tecniche.
Solitamente uso questi 4 siti per svolgere dei test e ricavare dei dati attendibili:

• GTmetrix
• Pingdom
• Webpagetest
• Bulk PageSpeed Test – questo strumento è basato su Google PageSpeed Insights o Lighthouse ed è comodo perchè permette di effettuare l’analisi di un intero sito in una volta sola

Tutti e 3 ti permettono di fare dei test semplicemente incollando l’URL che ti interessa analizzare: ti verrà fornita un’analisi molto dettagliata di tutti gli elementi che influiscono sui tempi di caricamento.
Armati di pazienza (a volte il completamento di un test richiede qualche minuto) e quando sarà pronto il report ti consiglio di focalizzare l’attenzione su questi elementi:

1. Load Time – il tempo necessario al caricamento completo della pagina – che dovrebbe sempre essere inferiore a 3 secondi;
2. il costo della pagina (dato fornito sol oda Webpagetest) – che ti porterà su quest’altro sito;

1: Load Time

Potrei scrivere altri 100 paragrafi a riguardo: qui trovi qualcuno che l’ha già scritto meglio di come lo scriverei io.

2: il costo della pagina

Oggi anche le connessioni mobile hanno un’ampiezza di banda notevole; quando si compiono operazioni semplici come visitare una pagina spesso è difficile notare differenze nella velocità di caricamento tra una connessione mobile e una in fibra ottica. Che siano necessari 1.5 o 15 secondi per scaricare una pagina che pesa 5MB però poco cambia: il traffico che hai consumato è comunque eccessivo. Non solo il tempo è denaro, anche la quantità di dati lo è e dovresti sempre tenerlo presente, che tu sia visitatore o visitato.

Spero di esserti stato utile e averti dato qualche indicazione interessante per valutare le performance del tuo sito.

Se vuoi approfondire le tue conoscenze il web è pieno di informazioni a riguardo. Se vuoi confrontarti con persone piuttosto che con un motore di ricerca posso consigliarti il gruppo Facebook Web Performance Italia e se abiti vicino a Torino anche il Turin Web Performance Group. A questi gruppi e alle persone che li compongono devo buona parte delle cose che ho imparato su questo argomento.