Nello sviluppo di una HTML5 mobile app le performance dell’interfaccia, dei suoi componenti, e delle animazioni CSS3 ad essi legate è un fattore che può fare la differenza nel risultato finale del prodotto, determinandone la qualità ed il relativo successo.

Per realizzare una user-experience piacevole è necessario fare in modo che l’applicazione sia reattiva, presenti animazioni prive di scatti o salti di frame, e che generi il markup HTML di ogni schermata nel minor tempo possibile.

Forse ti potrebbero interessare gli articoli sulle performance e prestazioni di animazioni CSS3 per le HTML5 Mobile App pubblicati su upCreative.net:

• Performance CSS3: consigli per ottimizzare le animazioni
• Web e Mobile app fluide con layer e hardware acceleration

Oppure questi articoli che ho scritto per YourInspirationWeb.com:

• HTML5 Mobile app: transizioni e animazioni CSS3 – parte 1
• HTML5 Mobile app: transizioni e animazioni CSS3 – parte 2

Ma come è possibile raggiungere tali obiettivi?

In questo articolo voglio condividere con te 6 consigli e tecniche che ho imparato durante le mie esperienze nella realizzazione di numerose HTML5 Mobile App, tra cui due progetti personali, Tint e Dieta SI o NO?.

---

Le 6 migliori tecniche per aumentare le performance di una #HTML5 #MobileApp #webdesign
Click To Tweet

---

1. Non generare (mai) il tuo markup HTML5 sul server

Molti mi chiedono come implementare il codice (php, asp, asp.net ecc.)  per la generazione dinamica del markup HTML5 dell’interfaccia sul server; tuttavia proprio il fatto che il markup venga generato lato-server rappresenta un’approccio sbagliato.

Il motivo? Servirsi di codice lato-server per generare il proprio markup è chiaro un fattore di lentezza.

Perché effettuare una chiamata remota per ottenere dei tipi di dati (come il markup) che possono essere benissimo inclusi nei file dell’applicazione?

Le uniche chiamate ajax che dovresti effettuare sono quelle il cui scopo è ottenere informazioni (in XML, json ecc) o provvedere al salvataggio di quelle ottenute dall’applicazione.

Per generare del markup  direttamente dall’applicazione in base alle informazioni ottenute dal server, possiamo procedere in due modi. Vediamoli brevemente, supponendo di aver ottenuto questo tipo di dati in formato json:

/* Informazioni restituite dal server */
var team = [
	{
		"name": "Giacomo",
		"occupation": "Developer"
	},
		"name": "Luigi",
		"occupation": "Designer"
	},
	{
		"name": "Mario",
		"occupation": "Web Marketer"
	},
	{
		"name": "Francesco",
		"occupation": "CEO"
	}
];

 a) – Genera il tuo markup direttamente da javascript

/*generiamo il markup all'interno di una variabile*/

var markup = '<ul>';
for(var i=0;i<team.length;i++){
	var member = team[i];
	markup += '<li>'+member.name+' - '+member.occupation+'</li>'
}
markup += "</ul>";

/* inseriamo il markup nel contenitore desiderato */
$("#list-wrapper").append(markup);

b) – Usa un sistema di Templating

Ecco come effettuare il render dinamico del markup con il sistema di templating EJS

File list.ejs:

<li><%=name%> - <%=occupation%></li>

Javascript:

// carichiamo il file list.ejs in modo asincrono (da un file all'interno dell'applicazione)
var template = new EJS({url: '/list.ejs'});
//generiamo il markup
$("#list-wrapper").html(template.render(team));

Per sapere di più sui sistemi di templating ti consiglio di leggere questo articolo:

• I sistemi di Javascript Templating e le migliori librerie

Ricorda, stiamo parlando si una Single page app e non di un normale sito web.

---

Non generare mai il markup della tua #HTML5 #mobileapp sul server
Click To Tweet

---

2. Limita i dati tra server e client

Limitare la quantità di dati passati tra server e client può migliorare notevolmente l’esperienza utente, accorciando i tempi di attesa. Ecco come poterlo fare:

1. Salvare i dati già ottenuti in una cache locale: ci possiamo servire per esempio di funzionalità come l’HTML5 localStorage, un database SQLite, o il salvataggio su un file locale, per memorizzare dati che già abbiamo ottenuto in precedenza, come per esempio una stessa news selezionata per la seconda volta.
2. Limitare il traffico dati allo stretto necessario: non ha senso richiedere al server più informazioni di quelle che ci servono; potremo per esempio impostare le nostre API in modo tale che esse ci restituiscano solo dati che ancora non abbiamo. Ecco un piccolo esempio di una possibile chiamata Ajax che richiede al server solo delle news non ancora ricevute:
   

   $.ajax({
   	url: 'http://localhostAPI/news/',
   	data: { lastid: 115},
   	success: function (news) {
   		/*
                   nella variabile news saranno visualizzate 
                   solo le news che non abbiamo ancora mai ricevuto,
                   ovvero quelle con id più recente di 115, che è corrispondente
                   all'ultima news caricata nella cache
                   */
   	}
   });

    

---

Limita i dati trafficati tra server e client #html5 #mobileapp performance
Click To Tweet

---

3. Non attendere di ricevere informazioni dal server per visualizzare il tuo markup HTML

Non attendere di ricevere i dati dal server per visualizzare una schermata (view). Una buona pratica è quella di visualizzare la view, effettuare la chiamata ajax e, una volta ricevuti i dati, aggiornare la schermata:

/*
funziome di visualizzazione della schermata
*/

var template = new EJS({url: '/news.ejs'});
function visualizzaSchermata(data){
	if(typeof data!='undefined')	
		$("#news-wrapper").html(template.render(team));
	else
		$("#news-wrapper").html(template.render({}));
}

/*effettuo il render della schermata senza le news*/
visualizzaSchermata();

$.ajax({
	url: 'http://localhostAPI/news/',
	data: { lastid: 115},
	success: function (news) {
		/*effettuo il render della schermata passando le news come dati */
		visualizzaSchermata(news);
	}
});

Ho adottato questa tecnica per la realizzazione di Tint Weather App, dove per ogni schermata relativa ad una località ho dapprima effettuato il render della view mostrando un’animazione CSS3 di loading. Quindi ho effettuato la chiamata ajax per reperire i dati meteo dal server e, una volta ottenuti, ho aggiornato la view mostrandoli all’utente.

4. Usa animazioni CSS3 performanti

Le prime volte che mi dilettavo nella realizzazione di HTML5 Mobile App, mi servivo di framework come jQuery Mobile, jqTouch o simili, che basavano le loro animazioni su metodi jQuery come l’animate ( $(“#element”).animeate() ), i quali non sfruttano la tecnica dell’accelerazione hardware, supportata da tutti i browser mobile.

L’hardware acceleration permette di delegare il rendering degli elementi dell’ interfaccia dalla memoria centrale alla GPU, attraverso i livelli grafici, alleggerendone notevolmente il carico di lavoro.

---

Usa animazioni CSS3 performanti nello sviluppo di un #HTML5 #MobileApp
Click To Tweet

---

5. Elimina il ritardo di 300ms del browser

Hai mai notato, navigando un sito web con il tuo dispositivo mobile, che tra il touch su un link e l’inizio del caricamento della pagina successiva, oppure tra il touch su un input box ed il relativo focus, passa qualche millisecondo di tempo?
Ciò è dovuto al fatto che quando l’utente esegue il tap su un bottone, i browser mobile aspettano circa 300ms prima che facciano scattare l’evento del click.

Ma perché?

Il browser vuole essere sicuro che l’utente non voglia eseguire un double tap, in modo da distinguere l’evento del touch singolo da quello del doppio touch.

Visto che il nostro intento è quello di realizzare una HTML5 Mobile App fluida e reattiva, dobbiamo assolutamente risolvere questo problema (sicuramente avrai notato che nessuna applicazione nativa presenta quel fastidiosissimo delay, e noi dobbiamo fare altrettanto).

Per eliminare tale ritardo ci basterà includere nel  progetto la libreria FastClick.js, grazie alla quale sarà sufficiente inserire nel codice Javascript la seguente sintassi:

window.addEventListener('load', function() {
    FastClick.attach(document.body);
}, false);

---

Rendi le tue #HTML5 #MobileApp fluide e reattive con #FastClick
Click To Tweet

---

6. Ottimizza le immagini

Molti sottovalutano questo importante aspetto.

Il caricamento delle immagini rappresenta un elemento determinante per le performance di ogni HTML5 Mobile App: il modo in cui le implementiamo nell’interfaccia incide notevolmente sulla user-expericence finale.

Ecco alcuni punti da seguire per utilizzare correttamente le immagini:

• Usa gli spritesheet dove possibile: essi fanno in modo che tutte le immagini utilizzate nell’applicazione vengano caricate in una sola volta, evitando il load singolo solamente nel momento in cui sono visualizzate.
• Non ridimensionare le immagini: utilizza immagini che hanno le stesse dimensioni con cui saranno visualizzate; richiama diverse versioni della stessa immagine a seconda della risoluzione del dispositivo. Non ridimensionare le immagini con proprietà CSS o attributi HTML.
• Se possibile appoggiati ad un server CDN per l’hosting delle immagini che richiami via server: esistono diversi hosting CDN gratuiti da poter usare come spazio in cui salvare le tue immagini.
  
• Prevedi delle fallback per gli errori di caricamento: se un’immagine non viene trovata (errore 404) o si verifica un errore di caricamento, è sempre opportuno visualizzarne una predefinita, o magari evitare di inserire il relativo tag HTML nel markup dell’interfaccia. Ecco un esempio:
  

  <script type="text/javascript">
  function imgError(image) {
      image.onerror = "";
      image.src = "/images/noimage.gif";
      return true;
  }
  </script>
  
  <img src="image.png" onerror="imgError(this);"/>

   

---

Ottimizza le immagini per aumentare le performnce #HTML5 #MobileApp
Click To Tweet

---

Conclusioni

Realizzare applicazioni mobile in HTML5, CSS3 e Javascript rappresenta un grande vantaggio, in quanto permette sviluppare un singolo prodotto da poter distribuire su diverse piattaforme. Tuttavia uno dei possibili difetti di questo approccio è proprio la possibilità di avere scarse performance: diventa quindi indispensabile eliminare tale eventualità.

Adottando la serie di tecniche esposte in questo articolo posso affermare di aver incrementato le performance delle mie HTML5 Mobile App, ed averne incredibilmente ridotto la differenza rispetto alle applicazioni Native.

E tu? Hai qualche consiglio o tecnica da suggerirmi? Fammelo sapere lasciando un commento!

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!