Reducción de la latencia en aplicaciones web: una guía rápida para abordar los cuellos de botella adecuados

Si has llegado hasta aquí, probablemente ya sepas qué es la latencia y quieras tomar medidas. Este texto no le hará perder el tiempo definiendo el concepto nuevamente. Es una guía práctica para cualquiera que necesite hacer una aplicación web más rápido y quiera hacerlo en el orden correcto, sin perder semanas en optimizaciones que no mueven la aguja.

La regla que organiza todo lo que sigue es una sola: atacar primero el cuello de botella más grande. Concentrados de latencia. En una aplicación típica, uno o dos pasos representan la mayor parte de la espera. Encontrarlos y resolverlos vale más que decenas de pequeños ajustes repartidos por todas partes.

Pasemos de la parte que suele doler más a la parte que suele doler menos. Adapta el orden a tu realidad, pero sólo después de medir.

##Empieza midiendo, siempre

Saltarse este paso es el error más costoso. Sin medición, estás optimizando en la oscuridad y la posibilidad de equivocarte en el lugar equivocado es alta.

Antes de tocar cualquier código, instrumente la solicitud. Necesita saber cuánto tiempo se dedica al servidor, cuánto a la consulta de datos, cuánto a la red y cuánto a la representación del navegador. [Las herramientas de observabilidad en el backend y las herramientas de desarrollo del navegador brindan una imagen suficiente para comenzar.

Mire también la distribución, no solo el promedio. La latencia de los peores casos, usuarios en el percentil malo, es lo que genera quejas y abandono. Un tiempo medio aceptable puede ocultar una larga cola de personas sufriendo. Optimice con esta cola en mente.

La base de datos suele ser el villano.

En la mayoría de las aplicaciones que se ralentizan con el tiempo, el cuello de botella están en las consultas. Vale la pena empezar aquí.

El sospechoso clásico es la consulta sin un índice adecuado. A medida que la tabla crece, una búsqueda que era instantánea con mil registros se convierte en un fastidio con millones. Identificar consultas lentas y agregar los índices correctos suele ser la mayor optimización de retorno que existe.

El segundo sospechoso es el patrón de muchas consultas en secuencia: la aplicación busca en una lista y, para cada elemento, activa una nueva consulta. Diez artículos incluyeron once viajes al banco; cien elementos se convierten en ciento uno. Resolver esto obteniendo todos los datos a la vez convierte una página lenta en una página rápida sin cambiar nada más.

La tercera es la consulta que trae demasiados datos. Solicitar todas las columnas cuando usas tres, o incorporar miles de filas para mostrar veinte, desperdicia tiempo en cada capa. Pide sólo lo que usarás.

Caché: el atajo más poderoso y peligroso

El caché es la herramienta que más reduce la latencia e introduce los errores más sutiles. Úselo con intención.

La idea es sencilla: guardar el resultado de una operación costosa para no repetirla. Datos que cambian poco y se leen mucho, un catálogo, una configuración, una página pública, son candidatos perfectos. Servir desde la caché elimina la búsqueda en la base de datos y la mayor parte del procesamiento.

El peligro radica en la invalidación: garantizar que la caché se actualice cuando cambien los datos. El caché que sirve información antigua genera problemas difíciles de diagnosticar, porque el sistema "funciona", simplemente está mal. Antes de agregar caché, decida cómo se invalidará. Si no sabes cómo responder eso, aún no estás listo para hacerlo.

Caché en capas

Hay más de un lugar para rizar y se suman. En el navegador se pueden guardar recursos estáticos para que no se vuelvan a descargar. En una CDN, el contenido se puede servir desde un punto físicamente cercano al usuario. En el servidor, los resultados de operaciones costosas pueden permanecer en la memoria. Cada capa corta una parte de la latencia total.

Acorta la distancia y reutiliza las conexiones.

Parte de la latencia es pura física: la distancia entre el usuario y el servidor. No se puede superar la velocidad de la luz, pero sí se puede acortar el camino.

Una CDN coloca copias de su contenido cerca de quien accede a él. Para una audiencia brasileña, servir desde puntos de presencia en el país, en lugar de un servidor distante, reduce el tiempo de viaje que ninguna optimización del código podría recuperar. Para contenido y medios estáticos, es una de las mejores proporciones de esfuerzo para ganar.

Reutilizar las conexiones también ahorra. Abrir una nueva conexión segura cuesta viajes de ida y vuelta a través de la red; Mantener las conexiones activas y utilizar protocolos modernos reduce este costo repetido. Este es un beneficio que aparece especialmente en páginas que realizan muchas solicitudes.

Aliviar el navegador

Incluso con el servidor rápido, la pantalla sólo aparece después de que el navegador procesa la respuesta. Este último apartado merece atención.

Los delincuentes comunes son conocidos. JavaScript excesivo que ralentiza la carga de la página. Imágenes grandes publicadas sin compresión o en el tamaño incorrecto. Funciones que bloquean la pantalla mientras se carga. Reducir y posponer lo que no es imprescindible a la primera pantalla hace que la aplicación parezca rápida incluso cuando aún está terminando de cargar el resto.

La percepción importa tanto como los números. Mostrar contenido útil temprano, aunque sea parcial, hace que el usuario sienta velocidad. Una pantalla en blanco durante dos segundos es peor que una pantalla que muestra la estructura inmediatamente y luego la completa.

Vale la pena aplicar aquí también la misma lógica de proporciones. Antes de reescribir un componente completo en nombre del rendimiento, confirma que la sección que vas a atacar es la que aparece en la primera pantalla. A menudo, la mayor ganancia proviene de posponer la carga de algo secundario, no de reescribir lo principal.

El error de optimizar lo que no hace daño

Vale la pena la advertencia que cierra cualquier guía de desempeño honesta: no optimice lo invisible. Es fácil enamorarse de un código elegante y pasar días ahorrando milisegundos que nadie nota, mientras el verdadero cuello de botella permanece intacto.

Vuelva siempre a la medición. Después de cada optimización, mida nuevamente y confirme que el número que el usuario siente realmente ha mejorado. Si no mejoró, optimizaste algo incorrecto. El desempeño es un juego de proporciones, y la humildad para medir es lo que evita el desperdicio.

Cierre

Reducir la latencia no es magia ni heroísmo técnico. Es un método: medir, encontrar el mayor cuello de botella, solucionarlo, volver a medir. Base de datos, caché, distancia y navegador son los lugares donde más se pierde tiempo, y casi siempre uno de ellos concentra el problema.

La velocidad es una decisión de producto disfrazada de tarea de ingeniería. Los equipos que lo tratan metódicamente entregan aplicaciones que respetan el tiempo del usuario y gastan menos energía apagando problemas de rendimiento más adelante.

Si está en este trabajo ahora, comience con la medición antes que nada. Hay otros artículos aquí en el blog sobre arquitectura, almacenamiento en caché y escalabilidad que profundizan en cada uno de estos puntos.