Presupuestos de Rendimiento para Sitios con Medios Sintéticos: El Framework que Usamos en Mintec

Un sitio con video generado por IA, imágenes sintéticas y audio generativo no puede tratarse como un sitio normal a la hora de definir límites de rendimiento. Los presupuestos tradicionales — "máximo 300KB de JS", "LCP por debajo de 2.5s" — asumen un ecosistema de activos predecible. Los medios sintéticos son todo menos predecibles.

En los últimos doce meses hemos trabajado con tres clientes que integraban medios generados por IA como parte central de su propuesta de valor: un portal educativo con video-lecciones sintéticas, una tienda de retail con catálogos generados por IA, y una plataforma inmobiliaria con tours virtuales generativos. En cada uno, los presupuestos de rendimiento estándar fallaron en las primeras semanas.

Tuvimos que construir uno nuevo. Este es el framework.

Por Qué los Presupuestos Estándar No Funcionan

El problema no es la teoría de los presupuestos de rendimiento — esa está bien establecida desde que Tim Kadlec popularizó el concepto en 2017 y Google lo integró en Lighthouse CI. El problema es que los supuestos detrás de los budgets tradicionales no contemplan tres realidades de los medios sintéticos:

Tamaño variable. Una imagen generada por Stable Diffusion puede pesar 800KB o 2.3MB dependiendo del prompt, el sampler y el número de pasos. Dos prompts visualmente similares pueden producir archivos de pesos drásticamente diferentes. No es como JPEG comprimido al 80%, donde el peso es predecible.

Falta de metadatos de optimización. Las APIs de generación (OpenAI, Stability AI, Runway) devuelven PNG por defecto. Sin metadatos de compresión, sin thumbnails progresivos, sin perfiles de color optimizados. El activo llega al frontend en su forma más pesada.

Inserción dinámica impredecible. El medio sintético no siempre existe en el momento del build. Se genera bajo demanda, se inserta en el DOM sin control de layout, y puede disparar reflows que el equipo de frontend no anticipó.

Ya habíamos explorado antes cómo el costo real del rich media en 2026 afecta Core Web Vitals. Este artículo va un paso más allá: no es solo optimizar, es presupuestar proactivamente.

Las Cuatro Dimensiones del Framework

Después de iterar en esos tres proyectos, consolidamos un sistema de presupuestos organizado en cuatro dimensiones. Cada dimensión tiene métricas, thresholds, y métodos de enforcement distintos.

1. Presupuesto de Peso Entregado (Por Página)

La diferencia no es arbitraria. Si el sitio usa medios sintéticos, el LCP casi siempre será un poster de video o una imagen generada por IA. Ese activo compite directamente con el resto de la página. Reducir el presupuesto de JS y fuentes libera el hilo principal para procesar el medio.

Usamos Webpack/Rollup bundle analysis + el budget.json de Lighthouse CI para alertar cuando un nuevo componente supera el límite. En uno de los proyectos, un developer agregó una librería de gráficos de 85KB "por si acaso". El CI lo bloqueó.

2. Presupuesto de Red

Los medios sintéticos no solo pesan más — también generan más requests. Cada generación bajo demanda puede disparar una llamada API, una descarga deCDN, y una transformación.

El discovery más importante que hicimos: usar <link rel="preconnect"> con los dominios de generación de IA reduce el tiempo de conexión inicial en 200-400ms. Suena obvio, pero ningún generador de medio sintético lo documenta.

3. Presupuesto de Interactividad (INP)

Aquí es donde los medios sintéticos golpean más fuerte. El artículo de nuestro equipo sobre INP a 200ms explica por qué esta métrica es crítica. Para sitios con medios sintéticos, los thresholds deben ser más estrictos:

• INP target: ≤ 150ms (vs. 200ms estándar)
• Long tasks: 0 tasks de más de 50ms en el critical path
• Tiempo de procesamiento del reproductor de video: ≤ 80ms desde interacción hasta paint
• Tiempo de inserción DOM de medio sintético: ≤ 30ms

La razón: el reproductor de video sintético (ya sea un iframe de tercera parte o un <video> nativo con controladores personalizados) añade latencia de procesamiento. Si el INP base del sitio ya está en 150ms, el reproductor lo empuja sobre 200ms.

Solución que implementamos en el proyecto educativo: pre-hidratar el reproductor de video en un requestIdleCallback después de la carga inicial, y solo mostrar el poster estático hasta que el usuario haga scroll. El INP pasó de 210ms a 165ms.

4. Presupuesto de Estabilidad Visual (CLS)

Los medios sintéticos insertados dinámicamente son una causa frecuente de Cumulative Layout Shift. La imagen generada por IA que no tiene dimensiones explícitas. El video que se inserta después de que el layout ya se pintó.

La regla es simple: todo medio sintético debe tener dimensiones explícitas en el HTML. No en CSS, no en JS — en el HTML. <img width="1200" height="675" src="...">. Para video: <video width="1200" height="675" poster="...">. Esto elimina el 90% de los shifts causados por medios dinámicos.

Cómo Implementamos Esto en el Pipeline

El framework no sirve de nada si no se enforcea automáticamente. Este es el pipeline que corre en cada PR de los proyectos con medios sintéticos:

1. Build-time: Lighthouse CI ejecuta auditoría con budgets.json personalizado. Si el JS total supera 180KB, el build falla.
2. Asset-level: Un script de CI descarga cada nuevo activo sintético y verifica: peso < budget por tipo, dimensiones explícitas presentes, formato convertido a AVIF/WebP.
3. Production: WebPageTest monitorea las URLs críticas cada hora. Si INP supera 150ms en el percentil 75, genera alerta.
4. Weekly review: Revisamos los budgets contra datos de CrUX. Si el sitio consistentemente está por debajo de los thresholds, ajustamos los budgets — no los relajamos, los reasignamos a otras dimensiones.

En el proyecto inmobiliario, este pipeline detectó un problema en el segundo día: un tour virtual generativo estaba insertando un canvas de WebGL sin declarar dimensiones, causando un CLS de 0.15. El CI lo bloqueó antes de llegar a producción.

No es un Documento Estático

El error más común que vemos es tratar el presupuesto de rendimiento como un checklist que se define en el kickoff y se revisa seis meses después. Con medios sintéticos, eso no funciona. El tamaño de los activos cambia con cada versión del modelo de IA. La latencia de las APIs de generación fluctúa. Los formatos evolucionan.

Nuestro approach: los budgets son parámetros vivos. Se revisan cada sprint. Se ajustan cuando la evidencia lo justifica. Pero nunca se relajan sin datos que demuestren que el sitio puede soportar el cambio.

Para equipos que están empezando con medios sintéticos, recomendamos empezar con el presupuesto de peso entregado como primera barrera. Es la más fácil de medir, la más fácil de automatizar, y la que tiene el mayor impacto en las otras tres dimensiones. Una vez que el peso está controlado, la interactividad y la estabilidad visual se vuelven problemas manejables.

Si quieres profundizar en cómo estructuramos el modelo de contenido para medios de video, tenemos una guía sobre arquitectura de contenido video-first en headless CMS que complementa este framework. Y si el tuyo es un proyecto con catálogos visuales generados por IA, nuestro análisis de video sintético a escala cubre el lado de producción que alimenta estos presupuestos.