Come ottimizzare un sito web lento

Antefatto
Verso la fine del 2011 un cliente mi chiamava disperato: "Non ce la faccio più: ogni volta che invio una newsletter con i nuovi prodotti presenti sul mio sito, i clienti arrivano in massa e mi bloccano tutto. Non so come risolvere la cosa, ci deve essere qualche problema. Puoi capire di cosa si tratta?"

Questo è il classico caso nel quale, dopo anni di sviluppo di un sito, o semplicemente dopo una rapida crescita degli utenti, ci si accorge che l'architettura utilizzata è obsoleta, mal dimensionata o inadatta al tipo di traffico attuale.

In questi casi, colleghi di aziende per le quali ho lavorato, proponevano sempre la via più semplice: prendiamo una macchina più potente.

Purtroppo, in questo modo il problema non si risolve, si sposta semplicemente in avanti, aumentando i costi di infrastruttura e di licenze: se oggi pago 10.000 euro per mantenere i server, da domani pagherò 20.000 euro, ma il software che utilizzo continuerà ad avere problemi.

In questo caso specifico, la scelta di aumentare l'hardware utilizzato dal sito era già stata fatta.

Il problema di fondo era quello che, il linguaggio utilizzato per scrivere il codice del sito (si parla di Java 1.4) non era più in grado di sfruttare la potenza di calcolo dei nuovi server.
Oltre a questo, alcuni componenti software necessitavano di nuove licenze per poter usare tutti i processori disponibili, con un ulteriore aumento dei costi fissi annuali.

Questo rincorrersi continuo di costi aveva fatto così lievitare la spesa infrastrutturale dell'intero sito, mitigando i problemi, ma non risolvendoli: durante alcune campagne il sito era praticamente inutilizzabile.

Velocità di elaborazione
Prima di dare qualsiasi tipo di parere, volevo capire il reale stato del sito, basandomi su alcuni indicatori interni ed esterni.

Il primo indicatore che ho utilizzato è stato quello della velocità delle pagine.
Volevo sapere se, per caso, non ci fossero delle pagine in grado di fare da "tappo" a tutto il resto.

Risorse finite
Normalmente un'applicazione web viene pensata in modo da utilizzare delle risorse "finite". Una volta che sono esaurite, le richieste successive vengono rigettate o messe in coda.
Nel primo caso si ha un disservizio nelle nuove richieste, ma le richieste che arrivano al server sono soddisfatte in un tempo accettabile. Nel secondo caso si riesce a gestire meglio il maggior traffico, ma si introducono delle lentezze.

Il caso classico di risorsa finita è in numero di processi paralleli del webserver o la grandezza del connection pool dell'applicazione o il numero di accessi concorrenti che accetta il database utilizzato dal sito.
In base al server o al database che si utilizza, questo numero può variare di molto.

Tralascio tutte le tecniche con le quali verificare o configurare questi valori, dato che ogni architettura si valuta in modo diverso, e torno a questo caso specifico.

Il server soffriva di un problema di accodamento: c'erano delle parti del sito che, per come era scritto il codice, e per la quantità di informazioni che erano restituite all'utente finale, rallentavano l'intera architettura.

Per riuscire a trovare le pagine "tappo" abbiamo utilizzato vari strumenti.

Google Analytics: nella sezione Comportamento\Velocità del sito, è possibile avere una panoramica, sia delle pagine maggiormente richieste, sia dei tempi di visualizzazione medi.
Unito al fatto che le prestazioni possono essere osservate in un certo range di tempo, siamo riusciti ad isolare, sia le pagine globalmente lente, che quelle lente durante le campagne "email".

Log del server: ogni sito web dispone di propri log, nei quali, oltre ad esserci le informazioni sulle pagine che vengono effettivamente trovate o non trovare, c'è un'importante informazione rispetto alla dimensione della pagina che è stata generata.

Parlando di pagine HTML, un valore inferiore ai 50k è sicuramente accettabile. Valori molto superiori ai 50k, normalmente nascondono dei problemi.

Ci siamo così accorti di alcune pagine che restituivano oltre 2MB di dati e provando ad accedervi da browser ci siamo accorti che i tempi di creazione di queste pagine erano superiori al minuto.

Il primo passo di ottimizzazione è così andato verso l'ottimizzazione delle pagine che avevano i peggiori tempi di esecuzione.

Tempo di risposta del server
Un altro problema che avevamo era la banda utilizzata dal server. La banda è anch'essa una risorsa finita: una volta raggiunto il suo limite, le prestazioni decadono.

Per risolvere il problema di banda vi sono almeno 2 tecniche diverse:

Aumentare la banda disponibile: in questo caso la soluzione tende a rimuove il limite massimo di dati che possono essere trasportati.
Diminuire l'utilizzo della banda: in questo caso si tende invece a passare meno dati, in modo da non raggiungere il limite e soprattutto avere tempi di risposta più veloci.

Quando lavoro all'ottimizzazione di un sito tendo a seguire la seconda strada: provo a capire se sono stati messi in atto tutti gli accorgimenti necessari per diminuire i dati trasmessi dal serve web al clienti.

Anche in questo caso è possibile lavorare in più direzioni: alcune richiedono un impatto sul codice, a volte anche importante, altre sono semplici configurazioni.

Compressione dei dati
In questo caso specifico mi sono trovato di fronte ad un sito che, per obsolescenza della sua architettura, non usava la compressione dei dati fra il server e il browser.
Il motivo era facilmente spiegato: il server web utilizzato, si trattava di un vecchio BEA Weblogic, non disponeva di questa tecnologia e non era in grado di comprimere in GZIP i dati inviati.

Per risolvere la cosa potevamo lavorare in due direzioni: anteporre al sito web un bilanciatore in grado di effettuare la compressione di protocollo, oppure trovare un prodotto che lo facesse internamente.

In questo caso ci siamo affidati a Pjl comp filter, un filtro Java in grado di effettuare la compressione dei dati in modo trasparente.

Questa aggiunta ha permesso così di ridurre il traffico a circa 1/5 rispetto a prima, facendo dimenticare qualsiasi problema di banda, ma non solo: accelerando di parecchio il tempo di ricezione dei dati e dando la sensazione di avere un sito web molto più veloce.

Riduzione delle risorse
Queste prime migliorie ci avevano già permesso di migliorare di molto i tempi di risposta del server, ed anche di decongestionarlo durante i momenti di picco.
Vi erano però ancora dei punti dove era facile migliorare la velocità del sito, senza andare ad intaccare particolarmente il codice.

Tramite Webpagetest.org e Firebug, abbiamo analizzato il numero di richieste che venivano fatte dalle singole pagine e abbiamo provato, da un lato a ridurre il numero di chiamate, accorpando alcuni script e alcuni fogli di stile fra di loro, dall'altro abbiamo introdotto una data di scadenza ai file, in modo che, in navigazioni successive, il browser non continuasse a scaricare file dalla rete, ma riutilizzasse quanto già scaricato.

Questa piccola ottimizzazione ha permesso di dare un taglio netto al numero di richieste del sito web, accelerando parecchio la navigazione dalla seconda pagina in poi che, a questo punto, era quasi istantanea.

Conclusione
Questi sono solo alcuni dei lavori fatti per ottimizzare il sito, dato che l'attività è durata circa 40 giorni. Parte del tempo è stata allocata sull'analisi di cosa occorreva fare, circa 10 giorni da parte mia. Il restante tempo è stato utilizzato dal cliente per la modifica del sito, secondo quanto avevamo concordato ed analizzato.

Il risultato di tutto questo lavoro è stato che:

* Sono scomparsi i blocchi del server in caso di alto traffico
* I tempi di risposta medi del sito si sono ridotti ad 1/4 rispetto a prima
* La banda allocata è stata ridotta a circa 1/10

Chiaramente il cliente è stato felice di questo lavoro e da allora non ha più avuto nessun problema prestazionale.

Inutile aggiungere che questo ha portato anche ad un aumento di fatturato, dato che il sito ha avuto, sia un apprezzamento da parte dei motori di ricerca, che lo hanno posizionato meglio all'interno delle loro SERP, sia da parte degli utenti che tendono a utilizzare maggiormente siti veloci rispetto a siti lenti.

Se anche tu hai questi problemi col tuo sito, non esitare a contattarmi, studieremo insieme come risolverli

ciao
Matteo