Ottimizzare la velocità di caricamento delle pagine
Venerdì 1 Dicembre 2006 - 09:05
di Cesare Lamanna
Che dentro Yahoo! ci sia un team ad hoc che si occupa a tempo pieno del miglioramento delle performance dei vari siti del network è cosa che non stupisce. La buona notizia è che abbiano deciso di pubblicare su YUI Blog alcuni consigli frutto della loro esperienza sul campo. Il primo post della serie è dedicato ad uno dei cardini di qualuqnue processo di ottimizazione: la riduzione delle richieste HTTP.
Con un paio di grafici mostrano come sia preferibile concentrare gli sforzi non sull’HTML e sui meccanismi lato server che lo generano, ma sui fattori che di fatto costituiscono l’80% (più o meno, a seconda del sito esaminato) del tempo impiegato dal browser per caricare la pagina nella sua interezza: in genere si parla di script, CSS e immagini. Risultato:
La nostra esperienza dimostra che la riduzione del numero di richieste HTTP è l’elemento che ha il maggior impatto sulla diminuzione dei tempi di risposta ed è spesso il miglior sistema per migliorare le performance.
Curiosando tra i commenti ho ricavato questo tip che passo a quanti ne siano all’oscuro. Il post è accompagnato da un bel grafico che mostra i tempi di caricamento di ciascun componente della pagina (riporto qui un dettaglio):
Si può fare facilmente usando un’estensione per Firefox, TamperData, di cui parla in questo post Simon Willison.
Categoria: Web Design | Permalink
Commenti
1
Molto interessante, non avevo mai pensato che la richiesta in se potesse far perdere tanto tempo prezioso.
Spesso utilizzo piu’ di un css per pagina e non voglio (e’ una questione di ordine mentale) iniziare ad accorpare tutto in un unico css, mi piacerebbe sapere se qualcuno sa o puo’ testare cosa succedde a livello di richieste HTTP se richiamo un css che a sua volta incorpora altri css tramite @import anche se penso che campi poco.
# - postato da Grab - 01 Dicembre 2006 - 09:45
2
Interessante l’articolo, però bisogna porsi la domanda se è meglio compattare tutto in pochi file per migliorare il caricamento, a discapito di una migliore organizzazione ed aggiornabilità della pagina, o viceversa.
Ho provato l’altro giorno @import dentro un css, ma a voi funziona?
# - postato da Alessio Michelini - 01 Dicembre 2006 - 10:08
3
E’ vero, molto dipende dal numero di chiamate, ma bisogna concentrarsi anche sul codice (X)HTML che è quello che richiama le varie cose.
# - postato da Simone - 01 Dicembre 2006 - 10:22
4
Mi fido di quel che dicono, ma alla lunga, dividere i contenuti e sfruttare la cache del browser è cmq preferibile, IMHO. Il problema è dividere i contenuti assennatamente in modo da sfruttare la modularità (e la parte “cascading” dei CSS)
# - postato da paperogiallo - 01 Dicembre 2006 - 10:30
5
@paperogiallo:
hai ragione, infatti bisognerebbe considerare che buona parte delle richieste vengano fatte solo la prima volta e poi si carica solo la pagina# - postato da Simone - 01 Dicembre 2006 - 10:35
6
Provata l’estensione per Firefox, TamperData…
Sembra funzionare bene…Interessente, grazie per la segnalazione
# - postato da Demetrio Polimeno - 01 Dicembre 2006 - 11:55
7
- la soluzione “@import”: non credo che cambi molto, di fatto il browser deve richiamare un ulteriore file CSS, cambia poco che sia richiamato in un punto o in un altro.
- l’unica soluzione che mi viene in mente per ridurre i tempi ma non unire tutto in un solo CSS è di lavorare con CSS ma riunirli lato server con uno script, che si incarica di inviare quell’unico file al browser. Uno sbattimento, ma se fatto bene, un solo script server può andare benissimo per molti CSS (es: invia tutti i CSS nella cartella X. se mi serve, ne aggiungo altri, ne tolgo ecc.).
- caching: effettivamente il bello dell’HTML è la frammentazione, che richiede più connessioni iniziali ma poi permette di riciclare ciò che è già stato scaricato. Quindi: attenzione a focalizzarsi troppo sull’ottimizzazione di UNA pagina: la prima pagina caricata può essere più lenta delle altre, ma poi le cose scorrono.
- allora è buona norma assicurarsi che appaiano per prime quelle cose che colpiscono di più l’attenzione: inutile caricare duecento javascript prima del codice se poi tutto parte con un onload: l’utente aspetta il caricamento degli script (invisibile), poi finalmente vede qualcosa. Meglio forse invertire: appare prima il testo e le immagini, poi mentre l’utente è intento a leggere, si carica il javascript (inclusi eventuali preload per pagine successive). Questo ovviamente se si ha veramente tanto javascript, altrimenti cambia poco.
- vale la pena soffermarsi allora anche sulla possibilità di comprimere il flusso in tempo reale, secondo le specifiche HTTP 1.1 (so che Apache offre questa possibilità in modo più semplice che su IIS, anche se non mi ricordo il motivo di tale differenza).
# - postato da p.bat - 01 Dicembre 2006 - 12:23
8
@p.bat
sono d’accordo, anche io avevo pensato alla possibilità di unire tutti i CSS lato server come uno script. Un pò laborioso (soprattutto se si utilizza qualche CMS o sistema già fatto) ma funzionale.Nel caso delle immagini invece potrebbe essere interessante accorpare più immagini in una sola e poi mostrare la parte selezionata tramite coordinate (mi sembra di aver letto un articolo su questa tecnica molto tempo fa)
9
Ho provato l’estensione TamperData su un mio sito con un homepage abbastanza pesante e ho riscontrato dei risultati differenti rispetto a quanto suggerito dall’articolo.
Vi segnalo il grafico dei risultati.
In particolare risulta che il numero di richieste http è quasi ininfluente, mentre il numero di CSS/javascript richiamati nell’header influisce molto.
Quasi sicuramente questo è dovuto al fatto che io abbia aumentato il numero massimo di richieste che FF può fare ad uno stesso server.Sarebbe interessante a questo punto sapere qual è l’impostazione media degli utenti (cioè quanti han modificato FF come me? quante ne gestisce explorer? quante opera? quante safari? ecc). Io penso sia più comune quella che usa Yahoo, però mi piacerebbe consultare dei dati certi.
Qualcuno invece mi sa spiegare come mai il caricamento di JS e CSS sia sequenziale e non in parallelo? Gli URL sono inclusi direttamente nell’HTML, quindi lui fin da subito sa già tutti i file che deve scaricare, eppure per scaricarli aspetta praticamente la fine di quello precedente…
10
@ Arthens:
Devi considerare però che probabilmente il tuo sito non è affollato come invece è Yahoo!.
Penso che l’articolo si riferisca proprio al server che viene visitato contemporaneamente da taaaaante persone.