Presupuestos de rendimiento que funcionan: límites prácticos para aplicaciones web rápidas

Por qué el rendimiento necesita presupuestos, no solo buenas intenciones

Un presupuesto de rendimiento es un conjunto de límites acordados antes de construir. Puede ser un límite de tiempo (qué tan rápida se siente la página), un límite de tamaño (cuánto código envías) o un tope simple (peticiones, imágenes, scripts de terceros). Si superas el límite, se trata como un requisito roto, no como una tarea “bonita de arreglar después”.

La velocidad suele empeorar porque el envío es aditivo. Cada nuevo widget añade JavaScript, CSS, fuentes, imágenes, llamadas a APIs y más trabajo para el navegador. Incluso cambios pequeños se acumulan hasta que la app se siente pesada, especialmente en teléfonos de gama media y redes más lentas, donde está la mayoría de usuarios reales.

Las opiniones no te protegen aquí. Una persona dice “se ve bien en mi portátil”, otra dice “va lento” y el equipo debate. Un presupuesto termina la discusión convirtiendo el rendimiento en una restricción de producto que puedes medir y hacer cumplir.

Aquí encaja el pensamiento de Addy Osmani: trata el rendimiento como restricciones de diseño y reglas de seguridad. No “intentas” mantener la seguridad ni “esperas” que el diseño quede bien. Fijas estándares, los verificas continuamente y bloqueas cambios que los rompen.

Los presupuestos resuelven varios problemas prácticos a la vez. Hacen explícitos los trade‑offs (añadir una característica implica pagar por ella en otro sitio), detectan regresiones temprano (cuando arreglar es más barato) y dan a todos la misma definición de “lo suficientemente rápido”. También reducen el pánico tardío que suele aparecer justo antes del lanzamiento.

Aquí está el escenario para el que se crean los presupuestos: añades una librería de gráficos para un panel. Se envía a todos, aumenta el bundle principal y retrasa la primera pantalla significativa. Sin un presupuesto, esto se cuela porque la característica “funciona”. Con un presupuesto, el equipo debe elegir: lazy‑load el gráfico, reemplazar la librería o simplificar la vista.

Esto importa aún más cuando los equipos pueden generar e iterar apps rápidamente, incluso con flujos de trabajo impulsados por chat como Koder.ai. La velocidad es fantástica, pero también facilita enviar dependencias extra y florituras de UI sin notarlo. Los presupuestos impiden que la iteración rápida se convierta en productos lentos.

Empieza con un objetivo simple: página, dispositivo y red

El trabajo de rendimiento falla cuando mides todo y no te responsabilizas de nada. Elige una ruta de página que importe a usuarios reales y trátala como el ancla para tus presupuestos.

Un buen punto de partida es un recorrido principal donde la velocidad afecta la conversión o el trabajo diario, como “inicio → registro”, “carga inicial del dashboard tras el login” o “checkout y confirmación de pago”. Elige algo representativo y frecuente, no un caso extremo.

Elige un objetivo que coincida con tus usuarios

Tu app no corre en tu portátil. Un presupuesto que funciona en una máquina rápida puede sentirse lento en un teléfono de gama media.

Decide una clase de dispositivo objetivo y un perfil de red para empezar. Manténlo simple y escríbelo como una frase que todos puedan repetir.

Por ejemplo: un teléfono Android de gama media de los últimos 2–3 años, en 4G en movimiento (no Wi‑Fi de oficina), midiendo una carga fría y luego una navegación clave, en la misma región donde está la mayoría de usuarios.

No se trata de elegir el peor caso. Se trata de escoger un caso común que realmente puedas optimizar.

Fija una configuración de prueba base

Los números solo importan si son comparables. Si una ejecución es “Chrome con extensiones en un MacBook” y la siguiente es “móvil con throttling”, tu línea de tendencia es ruido.

Elige un entorno base y apégate a él para las comprobaciones de presupuesto: misma versión del navegador, mismos ajustes de throttling, misma ruta de prueba y mismo estado de caché (frío o caliente). Si usas dispositivos reales, usa el mismo modelo.

Ahora define qué significa “lo suficientemente rápido” en términos de comportamiento, no de demos perfectas. Por ejemplo: “los usuarios pueden empezar a leer contenido rápidamente” o “el dashboard se siente responsive tras el login”. Traduce eso a una o dos métricas para este recorrido y luego fija presupuestos en torno a ellas.

Tipos de presupuesto: tiempo, tamaño, peticiones y tiempo de ejecución

Los presupuestos funcionan mejor cuando cubren tanto lo que los usuarios sienten como lo que los equipos pueden controlar. Un buen conjunto mezcla métricas de experiencia (la parte de “se sintió rápido o no”) con límites de recursos y CPU (la parte de “por qué se puso lento”).

Presupuestos de tiempo (experiencia de usuario)

Estas miden cómo se comporta la página para personas reales. Las más útiles se mapearán directamente a Core Web Vitals:

• LCP (Largest Contentful Paint): qué tan rápido aparece el contenido principal.
• INP (Interaction to Next Paint): qué tan responsiva es la página cuando alguien toca, hace clic o escribe.
• CLS (Cumulative Layout Shift): cuánto se mueve el diseño.

Los presupuestos de tiempo son tu norte porque reflejan la frustración del usuario. Pero no siempre te dicen qué arreglar, así que también necesitas los tipos de presupuesto siguientes.

Presupuestos de tamaño, peticiones y tiempo de ejecución (qué causa lentitud)

Estos son más fáciles de hacer cumplir en builds y revisiones porque son concretos.

Los presupuestos de peso limitan cosas como JavaScript total, CSS total, peso de imágenes y fuentes. Los presupuestos de peticiones limitan el número total de requests y scripts de terceros, reduciendo la sobrecarga de red y el trabajo sorpresa de etiquetas, widgets y trackers. Los presupuestos de tiempo de ejecución limitan long tasks, tiempo en el hilo principal y tiempo de hidratación (especialmente en React), que muchas veces explican por qué una página “se siente” lenta en teléfonos de gama media.

Un ejemplo práctico en React: el tamaño del bundle puede parecer correcto, pero un nuevo carrusel añade renderizado pesado en cliente. La página carga, pero al tocar los filtros todo se siente pegajoso porque la hidratación bloquea el hilo principal. Un presupuesto de tiempo de ejecución como “no hay long tasks por encima de X ms durante el arranque” o “la hidratación completa en Y segundos en un dispositivo de gama media” puede detectar esto incluso cuando los presupuestos de peso pasan.

El enfoque más sólido los trata como un sistema: los presupuestos de experiencia definen el éxito, y los de tamaño, peticiones y tiempo de ejecución mantienen honestos los releases y facilitan responder “¿qué cambió?”.

Presupuestos concretos de inicio que puedes aplicar

Si pones demasiados límites, la gente deja de prestar atención. Escoge de 3 a 5 presupuestos que correspondan a lo que los usuarios más sienten y que puedas medir en cada pull request o release.

Un set práctico inicial (ajusta los números más adelante):

• LCP: advertencia a 2.5s, fallo a 3.0s (móvil, carga fría).
• INP: advertencia a 200ms, fallo a 300ms (interacciones comunes como abrir un menú o enviar un formulario).
• CLS: advertencia a 0.10, fallo a 0.15.
• Tamaño del bundle JS (ruta inicial): advertencia a 170KB gzip, fallo a 220KB gzip (solo código de la app).
• Imágenes (vista inicial): advertencia a 800KB, fallo a 1.2MB (bytes transferidos totales de imágenes cargadas en la primera pantalla).

Dos umbrales mantienen la cosa sensata. “Advertencia” te dice que te estás escapando. “Fallo” bloquea un release o requiere aprobación explícita. Eso hace que el límite sea real sin crear alarmas constantes.

Escribe el presupuesto en un lugar compartido para que nadie lo debata durante un lanzamiento ocupado. Manténlo corto y específico: qué páginas o recorridos cubre, dónde se ejecutan las mediciones (auditoría local, CI, build staged), qué dispositivo y perfil de red usas, y exactamente cómo se definen las métricas (campo vs lab, gzip vs bruto, a nivel de ruta vs toda la app).

Paso a paso: fija presupuestos desde tu app actual

Empieza con una línea base repetible. Elige una o dos páginas clave y pruébalas con el mismo perfil de dispositivo y red cada vez. Ejecuta la prueba al menos tres veces y registra la mediana para que una ejecución rara no marque la dirección.

Usa una hoja base simple que incluya tanto una métrica de usuario como una métrica de build. Por ejemplo: LCP e INP para la página, más JavaScript total y bytes totales de imágenes para el build. Esto hace que los presupuestos se sientan reales porque puedes ver lo que se envió, no solo lo que una prueba de laboratorio estimó.

Fija presupuestos un poco mejores que hoy, no números de fantasía. Una regla sólida es mejorar un 5–10% respecto a tu mediana actual en cada métrica que te importe. Si tu LCP es 3.2s en tu setup base, no saltes a 2.0s. Empieza con 3.0s y aprieta luego cuando demuestres que puedes mantenerlo.

Añade una comprobación rápida a cada release antes de que los usuarios lo vean. Manténla lo suficientemente rápida como para que la gente no la omita. Una versión simple: ejecuta una auditoría de una página en la página acordada, falla el build si JS o imágenes exceden el presupuesto, guarda resultados por commit para ver cuándo cambió algo y siempre prueba la misma URL (sin datos aleatorios).

Revisa las violaciones semanalmente, no solo cuando alguien se queje. Trata una violación como un bug: identifica el cambio que la causó, decide qué arreglar ahora y qué programar. Aprieta lentamente, solo después de mantener la línea varias releases.

Cuando el alcance de producto cambie, actualiza presupuestos deliberadamente. Si añades una nueva herramienta de analítica o una función pesada, anota qué creció (tamaño, peticiones, tiempo de ejecución), qué harás para compensarlo más tarde y cuándo debería volver a la línea.

Auditorías rápidas: una forma veloz de ver qué cambió

Un presupuesto solo ayuda si puedes comprobarlo rápido. El objetivo de una auditoría de 10 minutos no es probar un número perfecto. Es detectar qué cambió desde el último buen build y decidir qué arreglar primero.

Flujo de auditoría de 10 minutos

Empieza con una página representativa del uso real. Luego ejecuta las mismas comprobaciones rápidas cada vez:

• Identifica el elemento LCP (imagen hero, bloque de encabezado, galería de producto). Si el elemento LCP cambió, los resultados variarán.
• Revisa el peso de JavaScript y los chunks más grandes. Busca una dependencia nueva, una librería duplicada o una feature grande enviada a todos.
• Escanea imágenes above‑the‑fold por errores comunes (activos sin comprimir, dimensiones incorrectas, faltan fuentes responsive).
• Revisa etiquetas de terceros (analítica, chat, tests A/B). Una nueva etiqueta puede añadir long tasks y bloquear el hilo principal.
• Observa red y CPU juntos: ¿va lento porque aumentaron los bytes o porque la página hace demasiado trabajo?

Cómo detectar los mayores problemas rápido

Dos vistas suelen darte respuestas en minutos: el waterfall de red y la línea de tiempo del hilo principal.

En el waterfall, busca una petición que domine la ruta crítica: un script gigante, una fuente bloqueante o una imagen que empieza tarde. Si el recurso LCP no se solicita temprano, la página no cumplirá ningún presupuesto de LCP por muy rápido que esté el servidor.

En la timeline, busca long tasks (50 ms o más). Un conjunto de long tasks al inicio suele significar demasiado JavaScript en la primera carga. Un chunk enorme suele ser un problema de routing o un bundle compartido que creció con el tiempo.

Notas que hacen que la siguiente prueba sea comparable

Las auditorías rápidas fallan cuando cada ejecución es diferente. Captura lo básico para que los cambios queden claros: URL y versión del build, dispositivo y perfil de red de la prueba, descripción del elemento LCP, los números clave que rastreas (por ejemplo LCP, bytes JS totales, conteo de peticiones) y una nota corta sobre el mayor culpable.

Las pruebas en escritorio están bien para feedback rápido y checks en PR. Usa un dispositivo real cuando estés cerca del presupuesto, cuando la página se sienta entrecortada o cuando tus usuarios sean mayoritariamente móviles. Las CPUs móviles hacen los long tasks evidentes, y ahí es donde muchas versiones “funciona en mi portátil” se rompen.

Qué arreglar primero: reglas simples que ahorran tiempo

Cuando un presupuesto falla, lo peor es “optimizar todo”. Usa un orden de triaje repetible para que cada arreglo tenga un retorno claro.

Un orden práctico de triaje

Empieza por lo que más notan los usuarios y luego afina:

• Haz rápido el elemento principal above‑the‑fold. Encuentra qué pinta como el contenido más grande y arregla ese activo o la ruta de renderizado primero. Redimensiona y comprime imágenes, usa el formato adecuado y evita fuentes que se carguen tarde y bloqueen la primera vista.
• Reduce JavaScript antes de pulir CSS. Si la página envía demasiado JS, todo lo demás sufre: parseo más lento, mayor trabajo en el hilo principal y render tardío. Elimina código no usado, divide rutas pesadas y prefiere renderizado en servidor o contenido estático para UI simple.
• Domina scripts de terceros pronto. Widgets de chat, analítica, gestores de etiquetas y herramientas A/B pueden añadir descargas grandes y long tasks. Si no se necesitan en la primera vista, retrásalos. Si aportan poco valor, elimínalos.
• Evita los layout shifts por diseño. Reserva espacio para imágenes, anuncios y embeds. Define width/height, usa placeholders estables y evita inyectar UI encima del contenido existente después de la carga.
• Si la interacción va lenta, elimina long tasks. Cuando INP es malo, busca trabajo cliente pesado: renders grandes, actualizaciones de estado costosas y mucho procesamiento de JSON. Divide el trabajo en trozos más pequeños, reduce rerenders y mueve trabajo no‑UI fuera de la ruta crítica.

Un ejemplo rápido

Un equipo lanza un nuevo dashboard y de repente no cumple el presupuesto de LCP. En lugar de tocar cabeceras de caché primero, encuentran que el elemento LCP es una imagen de gráfico a todo ancho. La redimensionan, la sirven en un formato más ligero y cargan solo lo que importa al inicio. Luego detectan que una librería de gráficos grande se carga en todas las rutas. La cargan solo en la página de analítica y retrasan un widget de soporte de terceros hasta después de la primera interacción. En un día, el dashboard vuelve a entrar en presupuesto y el siguiente release tiene respuestas claras de “qué cambió”.

Errores comunes que cometen los equipos con presupuestos

El mayor modo de fallo es tratar los presupuestos como un documento de una sola vez. Los presupuestos funcionan solo cuando son fáciles de comprobar, difíciles de ignorar y están ligados a cómo envías cambios.

Errores que hacen fracasar los presupuestos

La mayoría de equipos se atascan en unos pocos patrones:

• Poner demasiados presupuestos el primer día, o tan estrictos que todos los builds fallen.
• Medir con ajustes diferentes cada vez (dispositivo, throttling, estado de caché, página de prueba).
• Perseguir puntuaciones de laboratorio mientras se ignora el dolor real del usuario.
• Dejar que una gran dependencia entre sin que se note.
• Tratar el rendimiento como un proyecto que se termina en lugar de una regla de release.

Un patrón común es una “pequeña” característica que introduce una librería nueva. El bundle crece, LCP se retrasa un segundo en redes lentas y nadie lo nota hasta que llegan tickets de soporte. Los presupuestos existen para hacer ese cambio visible en la revisión.

Cómo evitarlos

Empieza simple y mantén las comprobaciones consistentes. Elige 2–4 presupuestos que se mapeen a la experiencia del usuario y apriétalos gradualmente. Bloquea tu setup de prueba y escríbelo. Rastrea al menos una señal de usuario real si puedes y usa pruebas de laboratorio para explicar el “por qué”, no para ganar discusiones. Cuando una dependencia añade peso significativo, exige una nota breve: cuánto cuesta, qué reemplaza y por qué merece la pena. Lo más importante: pon la comprobación de presupuesto en el camino normal de release.

Si los presupuestos parecen fricción constante, normalmente son irreales para hoy o no están ligados a decisiones reales. Arregla primero esas dos cosas.

Ejemplo: convertir una app lenta en un proceso de release con presupuestos

Un equipo pequeño lanzó un dashboard de React en una semana. Al principio parecía rápido, pero cada release del viernes lo hacía algo más pesado. Tras un mes, los usuarios empezaron a decir que la primera pantalla “se queda colgada” y los filtros responden con lag.

Dejaron de discutir sobre “lo suficientemente rápido” y escribieron presupuestos ligados a lo que los usuarios notan:

• LCP: 2.5s en un teléfono de gama media en 4G
• INP: menos de 200ms para acciones comunes (abrir menú, aplicar filtro)
• JavaScript: 250KB gzip para la ruta inicial, con un tope claro por nueva funcionalidad
• Imágenes: no hay hero images sin comprimir y tamaño máximo por componente

La primera falla apareció en dos sitios. El bundle inicial creció con charts, librerías de fecha y un kit UI. Al mismo tiempo, la imagen de cabecera del dashboard se cambió por un archivo más grande “temporalmente”, empujando LCP fuera del límite. INP empeoró porque cada cambio de filtro disparaba rerenders pesados y cálculos caros en el hilo principal.

Lo arreglaron en un orden que produjo victorias rápidas y evitó regresiones repetidas:

1. Bajar LCP redimensionando y comprimiendo imágenes, fijando dimensiones explícitas y evitando cargas de fuentes que bloqueen.
2. Reducir JS inicial eliminando librerías no usadas, dividiendo rutas no críticas y cargando charts de forma lazy.
3. Mejorar INP memoizando componentes caros, haciendo debounce en filtros de escritura y moviendo trabajo pesado fuera de la ruta caliente.
4. Añadir una comprobación de presupuesto en cada release para que si una métrica falla, el lanzamiento espere.

Tras dos releases, LCP bajó de 3.4s a 2.3s y la INP mejoró de ~350ms a menos de 180ms en el mismo dispositivo de prueba.

Lista de verificación y siguientes pasos (incluyendo un flujo ligero con Koder.ai)

Un presupuesto solo ayuda si la gente puede seguirlo siempre igual. Manténlo pequeño, escríbelo y hazlo parte del envío.

Elige un puñado de métricas que encajen con tu app, fija umbrales de “advertencia vs fallo” y documenta exactamente cómo pruebas (dispositivo, navegador, red, página/flujo). Guarda un informe base del mejor release actual y etiquétalo claramente. Decide qué cuenta como excepción válida y qué no.

Antes de cada release, ejecuta la misma auditoría y compárala con la base. Si algo regresa, regístralo donde rastreas bugs y trátalo como un paso de checkout roto, no como una tarea “para después”. Si envías con una excepción, registra un responsable y una fecha de caducidad (habitualmente 1–2 sprints). Si la excepción se renueva continuamente, el presupuesto necesita una discusión real.

Mueve los presupuestos más temprano en la planificación y estimaciones: “esta pantalla añade una librería de charts, así que tenemos que eliminar otra cosa o cargarla de forma lazy”. Si construyes con Koder.ai (koder.ai), también puedes escribir estas restricciones desde el principio en Planning Mode, iterar en slices más pequeños y usar snapshots y rollback cuando un cambio te pase del tope. El punto no es la herramienta, es el hábito: cada nueva característica debe pagar por su peso o no se envía.