Nell’ottica di limare sempre più i tempi di caricamento, da alcune settimane molte delle immagini presenti su queste pagine vengono visualizzate attraverso la tecnica dei CSS Sprites. Per farvi capire meglio di cosa si tratta, prendiamo in considerazione l’immagine a lato.

La colonna di sinistra riporta in un’unica immagine tutti gli elementi grafici che compongono le pagine di questo blog. Per visualizzare uno di quegli elementi basta richiamare via CSS l’immagine intera indicando le coordinate (offset orizzontale e verticale) dell’area dell’immagine da mostrare. Nell’esempio ho fatto scorrere l’immagine di 146 pixel prima di visualizzarla in un’area alta 15 pixel per far apparire l’antipixel relativo a Technorati. Tutto il resto, essendo al di fuori di quell’area è come se rimanesse “sotto il vestito”.

1
2
3
4

.sprite-technorati {
background:#fff url(csssprite.png) no-repeat top left;
background-position:0 -146px;
}

Qual è il vantaggio dovuto all’uso dei CSS Sprites?

• Riunendo in un’unica immagine tutti gli elementi la dimensione totale (in kb) sarà inferiore a quella della somma del peso di ogni immagine (in quanto le intestazioni del formato JPG non sono ripetute n-volte).
• Il browser di un visitatore non dovrà effettuare n-richieste HTTP per ottenere tutte le immagini: basterà un’unica richiesta per ricevere tutti gli elementi che incontrerà nella pagina. Effettuato il primo download tutte le altre volte che dovrà mostrare quel file si accorgerà di averlo già scaricato (csssprite.png sarà in cache) e potrà visualizzarlo immediatamente facendo slittare l’immagine in base a quanto indicato via CSS.

Questo comporta un vantaggio sia per l’utente che navigherà sul sito più velocemente che per il gestore del sito web infatti minori richieste HTTP comportano un carico minore sul server che potrà, in questo modo, fronteggiare contemporaneamente alle richieste d’accesso di un numero maggiore di visitatori.

Inoltre sono sempre più convinto (ma dovrebbe essere prassi comune) che un “contenitore” leggero e scattante permette di destinare quei kb risparmiati ai contenuti (ad esempio le foto in un post). E’ come un ciclista che non usando una bicicletta di ferro può sfruttare quel peso per trasportare litri di acqua in più.

Quando non conviene usare i CSS Sprites?

• Come al solito ogni scelta tecnica che si intraprende va valutata in base alle situazioni. In linea di massima comunque non conviene quando si prevede che esistano pagine con un livello di traffico non indifferente che visualizzano meno del 50% degli elementi grafici inseriti nel nostro sprite.

La tecnica è talmente importante per l’ottimizzazione di un sito che anche colossi come Google o Facebook la sfruttano nelle loro pagine da anni (senza che ve ne siate mai accorti).

Emanuele

Siccome son paranoico questo blog è un tavolo degli esperimenti, da qualche giorno queste pagine si aprono più velocemente che mai. Per la precisione la prima apertura ha guadagnato mezzo secondo mentre un qualsiasi reload sucessivo della pagina si è dimezzato: da poco più di tre secondi a circa un secondo e mezzo.

Come ho fatto? Vuoi velocizzare anche le tue pagine?

I passi necessari sono:

1. Riunisci in un unico file i css e javascript presenti nelle pagine: se controlli sotto la gonna di questo blog vedrai che non vi sono più differenti css o javascript sparsi, oltre quelli caricati da domini esterni (ad esempio Google Analytics). Il motivo è semplice: il tuo browser scarica queste pagine “due pezzi per volta”, così se diminuisci il numero di file da recuperare, diminuisci il tempo di caricamento totale della pagina.
2. Minimizza qualsiasi cosa possibile: javascript e css sicuramente possono esser sostituiti dalla loro versione compressa, cui son stati rimossi spazi e commenti ed han ricevuto un paio di ottimizzazioni. Per comprimerli ho usato JSCompress per i javascript e MinifyCSS per i fogli di stile. Il risparmio si quantifica in quasi 100kb in meno (moltiplicali per il numero di visitatori e conta il risparmio giornaliero). Ovviamente se hai immagini non ottimizzate puoi intervenire anche lì: non mettere online una foto a 2500×2500 se poi la visualizzi in un’area della pagina limitata a 300×400!
3. Richiama dall’esterno i javascript comuni: framework come jQuery o prototype (se li usi), puoi richiamarli attraverso la loro versione (minificata) fornita da Google, questo alleggerisce il carico sul tuo server, parallelizza il download della pagina e molto probabilmente un visitatore avrà già scaricato il file navigando altrove.
4. Imposta correttamente l’expire dei file. E’ inutile ricaricare le immagini che, su un blog, molto probabilmente non cambieranno mai: quando pubblico qualcosa è perché voglio rimanga lì. E allora ecco i codici da inserire nel file .htaccess del tuo blog:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

# Abilita l'expire dei contenuti <ifmodule mod_expires.c> ExpiresActive On # 1 anno per gli mp3, i video e i contenuti multimediali <filesmatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$"> ExpiresDefault A9030400 </filesmatch> # 1 mese per le immagini e i fogli di stile <filesmatch "\.(jpg|jpeg|png|gif|swf|css)$"> ExpiresDefault A2592000 </filesmatch> # 7 giorni per i javascript ExpiresByType application/x-javascript "access plus 7 days" </ifmodule>

5. Rimuovi l’header ETag per ogni file. Questa te la spiego così: il browser ad ogni connessione interroga il server e controlla che ciò che già conosce (per via di una visita precedente) non sia cambiato. L’ETag è un codice univoco usato per il confronto. Perché rimuoverlo? Perché senza esso il browser fa totale affidamento su quanto gli hai detto sopra con l’expire dei file: una volta al mese aggiorna le immagini, per il resto non fa alcun controllo e si fida che sia rimasto tutto uguale. Ecco cos’altro inserire.

1 2 3 4 5

# Rimuove il tag ETag dall'header per tutti i file <ifmodule mod_headers.c> Header unset ETag FileETag None </ifmodule>

6. Si può fare di più (si può sempre fare di più!). Il prossimo passo sarà utilizzare i CSS Sprites per riunire le immagini statiche (non quelle dei post). Il motivo è  lo stesso del punto uno… ma lascio a te il compito di approfondire l’argomento!

Hai altri consigli?

Emanuele

Questo è un post sponsorizzato, come al solito poche lire. Non sono obbligato a parlar bene ma è giusto informarvi per correttezza.

~~~

In questi giorni DreamsWorld è stato down, il mio precedente hosting mi ha semplicemente detto che non riuscivano a reggere il carico sul server generato dalle pagine del blog.

Ho tentato in vari modi di alleggerire il “peso” delle pagine ma, dopo alcuni test, continuava a non bastare (per loro). Vi racconterò meglio di quest’esperienza tra qualche giorno, quando sarà tutto concluso, intanto però, vi presento WebHostingChoise e vi faccio le mie raccomandazioni.

WebHostingChoise è un piccolo archivio di servizi di web hosting che propone una classifica degli hosting più convenienti secondo le proprie necessità (hosting di un blog, di un sito di eCommerce, di un server SQL e così via…) che però, secondo me, non mette in risalto le caratteristiche fondamentali di un servizio di hosting.

Lo spazio illimitato (così come le mail illimitate, i database illimitati e così via…) sono, infatti, uno specchietto per allodole che non descrive le prestazioni del server.

Volendo fare un paragone, è come se un trasportatore vi dicesse “ho delle scatole grandissime, usa le mie” e poi però foste vincolati al suo servizio di trasporti che invece di viaggiare in aereo cammina ancora su un calesse trainato da asini.

Va di moda offrire miliardi di Gb ad utente (o addirittura servizi pseudo-illimitati) ma nessuno si preoccupa dal dichiarare quanta CPU vi verrà concessa, quanta RAM avrete disponibile e così via. Eppure le prestazioni finali dipendono esclusivamente da quella. Avere centinaia di gigabyte di dati, acessibili ad una velocità infima, è come non averli!

Quando scegliete un hosting dunque, cercate di conoscere quei valori, cercate di capire quanti account-utente vengono caricati su un singolo server, cercate di capire che tipo di gestione CPU/RAM hanno (con conseguente gestione di eventuali picchi di richieste di risorse e così via…).

Non affidatevi esclusivamente alle prime tre parole “spazio illimitato gratis”.

Emanuele

Ormai sembra una costante, ieri però ho toccato un nuovo record. Quasi 4000 accessi unici, tutti concentrati nel pomeriggio, mentre MSN aveva problemi…

WebPerTe mi ha oscurato il sito per alcune ore… sembra che neanche Wp-Super-Cache abbia resistito… (però ho dimenticato di attivare l’opzione “Lock Down” che dovrebbe freezare le pagine senza aggiornarle più finché il numero di accessi non diminuisce…).

Decine di accessi al minuto che ovviamente non lasciavano scampo all’hosting condiviso richiedendo anche il 40% della CPU.

Adesso il dubbio è amletico: rimuovo quel post e fanculo all’etica che ricorda che “un buon link non muore mai”? Oppure continuo a cercare soluzioni per rendere sempre più resistente questo blog?

C’è qualcuno che ha qualche consiglio da darmi?

Emanuele

Alcune ore fa ho ricevuto una e-mail da WebPerTe.

Salve,
al momento non stiamo in effetti rilevando ulteriori carichi notevoli per quanto riguarda il suo sito, sembra che la modifica apportata abbia quindi sortito gli effetti desiderati.
Inoltre, in questo caso, abbiamo provveduto ad impostare il php-safe off, potrà quindi installare il wp-super-cache.
Saluti,
Andrea Zorzetto

–
Aziende Italia S.r.l.
Supporto Tecnico

Ringrazio l’attenzione mostrata nei miei confronti per risolvere il problema. Il PHP-Safe è un sistema di PHP per migliorare la sicurezza nei server con hosting condivisi. Disattivarlo per il mio account è qualcosa che non credo altri servizi di hosting avrebbero fatto.

Ho attivato al volo Wp-Super-Cache che è nuovamente attivo su queste pagine: la navigazione dovrebbe risultare ancora più veloce in quanto le pagine più visitate sono già salvate in formato .html e vengono inviate direttamente al browser del visitatore senza dover essere “costruite” di volta in volta. L’installazione di Wp-Super-Cache è rapida ed indolore, così consiglio anche a voi di installarlo (prevenire è meglio che curare…).

Ovviamente tutto è funzionante – fino a prova contraria -. Se qualcuno dovesse incontrare qualche errore me lo faccia presente tra i commenti.

Ciao,

Emanuele

Sembra che il mio blog non abbia pace.

Ovunque vada le risorse non bastano mai… merito probabilmente di alcuni post fin troppo ben indicizzati che risentono facilmente dell’andamento di alcuni servizi online. Uno per tutti, quello su due errori di Msn Messenger… lo scrissi tempo fa e ogni volta che il servizio di messaggistica ha problemi, migliaia di utenti si riversano – attraverso Google – su queste pagine per tentare di trovare una risposta al loro problema. Oggi è toccato probabilmente a molti utenti della rete Infostrada, in quanto la maggior parte degli accessi a quel post proveniva proprio da connessioni Infostrada.

Così, verso le 14 questo blog è andato offline (ed è rimasto tale fino alle 19) perché i tecnici di WebPerTe hanno rivelato un consumo abnorme di ram e cpu nel server che ospita il blog. Sono stato un pomeriggio in contatto con loro per proporre soluzioni. Alcuni giorni fa avevo rimosso un paio di plugin per alleggerire ulteriormente queste pagine, oggi ho inserito la paginazione dei commenti. Il server probabilmente dovrà fare meno sforzi dovendo servire delle pagine indubbiamente più piccole da generare.

Purtroppo su WebPerTe, per via del php-safe attivo, Wp-Super-Cache non funziona correttamente. Lo provai al momento del trasferimento, chiesi aiuto anche ai tecnici per tentare di farlo andare, ma non ci fu verso di aggirare l’ostacolo. Stasera, nell’ultimo ticket ho chiesto nuovamente di non sottovalutare l’idea di impegnarsi – in qualche modo – per far funzionare il plugin: ne gioverebbero i visitatori, i proprietari dei blog e… i server (minori risorse impegnate, minori consumi, risparmi energetici… e continuando a catena fino al risparmio monetario). Chissà se vorranno ascoltarmi… magari vederlo scritto qui pubblicamente servirà a qualcosa, non so.

Intanto mi sono reso conto che gli errori 500 di HostingZoom non erano totalmente colpa dei suoi limiti… e così sto anche rivalutando quel provider come qualità.

I vostri blog non hanno problemi con i post con centinaia di risposte? Accolgono le richieste senza problemi? Il post con più commenti, quante risposte conta? Mi piacerebbe confrontare un po’ le esperienze su server diversi.

Emanuele

Se c’è una regola che vale su internet da sempre è che il visitatore vuole tutto subito (o quanto meno in tempi ragionevoli). Se un sito è scomodo da navigare o risulta lento a caricarsi, finisce per stancare e non esser visitato.

L’unico studio che rivelò, anni fa, che le connessioni lente risultavano “più appaganti” era quello che analizzò il web per i navigatori *porcelloni* che scaricando immagini di donnine nude potevano eccitarsi di più dovendo attendere tempi maggiori per il completamento del download…

Siccome questo non è un sito porno e non c’è motivo di farvi attendere, sto provando il plugin WP Super-Cache, che è a tutti gli effetti una evoluzione di WP-Cache.

Spero in questo modo di risolvere gli errori che da alcuni mesi affligevano questo blog.

Tra qualche giorno proverò a vedere il carico della CPU per il mio account e spero che risulti migliorato.

Se intanto doveste notare qualche anomalia, segnalatemelo… ultimamente vado sempre di corsa ed ho poco tempo per controllare queste cose.

Emanuele

PS: se avete voglia di provarlo, non fatevi scappare ovviamente i plugin più simpatici del web: BlogBabel Rank Plus e BlogItalia Rank…!

In questi giorni sembra che il caldo abbia messo sotto sforzo il mio server (ma c’è caldo dall’altro lato dell’oceano?!) e così non era raro incontrare errori 500 durante la navigazione sul sito.

A quanto pare, l’errore era imputabile ad uno sfruttamento superiore a quanto consentito delle risorse del server (e qui inizio a chiedermi se ci sia qualche hosting – anche italiano – interessato a farmi una buona offerta…). Tra BlogValidator, questo blog ed altri 2 domini, superavo spesso i limiti previsti da HostingZoom.

Ho deciso così di disattivare Php-stats, noto per essere ingordo di risorse (tanto che su Aruba è vietato e viene disattivato…): peccato, le mie statistiche erano così ordinate in quello script.

Ho iniziato a guardarmi intorno ed ho provato FireStats, ma nonostante sia ben consigliato da Davide, non m’è piaciuto (e mi chiedo a questo punto cosa ne pensi il fratello che non ne ha mai parlato fin ora). Un po’ troppo rozzo (riporta tutto su una pagina) e, comunque, pesante (gli errori 500 erano rimasti e dai resourcelog del server ho visto che spesso erano proprio i suoi script ad esser bloccati).

Così, non contento della situazione, ho cercato ancora ma, alla fine, mi sono ritrovato come *tutti*: utente di servizi esterni.

Ho attivato sul blog, oltre a Google Analytics (per la felicità di Tambu! ), WordPress Stats, un recente plugin creato dagli sviluppatori di WordPress che realizza delle semplici ma efficaci statistiche.

Continua a mancarmi un servizio di live-hits, ma non so se attiverò LLOOGG (avete qualche feedback da darmi?). Non voglio appesantire troppo la navigazione con decine di collegamenti verso l’esterno.

Intanto adesso la situazione sembra esser migliorata… staremo a vedere.

Ciao,

P|xeL