La obsesión por el arranque en frío
El inicio en frío es la primera impresión que una aplicación causa en el usuario. Si tarda más de un segundo en estar lista para su uso, ya le hemos dado a entender a la persona que la utiliza que se trata de una aplicación lenta, independientemente de lo rápido que funcione todo lo demás a partir de ese momento.
Además, es el momento que los usuarios viven con más frecuencia. Una aplicación para llevar un seguimiento de hábitos se abre durante unos segundos para marcar algo como completado. Una aplicación para llevar un seguimiento de las migrañas se abre cuando alguien se encuentra mal y quiere registrarlo rápidamente. En el caso de aplicaciones como estas, la apertura no es un preludio de la experiencia, sino que constituye la mayor parte de la misma.
Nuestro objetivo
Nuestro objetivo es menos de 600 ms Desde que se pulsa el icono hasta que aparece la interfaz de usuario interactiva en un iPhone de hace cinco años. Eso ocurre después de que el sistema operativo haya cargado el binario, haya asignado memoria y nos haya cedido el hilo principal. Todo lo que ocurre entre ese traspaso y el primer fotograma depende de nosotros.
“Interactivo” es la palabra clave. Una pantalla de bienvenida que aparece al instante y luego se queda ahí sin más no cuenta. Tampoco cuenta un primer fotograma lleno de marcadores de posición que se reorganizan un momento después. El objetivo es llegar al punto en el que puedas tocar lo que has venido a buscar y esto responda.
Realizamos las mediciones en el dispositivo antiguo, no en el nuevo, por la misma razón por la que hacemos las pruebas allí: el teléfono más nuevo ocultará casi cualquier error.
Lo que obliga
Alcanzar esa cifra pone fin a muchas discusiones desde el principio. No se puede establecer una red de contactos durante la fase de lanzamiento. Los SDK de terceros son difíciles de vender: la mayoría de ellos generan tareas en segundo plano antes de application(_:didFinishLaunching…) devuelve incluso resultados. Las cachés de imágenes se cargan de forma diferida. Las migraciones de la base de datos se ejecutan en una cola en segundo plano, sin bloquear nunca la cola principal.
De ahí se derivan algunos hábitos. La primera pantalla se genera a partir de los datos que ya hay en el dispositivo, por lo que la aplicación muestra algo real de inmediato y se actualiza de forma discreta si hay algo que actualizar. Las funciones que no son necesarias en la primera pantalla no se configuran hasta que alguien las solicita. Y cada vez que nos sentimos tentados a añadir una biblioteca, nos preguntamos qué hace al iniciarse antes de preguntarnos qué nos aporta.
Las ventajas y desventajas
Esta disciplina tiene su precio. Renunciar a un SDK que nos vendría bien a veces implica escribir y mantener nosotros mismos el código equivalente. Mostrar primero los datos locales significa diseñar teniendo en cuenta el caso en el que estén ligeramente desactualizados. La carga diferida requiere un cuidado especial para evitar que la pantalla se cuelgue la primera vez que se abre una página más pesada. Aceptamos esos costes porque la alternativa es un pequeño retraso en cada inicio, para siempre, para todos.
En qué nos equivocamos
El tiempo de inicio rara vez se ve afectado por un único cambio drástico. Se va deteriorando poco a poco: un poco de código de configuración por aquí, una comprobación adicional por allá, cada uno de ellos inofensivo por sí solo. Lo aprendimos por las malas, al darnos cuenta demasiado tarde de que una aplicación tardaba más en abrirse sin que hubiera una única modificación a la que culpar. Ahora, el tiempo de inicio se comprueba en el dispositivo de referencia como parte de cada lanzamiento, de modo que cualquier desviación se detecta cuando aún es mínima.
El mismo principio se aplica a nuestras otras plataformas. Una aplicación Windows o una ventana emergente de una extensión de navegador tiene su propia versión de «arranque en frío», y se aplica la misma regla: mostrar algo útil de inmediato y posponer todo lo demás.
Por qué merece la pena
La disciplina se amortiza por sí sola. Cuando el lanzamiento es rápido, todo lo demás también lo es, porque las mismas reglas se aplican en todas partes.