L'ossessione per l'avvio a freddo

L'avvio a freddo è la prima promessa che un'app fa al proprio utente. Se ci vuole più di un secondo prima che diventi utilizzabile, abbiamo già fatto capire a chi la sta utilizzando che si tratta di un'app lenta, indipendentemente dalla velocità con cui funzionerà in seguito.

È anche il momento che gli utenti vivono più spesso. Un’app per monitorare le abitudini viene aperta per pochi secondi per spuntare qualcosa. Un’app per monitorare l’emicrania viene aperta quando qualcuno non si sente bene e vuole registrare rapidamente il disturbo. Per app come queste, l’avvio non è un preludio all’esperienza: è la maggior parte dell’esperienza stessa.

Il nostro obiettivo

Il nostro obiettivo è meno di 600 ms Dal tocco dell’icona all’interfaccia utente interattiva su un iPhone di cinque anni fa. Questo avviene dopo che il sistema operativo ha caricato il file binario, allocato la memoria e ci ha fornito il thread principale. Tutto ciò che accade tra quel passaggio di consegne e il primo fotogramma dipende da noi.

“Interattivo” è la parola chiave. Una schermata iniziale che appare all’istante e poi rimane lì ferma non conta. E nemmeno un primo fotogramma pieno di segnaposto che si riorganizzano un attimo dopo. L’obiettivo è il momento in cui puoi toccare ciò che stavi cercando e questo risponde.

Effettuiamo le misurazioni sul vecchio dispositivo, non su quello nuovo, proprio per lo stesso motivo per cui effettuiamo i test proprio lì: il telefono più recente nasconderebbe praticamente qualsiasi errore.

Cosa impone

Raggiungere quella cifra mette subito fine a molte discussioni. Il networking non può avvenire durante la fase di lancio. Gli SDK di terze parti sono difficili da far accettare: la maggior parte di essi genera attività in background prima che application(_:didFinishLaunching…) restituisce anche i risultati. Le cache delle immagini vengono caricate in modo differito. Le migrazioni del database vengono eseguite in una coda in background, senza mai bloccare quella principale.

Da ciò derivano alcune abitudini. La prima schermata viene generata dai dati già presenti sul dispositivo, quindi l’app mostra immediatamente contenuti reali e si aggiorna in modo discreto se necessario. Le funzionalità non necessarie nella prima schermata non vengono configurate finché qualcuno non le richiede. E ogni volta che siamo tentati di aggiungere una libreria, ci chiediamo innanzitutto quale sia la sua funzione al momento del lancio, prima ancora di chiederci cosa possa fare per noi.

I compromessi

Questa disciplina ha un costo. Rinunciare a un SDK pronto all’uso a volte significa scrivere e mantenere da soli il codice equivalente. Mostrare prima i dati locali significa progettare tenendo conto del caso in cui questi siano leggermente obsoleti. Il caricamento differito richiede un’attenzione particolare per evitare rallentamenti la prima volta che si apre una schermata più pesante. Accettiamo questi costi perché l’alternativa è un piccolo rallentamento ad ogni singolo avvio, per sempre, per tutti.

Cosa abbiamo sbagliato

Il tempo di avvio raramente subisce un cambiamento drastico in un colpo solo. Si deteriora gradualmente: un po’ di codice di configurazione qui, un controllo in più là, ciascuno innocuo di per sé. L’abbiamo imparato a nostre spese, accorcendocene troppo tardi che un’app era diventata più lenta ad aprirsi senza che ci fosse un singolo commit da incolpare. Ora il tempo di avvio viene verificato sul dispositivo di riferimento come parte integrante di ogni release, in modo che eventuali scostamenti vengano individuati quando sono ancora minimi.

Lo stesso principio vale anche per le nostre altre piattaforme. Un'app Windows o un popup di un'estensione del browser hanno una propria versione di "cold start", e vale la stessa regola: mostrare subito qualcosa di utile, rimandando tutto il resto.

Perché ne vale la pena

La disciplina si ripaga da sola. Quando il lancio è veloce, lo è anche tutto il resto — perché le stesse regole valgono ovunque.