La tua app è lenta? Prima di ottimizzare, scopri perché

Abbiamo tutti sperimentato, come utenti, la terribile esperienza di utilizzo di un’applicazione che reagisce un po’ in ritardo ai tap, con schermate che richiedono secondi interi di attesa per caricare o addirittura che rimane bloccata alla schermata che precede l’interfaccia principale.

Non è un problema secondario. Un’applicazione lenta:

• Genera frustrazione nell’utente
• Porta l’utente all’abbandono
• Alla lunga, abbassa le valutazioni negli store
• Comporta una perdita di fatturato

Ma come si interviene quando un’applicazione non si comporta nella maniera attesa? Ottimizzare alla cieca non è la soluzione. Il primo passo è capire esattamente dove si trova il problema e intervenire in modo mirato.

Le cause di un’applicazione lenta

Affermare che l’app è lenta è come andare dal medico e dire “sto male”: è un’indicazione utile, ma troppo poco precisa per poter individuare una soluzione. Per ovvi motivi, però, è anche il tipo di segnalazione che più spesso fanno gli utenti.

Nell’urgenza di trattenere gli utenti dalla fuga, il primo istinto potrebbe essere quello di lanciarti immediatamente nell’ottimizzazione dell’app. Non farlo: procedere senza una guida sarebbe solamente uno spreco di risorse temporali ed economiche.

Il primo step è comprendere cosa significa che “l’app è lenta”: gli utenti stessi a volte forniscono nelle loro recensioni delle indicazioni da non trascurare.

Come valutare che tipo di lentezza

Nella nostra esperienza esistono almeno cinque tipi di lentezza che possono essere individuati. Ognuno di questi ha delle caratteristiche specifiche e punta a una diversa area che richiede ottimizzazione.

Per capire che velocità ci si aspetta da un’applicazione, bisogna tenere conto che a 60Hz è considerato fluido un frame ridisegnato ogni 16 millisecondi. Per Android, un frame oltre i 700 millisecondi è considerato un frozen frame; per l’utente, invece, l’app è semplicemente bloccata.

Come distinguere la causa della lentezza: strumenti e procedure

Saper individuare la motivazione sottostante non è una questione di intuito, ma di metodo. Il metodo che usiamo noi di Mabiloft richiede quattro accorgimenti:

Riprodurre il problema. Se il problema non è replicabile, non è possibile intervenire miratamente. Vedere il problema con i propri occhi consente di rispondere a domande come: in che schermate avviene, quando succede e lo fa in maniera costante o solo a volte?

Misurare nelle condizioni giuste. Più le condizioni sono simili a quelle dell’utente, più la misurazione è affidabile. Per questo è bene utilizzare un dispositivo reale, anziché un simulatore, e una build quanto più vicina a quella utilizzata realmente dagli utenti.

Segmentare il problema. Ridurre il campo ci avvicina alla causa del problema. Ciò significa individuare se il problema si presenta solo su dispositivi di fascia bassa o su tutti, se solo su Android o iOS o su entrambi i sistemi operativi, da quale versione l’app ha iniziato a rallentare e così via.

Separare client e server. Se la risposta delle API è veloce, ma la schermata si carica lentamente, il problema è nell’applicazione. Se invece è il server a far aspettare l’app, allora va controllato il backend.

Potrebbero sembrare molte cose da tenere sott’occhio, ma ci vengono in aiuto gli strumenti di monitoraggio gratuiti per ciascuna piattaforma: noi utilizziamo Flutter DevTools, ma ne esistono diversi per iOS, per Android e anche cross-platform.

Intervenire sulla velocità dell’applicazione

Una volta individuato il problema è possibile stabilire dei metodi con i quali intervenire. Ovviamente, la soluzione è strettamente dipendente dalla causa individuata.

Per identificare correttamente la causa del problema, infine, ogni correzione deve essere applicata singolarmente: ciò significa misurare un “prima” e un “dopo”, in modo da avere una misura certa che ci indichi se il nostro intervento è stato risolutivo.

Correggere un avvio lento

Come abbiamo detto, un avvio lento dell’applicazione dipende dalle inizializzazioni nel posto sbagliato. Si tratta di un problema che riscontriamo spesso, e anche piuttosto insidioso: l’applicazione funziona, fa quello che deve, ma l’utente si lamenta che ci mette una vita ad aprirsi.

Quello che succede sotto è che all’avvio, prima di mostrare la prima schermata, tutto inizia immediatamente a funzionare: analytics, crash reporting, notifiche push, configurazioni remote, database locale, SDK pubblicitari e chi più ne ha più ne metta. 

Ogni elemento singolarmente aggiunge appena qualche centinaio di millisecondi, ma nel complesso lo splash screen resta sullo schermo per diversi secondi.

Spesso questo problema è aggravato dalla richiesta immediata di tutti i permessi: fotocamera, notifiche, posizione, prima ancora che l’utente abbia visto l’applicazione funzionare, con la conseguenza di risultare un po’ sospetti e invadenti.

La correzione di questo problema è solitamente semplice: 

• Distinguere quello che è indispensabile per l’avvio dell’app e limitarsi a quello. Tutto il resto può venir spostato in background finché l’utente sta usando l’app.
• Per ciò che non dipende da altro può essere utile parallelizzare, anziché eseguire tutti i processi in sequenza.
• L’eventuale richiesta di permessi può avvenire al bisogno: quando si cerca di accedere a una sezione “Mappa”, ad esempio, può essere richiesto il consenso a rilevare la posizione, anziché domandarlo preventivamente.

Altri problemi da conoscere e correggere

Ovviamente l’avvio lento è solo uno dei possibili problemi. Un’analisi accurata consente di individuare e correggere buona parte dei problemi.

Ad esempio, se l’interfaccia scatta, il problema è spesso legato a widget che si ridisegnano più spesso di quanto sia necessario, oppure a liste che costruiscono tutti gli elementi, anche quelli non in vista, o a effetti grafici pesanti. In Flutter, in particolare, uno state management non pensato può portare a rebuildare intere schermate alla modifica di un solo dato.

Se invece è il thread principale a essere bloccato, può essere che ci siano JSON molto grandi in gioco, oppure che le immagini stiano venendo elaborate sullo stesso thread che disegna l’interfaccia. La soluzione, ovviamente, è spostare queste attività in background.

Altri problemi comuni includono leak di memoria, specialmente se il problema si riscontra su dispositivi più vecchi, con poca RAM, e problemi sul database locale, come query senza indici e letture e scritture sincrone eseguite durante la navigazione.

Quando è l’app ad aspettare

L’utente aspetta l’app, ma a volte l’app sta aspettando il server. Alcune cause tipiche sono:

• Risposte troppo pesanti, con l’API che restituisce oggetti enormi anche se nella schermata sono necessari solo pochi campi.
• Se per mostrare una schermata servono cinque richieste diverse, si corre il rischio di effettuare troppe chiamate a cascata, ognuna in attesa di quella precedente.
• Nessuna cache: gli stessi dati devono essere riscaricati ogni volta.
• Server lento o sovraccarico, con query poco ottimizzate.

Anche per uno sviluppatore mobile può essere utile conoscere questi aspetti, in modo da favorire il dialogo tra team. Ciò significa anche pensare assieme agli endpoint, in relazione alle schermate che devono essere prodotte.

Lato app è possibile anche mostrare subito i dati cachati e aggiornarli in un secondo momento, per evitare all’utente quella noiosa attesa di fronte a uno spinner.

Come costruire un’app veloce

Raramente un’app è lenta per un singolo errore, anche se ovviamente può capitare, in caso di errori madornali. Ma più spesso gli errori si accumulano: un SDK inutile, una chiamata di troppo, schermate che diventano più grandi a ogni rilascio.

Perciò, è bene cercare di prevenire il problema, trattando la performance dell’app come un'abitudine del team anziché un’emergenza su cui intervenire quando fioccano le recensioni negative.

Le buone abitudini che prevengono la lentezza

Alcune buone abitudini possono aiutare a risolvere situazioni spiacevoli prima che si verifichino. 

Ad esempio, è bene testare l’app su dispositivi diversi: un telefono di ultima generazione non performa come un telefono che ha 3 o 5 anni alle spalle. Ma l’utente medio non sempre utilizza dispositivi aggiornati e al top di gamma. 

Va anche introdotta una politica di valutazione degli SDK: ogni libreria ha un costo quando viene avviata e occupa memoria. Ciò che è superfluo e può incidere sui tempi di caricamento va omesso di default, anziché buttar dentro tutto e poi eventualmente fare pulizia a posteriori.

Inoltre, va inserito un monitoraggio a ogni versione: i dati storici consentono di individuare più rapidamente eventuali problemi e se necessario ripristinare versioni precedenti. Inoltre, permettono di scoprire immediatamente un peggioramento nelle performance.

Per facilitarci il lavoro, possiamo anche inserire un controllo nei tempi di avvio direttamente nella checklist di rilascio, assieme ai test: costa pochi minuti, ma intercetta le regressioni prima che se ne accorgano gli utenti.

Progettare per la velocità

Un’app lenta non è una condanna e non richiede quasi mai di ripartire da zero. La difficoltà, però, non è correggere la causa, o più spesso le cause, ma trovarle. Per questo, mettere in piedi un sistema ben strutturato fin da subito consente di evitare i problemi più comuni, ma anche di correggerli più velocemente.

Se la tua applicazione è lenta e non sai da dove iniziare per migliorare le prestazioni, puoi contattarci. Ti aiuteremo a individuare i punti deboli, a correggerli uno alla volta e ad arrivare preparato al prossimo rilascio.