Desempeño móvil en Lyft

Este artículo fue publicado originalmente el 28 de octubre de 2021 en eng.lyft.com.

En el segundo trimestre del 2021 Lyft atendió a 17.1 millones de pasajeros activos a través de nuestros servicios de aplicaciones móviles. A esta escala, cada fallo, cuadro congelado, o desliz pueden convertirse en miles de horas de tiempo perdido y de frustración. Dado el potencial de impactar a millones de usuarios de Lyft, duplicamos nuestros esfuerzos en 2020 para mejorar la velocidad y estabilidad de nuestras aplicaciones con el lanzamiento de una iniciativa de desempeño móvil interna.

Esta es la primera de una serie de historias que detallan el camino para mejorar significativamente la velocidad y estabilidad de nuestras aplicaciones. Esperamos que esto pueda ser usado como referencia e inspiración por otras compañías para su propio desarrollo en este ámbito.

En este post exploraremos cómo y por qué empezamos a invertir en rendimiento móvil en Lyft y profundizaremos en la filosofía del equipo — desde cómo seleccionamos proyectos hasta cómo evaluamos el éxito.

Definiendo el desempeño

El desempeño en el contexto de desarrollo de software ha sido históricamente referido a la velocidad de la experiencia de una aplicación (por ejemplo, el arranque de una aplicación y la “fluidez” general de la experiencia). En Lyft vemos la inversión en desempeño como un esfuerzo para eliminar las desviaciones en funcionalidad y latencia.

Desempeño Móvil = Velocidad (arranque, fluidez de la experiencia) + Estabilidad (proporción de errores, bugs, etc.)

Primeros días

Antes de lanzar nuestra iniciativa de desempeño en el Q1 del 2020, el equipo de producto usaba, principalmente, una aplicación de métricas de fallo para medir el desempeño. Capturamos los errores en la aplicación del cliente y se los proporcionamos al flujo de analítica. Si la proporción de errores supera un margen, se dispara una alarma y los desarrolladores de funcionalidades pueden usar los reportes de fallo para adentrarse en los detalles del error por medio de Bugsnag.

Este es quizá el proceso más común en compañías de tecnologías móviles para evaluar el desempeño, pero ¿habrá más al respecto? ¿Existirán algunas otras métricas de desempeño que deberíamos usar además de los errores? ¿La razón de los errores que rastreamos es verdaderamente acertada? ¿Cómo es que nuestras apps se comparan con el resto de la industria de tecnología móvil? En aquel momento, no teníamos las herramientas ni la tecnología necesaria para responder estas respuestas básicas de desempeño. En Lyft incrementamos nuestra plantilla a más de 150 ingenierxs móviles, pues se volvió muy importante preocuparnos acerca de los detalles del desempeño.

Dando el primer paso

Una inversión profunda en desempeño puede ser difícil de priorizar debido a varias razones:

• Correlacionar el desempeño con una métrica central del negocio puede ser retador.
• Hay muchas otras áreas de inversión que tienden a tomar precedente, incluyendo cambios en producto y funcionalidades, arquitectura, experimentación, observabilidad, etc.
• Las inversiones en desempeño suelen necesitar un conocimiento profundo y extensas investigaciones, que a su vez requieren un costo de entrada alto con resultados postergados.

Muchas veces, la parte más dura de un camino es el primer paso, y decidimos probar el valor de una inversión continua en el desempeño móvil al encontrar un problema, solucionarlo y mostrando el valor de esa solución.

Delimitando el proyecto

Afortunadamente, durante el desarrollo de un proyecto no relacionado al desempeño, habíamos identificado una pantalla en particular que creíamos que estaba causando un aumento drástico en el tiempo de interacción (Time-To-Interact, TTI por sus siglas en inglés) de la aplicación de los conductores de Lyft. Usamos este entendimiento para proponer un proyecto de desempeño que optimizaría esta pantalla con el objetivo de mejorar el TTI de nuestra aplicación.

Si bien las aplicaciones de Android y iOS de Lyft se podían beneficiar de la optimización identificada, decidimos enfocarnos primero en Android. Después, si los resultados se vieran prometedores, trabajaríamos en esa misma optimización para la aplicación de iOS.

Propuesta

Llevamos a cabo una investigación inicial para entender la importancia del TTI en las aplicaciones móviles. Sintetizamos nuestra investigación en las siguientes categorías:

• Es una mejor experiencia de usuario para nuestros clientes: el TTI es tan importante que Google y Apple han dedicado recursos de documentación extensivos referentes a cómo mejorar el tiempo de arranque de una aplicación y por qué hace una diferencia.
• Una correlación positiva entre bajos tiempos de arranque y métricas de negocio: hay una razón por la que muchas compañías se enfocan en mejorar el tiempo de arranque de las aplicaciones: tiene impacto en las métricas de negocio. Tanto que muchas empresas han detallado públicamente sus acercamientos a estas mejoras: Facebook, LinkedIn, Redfin, NYTimes.
• El tiempo de arranque es un factor que Google utiliza para clasificar a las aplicaciones en la búsqueda de la app store: las métricas de desempeño de Android Vitals son utilizadas para la clasificación dentro de las búsquedas de Google Play. Si queremos ser líderes en la app store, necesitamos ser líderes en desempeño.

Utilizamos Google Play Console para entender que en comparación con nuestro grupo de colegas en Play Console (10 apps), somos cerca de un 15–20% más lentos en el tiempo de arranque de la aplicación, según la define Google. Combinamos la idea del proyecto con esta justificación para desarrollar una propuesta y presentarla a los líderes. Ésta fue lo suficientemente convincente para lograr un consenso que nos dio luz verde para actuar.

Creación y Lanzamiento

Cuando una aplicación móvil es lanzada, hay varias fases que ocurren para prepararse para la interacción del usuario. Empezamos por perfilar cada fase del lanzamiento de la app en un esfuerzo para entender dónde estaban las áreas de oportunidad más grandes. Abajo se muestran las fases, además de algunos datos iniciales obtenidos por medio de un perfilamiento local:

1. Aplicación: empezar el proceso de la aplicación
2. Actividad: comenzar la renderización de UI de la aplicación
3. Arranque: iniciar la aplicación con peticiones a la red y con los datos necesarios para mostrar la pantalla inicial
4. Mostrar la pantalla inicial: enseñar la pantalla principal para que los conductores puedan operar

Fases del arranque de la aplicación de conductores Lyft Driver

Los resultados verificaron nuestra hipótesis de que el arranque de esta pantalla en particular representaba la mayor parte del tiempo del inicio de la app. En contexto, la pantalla de arranque se usa como un contenedor para que ingeniería inicie las peticiones a la red y que obtenga los datos necesarios para cargar la aplicación. Desde una perspectiva de usuario, los conductores sólo esperan en una pantalla que muestra el logo de Lyft.

Fuimos capaces de identificar varios acercamientos diferentes para optimizar la pantalla de carga.

1. Reducir el número de llamadas a la red durante el arranque crítico: después de desintegrar nuestros servicios de backend en 2019, algunas de las llamadas a la red ya no eran necesarias, así que las eliminamos.
2. Ejecutar las llamadas a la red de forma asíncrona siempre que sea posible: si algunos de los datos eran requeridos para que la app funcionara, pero no eran necesarios durante el lanzamiento, estas llamadas fueron hechas no bloqueantes, para que el arranque pudiera continuar sin ellas. Por ejemplo, la llamada a la red que revisaba si el usuario activó la funcionalidad Shortcut se convirtió, de manera segura, en una llamada que no bloquea el arranque y continúa en segundo plano.
3. Almacenar datos entre sesiones: algunos de los datos eran necesarios para que la aplicación iniciara, pero no cambian con el tiempo. Empezamos a almacenar estos datos en caché entre las sesiones, reduciendo aún más el TTI. Por ejemplo, dependiendo de si el conductor ha iniciado o no la aplicación, la app Lyft Driver muestra diferentes páginas iniciales después del lanzamiento de la aplicación. Una vez que el conductor la ha iniciado, el valor no cambiaría para ese conductor. Por ende, podemos guardar esos datos en caché hasta que el conductor cierre sesión.

Estimamos que estas mejoras simples mejoraron el TTI para la gran mayoría de los conductores. Con la información detallada arriba, esperábamos reducir el TTI en un 50% en muchos casos. Después de estimar el tamaño y la viabilidad de la oportunidad, hicimos los cambios.

Antes de lanzar la optimización para todos los conductores, queríamos cuantificar las mejoras. Hicimos el cambio detrás de un experimento A/B e introdujimos una nueva métrica TTI en nuestro framework de pruebas A/B para poder analizar los resultados.

Resultados

Los resultados del experimento en Android demostraron una reducción promedio del 21% (3.7s) en el TTI de la app al arranque, con un incremento del 5% en las sesiones de conductores. El mismo experimento ejecutado posteriormente en iOS mostró una reducción aún más drástica del 42.2% (3.2s). Un GIF del antes y después puede verse arriba. Después compartimos estos resultados con los líderes, junto con una propuesta para una inversión continua, lo cual produjo suficiente ímpetu para crear un flujo de trabajo dedicado al desempeño móvil.

Aprendizajes

• Escoge el proyecto con mayor campo de acción: entregar resultados significativos en un flujo de trabajo nuevo es de vital importancia para lograr un consenso que consiga inversiones futuras, así que asegúrate de que el proyecto se intersecte en el punto de mayor impacto con el menor esfuerzo.
• Comunícate temprano y con frecuencia: las iniciativas en etapas iniciales no son tan conocidas a través de la compañía como aquellas que están más establecidas. Una comunicación consistente de los objetivos, planes, experimentos y resultados es clave para conseguir el apoyo de los líderes. También encontramos que es beneficioso invertir tiempo en educar al equipo de producto, a los líderes y al resto de la organización en el problema y cómo se está abordando, debido a que gran parte del trabajo es altamente técnico.

Lo que sigue

Escogimos mejorar el TTI porque sabíamos que era el proyecto más accionable que podría producir resultados significativos y el que ofrecía la justificación más convincente para inversiones futuras, pero eso sólo fue el comienzo. En nuestro siguiente post de esta serie, detallaremos la siguiente fase de la iniciativa de desempeño móvil: enfrentando problemas de estabilidad.

Si te interesa trabajar en problemas de desempeño en Lyft, ¡estamos contratando!