La velocità è tutto…

Non passa giorno che mi debba scontrare con la lentezza di questo o quel dispositivo (PC, tablet, …) ad accendersi e ad essere realmente usabile. Medesimo discorso per i vari programmi, partendo ovviamente dai sistemi operativi.

Nonostante il continuo aumento di prestazioni di questo fatato mondo, non c’è corrispondenza con un aumento di prestazioni reale, concreto, visibile cioè dal lato utente. Riformulo: hardware e software vanno di pari passo e sussiste qualcosa tipo:

prestazioni(software * hardware) al tempo t = costante

Software bloat Vs Prestazioni

Penso sia naturale, dopotutto: più le “macchine” migliorano e più si possono aggiungere feature nel software, dimenticandosi o non dando troppa attenzione all’ottimizzazione del codice (“tanto i PC attuali ce la fanno lo stesso”). Questo è un esempio di software bloat istituzionalizzato:

Software bloat is a process whereby successive versions of a computer program include an increasing proportion of unnecessary features that are not used by end users, or generally use more system resources than necessary, while offering little or no benefit to its users.

Questo è dovuto anche alla necessità per le aziende produttrici di hardware e di software di presentare sul mercato sempre qualcosa di nuovo e non sempre le novità introdotte sono così utili, diciamo così.

Ad esempio, perchè per fare le stesse azioni che un utente-medio svolgeva su un PC con Windows XP e 256-512MB di RAM ora serve un PC con Vista/7 e 2+ GB di Ram? Cosa ci ha guadagnato davvero l’utente finale nel passaggio? Aero può da solo giustificare tutto questo? Ok, il sistema operativo sotto sotto è migliorato, ma dopo 6 mesi di uso relativamente intenso le prestazioni delle due piattaforme, vecchia e nuova, sono tristemente simili (cfr. vecchio post). Erro?

Spolsky in un celebre post, “Strategy Letter IV: Bloatware and the 80/20 Myth“, tratta questo concetto – il “bloatware” – dal lato economico, spiegando come tutto debba essere sempre preso in considerazione rispetto ai tempi di rilascio sul mercato, ossia tenendo bene in mente i costi via via ridotti e le prestazioni via via in aumento dei PC.

Tuttavia, concordando anche con Spolsky sugli aspetti economici del suo ragionamento, non mi viene da concordare con lui sugli effetti pratici: perchè comprando un hardware nuovo con del software nuovo, io, utente, devo pagare anche questa tassa occulta sulle prestazioni?

Dal desktop al web il discorso non cambia

Osservando questo “problema” dal punto di vista del web, la situazione si ripropone pari pari. Mi riferisco al fatto che una discreta quantità di siti sembrano pensati e testati per lo stesso tipo di hardware e software con cui sono stati sviluppati. O non vengono affatto testati.

Mai considerare la propria macchina di sviluppo come indicativa per i test. Di solito uno sviluppatore sceglie per sè una macchina adeguata al suo lavoro, personalizzata a suo uso e consumo e di solito ben diversa dal tipo di macchina dell'utente finale. Vista l’impossibilità pratica di disporre di più macchine diverse per i test, una batteria di virtual machine con differenti configurazioni – magari browser diversi, come fa John Resig, l’autore di jQuery – potrebbe rappresentare un onesto palliativo.

Per cui è facile imbattersi in siti relativamente ben fatti che però richiedono letteralmente megabyte di dati scaricati prima di vedere la sola homepage completa. Il discorso-scusa “tanto c’è la cache del browser” in questo caso non regge: se un utente visita per la prima volta il vostro sito la cache è ovviamente vuota.

Quantificare la pazienza dell’utente

Da utente dotato di un ASDL decente trovo fastidioso ben oltre l’accettabile attendere più di 10 secondi per riuscire a leggere qualcosa – qualunque cosa – in un sito. Trovo la cosa doppiamente irritante se ho atteso il caricamento di tonnellate di dati per poi scoprire che quel sito non fa il caso mio, un evento relativamente comune.

La pazienza dell’utente è quantificabile. La mia è pari a 30 secondi: se un sito ci mette più di quel tempo a caricare – e da bravo utente non mi interessa minimamente sapere il perchè – cambio sito.

Sono così stanco di queste futili attese quando navigo, che ormai ho sviluppato una strategia semplice e spesso efficiente. Quando ricerco qualcosa, apro almeno più siti-risultato in parallelo ossia in altrettanti tab del browser. Se il primo tab ci mette più di quei 30 secondi, lo chiudo da tastiera, passando automaticamente al secondo e così via. Se i tab finiscono torno da Google e cambio i termini di ricerca e riprendo da capo.

Non sopporto i rallentamenti nè tollero chi progetta siti senza tener in minimo conto che il tempo dell’utente è prezioso e non va sprecato costringendolo ad attendere il caricamento di inutili orpelli.

Un altro fattore di rallentamento: la creazione delle pagine dinamiche

Non c’è solo il tempo effettivo di ricezione e caricamento dei dati nel browser, non ci sono solo i ritardi di trasmissione sulla rete, ma nel calderone vanno inclusi i tempi di generazione delle pagine, ossia la composizione delle pagine dinamiche prima dell’invio all’utente.

Nel bellissimo post “Performance is a Feature“ di CodingHorror si parla proprio di questo:

“[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

I believe the converse of this is also true. That is, the faster your website is, the more people will use it. This follows logically if you think like an information omnivore: the faster you can load the page, the faster you can tell whether that page contains what you want. Therefore, you should always favor fast websites.

The opportunity cost for switching on the public internet is effectively nil, and whatever it is that you’re looking for, there are multiple websites that offer a similar experience.

So how do you distinguish yourself? You start by being, above all else, fast.“

Se ne deduce che io, con i miei “30 secondi di pazienza”, rientro nella classe di utenti tutto sommato pazienti. Voi in che classe di utenti vi ponete? Quanti secondi di “latenza” riuscite a tollerare prima di abbandonare un sito?

Curioso che in tutto questo l’aspetto dei contenuti sia secondario: i migliori contenuti che si possano trovare sulla Rete valgono poco se l’utente è già scappato, esasperato dalla lentezza complessiva del sito che li ospita.

Che ne pensate?