Le performance acquisiscono un peso sempre maggiore agli occhi di Google, tanto che Google, da tempo, ha rilasciato una quantità di tool, come ad esempio PageSpeed Insights, dove basta mettere la url del tuo sito e Big G lo controlla per te, con una serie di test automatici che ti permettono di individuare una o più criticità che puoi risolvere.

A meno che tu non sia in un posto del mondo dove il principale motore di ricerca non è Google ( forse solo in Cina o in Russia.. e nel paese dei balocchi ), allora questa cosa ti dovrebbe interessare al punto da farne una tua battaglia personale.

Lo so, tra le migliaia di cose che tu, in qualità di sviluppatore frontend, sei tenuto a sapere perché altrimenti non sei abbastanza aggiornato, c’è pure questa. Le performance.

Un mondo sempre più veloce, ma sempre più lento

Ricordi quando, verso la fine degli anni ’90, esplodeva internet e i siti web si diffondevano a macchia d’olio? Io me lo ricordo, era un periodo fantastico! I siti web facevano più o meno tutti schifo, i più evoluti erano composti da alcune caratteristiche:

  • git animate a non finire di qualsiasi tipo come scheletri, fulmini e saette
  • sfondi pattern da spara-flasharti gli occhi e rovinarti la vista, altro che display retina
  • font che funzionavano solo sui computer di chi faceva il sito web, perché ancora non sapeva che il font non era installato per forza su tutti i computer
  • ecc.. ecc..

ma c’era una cosa che accomunava questi siti: erano composti per la maggior parte da semplice testo, pochissime foto ( e comunque a bassissima risoluzione ) e, a volte, un midi in sottofondo. Te li ricordi? Comunque sia, i siti erano piuttosto snelli, perché le connessioni erano estremamente lente. Personalmente ho iniziato con il 56K, per poi passare all’ISDN. Non ti dico che goduria quando ci passavamo i giochi e i download duravano una settimana ( non sto scherzando! si rimaneva connessi per giorni per scaricare un file, ma questa è un’altra storia… )

Ma oggi? non dovremmo essere velocissimi? C’è la Fibra, Google negli USA sta installando le prime reti da 1Gb al secondo. Chi se ne frega di quei 200 Kb in più di quella PNG. Giusto?

SBAGLIATO!

Esistono dei dispositivi chiamati mobile, che, di solito, hanno una quantità di banda limitata. Già, perché la banda nessuno te la regala ( almeno non nel 2015 ). Ma non solo, i nostri siti sono diventati pachidermici in modo incontrollato, perché ormai un sito web non è più testo, qualche immagine e qualche suono: adesso dentro il browser “girano” vere e proprie applicazioni interattive che permettono di fare quasi qualsiasi cosa dentro un “semplice browser.

Il risultato? Siti estremamente lenti, che impiegano decine di secondi per caricare le risorse ( css, javascript, immagini ) e che, come se non bastasse, perdona l’espressione un po dura, ma sono anche scritti con il culo. Tra tutte i siti che spesso analizzo per mia curiosità professionale, vedo sempre più spesso che i file javascript sono la componente più pesante in assoluto ( a parte le immagini, ovviamente, ma quello dipende da sito a sito ).

I javascript sono il male?

Risposta veloce: NO, non diciamo sciocchezze. Risposta più articolata: dipende cosa si intende per javascript. Spesso i file javascript sono scritti da persone che non hanno la minima idea di quello che stanno scrivendo. Se il mio adorato dobermann camminasse sulla tastiera per sbaglio, scriverebbe del codice migliore di quello che spesso vedo. Quindi nemmeno possiamo dire che scrivono da cani, scrivono peggio, alcuni.

I javascript servono principalmente per interagire, in maniera più interessante, con il sito web che stiamo visitando. Prendi i classici menu dropdown, sono fatti quasi tutti con javascript ( hey, frena! lo so che esistono i pure dropdown, ma quei giochini li lasciamo a chi non deve supportare bene tutti i browser e vuole un’esperienza utente imprecisa e banale, chiaro? ).

Anche i CSS non scherzano

Si, perché anche i CSS occupano una fetta discreta dei Kb che l’utente deve scaricare ogni volta che si collega ad un nuovo sito ( e per fortuna esistono le cache dei browser, altrimenti sai che tragedia? ).

Di solito, quello che si vede in giro, è un’accozzaglia di file css, creati senza una particolare logica, anzi spesso ereditati da estensioni di terze parti, che hanno avuto la decenza di mettere in un loro file il codice css e che gli “sviluppatori” che intervengono, modificano secondo le loro esigenze. Però questo maledettissimo style.css ( o styles.css ) lo vogliamo eliminare del tutto si o no? È davvero imbarazzante vedere tonnellate di codice nello stesso file caricato in tutte le pagine. Dai, andiamo. Siamo ancora alla fine degli anni 2000 e non me ne ero accorto?

Ci sono tantissime tecniche per ottimizzare i CSS, ma oggi vedremo la tecnica chiamata “Critical CSS”

La tecnica Critical CSS

Il concetto potrebbe sembrare intuitivo, addirittura banale e scontato secondo lo “sviluppatore medio”, quello che è sempre bravo a dire “ma si è ovvio, io lo faccio da trentordici anni!”. Sub-umani saccenti a parte, un po’ dappertutto se ne parla, ma solo ultimamente sta “venendo fuori” in modo un po’ più preciso e potente. La tecnica è una di quelle cose che aiuta a ottimizzare i siti e adesso vediamo un po’ più nel dettaglio come funziona.

Adesso ti dirò una cosa sconvolgente: devi usare gli stili inline.

BOOOOM! è esploso l’omino nel tuo cervello? Lo immagino, anche io ho avuto la stessa sensazione dopo aver studiato questa tecnica. SI perché ci rompono i maroni dai tempi di Dave Shea e di CssZenGarden con e potenzialità del css, che deve essere separato dalla struttura e dall’html e ora torniamo indietro, all’età della pietra? Non proprio, adesso ti spiego come funziona, stai calmo.

Detto in poche e semplici parole: devi mettere inline solo il CSS della parte da subito visibile del tuo sito web. Come si calcola la parte visibile, se dipende dalla risoluzione e dalle dimensioni del monitor? Semplice, prendi la risoluzione che abbraccia la più ampia fetta di mercato e hai la tua misura.

Solo a fini didattici: mettiamo il caso che la zona visibile è 700 pixel e il tuo sito è composto da un layout simile a questo:

Esempio di layout

La parte visibile, se abbiamo detto di prendere in considerazione i primi 700 pixel, sarà composta da header + un pezzo del content, cioè 500 pixel del contenuto. Il resto del content ed il footer non sono subito visibili al caricamento del sito, perché queste ultime aree non rientrano nella zona d’interesse della tecnica “critical css”.

In pratica, nel tag <head> di ogni pagina, dovrebbe esserci il codice CSS che permette di visualizzare correttamente i primi N pixel ( in questo caso 700 per pura semplicità didattica ). Quando il browser avrà “parsato” tutto il DOM, il codice CSS sarà già stato scaricato. Il tutto non dovrebbe pesare molto, l’ideale è che si aggiri sui 20/30 kb, non superando mai i 50Kb, altrimenti c’è quasi sicuramente un problema nel modo in cui lo hai scritto. Questa è la versione iper-semplificata che consiglia Google. Personalmente, però, trovo un “filo” più pulita una tecnica leggermente riadattata.

Invece di scrivere il codice CSS direttamente inline, lo puoi inserire in un file CSS ( magari compresso/minificato e quindi ottimizzato ) e puoi richiamarlo come unico file CSS caricato dall’head.

Tramite javascript, subito dopo, con una chiamata Ajax viene caricato in modo asincrono il resto del CSS, che, banalmente, sarà scritto in un altro file, che va a completare il primo. In pratica, spezzetti il CSS della pagina in 2 parti:

  • quello che fai caricare subito
  • quello che fai caricare subito dopo

Che cosa deve comprendere il tuo file critical CSS

  • reset ( io utilizzo quello di Eric Meyer )
  • il file grid per le colonne
  • la tipografia
  • le call to action ( se presenti nella zona visibile )
  • i font
  • l’header

Tutto questo è possibile crearlo in modo molto semplice quanto potente con Sass, come spiego nell’articolo introduttivo ( e anche nella guida Sass che puoi scaricare ).

Conclusioni

Detto sinceramente, solo per questa tecnica ci vorrebbero ore di formazione e non è possibile esaurire tutto l’argomento in un solo articolo, andrebbero mostrati esempi, best practices e sicuramente ci sono una quantità di dettagli che si possono apprezzare nel momento in cui cominci a “sporcarti le mani” e a provare a fare il tuo bundle CSS critical e non critical.

Spero di averti dato un input interessante e stimolante che ti porti ad approfondire il tema performance, guardandolo da un punto di vista troppo spesso non conosciuto, perché le performance faranno sempre più la differenza tra un sito in alto su Google e uno che non comparirà mai.