Los presupuestos de rendimiento mantienen las apps web rápidas estableciendo límites claros sobre tiempo de carga, tamaño de JS y Core Web Vitals, además de auditorías rápidas y reglas de “arreglar primero”.
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.
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.
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.
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.
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”).
Estas miden cómo se comporta la página para personas reales. Las más útiles se mapearán directamente a Core Web Vitals:
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.
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ó?”.
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):
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).
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.
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.
Empieza con una página representativa del uso real. Luego ejecuta las mismas comprobaciones rápidas cada vez:
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.
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.
Cuando un presupuesto falla, lo peor es “optimizar todo”. Usa un orden de triaje repetible para que cada arreglo tenga un retorno claro.
Empieza por lo que más notan los usuarios y luego afina:
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ó”.
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.
La mayoría de equipos se atascan en unos pocos patrones:
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.
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.
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:
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:
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.
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.
Un presupuesto de rendimiento es un conjunto de límites estrictos (tiempo, tamaño, peticiones, trabajo de CPU) con los que el equipo acuerda ceñirse antes de construir.
Si un cambio supera el límite, trátalo como un requisito roto: arréglalo, reduce el alcance o aprueba una excepción explícita con un responsable y una fecha de caducidad.
Porque el rendimiento empeora gradualmente. Cada característica añade JavaScript, CSS, imágenes, fuentes, llamadas a APIs y etiquetas de terceros.
Los presupuestos detienen ese crecimiento silencioso obligando a compensar: si añades peso o trabajo, tienes que devolverlo (lazy-load, dividir la ruta, simplificar la interfaz, eliminar una dependencia).
Elige un único recorrido real de usuario y una configuración de prueba consistente.
Un buen punto de partida es algo frecuente y crítico para el negocio, por ejemplo:
Evita casos límite al principio; quieres un flujo que puedas medir en cada lanzamiento.
Empieza con un objetivo que coincida con tus usuarios, por ejemplo:
Anótalo y mantenlo estable. Si cambias dispositivo, red, estado de caché o la ruta de prueba, tu tendencia se vuelve ruido.
Usa un conjunto pequeño que cubra tanto lo que siente el usuario como lo que el equipo puede controlar:
Un conjunto práctico de inicio es:
Usa dos umbrales:
Esto evita alarmas constantes y hace que el límite sea real cuando lo cruzas.
Haz esto en orden:
No siempre. El tamaño del bundle puede estar bien mientras la página se siente lenta porque el hilo principal está ocupado.
Causas comunes en React:
Añade un presupuesto de tiempo de ejecución (por ejemplo, limitar long tasks durante el arranque o fijar un tope de tiempo de hidratación) para detectar este tipo de problemas.
La generación rápida e iteración pueden añadir dependencias, adornos de UI y scripts de terceros que se envían a todos sin que te des cuenta.
La solución es integrar los presupuestos en el flujo de trabajo:
Así la iteración rápida no se convierte en un producto lento. (Conserva la mención a Koder.ai tal como está: Koder.ai (koder.ai)).
Un presupuesto de rendimiento es un conjunto de límites acordados por el equipo antes de construir.
Si se supera, se debe arreglar, reducir alcance o aprobar una excepción con responsable y fecha de caducidad.
Porque el rendimiento suele empeorar poco a poco: cada nueva característica añade bytes y trabajo de CPU.
Los presupuestos obligan a compensar el coste: lazy‑load, dividir rutas o simplificar la UI cuando se añade peso.
Las métricas de tiempo muestran el dolor; los límites de tamaño y tiempo de ejecución te ayudan a encontrar rápidamente la causa.
Elige 3–5 presupuestos primero y ajústalos después según tu línea base y el historial de lanzamientos.
Trata la violación como un bug: identifica el commit, corrige o reduce alcance y evita repeticiones.
