Sul web, intendo.
Quando e quanto la ricerca esasperata e maniacale delle migliori performance ha senso?
Ho fatto alcuni ragionamenti partendo dall'ottimo tool YSlow di Yahoo.
Questo consente di analizzare il sito (o web application) e di assegnare un punteggio basato su un set di 23 regole "d'oro" messe a punto da Yahoo stessa (in realtà molte di queste sono già ben conosciute da chi si occupa di web development).
Il tool è molto pratico e restituisce risultati completi e comprensibili, corredati da hints per l'ottimizzazione e il "risanamento" delle carenze.
YSlow all'opera... |
Un altro strumento eccezionale, non solo per l'ottimizzazione, ma anche per il debug è Speed Tracer di Google.
Se avete presente la tab Network dei Developer Tools di Chrome... beh... questo ne è una versione agli steroidi e consente di indagare a bassissimo livello anche sugli eventi DOM (per es. il parsing dell'html, painting del layout o l'applicazione degli stili).
Speed Tracer |
Qui le mie osservazioni su alcune delle regole di ottimizzazione delle performance formalizzate da Yahoo e sulla loro applicabilità...
"Minimize HTTP Requests"
Ridurre il numero di chiamate HTTP consente di velocizzare il caricamento delle pagine.E, perché no, di alleggerire il web server...
Una delle vie più pratiche è quella di accorpare/combinare più .js o più .css in un singolo file.
Un'operazione piuttosto scomoda da effettuare a mano, ma ci vengono in aiuto molti tool, sia online che offline.
Io ho scelto Chirpy: un plugin per Visual Studio che ben si integra nel processo di sviluppo.
L'utilizzo è di una semplicità disarmante.
Inoltre è compatibile con LESS (ne compila al volo i sorgenti) e offre la minificazione (ne parleremo dopo) e la validazione contemporanee alla combinazione.
Applicabilità: sempre
"Use a Content Delivery Network"
CDN o non CDN? Questo è il dilemma...In linea di massima affidarsi a server di grossi provider, potenti, veloci, stabili e dislocati geograficamente sembra buona cosa.
Anche perché è certamente più probabile che il browser di un nuovo visitatore abbia già in cache le librerie di jQuery (per esempio) fornite da Google o Microsoft, in seguito alle precedenti navigazioni, piuttosto che dal nostro server.
Ecco un'interessante comparativa tra alcune delle più grosse CDN disponibili:
CDN Performance |
È altresì vero, però, che le performances delle CDN sono molto variabili, in termini di latenza e velocità pura di download.
E che per applicazioni custom (RIA?) dedicate a pochi utenti unici, specializzati e frequenti utilizzatori della nostra piattaforma, probabilmente il nostro server sarà abbastanza veloce e scarico da fornire prestazioni dignitose. Senza contare che per gli accessi successivi al primo sarà già tutto in cache.
In questi casi, forse, vale la pena conservare l'autoconsistenza del package di deploy, senza appoggiarsi a server esterni; ciò che consente anche di scongiurare eventuali blocchi di proxy/firewall in reti aziendali particolarmente blindate.
Applicabilità: dipende
Anche questa regola, quindi, pare un ulteriore ottimo consiglio.
Ma nella situazione di cui sopra (RIA custom) potrebbero esserci delle "grane": per esempio potremmo trovarci a dover aggiornare una risorsa (immagine, css, script o perfino pagina intera) per implementare una nuova funzionalità, un ritocco chiesto dal cliente o correggere una bug e a dover aspettare che scada il periodo di validità per essere certi che le modifiche si propaghino su tutti i client (in questo caso infatti il browser non verificherà neppure se esiste una nuova versione remota del file).
O a chiedere a tutti di svuotare la cache manualmente!
Applicabilità: dipende
Ricordo, per esempio, che sul vecchio IIS 5.0 era necessario ricorrere a un filtro ISAPI, poiché il meccanismo di compressione nativo era davvero scomodo e buggoso.
Oggi i web server offrono ottimi motori integrati di compressione gzip (generalmente già attivi per default) e i browser supportano da tempo la negoziazione http di risorse compresse.
Non vedo quindi controindicazioni nell'adozione di questa regola nel 100% dei casi (salvo un minimo carico aggiuntivo del server).
Volendo si potrebbero perfino comprimere staticamente i file prima del deploy, ma credo sia un'alternativa che rende difficile la manutenibilità.
Applicabilità: sempre
C'è un'unica controindicazione nella minificazione: script e css diventano non human-readable...
E quindi le operazioni di sviluppo e debug si complicano.
Fortunatamente Chirpy, di cui ho parlato sopra, automatizza anche questa procedura: in un colpo solo possiamo accorpare e minificare più sorgenti solo in fase di deploy, mantenendo le versioni originali inalterate e... leggibili!
Applicabilità: sempre
In questo senso "appendere" i javascript al fondo del body consente un boost di performance notevole, anche grazie al fatto che nel frattempo il DOM viene renderizzato progressivamente.
Però...
Spesso gli script hanno dipendenze l'uno con l'altro ed è indispensabile che vengano caricati nella sequenza corretta.
Pensiamo solo a tutto ciò che si appoggia su jQuery, per esempio.
Grande attenzione va posta quindi nel compiere consapevolmente questa scelta.
Applicabilità: dipende
In conclusione la mia opinione è che non esista una regola buona per tutte le stagioni: gli analisti di Yahoo basano le loro considerazioni su volumi, target e domini applicativi tipici di web company del calibro di Yahoo stessa.
Considerazioni che potrebbero rivelarsi addirittura controproducenti in altri ambiti.
Un'unica regola, sopra a tutte, è sempre vincente: sviluppare (codice e design) con estrema attenzione alla qualità, all'ottimizzazione dei contenuti e alla percezione reale dell'utente. ;-)
Applicabilità: dipende
"Add an Expires or a Cache-Control Header"
Aggiungere esplicitamente gli http header che segnalano al browser il periodo di validità delle risorse consente di evitare anche la piccola richiesta http che il browser stesso compie per confrontare il file remoto con quello in cache.Anche questa regola, quindi, pare un ulteriore ottimo consiglio.
Ma nella situazione di cui sopra (RIA custom) potrebbero esserci delle "grane": per esempio potremmo trovarci a dover aggiornare una risorsa (immagine, css, script o perfino pagina intera) per implementare una nuova funzionalità, un ritocco chiesto dal cliente o correggere una bug e a dover aspettare che scada il periodo di validità per essere certi che le modifiche si propaghino su tutti i client (in questo caso infatti il browser non verificherà neppure se esiste una nuova versione remota del file).
O a chiedere a tutti di svuotare la cache manualmente!
Applicabilità: dipende
"Compress Components with gzip"
Non siamo certo in presenza di una novità...Ricordo, per esempio, che sul vecchio IIS 5.0 era necessario ricorrere a un filtro ISAPI, poiché il meccanismo di compressione nativo era davvero scomodo e buggoso.
Oggi i web server offrono ottimi motori integrati di compressione gzip (generalmente già attivi per default) e i browser supportano da tempo la negoziazione http di risorse compresse.
Non vedo quindi controindicazioni nell'adozione di questa regola nel 100% dei casi (salvo un minimo carico aggiuntivo del server).
Volendo si potrebbero perfino comprimere staticamente i file prima del deploy, ma credo sia un'alternativa che rende difficile la manutenibilità.
Applicabilità: sempre
"Minify Javascript and CSS"
La minificazione (rimozione di commenti e spazi inutili) delle risorse testuali (scripts e css) permette risparmi di dimensioni davvero impressionanti. Questo, unito alla compressione gzip, permette di ridurre corpose librerie anche del 90%.C'è un'unica controindicazione nella minificazione: script e css diventano non human-readable...
E quindi le operazioni di sviluppo e debug si complicano.
Fortunatamente Chirpy, di cui ho parlato sopra, automatizza anche questa procedura: in un colpo solo possiamo accorpare e minificare più sorgenti solo in fase di deploy, mantenendo le versioni originali inalterate e... leggibili!
Applicabilità: sempre
"Put Javascript at bottom"
Linkare, com'è d'uopo, gli script nell'header forza il browser a scaricarli in sequenza, disattivando di fatto la parallelizzazione.In questo senso "appendere" i javascript al fondo del body consente un boost di performance notevole, anche grazie al fatto che nel frattempo il DOM viene renderizzato progressivamente.
Però...
Spesso gli script hanno dipendenze l'uno con l'altro ed è indispensabile che vengano caricati nella sequenza corretta.
Pensiamo solo a tutto ciò che si appoggia su jQuery, per esempio.
Grande attenzione va posta quindi nel compiere consapevolmente questa scelta.
Applicabilità: dipende
In conclusione la mia opinione è che non esista una regola buona per tutte le stagioni: gli analisti di Yahoo basano le loro considerazioni su volumi, target e domini applicativi tipici di web company del calibro di Yahoo stessa.
Considerazioni che potrebbero rivelarsi addirittura controproducenti in altri ambiti.
Un'unica regola, sopra a tutte, è sempre vincente: sviluppare (codice e design) con estrema attenzione alla qualità, all'ottimizzazione dei contenuti e alla percezione reale dell'utente. ;-)