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.
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:
<link rel="stylesheet" href="//www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/style.css" type="text/css" media="screen" />
Il file style.css al suo interno, però, richiama i vari fogli di stile:
@import url("//www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/main.css");
@import url("//www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/header.css");
@import url("//www.dreamsworld.it/emanuele/wp-content/themes/emanuele-theme/css/sidebar.css");
@import url("//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
Ottimo articolo. L’unica cosa che non condivido è l’uso di import in un file separato. Con i sistemi tipo WordPress, se devi cambiare il nome, lo farai comunque una sola volta, nel tema, mica pagina per pagina. Ottime le indicazioni sulla SEO 😉
Beh, è vero che su WordPress basta cambiare il nome del CSS solo una volta però… ci sono dei però! 🙂 Innanzitutto, nel caso non si stia lavorando con pagine dinamiche, è un vantaggio e poi – in ogni caso – aumentare il numero di risorse esterne da far-controllare-e-automaticamente-scartare dagli spider, seppur di poco, aumenta pur sempre il tempo necessario al download (più righe, più byte… figurati che c’è chi consiglia di eliminare persino gli spazi dai codici!), alla scansione e conseguentemente persino alle risorse richieste al tuo server. Insomma, “ogni fegatino di mosca è sostanza” si dice dalle mie parti (o per lo meno, lo si diceva in tempo di carestia…) e ogni piccola attenzione risulta sicuramente un vantaggio che alla lunga ripaga in qualche modo. In realtà non mi sono soffermato molto sui Javascript ad esempio (c’è chi li comprime, chi usa versioni ridotte delle librerie più diffuse, chi sfrutta artefizi per averli sempre in cache…). Son piccolezze, è vero, ma possono fare la differenza secondo me. Non sei d’accordo?
Ciao,
Emanuele
Si, sono d’accordo. Io ho compresso sia il javascript che il CSS, rendendo il mio tema più leggero e maneggevole. Non tutti i siti possono vantarsi di “pesare” sui 200Kb, tutto compreso 😉
Io in realtà sul mio blog devo ancora farlo. Hai visto, a proposito, che carino il nuovo tool di Google “Page Speed”? 🙂
L’ho installato qualche giorno fa ma devo ancora lavorare sui consigli ricevuti…
Ciao,
Emanuele
ehm, no, non ne ho mai sentito parlare… ora mi documento 🙂
Documentati, documentati… sono sicuro che il tuo “spirito ottimizzatore” lo apprezzerà tanto. Tra l’altro Google lo usa già in azienda per i progetti realizzati dai suoi dipendenti. 🙂
Ciao,
Emanuele
Ussignur, mai me l’avessi detto, ora lo spiritello talebano chi lo sente… è già tutto gasato per procedere con le ottimizzazioni!
Ecco, uno dei suggerimenti di questo strumento è “Serve the following static resources from a domain that doesn’t set cookies:” ma mica posso comprarmi un altro dominio solo per far contento Google 🙂 Comunque grazie per la segnalazione, sto effettuando le modifiche possibili eh eh
Si beh certi consigli sono esageratamente drastici… tra l’altro non capisco perché aggiungere altri domini. E’ vero che puoi bilanciare il carico ma, solo se si ha la possibilità di avere più server. Se invece si usa un altro dominio sullo stesso server il vantaggio scompare e diventa uno svantaggio: sarà effettuata una nuova connessione con ulteriore carico sul server che – a differenza di una soluzione multiserver – non potrà certamente andare più velocemente di quanto farebbe con un’unica connessione.
Ciao,
Emanuele
PS: che hai modificato tu?
No, il suggerimento di usare un dominio diverso, almeno nel mio caso, era legato all’usare un dominio “cookieless” per i contenuti statici (immagini, javascript, css) per alleggerire il dialogo tra browser e server, per questi oggetti. Sfortunatamente infatti usare un sottodominio non basta, perché (mi sono documentato) i cookie impostati da Analytics sono per *.duechiacchiere.it, quindi static.duechiacchiere.it (che con Tophost potrei fare) non risolverebbe il problema. Un altro suggerimento è di ripulire il CSS dall’uso eccessivo di “selettori CSS inefficienti” ma anche lì non ho proceduto. Uno perché sono pigro, e due perché ho trovato un sito dove, dati alla mano, dimostrano che ripulire il CSS da circa 100 selettori “inefficienti” porta un beneficio in termini di rendering della pagina pari a 20 millisecondi. Il gioco non vale la candela 🙂 Le modifiche fatte (di cui parlerò brevemente in un articolo nei prossimi giorni) sono: 1) spostare l’inline javascript che uso in cima alla pagina come suggerito 2) innalzare l’expire dei contenuti statici a più di un mese, 3) aggiungere width and height alle immagini che non l’avevano impostata, 4) attivare la compressione gzip (anche se mi dice ancora che non è attiva, ma con Live HTTP headers la vedo boh).