Di solito non ci si pensa, non si pensa al fatto che una pagina internet non è composta solo della pagina fine a se stessa ma è composta anche di altri elementi, quali i file css, i file java (.js) le immagini etc etc.
Tutti questi componenti contribuiscono a rallentare la consultabilità di un sito. Attualmente sto lavorando sul sito Maestroalberto.it per cercare di ottimizzare la banda, infatti questo sito ogni giorno invia una cosa come 1.2 Gb di dati per 6.200 visitatori al giorno, con un rapido calcolo si evince che per ogni visitatore vengono spediti circa 200 Kb. Questo dato tendenzialmente è un dato che non spaventa, spaventa quando si arriva a fine mese e si vedono 30 Gb di traffico trasferiti senza contare il traffico dei motori di ricerca che come ho scritto poco tempo addietro è e deve essere il benvenuto. Dati alla mano andiamo a vedere dove si può ritoccare qualcosa. Il ritocco più grosso è stato fatto sul CSS togliendo tutti gli invio che possono risultare inultili, visivamente la struttura del css inizialmente è così: alla fine dell’elaborazione cancellando tutti gli invio (che ricordo a tutti essere composti da 2 byte: CR e LF) il risultato è questo: Ma andiamo a vedere i numeri che sono molto più interessanti. Il file CSS inizialmente era di 12.648 byte dopo l’elaborazione siamo arrivati a 9.769 byte, un bel risparmio per ora, ma non è finita, si può infatti togliere tutti i commenti, cioè tutto quello compreso tra /* e */. Ancora non abbiamo finito, se nel foglio di stile c’è un riferimento ad una immagine troveremo una dicitura come questa:url('images/nomeimmagine.gif');
possiamo estremizzare l’oittimizzazione cambiando il nome della vcartella da images a img risparminado 3 caratteri per ogni riferimento: url('img/nomeimmagine.gif');
in questo caso i riferimenti erano 24 quindi ho risparmiato 72 byte per ogni chiamata. Continuando sullo stesso tono possiamo anche cambiare il nome degli stili ad esempio uno stile che viene chiamato spesso è navigationbar che ho cambiato in nav, risparmiando preziosi byte. A questo punto non ci resta che ripetere quest’operazione ovunque troviamo la possbilità di accorciare i nomi. Alla fine mi sono ritrovato con un file di 8.924 byte che sottratto alla dimensione iniziale mi da un 3 Kb di risparmo per singolo visitatore unico. Con questa operazione mi sono risparmiato la bellezza di 18 Mb al giorno sulla carta che poi in realtà si sono trasformati in 50/60 Mb a seconda della giornata e del numero di pagine viste.]]>
Nessun commento “Diminuire la quantità di dati spediti su internet – accorciamo il CSS”
Good job man! 🙂
ehhh si mi sta facendo imèpazzire questa battaglia all’ultimo byte
ma ci sono ancora altre cosine da fare
Interessante. Peccato che il codice diventi poco leggibile e conseguentemente meno facile da modificare in futuro.
In ogni caso è pur sempre un’ottima cosa per chi ha limiti di banda.
Ciao,
Emanuele
Una discussione decisamente interessante, vi esprimo la mia opinione!
Francamente, credo che per risparmiare 18 Mb al giorno su più di 1200 non renderei il mio codice illeggibile.
Poi considerando che un css esterno viene cachato e scaricato una sola volta per l’intero sito, non credo ne valga la pena parlando in termini di velocità di navigazione, più che altro darebbe giovamento una diminuzione dei riferimenti esterni.
Comunque a questo punto potresti lavorare allo stesso modo anche su php e html e guadagnare molto di più.
In ogni caso, per quanto riguarda il css, se guardi in:
–> wp-content/plugins/wp-pagenavi/pagenavi-css.css
troverai altro da ottimizzare 😉
Sono daccordissimo sul fatto che 18 Mb su 1200 è meno dell’un percento ma è sempre qualcosa.
Piuttosto non saperi che farmene di un css tutto bello formattato se poi non lo tocca mai, ma proprio mai 🙂
La cache vale solo per lo stesso computer, per 6.000 visite uniche sono 6.000 css
Alcuni plugin installano il loro CSS, come giustamente fai notare anche pagenavi. Basterebbe integrarli nel css principale.
Il lavoro più grosso sul sito del maestro è stato fatto con i js.
Purtroppo un file in particolare il prototype.js è abbastanza pesante ed avendo un nochace in php non viene mai cacheato quello ha diminuito il traffico da 1200 a 600 Mb al giorno.
Grazie comunuqe per le considerazioni 🙂
>Piuttosto non saperi che farmene di un css tutto bello >formattato se poi non lo tocca mai, ma proprio mai 🙂
Magari tenendo due versioni allineate il problema è risolvibile anche per casi in cui le modifiche sono più frequenti.
>La cache vale solo per lo stesso computer, per 6.000 >visite uniche sono 6.000 css
Certo, ma 6000 visite con pagine che pesano circa 20kb + css significherebbe che in media ognuno visita meno di una pagina per generare 1200mb al giorno, perciò credevo si trattasse di hit al giorno.
>Grazie comunuqe per le considerazioni 🙂
Grazie a te per l’ottimo spunto! 🙂
1200 Mb al giorno per un totale di 6000 visite uniche sono 0.2 Mb cioè 200Kb a computer
con 20k a pagina + css sono poco più di 5 pagine a computer… giusto?
oddio mi sono perso.
sigh
cmq in media una pagina, tutto compreso tranne le immagini, IMHO non dovrebbe superare i 50/60 Kb
adoro queste discussioni!!! hehhehe
Si, giusto, ma aggiungendo dei js esterni… bah!
Comunque sono d’accordo 50/60 Kb sono il limite anche per me!
🙂
ohhhhhhh là è anche una questione di educazione nei confronti dell’utente che ti viene a visitare
Inutile dargli millem mila informazioni quando poi è tutto più lento