I siti pigri sono i più veloci

Ho messo da parte in questi anni un bel po’ di materiale e documentazione relativi alla performance e ottimizzazione dei siti web, sia per quanto riguarda il cosiddetto lato server, sia per quello che viene chiamato front end.

Verrà – spero presto – il momento di compilare un elenco ragionato di tutte queste risorse (potete farvene un’idea visitando la sezione optimization del mio delicious), ma ora mi limito a citare un articolo che propone in modo molto chiaro uno dei nodi fondamentali da affrontare. Si tratta di Lazy web sites run faster scritto da Gojko Adzic.

Per aumentare le performance dei siti potete investire sull’hardware, quindi più processori e sistemi più veloci, migliore connettività, infrastruttura moderna. Vi accorgerete però che anche così facendo il web server fatica, per architettura, a gestire un sito il cui codice non sia ottimizzato.

Potete allora dedicarvi alla riscrittura (o refactoring) del codice per renderlo più veloce. Anche qui però arriverete ben presto a un limite.

Il segreto, secondo Gojko, sta invece nella progettazione di un sistema che si preoccupi di

  • delegare le operazioni più complesse a processi che girano in background;
  • non comunicare con sistemi esterni in modo sincrono, non importa quanto velocemente;
  • essere pigro: meglio lasciare per dopo tutto quello che non ha necessità di essere eseguito al momento.

Aggiungerei anche di eliminare le elaborazioni inutili, come per esempio l’esecuzione a ogni richiesta di interrogazioni esose (come quelle verso i database) per contenuti che non cambiano quasi mai. In questo caso potrebbe essere interessante sperimentare qualche meccanismo di caching.

Se ripenso ai colli di bottiglia dei progetti che ho visto da vicino, la maggior parte poteva essere evitata rimandando operazioni non immediatamente essenziali, come per esempio:

  • l’invio di un messaggio di posta elettronica di conferma;
  • la trasformazione di file (soprattutto in formato XML);
  • la comunicazione con sistemi di gestione;
  • il calcolo di statistiche.

Capita di trovare anche online degli esempi che fanno riflettere. Ogni volta che utilizzo la funzione “all time” di Feedburner per analizzare il traffico complessivo dei miei feed mi trovo ad aspettare almeno una decina di secondi. Probabilmente il sistema sta elaborando il consuntivo in tempo reale, quando avrebbe potuto farlo a priori. Non c’è nulla di male ad aspettare anche se a volte, per carico del server, viene restituito un timeout. Forse non proprio il modo ideale per gestire questa funzionalità, anche se utilizzata da una minoranza.

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