Da sempre il web designer/developer deve sostenere la famosa dura lotta della compatibilità browser, con un occhio di riguardo soprattutto per Internet Explorer, ed in particolar modo per l’utilizzo delle numerose funzionalità CSS3, che contribuiscono ad incrementare la qualità e la user experience di ogni interfaccia.

Negli ultimi tempi l’interpretazione di animazioni, transizioni e altre proprietà CSS3 su tutti i browser sembra una meta sempre meno lontana, per cui molti front-end developer, compreso il sottoscritto, cercano di impiegarli il più possibile all’interno dei loro progetti.

Tuttavia nell’utilizzare funzionalità del genere bisogna fare attenzione alle performance CSS3 del dispositivo/browser su cui dovranno “girare”, in particolare se si tratta di quelli mobili, molto meno potenti rispetto ai desktop.

Un esperienza a riguardo

Recentemente ho sviluppato e pubblicato nell’App Store Tint, un’applicazione realizzata interamente con markup HTML5, animazioni CSS3 e l’ausilio di Backbone (che approfondirò in un articolo futuro), riscuotendo anche un notevole successo in fatto di download.

Ma perché ho introdotto Tint?

In questo articolo ti voglio parlare di una lezione importante nell’ottimizzare performance CSS3 di animazioni, transizioni ed effetti applicati ad elementi DOM, che ho personalmente imparato durante la mia esperienza nello sviluppo di Tint, la quale ha contribuito ad incrementarne notevolmente le prestazioni.

Nonostante sia da molto tempo che mi occupo di interfacce web, questa è stata la prima volta che ho avuto l’esigenza di ottimizzare al massimo le prestazioni in dispositivi che, per caratteristiche hardware, riescono difficilmente a supportare certi tipi di animazioni e transizioni.

Ho dovuto pertanto cambiare il modo di realizzare alcuni effetti che su smartphone si arrestavano o mostravano uno sfarfallio (quanto lo odio!), mentre per desktop non davano nessun problema.

Punto focale: il rendering

Quando parliamo di prestazioni su un browser, dobbiamo pensare in particolare al rendering e su come esso rappresenti la ragione principale per le scarse prestazioni derivanti dai nostri stili CSS3.

Mi spiego meglio:

i vari step che compongono il processo in base al quale il browser passa dalla “lettura” del DOM al “disegno” sullo schermo, si possono riassumere in 3 fasi principali, nell’ordine:

1. Calcolo dei stili: in questa prima parte vengono calcolate e definite tutte quelle proprietà che definiscono la morfologia dell’elemento, come width, height, margin, padding, font-size, top, left ecc.
2. Disegno dell’elemento: è il momento in cui l’elemento viene “arricchito” con proprietà come ombra, background, outline, border ecc..
3. Creazione dei layers: qui vengono creati i layer dei “disegni” appena creati, che si differenziano in due categorie: quelli per il render, i quali definiscono la struttura ad albero di elementi e sotto-elementi, e quelli grafici, che vengono creati ogni volta che la GPU viene chiamata in causa. Possiamo dire quindi che quest’ultimo processo interessa proprietà CSS3 come translate, transform, scale, rotate ecc..

La cosa più importante su cui soffermarsi è il fatto che queste tre operazioni vengono eseguite dal browser in coda. Per cui se ad un elemento DOM già disegnato sullo schermo, andiamo a modificare proprietà classificate nel primo punto, poi dovranno essere rieseguiti anche gli altri due step.

Se invece modifichiamo attributi appartenenti al secondo step, il browser si preoccuperà di eseguire anche il terzo step.

Infine, modificando proprietà classificate nell’ultimo step, il lavoro del browser sarà alleggerito notevolmente perché non dovrà rieseguire gli step precedenti.

Questo discorso vale in linea generale per tutti i tipi di browser, a parte il nostro solito amico/nemico Internet Explorer, del quale non abbiamo molte informazioni sul processo di rendering (confidiamo nelle future release).

Tutto questo per dire cosa?

Beh, se ho esposto bene il funzionamento di rendering, sarà facile darsi una risposta:

al fine ottimizzare al massimo le prestazioni di un’animazione bisogna fare in modo che il browser prenda la strada più corta per realizzarla.

Faccio un esempio banale.

Se dobbiamo spostare una div dalla parte superiore del documento a quella inferiore in modo animato, invece di applicare l’animazione all’attributo top o bottom, che costringerebbe il browser a ripetere tutte e 3 le fasi del processo per ogni singolo frame dell’animazione, la applicheremo alla proprietà transform: translate ( o transform: translate3d) le quali interesseranno solo l’ultimo dei 3 step.

In questo modo aumenteremo in modo considerevole la fluidità degli effetti dei nostri progetti.

Dall’esempio possiamo vedere due modi diversi di realizzare la stessa animazione, con performance CSS3 completamente differenti.

Di seguito elenco le proprietà per ognuno dei tre (macro) step.

Step 1: calcolo degli stili

Step 2: disegno dell’elemento

Step 3: creazione dei layers

Conclusioni

Una volta preso in considerazione questo importante discorso, la fluidità delle animazioni e transizioni applicate ai vari elementi della mia app Tint è aumentata in modo considerevole, avvicinandosi sempre di più a quella di applicazioni native (se vuoi vedere il risultato l’app è scaricabile nell’app store).

Spero quindi che anche tu applicherai questo importantissimo concetto nel tuo prossimo lavoro.

Buon divertimento!