Che ci crediate o no, il concetto di ottimizzazione del codice del front-end per massimizzare le prestazioni è relativamente nuovo. Certo, anche molti anni fa sapevamo che era importante; tuttavia, non avevamo accesso agli strumenti di cui disponiamo oggi. Fino a sei anni fa, ci preoccupavamo di più del fatto che i siti web funzionassero correttamente in Internet Explorer 6 che delle prestazioni delle applicazioni.
Fortunatamente oggi, mentre Chrome e Firefox continuano la loro lotta per chi ha il numero di versione più alto, ci troviamo nell’era d’oro dello sviluppo web.
Grazie ai CSS3 e HTML5, i designer sono in grado di ridurre drasticamente il “peso” dei loro design. Le immagini di sfondo sono state sostituite dalle sfumature CSS3, mentre @font-face, per la gioia dei designer, ha preso il posto di sIFR (i font bastai fu flash). Anche i nuovi elementi HTML5 aiutano a migliorare le prestazioni durante le query al DOM. Anche e un risparmio di qualche centinaio di millisecondi può sembrare poca cosa, vi assicuriamo che può fare la differenza. Inoltre questo è il nostro mestiere: se non prendiamo noi in considerazione queste cose, chi lo fa?
Viviamo in un ambiente in cui la gratificazione immediata è fondamentale. Anche un secondo in più può fare la differenza tra effettuare un acquisto e/o passare al sito successivo.
Vediamo quindi insieme consigli da seguire e errori da evitare:
Errori comuni
Sfortunatamente, nella blogosfera la maggior parte dei consigli sull’ottimizzazione delle prestazioni riguarda tecniche che, in tutta onestà, hanno effetti negativi. Ecco quindi alcuni errori comuni da evitare:
1.Virgolette singole o doppie
La maggior parte degli sviluppatori PHP conosce sicuramente la discussione su virgolette singole e doppie. Per chi non lo sa, il succo è che, per motivi di prestazioni, è meglio inserire le stringhe tre virgolette semplici e non doppie. La giustificazione è che, poichè PHP non ha bisogno se rilevare se le variabili si trovano nella stringa, le prestazioni non possono che migliorare.
Non solo questo non è vero, ma estremizza anche il concetto di pre-ottimizzazione.
2.Selettori jQuery
I fan di jQuery avranno certamente letto numerosi articoli che indicano diversi modi per ottimizzare i selettori passati a jQuery. Di nuovo, la verità è che, sempre che non siate contrari ai selettori e facciate attenzione al fatto che il motore dei selettori, Sizzle, analizza le stringhe di selettori da destra a sinistra, jQuery svolge un ottimo lavoro di ottimizzazione del codice. Nella maggior parte dei casi, sia che usiate children() o find() per cercare un elemento, tutto questo non avrà alcun effetto percepibile. Non è qui che dovete investire il vostro tempo: Dovete certamente tenere in considerazione le prestazioni ma concentrarvi sulle cose giuste.
3.Selettori CSS
A un certo punto, si credeva che il selettore CSS universale * fosse terribile e non dovesse mai essere usato. la verità è che, quando fa riferimento a se stesso, questo selettore non è diverso da quando fa riferimento a qualsiasi altro elemento. Le prestazioni migliorano quando viene usato come selettore discendente, come .content>*.
Poichè i CSS vengono analizzati in un formato da destra verso sinistra, prima deve ottenere ogni elemento dal DOM e poi stabilire se ognuno è figlio dell’elemento con la classe content. In questi casi, non dovete mai utilizzare il selettore universale.
Tuttavia se dovete eseguire un’azione simile all’azzeramento di margine e spaziatura di tutti gli elementi, usatelo nel modo seguente:
* {margin: 0;padding:0}
Se state lavorando a un sito web abbastanza gestibile, non avete niente di cui preoccuparvi. Ricordate: sono tante le cose da prendere in considerazione prima di concentrare la vostra attenzione sulle prestazioni dei selettori CSS. Sul web troviamo una frase di uno dei principali sviluppatori di WebKit, Antti Koivisto, il quale non avrebbe poto rendere meglio l’idea:
Ritengo che non sia compito degli autori preoccuparsi dell’ottimizzazione dei selettori (e dal mio punto di vista generalmente nonn lo fanno). È un lavoro che spetta al motore.
Questi sono i principali errori comuni che vengono svolti nello sviluppo web, passiamo invece adesso ai consigli da seguire:
Soluzioni migliori
Una sorprendente statistica rivela che l’80% dei carichi di pagina viene speso per il frontend o, in altre parole, sulle immagini, i fogli di stile e gli script che abbelliscono il nostro sito: Nonostante il cattivo consiglio che circola su internet, società come Yahoo! e Google si sono sforzate di raccomandare una serie di pratiche a prova di bomba, che dovrebbero essere integrate in tutti i progetti.
YSlow
Yslow di Yahoo! è un’estensione del browser che analizza il sito web e rileva automaticamente gli hotspot, o le aree in cui le prestazioni possono essere migliorate. Assolve questo compito eseguendo una serie di test e assegnando a ciascuno una valutazione compresa tra A e F. Alla fine verrà eseguita una media del punteggio di ogni test.
Inoltre, questi test assicurano che i fogli di stile e gli script vengano posizionati rispettivamente all’inizio e alla fine del documento. In questo modo si ha l’illusione che la pagina venga caricata più velocemente. Queste situazione è maggiormente percepibile nei browser più vecchi, dove gli script non vengono caricati in parallelo. Di conseguenza, il resto della pagina non viene analizzato finchè lo script non è stato completamente analizzato.
Tuttavia, la cosa più importante è che YSlow stabilisce se tutte le risorse, cioè gli script e i fogli di stile, sono stati concatenati e compressi: La concatenazione si riferisce, per esempio, al processo di recupero di tre richieste HTTP, o di collegamenti ai fogli di stile, e alla loro unione in un file più grande: In questo modo vengono eliminate due richieste HTTP, cosa che potrebbe apparire insignificante ma che è meglio di niente.
Oltre alla concatenazione, la compressione del file, è in grado di ridurre le dimensioni di un documento del 40-70%.
PreProcessori CSS
I CSS ti permettono di fare un sacco di cose, ma peccano su alcune caratteristiche, tipiche della fase development, come variabili, costanti e , sintassi più veloci in generale. Come ben sappiamo, i CSS non possono fare tutto questo, sono stati quindi creati dei preprocessori CSS per consentire l’utilizzo di variabili sui file CSS e, in seguito ricompilare il tutto per il normale foglio di stile.
I preprocessori CSS, oltre a espandere le funzionalità dei CSS, consentono di utilizzare durante lo sviluppo più fogli di stile (per scopi organizzativi), esportando alla fine un unico foglio di stile compresso.
Ecco una lista dei principali compilatori in rete:
Ridurre il peso dei CSS3
Tutti i web designer devono essere grati del fatto che i produttori di browser hanno sperimentato le nuove proprietà CSS3 prima di loro. Detto questo, ci troviamo ora a un punto in cui una singola proprietà, per ottenere la compatibilità tra browser, può richiedere fino a cinque versioni separate. Per esempio, per le transizioni CSS3 occorre rappresentare i prefissi di WebKit, Mozilla, Microsoft e Opera:
.transition {
-webkit-transition: all 1s;
-moz-transition: all 1s;
-o-transition: all 1s;
-ms-transition: all 1s;
transition: all 1s;
}
Lo svantaggio di questa situazione è che, soprattutto per design molto grandi e che fanno un ampio uso del CSS3, la dimensione del file del foglio di stile aumenterà significativamente.
Sebbene strumenti come Nettuts+ o Prefixr facilitino il processo di scrittura dei CSS3 tra browser, le soluzioni alternative basate su JavaScript, come -prefix-free (del quale trovate una recensione approfondita sul mio blog) il quale sfrutta un approccio diverso: create i vostri design usando la sintassi ufficiale e, quando la pagina verrà caricata nel browser, -prefix-free rileverà il browser corrente e applicherà alle proprietà i prefissi dei produttori necessari in maniera dinamica.
Nonostante un problema di -prefix-free sia che è una soluzione basata su JavaScript, un vantaggio considerevole è che la dimensione di file del foglio di stile può essere enormemente ridotta, per non parlare del fatto che potete liberarvi definitivamente dei prefissi.
Waterfall
Monitorare il ciclo di caricamento di una pagina è molto facile di questi tempi, grazie a strumenti come Firebug e Chrome Developer Tool (disponibile di default con il browser). Spesso chiamata The Waterfall, e disponibile tramite la scheda Network in Chrome Dev Tools, la timeline fornisce informazioni importanti sul numero di millisecondo necessari per caricare ciascuna risorsa. Questo strumento può essere usato per rilevare e correggere eventuali problemi.
Conclusioni
Come potete vedere ci sono tantissimi metodi e sistemi per poter ottimizzare i vostri siti e il vostro metodo di lavorare ad essi. Nell’articolo ho inserito tanti elementi che vi saranno utili ma tenete conto che questa è solo la punta dell’iceberg!
Ad ogni modo, valutate sempre se conviene o no apportare certi accorgimenti: a volte rischierete di perdere tempo prezioso per cose che non andranno a influenzare le prestazioni delle vostri pagine (vedi appunto la parte degli errori comuni).
E voi cosa ne pensate? Utilizzavate già questi accorgimenti o gli utilizzerete in futuro?
Conoscete altre consigli utili a livelli di ottimizzazione delle prestazioni?
