Le performance dei siti ad alto traffico

Tra gli aspetti più importanti di un sito web c’è sicuramente la performance del sito, ovvero la percezione da parte di un utente della velocità con cui il sito risponde ai propri comandi.

Si parla di percezione, perché grazie ad opportuni accorgimenti, quali ad esempio porre il contenuto più importante all’inizio della pagina, anche in caso di connessioni lente si può limitare il malcontento dei visitatori.

Esitono diversi testi che aiutano a ottimizzare il proprio sito; ho personalmente apprezzato qualche anno fa la lettura di “Speed up your site” di Andy Kind che fa una disanima delle tecniche per rendere più veloce il caricamento della pagina (riduzione del codice, compressione, tecniche per il salvataggio delle immagini, ecc.).

Da tempo cercavo però qualcosa che fosse stato scritto da chi (e per chi) realizza siti con tanto traffico, perché necessitano di accortezze tutte particolari.

Per puro caso mi sono imbattituto nella presentazione di un tecnico Yahoo! del 2005 che contiene ottimi suggerimenti e anche qualche conferma per quanto riguarda le strategie da adottare per i grossi siti.

Nella presentazione i contenuto dei siti sono divisi in 3 macrocategorie, in base alla frequenza di aggiornamento:

  • HTML: il contenuto a più alta variazione
  • CSS e Javascript, che cambiano, ma non molto spesso
  • Immagini, che variano raramente

In virtù di questo ragionamento, sono indicati alcuni suggerimenti interessanti:

  • è bene istruire il server e i proxy perché non aggiornino il contenuto delle immagini del sito. Questo vuol dire che i redattori che caricano i contenuti dovrebbero, in caso di modifica delle immagini, caricarne altre con nome diverso
  • un suggerimento è quello di tenere i contenuti non dinamici in uno o più server dedicati, e fare in modo che per l’accesso a questi contenuti non vengano creati cookie, così da rendere molto più efficiente la comunicazione tra browser e server
  • vale la pena, nel caso di contenuti privati di un utente registrato (come per esempio caselle di posta elettronica web based), utilizzare URL diversi per ogni utente, così da permetterne il caching da parte dei proxy, ma evitare che un utente possa erroneamente accedere al contenuto privato di un altro
  • nel caso di contenuti ad altra variabilità, come i banner, è bene arricchire l’URL con numeri casuali, così da renderne altamente improbabile il caching da parte del browser o dei proxy 

L’usabilità delle newsletter

Si parla tanto di usabilità dei siti, ma anche le newsletter inviate ai propri iscritti devono essere progettate con attenzione. Anzi, si potrebbe quasi dire che in questo caso l’operazione è ancora più importante: dopo i molti sforzi fatti per invitare l’utente a registrarsi, è bene a questo punto fare di tutto per non perderlo.

Se dovessi giudicare le newsletter che ricevo, però, mi verrebbe da dire che poco è stato fatto per migliorarne l’usabilità.

Una delle newsletter che aspetto con impazienza è per esempio quella della biblioteca civica di Belluno, che come spesso succede fa bene alcune cose, male molte altre.

Male

  • E’ rigosoramente aperiodica: qualche mese ne vengono spedite 5, altri mesi un paio. Questo non sarebbe un problema [dello stesso problema, a dire il vero, soffre pure la newsletter di Fucinaweb]
  • Il subject dell’email non dice nulla sul contenuto: “Messaggio n. 27/2006”
  • La newsletter è composta solo da un elenco un po’ troppo sterile di avvenimenti, che riguardano eventi futuri anche di 2/3 mesi
  • A poco serve l’alternanza di colori tra i diversi eventi, se non a sottilineare il carattere artigianale della newsletter

Bene

  • Riporta correttamente gli estremi per contattare la biblioteca
  • Indica esplicitamente come annullare la propria iscrizione
  • Contiene, dove possibile, dei link di approfondimento verso il sito o altre risorse
  • Contiene testo, non immagini o inutili abbellimenti. Si potrebbe fare ancora di più: spedirla in formato esclusivamente testuale

Taxonomy e Folksonomy

Un interessante articolo pubblicato nel sito di Asis (The Information Society for the Information Age) e scritto dall’Information Architect Karen Loasby del sito BBC, presenta gli sforzi fatti dai gestori del network per facilitare la ricerca delle informazioni da parte degli utenti.

Dapprima, circa quattro anni fa, il team della Loasby si è limitato a facilitare l’indicizzazione delle pagine da parte dei principali motori di ricerca. Ma, all’aumentare dei contenuti del network, questa soluzione ha perso di efficacia.

Successivamente sono stati “taggati” i contenuti per mezzo di un vocabolario controllato. Questo vuol dire che i giornalisti sono stati istruiti per aggiungere da una lista di termini ben precisa (controllata) i metadati che un motore di ricerca può utilizzare per restituire i dati di interesse. Ma questa soluzione presenta comunque i suoi svantaggi, primo tra tutti il costo dell’operazione.

Una delle ipotesi per il futuro è quella di affiancare a un vocabolario controllato le potenzialità delle folksonomy, cioè la possibilità (alla del.icio.us e flickr) di aggiungere metadati al contenuto senza per forza essere costretti a usare (sempre) rigide regole di associazione.

Non sarebbe male che anche per la televisione nostrana qualcuno si preoccupasse di queste problematiche.