Performance Budgets for Synthetic Media Sites: The Framework We Use at Mintec

A site running AI-generated video, synthetic images, and generative audio cannot be treated like a normal site when defining performance limits. Traditional budgets — "max 300KB of JS", "LCP under 2.5s" — assume a predictable asset ecosystem. Synthetic media is anything but predictable.

Over the last twelve months we worked with three clients whose value proposition centered on AI-generated media: an educational portal with synthetic video lessons, a retail store with AI-generated catalogs, and a real estate platform with generative virtual tours. In every single one, the standard performance budgets failed within the first few weeks.

We had to build a new one. Here is the framework.

Why Standard Budgets Don't Work

The problem is not the theory of performance budgets — that has been well established since Tim Kadlec popularized the concept in 2017, and Google baked it into Lighthouse CI. The problem is that the assumptions behind traditional budgets do not account for three realities of synthetic media:

Variable asset size. An image generated by Stable Diffusion can weigh 800KB or 2.3MB depending on the prompt, the sampler, and the number of steps. Two visually similar prompts can produce drastically different file weights. This is not JPEG compressed at 80%, where the weight is predictable.

No optimization metadata. Generation APIs (OpenAI, Stability AI, Runway) return PNG by default. No compression metadata, no progressive thumbnails, no optimized color profiles. The asset arrives at the frontend in its heaviest possible form.

Unpredictable dynamic insertion. Synthetic media does not always exist at build time. It gets generated on demand, inserted into the DOM without layout control, and can trigger reflows the frontend team never anticipated.

We previously covered how the real cost of rich media in 2026 affects Core Web Vitals. This article goes one step further: not just optimizing, but proactively budgeting.

The Four Dimensions of the Framework

After iterating through those three projects, we consolidated a budget system organized around four dimensions. Each dimension has its own metrics, thresholds, and enforcement methods.

1. Delivered Weight Budget (Per Page)

The difference is not arbitrary. On a synthetic media site, LCP is almost always a video poster or an AI-generated image. That asset competes directly with the rest of the page. Reducing the JS and font budget frees the main thread to process the media.

We use Webpack/Rollup bundle analysis plus Lighthouse CI's budget.json to alert when a new component exceeds the limit. On one project, a developer added an 85KB charting library "just in case." The CI blocked it.

2. Network Budget

Synthetic media is not only heavier — it generates more requests. Each on-demand generation can trigger an API call, a CDN download, and a transform step.

The single most impactful discovery: using <link rel="preconnect"> for AI generation domains reduces initial connection time by 200-400ms. Sounds obvious, but no synthetic media generator documents it.

3. Interactivity Budget (INP)

This is where synthetic media hits hardest. Our team's deep dive on INP at 200ms explains why this metric is critical. For synthetic media sites, thresholds must be tighter:

• INP target: ≤ 150ms (vs. 200ms standard)
• Long tasks: 0 tasks over 50ms on the critical path
• Video player processing time: ≤ 80ms from interaction to paint
• Synthetic media DOM insertion time: ≤ 30ms

The reason: the synthetic video player (whether a third-party iframe or native <video> with custom controls) adds processing latency. If the baseline INP is already at 150ms, the player pushes it over 200ms.

The fix we implemented on the educational project: pre-hydrate the video player in a requestIdleCallback after initial load, showing only the static poster until the user scrolls. INP dropped from 210ms to 165ms.

4. Visual Stability Budget (CLS)

Dynamically inserted synthetic media is a frequent cause of Cumulative Layout Shift. The AI-generated image without explicit dimensions. The video inserted after layout has already painted.

The rule is simple: every synthetic media element must have explicit dimensions in the HTML. Not in CSS, not in JS — in the HTML. <img width="1200" height="675" src="...">. For video: <video width="1200" height="675" poster="...">. This eliminates 90% of shifts caused by dynamic media.

How We Enforce This in the Pipeline

A framework is useless without automated enforcement. Here is the pipeline running on every PR for synthetic media projects:

1. Build-time: Lighthouse CI runs with a custom budget.json. If total JS exceeds 180KB, the build fails.
2. Asset-level: A CI script downloads each new synthetic asset and verifies: weight < type-specific budget, explicit dimensions present, format converted to AVIF/WebP.
3. Production: WebPageTest monitors critical URLs hourly. If INP exceeds 150ms at the 75th percentile, it fires an alert.
4. Weekly review: We reconcile budgets against CrUX data. If the site consistently stays under thresholds, we adjust budgets — not by relaxing them, but by reallocating to other dimensions.

On the real estate project, this pipeline caught a problem on day two: a generative virtual tour was inserting a WebGL canvas without declared dimensions, causing a CLS of 0.15. The CI blocked it before it reached production.

Not a Static Document

The most common mistake we see is treating the performance budget as a checklist defined at kickoff and reviewed six months later. With synthetic media, that does not work. Asset sizes change with every model version. Generation API latency fluctuates. Formats evolve.

Our approach: budgets are living parameters. Reviewed every sprint. Adjusted when evidence justifies it. But never relaxed without data showing the site can handle the change.

For teams getting started with synthetic media, we recommend starting with the delivered weight budget as the first boundary. It is the easiest to measure, the easiest to automate, and it has the highest impact on the other three dimensions. Once weight is under control, interactivity and visual stability become manageable problems.

If you want to go deeper on how we structure media content models, our guide on video-first content architecture in headless CMS complements this framework. And if your project involves AI-generated visual catalogs, our take on synthetic video at scale covers the production side that feeds these budgets.