due chiacchiere

Cura dimagrante per il tema

In un’epoca in cui la banda larga oramai ce la tirano dietro, ha ancora senso parlare di ottimizzazione della dimensione delle pagine web? Secondo me si: il provider che ti ospita sarà contento, perché i suoi server lavoreranno un po’ meno; gli utenti con una connessione lenta saranno contenti, perché non dovranno aspettare 10 minuti per un’immagine che neppure gli interessa; l’amministratore del sito ed il grafico saranno contenti, perché potranno effettuare le modifiche in maniera più razionale ed organizzata. Vista questa lunga serie di buoni motivi, mi sono messo all’opera sul mio tema. Esteticamente si notano pochi cambiamenti (a parte il colore, ma quello cambia ogni mese) ma la dimensione complessiva di una generica pagina è adesso diminuita di oltre il 10%, passando da 180Kb a meno di 160. Ed ho appena cominciato.

Per far “dimagrire” il sito, sono partito dal funzionamento dei fogli di stile, che molti ignorano quando disegnano un nuovo aspetto grafico: la proprietà “a cascata” delle definizioni. In altre parole, anziché avere un unico CSS monolitico com’era finora, adesso ne uso tre:

  • la base dove sono definite le forme ed il posizionamento degli elementi nella pagina
  • lo stile per la larghezza dell’impaginazione (normale o larga)
  • i colori (mese per mese) dei vari elementi che compongono l’impaginato

Chi entra e chi esce

La base rimane fissa, mentre gli altri due possono variare dinamicamente a seconda delle impostazione scelte dal visitatore. Prima “ridefinivo” completamente tutto, nei vari fogli di stile che usavo per l’impaginazione normale o larga: adesso molte cose vengono definite una volta sola, e poi “a cascata” estendo le proprietà. Questo approccio di fatto porta due benefici:

  • semplicità di manutenzione e di aggiornamento: invece che aggiornare tanti fogli di stile, mi basterà lavorare su uno, a seconda che la modifica riguardi la forma, il colore o la dimensione
  • fogli più leggeri: rimossa la ridondanza di definizioni, il browser ha meno roba da caricare per visualizzare correttamente la pagina

Compressione a basso livello

Avevo anche provato ad implementare una funzione PHP che comprime con gzip i file inviati al browser. Mi sono però accorto che il guadagno di una manciata di bit, era controbilanciato dall’eccessivo overhead introdotto da questa funzionalità. Il server, anziché inviare direttamente le informazioni, doveva attivare tutte le volte l’interprete PHP, la compressione gzip e tutto quello che ne consegue. L’ho tolta dopo neppure mezza giornata, per la gioia del mio provider.

Commenti

  1. ha scritto:

    Anch’io sono contrario alla compressione delle pagine. E’ vero che diminuisci la banda, ma raddoppi il lavoro. Compressione da parte del server e decompressione nel browser (che in caso di sistemi lenti, mobili oppure obsoleti si traduce in un maggiore carico sulla CPU).
    Riguardo i CSS invece… è vero che razionalizzando i file ti viene più semplice aggiornarli, però aumenti il numero di elementi da scaricare (con conseguenti richieste di GET) durante la navigazione.
    E’ anche vero che i browser ormai hanno un buon sistema di caching ma non tutti navigano da browser con tali caratteristiche.
    L’ideale sarebbe lavorare in locale su 3 file e poi riunirli automaticamente in un unico da mettere online.
    Ciao,
    Emanuele

  2. camu
    ha scritto:

    Beh, io ho dato un’occhio alle mie statistiche, più del 98% dei visitatori usano Internet Explorer (6, 7, 8 per la stragrande maggioranza), Firefox e Safari. Direi che tutti e tre hanno un buon sistema di cache locale 🙂 Concordo però sul fatto che aumentano le GET sul server. Il fatto di lavorare in locale su 3 files e poi riunirli, nel mio caso non è sufficiente: le funzioni per l’accessibilità (alto contrasto, impaginazione larga, e via dicendo) mi impongono di creare un foglio di stile per ogni possibile variante, in quel caso. Mantenendo i file separati, posso giocare sulle combinazioni 🙂

  3. camu
    ha scritto:

    La citazione mi sembra capitare a fagiolo 🙂 Lui si che aveva capito tutto quello che c’era da sapere veramente sull’informatica. Comunque concordo: io ho speso un fine settimana a rielaborare il mio tema, partendo dall’idea di ottimizzarlo. Ci sono riuscito solo parzialmente, ma sono contento del risultato!

  4. Irish Coffee
    ha scritto:

    per una come me alle prime armi questo post è utilissimo,
    ora mi chiedo se la mia pagina è o no pesante, se chi entra fa fatica a caricare
    avendo fastweb io non mi accorgo se questo può accadere
    l’idea di cambiare header ogni mese è bellissima 🙂
    si possono fare tutte le stagioni anche…
    grazie, interessante veramente

  5. Trap
    ha scritto:

    “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

  6. Http500
    ha scritto:

    Cosa usi per misurare il peso di una pagina? Io sono un SEO, e mi interesso di queste cose. Grazie

  7. jgor
    ha scritto:

    Anni fa avevo trattato lo stesso tema. Ovviamente concordo appieno con quello che dici.

  8. camu
    ha scritto:

    Http500, c’è un bellissimo plugin per Firefox che si chiama Web Developer, grazie al quale hai a disposizione tutti gli strumenti che hai sempre sognato: dall’analisi del CSS ai cookie, dalla possibilità di disattivare il javascript al volo al non caricamento delle immagini. Se scarichi la versione in italiano, la dimensione della pagina si trova sotto Informazioni > Visualizza dimensione documento.

  9. Http500
    ha scritto:

    Uso da sempre Firefox, con varie estensiono,Web Developer è fatto bene, ma a volte vede delle dimensioni poco realistiche, infatti può vedere un sito a 500 kb, ma in realtà è molto meno, questo è dovuto al fatto che vede anche voci che alla fine non incidono sul caricamento, come ad esempio le varie cartelle presenti nel data base.

  10. camu
    ha scritto:

    Http500, non capisco cosa intendi per “cartelle nel database” riguardo alla misura del peso di una pagina. Per quanto ho visto, a me sembrava abbastanza attendibile…

  11. Http500
    ha scritto:

    Intendo che vedi il peso del file di Backup, che potrebbe essere 551 kilobytes, invece il peso di caricatura diventa : Dimensione pagina: 117.78kb
    Testo: 85kb
    Immagini: 32.78kb.
    E stiamo parlando dello stesso sito.

  12. camu
    ha scritto:

    Si, capisco cosa intendi… ma la prima volta che un utente accede al sito, si dovrà “sorbire” tutti i 500 e passa kilobytes, prima di poterselo gustare nella sua interezza. Sai, gli informatici guardano sempre al caso pessimo 🙂

  13. Http500
    ha scritto:

    Siccome io sono informatico, guardo un pò a tutto!

  14. Moebius
    ha scritto:

    Ti cito “In altre parole, anziché avere un unico CSS monolitico com’era finora, adesso ne uso tre”.
    Mi daresti qualche riferimento per la tecnica citata, sono interessato alla cosa per migliorare le prestazioni, ma sopratutto per gestire al meglio le personalizzazioni senza impazzire in un unico foglio megalitico!

    PS: ti ho inviato una mail tramite il form dei contatti, spero ti sia arrivata!

  15. camu
    ha scritto:

    Moebius, ti ho mandato una mail con tutte le spiegazioni dettagliate. Magari ne farò un articolo sul blog, più avanti.

  16. jgor
    ha scritto:

    Se fai un articolo sarebbe interessante,
    visto che sto preparando il restyling anche del mio sito
    e mi farebbe comodo fare delle prove:D
    Ovviamente ti stresserò un po’ 😛

    Ps grazie per la segnalazione, risolto tutto

Rispondi a Emanuele

Torna in cima alla pagina