Archivio dei post taggati ‘css’

La palla magica 8 si aggiorna…

Scritto il 21 luglio 2011 alle 18:20

Palla Magica 8Considerato che fermo non so stare oggi ho aggiornato Magic 8 Ball, una pagina che creai il 4 Aprile 2009 in un momento di ozio-pre-esami. In realtà non avevo mai completato i lavori così non ne parlai sul blog perché non mi piaceva presentare qualcosa di tecnicamente incompleto ma adesso Magic 8 Ball è scritto interamente in HTML5, la previsione dell’oracolo è  aggiornata usando la tecnologia AJAX in modo da non richiedere un refresh della pagina e il bottone è un bell’esempio di grafica tramite CSS3.

Come al solito mi diverte trasformare le idee in linee di codice e questa nacque perché non avevo la palla vera e mi piaceva illudermi di poter scoprire l’esito dei miei esami attraverso finte risposte! :-|

Siccome sono diligente nerd, automaticamente, l’intera pagina parla in italiano, inglese o in francese!

Emanuele

PS: Magic 8 ball utilizza le frasi storiche della palla della Mattel lanciata negli anni ’50!

CSS Sprites (anche su questo blog).

Scritto il 24 giugno 2011 alle 11:13

CSS SpritesNell’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 “contenitoreleggero 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

Come velocizzare il tuo blog in 5 mosse!

Scritto il 23 febbraio 2011 alle 18:29

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:
  5. 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>
  6. 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.
  7. 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>
  8. 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

Costruire un tema: ottimizzazione del codice.

Scritto il 4 giugno 2009 alle 9:37

Per mancanza di tempo, sono passati due mesi dall’ultimo post della serie “Realizziamo un tema per WordPress da zero” riguardo le attenzioni che ho avuto io durante la costruzione del mio nuovo template, così… eccomi di nuovo qui.

Facendo un veloce resoconto, nelle “precedenti puntate” abbiamo parlato di layout, di scelta delle dimensioni e dei colori, abbiamo parlato del testo (dimensioni e lunghezza) e degli effetti speciali che possono essere applicati ad una pagina per renderla più “interattiva” o quanto meno, più al passo con le tendenze del web (qualcuno lo chiama 2.0).

Bene… il passo conclusivo (o quasi) consiste nel mettere insieme tutto ciò che abbiamo imparato in un documento che dovrà esser letto – potenzialmente – dai browser dell’intero pianeta. Ho già parlato delle difficoltà (e dell’importanza) del rendere un tema cross-browser e cioè capace d’esser letto da browser diversi (cellulari, netbook, etc.) ma non dobbiamo neanche dimenticare un ulteriore aspetto delle nostre pagine: l’accessibilità passa anche da un buon codice.

La sintassi di una pagina è paragonabile ai costrutti lessicali di una lingua. “Io posso non  parlerei così”. Ecco. Usare costrutti errati o posizionati erroneamente può portare a difficoltà di interpretazione da parte dei browser tanto quanto vi è venuto difficile capire il senso di quella frase.

Il motore interno del vostro browser web, quando riceve una pagina, analizza prima i tag (che sono le indicazioni della nostra sintassi, per continuare il paragone) e in base a quelli costruisce un DOM in cui posiziona i vari oggetti.

Per capire meglio cosa succede durante il caricamento di una pagina date un’occhiata al seguente video.

Get the Flash Player to see this content.

Questa operazione prende il nome di reflow di una pagina (quello nel video è il reflow di Gecko per Mozilla.org) e, per via della struttura dell’html, avviene ricorsivamente sempre più in profondità. Da questo si capisce anche perché solitamente su pagine molto pesante e piene di elementi i computer con processore più datato impieghino qualche istante in più nel visualizzare la pagina.

Ecco che la parola chiave di un buon codice diventa ottimizzazione.

L’ottimizzazione, passa per prima cosa, dalla validazione del codice secondo gli standard concordati dal consorzio W3. Avere delle pagine con codice sintatticamente corretto aiuta sicuramente i browser durante il loro compito. E’ vero che i browser più diffusi fanno miracoli e spesso accettano codice non del tutto corretto (ad esempio un tag <div> inserito dentro un tag <a>) ma evitare problemi alla lunga paga.

Inoltre, non dobbiamo dimenticarci dei motori di ricerca. C’è chi dice che internet senza Google sarebbe ancora una grossa e asettica web-directory. Avere una pagina facilmente accessibile agli spider dei motori di ricerca significa ricevere un buon punteggio nelle loro liste di “siti preferiti” (semplificando di molto il discorso) e un buon punteggio si traduce in una buona indicizzazione e… sono poche le persone che costruiscono un sito web senza volere che sia visibile (così come sono poche le persone che usano il balcone per nascondersi!).

Dunque, una regola fondamentale da ricordare è: i motori di ricerca apprezzano pagine leggere, veloci da caricare e sintatticamente corrette.

Questo non mette in secondo piano i contenuti che rimangono l’elemento principale della pagina (figurarsi che possa importare a Google o chi per lui una pagina vuota ma correttissima sintatticamente) ma, a parità di “valore” del contenuto, il contenitore migliore verrà preferito.

Un po’ come quando esco da casa e devo scegliere tra Porsche e Ferrari… (sigh, è una metafora più astratta delle cose di cui stiamo parlando! :-D).

Un altro aspetto da tenere in considerazione è la struttura del codice che pubblichiamo.

I frame ad esempio, sono deprecati e non credo esistano ragioni valide per usarli ormai. Oltre a questo, cerchiamo di pubblicare i contenuti più importanti nella parte più alta del documento, in modo da far si che gli spider gli diano maggiore importanza (com’è giusto che sia). Ovviamente possiamo giocare poi con il posizionamento grafico tramite i fogli di stile.

Realizziamo un header compatto e completo. I motori di ricerca sfruttano quei dati per avere qualche informazione in più ma abusarne non serve a nulla… per questo non facciamo mancare il tag “title” ad esempio ma non abusiamo del metatag “description” perché spesso i motori di ricerca ignorano quelle keyword (che considerano viziate in partenza).

Evitiamo inoltre l’uso smodato di risorse esterne. Caricare contenuti esterni (immagini, javascript, video flash, audio…) rallenta il caricamento della pagina e oltre a non essere apprezzato dai motori di ricerca (Google tramite i webmasters tools vi permette di monitorare il tempo medio di caricamento delle vostre pagine), sicuramente fa perdere la pazienza ai visitatori (che alla fine, rimangono il vostro riferimento). Cerchiamo di ospitare sul nostro hosting il maggior numero possibile di contenuti.

A quest’ultimo aspetto ovviamente si ricollega la scelta dell’hosting che, sicuramente, va fatta anche in considerazione del peso dei contenuti che vogliamo pubblicare.

Un altra piccola attenzione può esser quella di comprimere i fogli di stile e collegarli all’interno del documento come unico file. Per capirci meglio, nel mio blog, il CSS è segnalato al browser tramite un’unica riga:

 

Il file style.css al suo interno, però, richiama i vari fogli di stile:

@import url("http://www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/main.css");
@import url("http://www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/header.css");
@import url("http://www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/sidebar.css");
@import url("http://www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/footer.css");

Questa scelta, oltre a favorire gli spider (che durante la scansione saltano una riga e non incontrano altre risorse esterne da scartare), favorisce anche la manutenzione del blog. Se volessi cambiare nome o inserire un nuovo foglio di stile, mi basterà effettuare le opportune modifiche dentro style.css senza dovermi ricordare dove l’avevo linkato.

Insomma, tanti piccoli accorgimenti che aiutano a mantenere sotto controllo sia il peso della pagina che la sua struttura.

Voi, avete qualche suggerimento da darmi? :-)

Emanuele

@import url(“ie_sucks.css”);

Scritto il 12 marzo 2009 alle 20:29

E’ assurdo che nel 2009, IE7 non implementi ancora l’@import nei CSS con media-type dichiarato.

E’ una specifica CSS2 del 1998.

Vado a mangiare il pollo allo spiedo, poi scappo all’infinitesima riunione scout.

Che schifo però!

Emanuele

Background random via CSS e PHP.

Scritto il 1 novembre 2008 alle 15:37

In questi giorni queste notti ho lavorato per rifare il sito del mio gruppo scout. Sarà online tra un paio di settimane ed ho deciso di sfruttare WordPress per pubblicare le notizie.

Una cosa carina che ho voluto realizzare è un background fisso con alcune foto prese da attività scout su cui la pagina scorre.

In un CSS però, non è possibile richiamare immagini random, così ho risolto con un piccolo ma semplicissimo hack.

La classe body è diventata come segue:

1
2
3
4
5
6
7
8
body {
   background: url(images/randimg.php) no-repeat 0 0 #fff;
   background-attachment:fixed;
   color: #000;
   font-family: Arial, Verdana, sans-serif;
   margin: 0;
   padding: 0;
}

In questo modo il background, richiama come immagine un piccolissimo script PHP che ritornerà una immagine random.

Sul web esistono svariati script per richiamare file random da una directory, personalmente però non volevo appesantire il codice con routine inutili ed ho compresso tutto nella seguente riga:

<?php header('Location: image00'.rand(1,7).'.jpg'); ?>

Le immagini vanno salvate nella cartella images/ numerandole nel formato image00*.jpg e sostituendo all’asterisco un numero incrementale. Personalmente avevo meno di 10 immagini da far ruotare, così ho scritto il codice adattandolo alle mie necessità. Comunque, è semplicissimo aumentare il numero di file che verranno presi in considerazione dallo script.

Il comando rand(1,7), serve appunto a specificare tra quali valori dovrà muoversi il numero casuale generato.

Infine, il file randimg.php va salvato nella stessa directory in cui salveremo le immagini (nel mio caso dentro images/).

Si potrebbe facilmente implementare il codice per far controllare il numero di file presenti nella directory automaticamente, ma se non cambia frequentemente è bene evitarlo per alleggerire quanto più possibile il codice da processare e rendere tutto il più leggero e veloce possibile.

Vi farei vedere il risultato se il sito fosse già online… :-)

Emanuele