Benchè i modem a 56k siano morti e sepolti e la banda larga sia (quasi per tutti) una realtà, la pratica dell’ottimizzazione è ancora un utile abitudine che aiuta drasticamente ridurre il tempo di rendering di una pagina web. Oggi i motivi per farlo sono differenti ma non meno importanti:
- Pagine più leggere impiegano meno tempo ad essere caricate (ma va?!?!) da tutti (ma proprio tutti: dagli utenti frettolosi agli spider di Google e affini): questo si traduce in una migliore navigabilità del sito che più probabilmente verrà esplorato più a fondo sia dagli utenti umani che dai ragnetti.
- Pagine più leggere fanno risparmiare banda: e se il nostro hosting ce la da limitata non è una cosa da tralasciare; soprattutto quando parliamo di portali di medie dimensioni.
- Ridurre i tempi di rendering delle pagine ci permette di renderle più belle senza sacrificare la performance: utilizzare immagini di qualità più elevata, icone ed effetti ajax senza far venire una sincope al nostro browser (e a quello dei nostri navigatori) è sicuramente un punto a nostro favore.
Di seguito 7 brevi consigli che non vogliono esaurire l’argomento ma coprirlo al 90% 
- Riduciamo le richieste HTTP: il nostro blog è bello davvero! Usa una 20ina di icone 5 immagini decorative e pure qualche gif animata… Ogni immagine è una richiesta HTTP che blocca il nostro browser gonfiando inutilmente i tempi di attesa. Per ovviare a questo problema si puù utilizzare la tecnica dei CSS Sprite (ne avevamo già parlato qui). In quona sostanza invece che utilizzare icone da pochi kappa è meglio utilizzare grandi tavole contenenti tutte le icone (e immagini) utilizzate per ridurre le 20-30 richieste ad un paio più capienti (che verranno prontamente cashate dal nostro browser di fiducia). Estendendo il concetto ogni file è una richiesta HTTP, quindi il secondo passo è quello di combinare i nostri CSS e Javascript in modo tale da avere un minor numero di file.
- Inserire i CSS prima di tutto il resto: così facendo la pagina si renderizzerà più rapidamente. Evitate @import e utilizzate link se volete che le pagine vengano renderizzate più rapidamente.
- Quando è possibile inserite gli script verso la fine del documento: gli script impiegano diverso tempo per essere caricati, renderizzati e interpretati. Quando è possibile metterli verso la fine del documento ne incrementa notevolmente la velocità di rendering. In ogni caso metterli dopo i CSS.
- Mettere CSS e Js in file esterni quando vengono usati in tutto il sito e in linea se vengono utilizzati solo in una pagina specifica. Il motivo è semplice: ciò che è in linea è più veloce perchè viene processato senza soluzione di continuità, viceversa se un css o un js è utilizzato in altre pagine, l’utente navigando il sito avra in cache i file riducendo drasticamente i tempi di caricamento. Succede spesso che la homepage di un sito utilizzi effetti particolari non impiegati nel resto del sito, quello è un buon momento per mettere gli script e i css in linea.
- Minimizzare il codice Javascript: un javascript minimizzato occupa meno spazio e quindi riduce (spesso drasticamente quando si parla di framework) i tempi di caricamento. Scegliete inproduzione sempre le versioni minimizzate dei framework (ad es. jQuery min) o, se non disponibili fateveli voi con strumenti come JSMin.
- Evitate i redirect (e qui mi do la zappa sui piedi ) : almeno che voi non abbiate un buon motivo per farlo evitate reindirizzamenti. Ognuno raddoppia le richieste al server (richiesta pagina -> reindirizzamento -> richiesta seconda pagina …). A parte i reindirizzamenti volontari attenti ai link: omettere la bassa finale di un indirizzo genera comunque un reindirizzamento inutile.
- Evitate gli script duplicati: succede più spesso di quanto si creda. Controllate l’html delle vostre pagine a caccia di duplicati potreste avere sorprese e grossi incrementi di prestazioni!
Gli strumenti:
A venirvi in aiuto esistono fondamentalmente due strumenti integrati che da soli coprono il 90% delle vostre esigenze: il pannello net di firebug e YSlow. Il primo tiene traccia dei tempi di ongi richiesta HTTP tracciandovi un comodo grafico e conteggiando numero di richieste e tempo parziale/complessivo. Yslow fa di più: macina la vostra pagina e applica le regole di cui abbiamo parlato (e molte altre) per analizzare le prestazioni e fornire utili consigli.
Approfondimenti:
E’ in libreria l’ottimo “Creare siti web ad alte prestazioni” di S. Souders edizioni O’REILLY. Libretto agile ma veramento ottimo sull’argomento.
6 Risposte
Ci sarebbero un po di appunti da fare a quanto detto. Quando citi la tecnica del Css Sprite [correggi il link perchè errato] dai per scontato che TUTTI abbiano il javascript attivo, cosa falsa quindi per quegli utenti avrebbero solo problemi di navigazione in quel sito. Meglio lavorare solo con i css per quanto riguarda la grafica.
Comunque di consigli da dare ce ne sono molti tipo usare la Cache o compressare il codice anche se dopo andrebbe aggiunto l’appendice che riguarda i browser che riescono a gestirla. Altro ancora potrebbe essere il consiglio di usare più server: magari quello delle immagini diverso da quello dove è hostato il sito ma anche qui, concettualmente, qualcuno potrebbe obbiettare.
Poi va concluso dicendo che non è detto che compressando i js, tipo gzippandoli, si abbia necessariamente un vantaggio. Certamente in fatto di banda il vantaggio è innegabile ma ricordiamoci che non tutti hanno dei mega computer con ram a iosa o multi processori, vedi smartphone o P4, quindi il browser del client si deve sobbarcare l’onere di gzippare, sempre ammesso che sia in grado di farlo, i js con risultati di lentezza di navigazione o addirittura non fruizione del sito.
Ciao David benvenuto,
ti ringrazio per la tua segnalazione e i tuoi appunti, vediamoli un attimo:
per quanto riguarda il post in cui parlo della tecnica Css Sprite2 (qui l’articolo originale di Shea): ho scelto appositamente quella tecnica perchè combina in modo intelligente jQuery e CSS per ottenere una degradazione su tre livelli mantenendo funzionalità sia in assenza di js che di CSS. In particolare la prima parte dello script serve per disattivare il comportamento dei CSS che in assenza di js si occuperebbero del funzionamento del menù. Per tornare alla tecnica CSS Sprite in se questa è CSS pura ed è molto utilizzata (un classico esempio è il menù orizzontale del sito di Apple).
Per gli altri consigli:
) converrebbe comprimere tutte le risposte di testo (CSS, JS, XML oltre ovviamente all’HTML che dovrebbe essere giù impostato come compresso sulla maggior parte dei server.) ma non ho mai provato ad abilitarli (ammesso che si possa fare via htaccess… considerando il carico sulla cpu immagino che la maggior parte degli hosting adotti una politica restrittiva su questo punto). A quanto pare comunque zippare tutto il zippabile può portare a riduzioni nei tempi di attesa anche del 50%.
La compressione lato server non l’ho citata io stesso perché non l’ho mai testata personalmente e richiede delle configurazioni su Apache per essere abilitata (oltre ai problemi di compatibilità che tu stesso citi).
Per quello che ne so’ (ma correggimi se dico cavolate
Quando parli di usare la cache immagino tu intenda di impostare gli header Expirers in un futuro lontano in modo da mettere tutto il possibile nella cache del browser. Anche in questo caso si tratta di configurare in modo opportuno apache. Personalmente non ho mai provato neppure questa tecnica quindi se hai intenzione di scriverci un articolo lo citerò sicuramente
.
Per quanto riguarda il fatto di utilizzare una rete di distribuzione dei contenuti per ridurre il sovraccarico del server le variabili da considerare sono molte (posizione geografica del server, connessione ecc.) e il vantaggio meno di rilievo (a meno che non stiamo parlando di grandi portali).
Per quanto riguarda i js il mio consiglio era quello di minimizzarli o offuscarli e non era riferito alla compressione lato server. La minimizzazione in produzione è sempre un vantaggio perché, senza applicare nessun algoritmo di compressione otteniamo comunque un file più piccolo e questo è particolarmente evidente sui js (ma lo stesso discorso può essere fatto anche per css e l’html) ad esempio prendi jquery minimizzato (54.5kb) e non minimizzato (97.8 kb).
In effetti di consigli da dare ce ne sono ancora molti! Ma il mio obiettivo era quello di fornire poche semplici regole applicabili da chiunque (e su qualunque hosting) per ottenere un netto miglioramento delle prestazioni (netto nei casi in cui nessuno dei consigli sopra citati sia stato precedentemente applicato
).
Per la cache intendevo lato server. Tu stesso usi Wp ed esiste un interessante modulo che si chiama Wp-supercache che crea delle pagine statiche sul server in modo da ridurre sia le chiamate al database.
Per quanto riguarda la compressione esiste anche php-speedy, altro plugin per WP che compressa praticamente tutto con tutti i problemi del caso.
Poi a seconda delle possibilità del nostro piano hosting possiamo lavorare sugli expiras header e gli etags. Prova a controllare con yslow ad esempio il mio sito, di cosette ce ne sono eppure ho un hosting condiviso con altri 1500 siti.
Ps: ricordati che non esiste solo Apache come webserver =)
già ma non se la passa neppure tanto male…
Grazie delle dritte ne farò buon uso (vedo che la tua home totalizza un bel pò di A, e poco più di 3 secondi con la cache del browser vuota, complimenti)
Si ma considera che comunque il plugin creato da Yahoo è più una specie di linea ipotetica da seguire. Ad esempio, come fai anche giustamente notare tu, usare un server aggiuntivo solo per le immagini può convenire per un sito di grosse dimensioni. Nel mio caso io aborro tenere le immagini in un server, magari gestito da terzi, separato dal mio.
Io uso solo wp-cache, ho provato ad usarlo in combinazione con php-speedy con relativi hack ma il risultato è stato disastroso. Su computer vecchi per lo più ho avuto un aumento, invece che diminuzione, dei tempi di caricamento senza poi dimenticare i problemi che avevo per alcuni plugin e javascript “dinamici”.
Quindi sul piano teorico è vero che si potrebbe avere un vantaggio ma va visto da caso a caso e non sempre prendere una A o una F cambia le cose.
si hai ragione ma è utile per avere un idea generale delle parformance del sito
ps. ho installato pure io wp-cache