Cómo optimizar el rendimiento de una app y que escale bien
Una app puede tener un diseño precioso y una idea redonda, pero si tarda cuatro segundos en abrir o se queda pillada al hacer scroll, el usuario la cierra y no vuelve. El rendimiento no es un lujo técnico: es lo que decide si alguien se queda o desinstala. Y lo peor es que casi nunca falla el día del lanzamiento, cuando hay cuatro usuarios de prueba. Falla meses después, cuando el negocio empieza a funcionar y de repente hay miles de personas usándola a la vez.
En este artículo repasamos qué hace lenta a una app de verdad, cómo medir el rendimiento con datos y no a ojo, qué técnicas de optimización dan resultados y, sobre todo, cómo dejar la aplicación preparada para cuando llegue el crecimiento. Sin recetas mágicas: criterio y trabajo constante.
Qué hace lenta a una app (y por qué casi nunca es lo que crees)
Cuando un cliente nos dice que su app va lenta, lo primero que hacemos es no creernos la primera hipótesis. La percepción de lentitud engaña. A veces el móvil del usuario tiene cinco años, a veces la culpa es de una única llamada al servidor que tarda dos segundos, y a veces el problema es una imagen de 4 MB que se carga en una pantalla donde se ve del tamaño de un sello.
Las causas más habituales suelen repartirse en unos pocos frentes. En el arranque, cargar demasiadas cosas antes de mostrar la primera pantalla: inicializar librerías, pedir permisos, leer configuración remota. En la interfaz, listas que renderizan miles de elementos de golpe en lugar de reciclar los que se ven, o animaciones que compiten con el hilo principal. En la red, peticiones que se hacen en serie cuando podrían ir en paralelo, o payloads gigantes con datos que la pantalla ni usa. Y en el backend, la sospechosa habitual: una consulta a base de datos sin índice que con 100 registros vuela y con 100.000 se arrastra.
La lección de fondo es que la lentitud rara vez tiene un único culpable. Es la suma de pequeñas decisiones que, por separado, parecían inofensivas.
Medir antes de tocar nada
Optimizar sin medir es apagar fuegos con los ojos cerrados. Antes de cambiar una línea de código conviene tener números concretos de dónde se va el tiempo. Estas son las métricas que de verdad importan.
Tiempo de arranque
Se distingue entre arranque en frío (la app no estaba en memoria) y en caliente (ya estaba abierta en segundo plano). El objetivo razonable en frío está por debajo de los dos segundos hasta que la pantalla es utilizable. Herramientas como el perfilador de Android Studio o Instruments en iOS te dicen exactamente qué se ejecuta en ese arranque y cuánto tarda cada pieza.
Jank y fluidez
El jank son esos tirones al desplazarse o al abrir una pantalla. Técnicamente ocurre cuando un fotograma tarda más de 16 milisegundos en dibujarse y se rompe la sensación de 60 fps. Los perfiladores gráficos marcan en rojo los fotogramas que se pasan de tiempo, y ahí es donde hay que mirar: normalmente es trabajo pesado ejecutándose en el hilo de la interfaz cuando debería estar en segundo plano.
Consumo de red y batería
Una app que gasta batería o datos como si no hubiera un mañana también se desinstala, aunque vaya rápida. Vale la pena revisar cuántas peticiones lanza en una sesión típica, si repite llamadas idénticas y si mantiene procesos despiertos sin necesidad. El monitor de energía del sistema y los paneles de red del entorno de desarrollo dan una foto bastante clara.
Tiempos de respuesta de la API
Aquí es donde muchas apps ganan o pierden la batalla. Conviene medir el tiempo de respuesta de cada endpoint no con la media, que miente, sino con percentiles: el p95 y el p99 te dicen cómo lo vive el usuario cuando las cosas van regular. Una API con media de 200 ms pero un p99 de tres segundos tiene un problema serio que la media te esconde.
Técnicas de optimización que funcionan
Con los datos delante, se ataca por orden de impacto. No tiene sentido pulir una pantalla que se abre dos veces al mes mientras el home, que ve todo el mundo, va a trompicones.
Caché: no pidas dos veces lo mismo
La petición más rápida es la que no se hace. Cachear respuestas que no cambian a menudo (un catálogo, la configuración, el perfil del usuario) evita viajes al servidor y hace que la app responda al instante. Hay varios niveles: caché en memoria para la sesión, caché en disco para que sobreviva a cerrar la app, y cabeceras HTTP bien configuradas para que sea el propio protocolo quien decida qué revalidar. Eso sí, toda caché necesita una estrategia de invalidación clara, o acabarás mostrando datos viejos.
Carga diferida y bajo demanda
No hace falta cargar la pantalla 20 cuando el usuario está en la 1. El lazy loading consiste en pedir cada cosa justo cuando se necesita: imágenes que se cargan al entrar en el viewport, listas que traen datos por páginas conforme se hace scroll, módulos que se descargan solo si el usuario entra en esa sección. Se arranca ligero y se va sumando peso solo cuando toca.
Imágenes: el peso muerto más fácil de arreglar
Las imágenes suelen ser la mitad del peso de una app y una de las victorias más rápidas. Servir cada imagen en el tamaño real en que se va a ver, usar formatos modernos como WebP o AVIF, comprimir sin que se note y apoyarse en un CDN que sirva la versión adecuada según el dispositivo puede recortar segundos de carga sin tocar una línea de lógica.
Consultas y backend
En el servidor, la mayoría de los problemas de rendimiento se resuelven con índices bien pensados en la base de datos, evitando el clásico problema de las N+1 consultas (pedir una lista y luego una consulta por cada elemento) y paginando todo lo que pueda crecer. Añadir una capa de caché en el backend, con algo como Redis para las respuestas más pedidas, quita presión a la base de datos y aplana los picos.
Perfilado continuo
El perfilado no es algo que se hace una vez y se olvida. Las herramientas de perfilado te muestran, con el código en la mano, dónde se consume CPU, memoria y tiempo. Integrar mediciones de rendimiento en el ciclo normal de trabajo permite cazar una regresión en la semana que se introduce, no seis meses después cuando ya está enquistada y hay que reescribir media pantalla.
Preparar la app para escalar
Que una app vaya rápida con mil usuarios no garantiza que aguante con cien mil. Escalar es otra disciplina, y conviene pensarla antes de que el problema aparezca, porque a las tres de la mañana con la app caída no es momento de improvisar arquitectura.
En el lado del servidor, la clave es el escalado horizontal: poder añadir más máquinas cuando sube la carga en lugar de depender de un único servidor cada vez más grande. Para eso ayuda que el backend sea stateless, que haya un balanceador repartiendo el tráfico y que la base de datos esté preparada con réplicas de lectura para absorber las consultas. Un CDN delante del contenido estático y de las respuestas cacheables quita una barbaridad de trabajo al origen.
También importa el comportamiento bajo estrés. Las pruebas de carga simulan miles de usuarios simultáneos antes de que sean reales y revelan dónde se rompe la cadena: casi siempre en un sitio que nadie había señalado. Y conviene diseñar para degradar con elegancia: si un servicio secundario se satura, que la app siga funcionando en lo esencial en lugar de caerse entera.
Todo esto no se monta y se abandona. El rendimiento se degrada solo con el tiempo: cada función nueva, cada dependencia actualizada y cada usuario extra van erosionando lo que antes iba fino. Por eso tiene sentido tratar la optimización como un proceso vivo, con monitorización, alertas y revisiones periódicas. Si prefieres que ese seguimiento lo lleve un equipo que ya conoce estos problemas, en Tangram Consulting ofrecemos soporte y optimización continua de apps para que la tuya siga rápida a medida que crece.
La velocidad se gana cada día
Optimizar el rendimiento de una app no es una tarea que se marca como hecha y se cierra. Es medir con datos reales, atacar primero lo que más impacta, no pedir dos veces lo que ya tienes, mantener el backend afinado y dejar la arquitectura lista para crecer sin sustos. Las apps que aguantan el crecimiento no son las que nacieron perfectas, sino las que alguien fue cuidando con constancia. Y esa constancia, al final, es lo que marca la diferencia entre una app que la gente usa a diario y una que se queda olvidada en la última pantalla del móvil.