Una ottimizzazione per Google poco discussa ma molto importante.
Monday, 09 April 07
Essendo l'ottimizzazione per i motori di ricerca (campo che in realta' si risolve in grande parte nell'ottimizzazione per un motore di ricerca, Google) assimilabile alla magia nera ognuno dara' la sua ricetta.
Alcune cose funzionano, altre no, altre sono dubbie, ma alcune hanno un pregio non indifferente: fanno bene al tuo sito a priori. Ad esempio e' congetturato che avere un sito che rispetta gli standard del W3C sia un buon punto, e certamente e' un buon punto a prescindere da Google, allora perche' no? Similmente una pagina scritta in modo che gli elementi XHTML siano utilizzati rispettando la loro semantica e' sicuramente una buona idea, cosi' se invece di utilizzare:
E' congetturabile che a Google siano molto attenti a questo problema, e alcuni test che ho fatto indicano che lo stesso sito se servito piu' velocemente tende a migliorare sia in termini di posizione nei risultati della ricerca che in termini di numero di pagine indicizzate.
Inoltre questa e' davvero una di quelle ottimizzazioni che fanno bene al nostro sito a priori: gli utenti hanno piu' possibilita' di seguire link all'interno del nostro sito se l'esperienza di navigazione e' istantanea, e finiranno di conseguenza per cliccare di piu' anche sui banner adsense.
Fortunatamente un sito veloce non e' prerogativa di chi ha grossi data center e tanti soldi, con un po' di impegno possiamo avere siti velocissimi anche noi comuni mortali. Di seguito alcuni punti importanti.
Per vedere se il vostro sito supporta la compressione HTTP utilizzate questo sito, come potete vedere la home page di questo blog viene servita 2.7 volte piu' velocemente grazie alla compressione. Ma guadagni piu' estremi con layout piu' complessi sono assolutamente normali.
Alcune cose funzionano, altre no, altre sono dubbie, ma alcune hanno un pregio non indifferente: fanno bene al tuo sito a priori. Ad esempio e' congetturato che avere un sito che rispetta gli standard del W3C sia un buon punto, e certamente e' un buon punto a prescindere da Google, allora perche' no? Similmente una pagina scritta in modo che gli elementi XHTML siano utilizzati rispettando la loro semantica e' sicuramente una buona idea, cosi' se invece di utilizzare:
<div class="title">Titolo pagina</div>scriviamo
<h1 class="title">Titolo pagina</h1>utilizziamo il tag <p> per i paragrafi, <strong> invece che <b> per la parte da mettere in evidenza del nostro contenuto, e' tutto di guadagnato. Una di queste ottimizzazioni non e' a mio avviso citata abbastanza.
Piu' veloce della luce
Avete presente l'impegno che Google mette nel servire i risultati di una ricerca il piu' velocemente possibile? Ci tengono tanto. Se poi i siti che presentano al momento del click da parte degli utenti non si aprono abbastanza presto i loro sforzi sono andati piu' o meno in fumo: non e' colpa del motore di ricerca ma l'esperienza dell'utente e' compromessa.E' congetturabile che a Google siano molto attenti a questo problema, e alcuni test che ho fatto indicano che lo stesso sito se servito piu' velocemente tende a migliorare sia in termini di posizione nei risultati della ricerca che in termini di numero di pagine indicizzate.
Inoltre questa e' davvero una di quelle ottimizzazioni che fanno bene al nostro sito a priori: gli utenti hanno piu' possibilita' di seguire link all'interno del nostro sito se l'esperienza di navigazione e' istantanea, e finiranno di conseguenza per cliccare di piu' anche sui banner adsense.
Fortunatamente un sito veloce non e' prerogativa di chi ha grossi data center e tanti soldi, con un po' di impegno possiamo avere siti velocissimi anche noi comuni mortali. Di seguito alcuni punti importanti.
Compressione HTTP
Il protocollo HTTP si occupa di permettere ai nostri browser di collegarsi ad un server web che contiene delle pagine e farne richiesta. Di norma quando il server spedisce la pagina richiesta al browser tale pagina non viene preventivamente compressa, ed e' uno spreco! perche' una pagina web si comprime utilizzando da un terzo ad un sesto dello spazio solitamente, un bel guadagno. Se prima il trasferimento della pagina impiegava 2 secondi utilizzando una connessione ADSL, ora serviranno alcune centinaia di millisecondi. E' un grosso vantaggio che consente anche di economizzare sulla banda utilizzata.Per vedere se il vostro sito supporta la compressione HTTP utilizzate questo sito, come potete vedere la home page di questo blog viene servita 2.7 volte piu' velocemente grazie alla compressione. Ma guadagni piu' estremi con layout piu' complessi sono assolutamente normali.
Struttura semplice dell'HTML
Ovviamente anche se la compressione aiuta avere un file HTML piccolo prima della compressione e' comunque una buona idea. Con l'utilizzo dei CSS si possono fare miracoli in termini grafici anche senza utilizzare una struttura complessa. Inoltre l'HTML complesso che contiene un gran numero di DIV annidati anche quando viene trasferito al browser molto velocemente e' comunque lento da rendere a video! o necessita che tutta la pagina sia stata caricata prima di essere visualizzata in maniera corretta.Utilizzare le immagini con parsimonia
Ovviamente un sito con troppe immagini non giova all'esperienza dell'utente, e in questo caso la compressione HTTP non aiuta: le immagini sono gia' compresse internamente, un nuovo round di compressione le lascerebbe piu' o meno inalterate e sprecherebbe solo CPU sul server. E' bene utilizzare PNG al posto del formato GIF: PNG comprime di piu' praticamente in tutti i casi. Allo stesso modo le immagini JPG dovrebbero essere compresse col fattore piu' alto possibile che consenta una qualita' sufficiente.I server vicini agli utenti
Se pensate di servire fondamentalmente l'utenza italiana potrebbe essere opportuno tenere il/i server in un buon provider nazionale. Ci sono meno rischi di congestioni e in generale la latenza e' minore (perche' ci sono meno hops di distanza tra il client e il server). Comunque e' molto piu' importante avere un buon server e un buon provider e pagarlo una cifra ragionevole, dunque anche se a parita' di condizioni e' meglio avere i server in casa non bisogna fissarsi troppo su questo punto ma ponderare.
Quante volte avete premuto il tasto BACK prima del caricamento integrale di una pagina perche' vi eravate scocciati della lentezza di un sito? Google questo lo sa, e ne tiene conto quando deve fornire il vostro sito tra i suoi risultati.
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Comments
1
10 Apr 07, 08:22:19
Davvero interessante! Magari sarebbe utile spiegare come si può implementare la compressione HTTP per il proprio sito ;)
10 Apr 07, 09:22:32
Purtroppo la compressione http è a livello server, per cui la si può implementare solo se si utilizza un server su cui si ha pieno accesso, ma non se si è in hosting condiviso.
A meno che Antirez non stia parlando di qualcosa di diverso rispetto a ciò che so io! :-)
A meno che Antirez non stia parlando di qualcosa di diverso rispetto a ciò che so io! :-)
10 Apr 07, 09:26:32
@napyfab e doxaliber: ciao Napyfab, ciao Doxaliber, basta installare mod_gzip e utilizzare una semplice configurazione di default. Come dice Doxaliber che parla esattamente di quello di cui parlo io serve avere accesso al server.
La buona notizia è che chi vende hosting quasi sempre la tiene attiva perchè è un suicidio per chi compra banda non avere la compressione HTTP, anche se si sa che il mondo è bello perchè è vario dunque non mi stupirei troppo se qualche provider avesse la compressione disabilitata :) In ogni caso un hosting a prezzi contenuti purtroppo finisce troppo spesso per essere lento a prescindere dalla possibiltà di attivare la compressione.
La buona notizia è che chi vende hosting quasi sempre la tiene attiva perchè è un suicidio per chi compra banda non avere la compressione HTTP, anche se si sa che il mondo è bello perchè è vario dunque non mi stupirei troppo se qualche provider avesse la compressione disabilitata :) In ogni caso un hosting a prezzi contenuti purtroppo finisce troppo spesso per essere lento a prescindere dalla possibiltà di attivare la compressione.
12 Apr 07, 06:04:10
Ma se il server lo supporta e il webmaster non lo utilizza? Ho trovato questo: http://whatsmyip.org/mod_gzip_test/phpgzip/
Ho provato in una pagina php che prima diceva di non essere gzipped, poi mettendo ob_start("ob_gzhandler"); il gzipping funziona..
Anche qui c'è un tool per il test: http://www.whatsmyip.org/mod_gzip_test/
Ho provato in una pagina php che prima diceva di non essere gzipped, poi mettendo ob_start("ob_gzhandler"); il gzipping funziona..
Anche qui c'è un tool per il test: http://www.whatsmyip.org/mod_gzip_test/
12 Apr 07, 12:24:42
@napyfab: In quel caso l'apache non c'entra e non serve il modulo, in pratica viene reimplementato mod_gzip in PHP in un certo senso! Il PHP salva il suo buffer di output, lo prende, lo comprime con gzip, e lo spedisce al client, bypassando la compressione di Apache.
E' importante pero' in tal caso controllare che tra gli header che il browser ha spedito c'e' quello che indica la sua capacita' di digerire gzip: firefox, IE e tutti gli altri browser maggiori lo supportano ma alcuni antichi e alcuni robots potrebbero avere difficolta'.
E' importante pero' in tal caso controllare che tra gli header che il browser ha spedito c'e' quello che indica la sua capacita' di digerire gzip: firefox, IE e tutti gli altri browser maggiori lo supportano ma alcuni antichi e alcuni robots potrebbero avere difficolta'.