Why does every HyperFrames render take 45 seconds longer than it should?

You have a short composition. It should render in seconds. Every render sits for most of a minute doing nothing first, and no setting you change makes the wait shorter.

Why it happens

The producer decides a composition is ready by polling for window.__timelines[<id>] until the composition player reports ready. If nothing ever registers, it gives up after player-ready-timeout, which defaults to 45 seconds. That wait is a fixed cost paid on every render. It does not scale with quality, resolution or media size, so lowering any of those cannot reduce it.

A composition with no GSAP timeline at all, because it is static, a still image, or built from video and audio only, has nothing to register. So it pays the full wait every time.

Fix: declare that there is no timeline

<div
  data-composition-id="promo"
  data-no-timeline
  data-width="1920"
  data-height="1080"
  data-duration="6"
></div>

data-no-timeline tells the renderer not to wait. npx hyperframes lint reports the omission as missing_data_no_timeline, so it is easy to find.

If you do want an animation, register a timeline instead of skipping the wait: see why an animation can be static.

Other ways to pay the same bill

Registering the timeline too late. If a timeline is created inside an async function or a .then(), it is not in window.__timelines when the producer first looks. The wait then runs to the timeout. This is documented as a bug in several registry blocks: the map blocks fetch their topology data from a CDN at render time and build their whole timeline inside the async callback, and a device-mockup block registers its timeline inside an async ready handler. Both stall for 45 seconds and fall back to screenshot capture. That report is still open, so if you use those blocks, expect it.

A script that throws. If the composition script errors before building the timeline, the timeline never registers and you pay the wait, then get a video that never moved. See why the first render can be a still image.

Static sections that are not marked. A bare data-composition-id host used for a static section was reported as burning the full player-ready budget on every render, for the same reason.

Check it worked

time npx hyperframes render --quality draft --output review.mp4

Before the change the draft render takes about 45 seconds longer than the work it does. After it, the wait is gone. Then see the full list of reasons a render is slow for what is left.