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

Fate un giro da queste parti.

Emanuele

Questo post mi sembra dovuto perché io credo che tante cose che non capiamo il più delle volte accadono per un motivo ben preciso che, semplicemente, sfugge alla nostra comprensione.

Per la mia laurea, ad esempio, ho ricevuto una fotocamera che ho snobbato durante tutti questi mesi ma che potrà essere finalmente utile durante il mio viaggio in Africa. Allo stesso modo, l’anno scorso tra i premi Fineco riuscii a prendere una valigia: strano premio che si è rivelato indispensabile in questo periodo di continui spostamenti (sia lavorativi che non).

Devo ringraziare voi perché questo blog è un gioco che mi sorprende di anno in anno. Il biglietto per l’Africa è venuto 1250€ e in appena sei mesi proprio attraverso queste pagine ho ricevuto 1260€ (è scritto tutto in maniera trasparente in questa pagina).

Grazie dunque a voi perché visitate queste pagine, perché ogni tanto cliccate sulla pubblicità (che, per rispetto, cerco di mantenere poco invasiva sulla destra di ogni post) e perché avete attirato, nel tempo, qualche sponsor che volesse spazio da queste parti.

Anni fa scrissi che avrei dovuto offrire 7000 caffé (l’occasione era il traguardo dei 7000 commenti) e oggi invece i commenti sono a quota 19700. Dovrei ingolfare un bar per un’intera giornata così la soluzione filosoficamente più bella è affermare che avrò un pensiero anche per voi mentre sarò in quella splendida terra a darmi da fare. Senza voi magari questo viaggio rimaneva ugualmente fattibile ma così ha un sapore immensamente più bello.

Emanuele

Questo è un articolo sponsorizzato, come al solito lo scrivo a chiare lettere e allo stesso modo vi ricordo che sono libero di esprimere le mie considerazioni su quanto trattato.

˜˜˜

E’ sempre più chiaro a tutte le aziende che il futuro del commercio si basa su sistemi in grado di riunire opinioni e pareri. I social network, in tal senso, sono ambienti perfetti per diffondere il proprio brand sfruttando il passaparola degli utenti. Lufthansa, da qualche mese, ha lanciato WeFly, una community dedicata a coloro che vogliono condividere la propria esperienza di viaggio.

Il portale si presenta sotto forma di blog in cui ogni iscritto alla community può raccontare il proprio viaggio, pregi e difetti dell’esperienza e così via. Personalmente avrei apprezzato vedere dei post un po’ più articolati, con tanto di programma di viaggio, itinerario e consigli ben organizzati ma quanto presente fin ora può rappresentare, in ogni caso, un supporto interessante per raccogliere pareri “reali” quando ci si accinge ad organizzare una vacanza da qualche parte. Fortunatamente attraverso il portale è possibile contattare gli altri membri della community per ricevere privatamente le informazioni che si desiderano su una determinata località.

L’iscrizione a WeFly, inoltre fornisce la possibilità di ricevere promozioni e novità di Lufthansa in anteprima e di partecipare, come membro della community, ai concorsi che verranno indotti (l’ultimo ha regalato cinque biglietti verso una capitale europea).

In definitiva mi sembra un’idea interessante che dipende fortemente dalla quantità e qualità degli utenti che vorranno farne parte.

Emanuele

Qualche giorno fa, una lettrice di questo blog ha scritto un commento che recita così:

E questa strana cosa…..non so…e ke so per certo ke venendo qui troverò qualcosa ke sarà quello ke cercavo….è come quando vai in farmacia senza ricetta e kiedi al farmacista un consiglio su quale medicinale possa andar bene per questo o quel problema…e poi insieme si decide per la soluzione migliore….ecco il tuo blog e la farmacia della mia anima….vengo qui, leggo i tuoi post, nn sono una cliente abituale, questo si…..il tempo è sempre tiranno con me, però so che all’improvviso le tue parole apriranno le porte…saranno da corrente per la soluzione giusta…!una medicina insomma.

Dopo 217 episodi, dopo avermi accompagnato per 10 lunghissimi anni (e degli ultimi cinque posso assicurarvi di non aver perso una singola puntata), stasera è arrivata la fine di Smallville! Io però, che SuperMan immagino d’esserlo per gioco nella vita di tutti i giorni, mi sento un po’ più povero adesso. Da chi prenderò ispirazione settimanalmente?

Preparatevi, gente, perché potrei cambiare drasticamente. A meno che…

Emanuele

Pochissimi giorni fa Aruba per un principio d’incendio alla sala UPS ha messo offline gran parte della rete italiana. Tantissimi webmaster si stavano domandando fin dai primissimi minuti successivi all’evento se il downtime potesse influenzare in qualche modo il valore di posizionamento delle proprie pagine. Google, in questi giorni ha pubblicato un post sul suo blog che descrive per bene come si comporta il suo algoritmo quando un contenuto non è raggiungibile. Ho pensato di tradurlo per chiarire il dubbio di tanti.

˜˜˜

Perciò eccoti, stai seguendo i tuoi affari, stai usando i Webmaster Tools per controllare quant’è favoloso il tuo sito… ma, aspetta! La pagina di raccolta degli errori è piena di errori 404 (Not found)! E’ imminente il disastro???

Non spaventarti, mio giovane padawan. Guardiamo meglio gli errori 404 e come essi influenzano (o meno) il tuo sito.

Domanda: Gli errori 404 riportati nella Webmaster Tools influenzano il ranking del mio sito?
Risposta: Gli errori 404 sono una parte del web perfettamente normale; internet è in continua evoluzione, nuovi contenuti nascono, vecchi contenuti muoiono, e quando muoiono (idealmente) ritornano un codice di risposta HTTP 404. I motori di ricerca sono a conoscenza di questo, abbiamo errori 404 anche sui nostri siti (Google n.d.r.), come puoi vedere sopra, e li troviamo ovunque nel web. Nei fatti, attualmente Google preferisce che, quando ti liberi di una pagina sul tuo sito, ti assicuri che essa ritorni un appropriato codice di risposta 404 o 410 (al posto di “404 soft”). Tieni in mente che per permettere ai nostri crawler di vedere i codici di risposta HTTP di un URL, esso dev’essere accessibile al crawler – se l’URL è bloccato dal tuo file robots.txt Google non sarà in grado di visitarlo e vedere il suo codice di risposta. Il fatto che alcuni URLs nel tuo sito non esistono più / ritornano un 404 non influenza come gli altri URL del tuo sito (quelli che ritornano 200 (Successful)) risultano nei nostri risultati di ricerca.

Domanda: Così i 404 non disturbano il mio sito del tutto?
Risposta: Se alcuni URL sul tuo sito rispondono con un 404, questo fatto da solo non ti disturba o conta negativamente per i tuoi risultati nelle ricerche di Google. Comunque, ci possono essere altre ragioni per cui tu vorresti gestire alcuni tipi di 404. Per esempio, se alcune delle pagine che ritornano un errore 404 sono pagine di cui ti occupi, dovresti approfondire perché Google sta vedendo risposte 404 quando le visita! Se tu vedi un errore di digitazione di un URL valido (ad esempio www.example.com/stuepndo invece di www.example.com/stupendo), è molto probabile che qualcuno ha linkato verso quella pagina del tuo sito ed ha fatto un errore di digitazione. Invece di ritornare un errore 404, tu potresti redirezionare i visitatori con un codice 301 dall’URL scritto male all’URL corretto e raccogliere il traffico previsto per quel link. Puoi anche assicurarti che, quando un utente finisce su una pagina 404 sul tuo sito, tu lo aiuti a trovare quel che stava cercando invece di dirgli semplicemente “404 non trovato”.

Domanda: Parlami ancora dei 404 soft.
Risposta: Un errore 404 soft è quando un server web ritorna un codice di risposta diverso da 404 (o 410) per un URL che non esiste. Un esempio comune è quando il proprietario di un sito vuole ritornare una pagina 404 attraente con informazioni d’aiuto per i suoi utenti, e pensa che per servire contenuti agli utenti debba ritornare un codice di risposta 200. Non è così! Tu puoi ritornare una codice di risposta 404 mentre servi qualsiasi contenuto tu voglia. Un altro esempio è quando un sito redireziona qualsiasi URL sconosciuto alla sua homepage invece di ritornare errori 400. In entrambi i casi abbiamo effetti negativi nel interpretare e indicizzare il tuo sito, così ti raccomandiamo d’assicurarti che il tuo server risponda con il codice di risposta corretto per contenuti non esistenti. Ricordati che solo perché una pagina dice “404 Non trovato”, non significa che stia attualmente ritornando un codice di risposta HTTP 404 – usa la funzione Visualizza come Googlebot nei Webmaster Tools per verificarlo. Se non sai come configurare il tuo server per ritornare i giusti codici di risposta, controlla la documentazione di aiuto del tuo web host.

Domanda: Come so quando un URL dovrebbe ritornare un 404, un 301 o un 410?
Risposta: Quando rimuovi una pagina dal tuo sito, rifletti se quel contenuto si sta spostando da qualche altra parte, o se non hai in mente di avere quel tipo di contenuto sul tuo sito. Se stai movendo quel contenuto verso un nuovo URL, dovresti redirezionare con codice 301 il vecchio URL verso il nuovo URL – in quel modo quando gli utenti arrivano sul vecchio URL cercando per quel contenuto, saranno automaticamente redirezionati verso qualcosa di rilevante a cosa stavano cercando. Se stai rimuovendo quel contenuto interamente e non hai niente che possa interessare gli stessi bisogni dell’utente, allora il vecchio URL dovrebbe ritornare un codice 404 o 410. Attualmente Google tratta i 410 (Gone) allo stesso modo dei 404 (Not Found), così è indifferente per Google se ritorni l’uno o l’altro codice.

Domanda: Molti dei miei errori 404 sono per URL strani che non sono mai esistiti sul mio sito. Che succede con essi? Da dove arrivano?
Risposta: Se Google trova un link da qualche parte nel web che punta ad un URL del tuo dominio, potrebbe tentare di indicizzare quel link, sia che qualche contenuto esista lì o meno; e quando lo fa, tu dovresti ritornare un errore 404 se non c’è nulla da trovare lì. Questi link potrebbero essere causati da qualcuno che ha fatto un errore di digitazione quando ti ha linkato, ovvero da alcuni errori di configurazione (sei link sono generati automaticamente, ad esempio da un CMS), o dalle funzioni potenziate di Google per riconoscere e indicizzare link inclusi in Javascript o altri contenuti inclusi nel documento; o possono essere parte di un check veloce da parte di Google per vedere come gestisca gli URL sconosciuti il tuo server. Google non sa quali URL sono importanti per te rispetto a quelli che sono pensati come 404, così ti mostriamo tutti i documenti 404 che troviamo sul tuo sito e tu decidi quali, se ne esistono, richiedono la tua attenzione.

Domanda: Qualcuno ha esplorato il mio sito ed ha causato una serie di 404 nel processo. Essi sono tutti URL “reali” con altri codici fissati in coda, come “http://www.example.com/images/kittens.jpg” width=”100″ height=”300″ alt=”kittens”/></a… Disturberà il mio sito?
Risposta: Generalmente non hai bisogno di preoccuparti riguardo i “link rotti” come questi. Google capisce che i proprietari dei siti hanno poco se non alcun controllo sulla gente che esplora e scansiona il loro sito, o chi li linka in maniere strane. Se sei un mago con le espressioni regolari, tu potresti considerare di redirezionare questi URL come descritto qui, ma generalmente non è importante preoccuparsi di loro. Ricorda che tu puoi anche compilare una richiesta di takedown quando credi che qualcuno stia rubando i contenuti originali dal tuo sito.

Domanda: La scorsa settimana ho fissato tutti i 404 che Webmaster Tools riportava, ma sono ancora elencati nel mio account. Significa che non li ho sistemati correttamente? Quanto tempo è necessario per vederli scomparire?
Risposta: Guarda nella colonna “Detected” nella pagina degli errori di crawling – questa è la data più recente in cui abbiamo riscontrato ogni errore. Se la data o le date in quella colonna sono precedenti al tempo in cui hai sistemato gli errori, allora significa che non abbiamo incontrato quegli errori da quella data. Se le date sono più recenti, significa che stiamo continuando a vedere questi errori 404 quando noi visitiamo il sito.

Dopo aver implementato una soluzione, puoi verificare se il nostro crawler vede il nuovo codice di risposta usando Visualizza come Googlebot. Controlla un po’ di URL e, se rispondono correttamente, questi errori dovrebbero iniziare presto a scomparire dalla tua lista di errori di crawling.

Domanda: Posso usare il tool di rimozione di Google per fare scomparire gli errori 404 dal mio account più velocemente?
Risposta: No; lo strumento di rimozione degli URL rimuove gli URL dai risultati di ricerca di Google, non dal tuo account su Webmaster Tools. E’ disegnato per richieste urgenti di rimozione solamente, e usarlo non è necessario quando un URL ritorna già un errore 404, perché un URL verrà rimosso dai nostri risultati di ricerca naturalmente nel tempo. Guarda la parte finale di questo post per maggiori dettagli su cosa lo strumento di rimozione degli URL può fare e cosa non può fare per te.

Fonte: Official Google Webmaster Center – Do 404s hurt my site?

Emanuele

PS: se cercate un hosting con uptime garantito, il mio vi rimborsa mensilmente quando il downtime è inferiore al 100%.

Non è che io non stia seguendo la politica di questi giorni visto che non è arrivato alcun post a riguardo. Semplicemente però inizio ad avvertire un fastidio sempre crescente che mi porta ad ignorare – per quanto possibile – ciò che ricevo.

Da tempo rifletto con un amico sul fatto che in Italia ormai, volenti o nolenti, non si riesce più a parlar di politica senza nominare Silvio Berlusconi. Tutto ruota intorno a lui.

Certe mattine facendo colazione ed ascoltando le ultime notizie si inizia a commentare ciò che non va e, gira e rigira, il problema è sempre lì.

Non si può iniziare la giornata, ogni giornata, ripetendo sempre le stesse cose. Non si può ridurre il proprio risveglio, il momento in cui guardare il sole dalla finestra o il gatto in giardino all’ennesimo tempo perso dietro la politica.

Così, un po’ per fastidio, un po’ per responsabile diniego, sto evitando di descrivere la mia rabbia per tante notizie disgustose, ignobili e vergognose che delineano la storia d’Italia di questi giorni.

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