Web Development · · 2 min de lectura
Presupuestos de rendimiento para sitios web — establecer límites antes de construir, no después
Los problemas de rendimiento en sitios web son casi siempre más baratos de prevenir que de corregir. Un presupuesto de rendimiento define los límites antes de que comience el desarrollo y mantiene el sitio rápido a medida que crece.
Por Mediseo
Los problemas de rendimiento en sitios web tienen un origen común: se acumulan gradualmente a lo largo del tiempo. Un sitio que se lanzó con 95/100 en Lighthouse está en 72/100 tres años después. Cada imagen añadida, cada nuevo script de terceros, cada fuente adicional — individualmente inofensivos, colectivamente significativos.
Un presupuesto de rendimiento es un conjunto de límites definidos — para el peso de la página, el tamaño del bundle JavaScript, el recuento de scripts de terceros, los umbrales de Core Web Vitals — que te comprometes a no superar. Previene la degradación gradual antes de que ocurra.
Por qué se degrada el rendimiento
Cada necesidad empresarial que se resuelve añadiendo algo a un sitio web:
- Añadir un chatbot → +200KB de JavaScript
- Añadir una herramienta de A/B testing → +150KB más scripts que bloquean el renderizado
- Añadir un video de fondo → +2MB
- Actualizar la imagen hero sin comprimirla → +800KB
Ninguna de estas decisiones, en aislamiento, parece una decisión de rendimiento. Juntas, convierten un sitio rápido en uno lento.
Sin un presupuesto de rendimiento, no hay mecanismo para que estos trade-offs sean evaluados. El equipo de marketing añade el chatbot porque quiere la funcionalidad de chat; nadie pregunta qué cuesta en tiempo de carga.
Definir tu presupuesto
Un presupuesto de rendimiento debe especificar:
Peso total de página: Para una página de marketing típica, menos de 1MB es bueno, menos de 500KB es excelente. Establece un presupuesto por tipo de página (inicio, páginas de servicio, posts de blog).
Tamaño del bundle JavaScript: La métrica más impactante para la interactividad. Menos de 200KB comprimido es bueno para la mayoría de las páginas.
Largest Contentful Paint: Menos de 2,5 segundos en móvil 4G. Este es el umbral de Core Web Vitals.
Scripts de terceros: Un límite de recuento (ej. no más de 5 scripts de terceros en ninguna página) más una regla de que cualquier nuevo script de terceros requiere revisión y aprobación.
Hacer cumplir el presupuesto en el desarrollo
Los presupuestos de rendimiento solo funcionan si se hacen cumplir durante el desarrollo, no se auditan después del lanzamiento.
Para proyectos Next.js, el paquete bundlewatch comprueba los tamaños de bundle JavaScript frente a umbrales definidos en CI/CD. Los pasos de compilación que superan el presupuesto fallan, forzando una resolución antes del despliegue.
Lighthouse CI puede ejecutar auditorías de rendimiento en cada PR y hacer fallar las compilaciones que caigan por debajo de las puntuaciones definidas.
El desafío organizacional
La parte más difícil de los presupuestos de rendimiento no es técnica — es organizacional. Marketing quiere el chatbot. Ventas quiere el chat en vivo. Nadie hace la conexión a la velocidad del sitio.
Un presupuesto de rendimiento crea un marco para evaluar estas solicitudes frente a una restricción compartida: "Tenemos espacio para un script de terceros más este trimestre. ¿Cuál entrega más valor?" Esto no es una conversación técnica; es una conversación de priorización empresarial que el presupuesto hace posible.
El rendimiento es parte de cómo construimos y cómo pensamos sobre el desarrollo web. Si tu sitio se ha deteriorado y quieres entender qué lo está ralentizando y qué llevaría arreglarlo, reserva una llamada.