Why is my HyperFrames render slow, and what actually speeds it up?
Separate a slow preview from a slow render, find the fixed 45 second tax, then work through source video, filters, encoding and resolution. Real fixes from HyperFrames' own performance guide.
Start by deciding which kind of slow you have, because the fixes do not overlap.
| What you see | Look first at |
|---|---|
| Preview stutters in one scene | Large blurs, masks, shadows, or many animated layers in that scene |
| Preview pauses the first time an image appears | Oversized source images or image decoding |
| The whole page is slow | Script work, layout thrashing, or too many DOM nodes |
| Render is slow but the result is correct | Source video extraction, frame capture, or encoding |
| WebM takes much longer than MP4 | VP9 encoding. Transparent WebM is CPU-heavy |
| Every render pauses about 45 seconds before doing anything | A missing timeline |
1. The flat 45 second wait
If every render, however small, starts with a long pause, it is not your content. A composition that never registers a timeline makes the producer wait out a fixed 45 second timeout. Fix it with data-no-timeline or by registering a real timeline. See the 45 second answer. Rule this out first: it is the biggest single saving for small projects.
2. Make a fast review render
npx hyperframes render --quality draft --output review.mp4
Draft reduces capture and encoder quality. It does not change timing, so what you check in the draft is what you ship. Use standard or high for the final.
3. Expensive browser work
Browsers are doing the rendering, so anything expensive in a browser is expensive here.
- Use fewer large
backdrop-filterandfilter: blur()layers. - Avoid animating dozens of shadowed elements at once.
- Replace a static blur or texture stack with a pre-rendered image.
- Size images near their actual delivery dimensions. A very large JPEG still decodes into a very large bitmap. For a 1920 by 1080 composition, a 3840 by 2160 source already gives a 2x display enough detail.
- Keep work inside animation callbacks small. Do not read layout and write styles in the same frame.
4. Do not over-spec the output
The defaults of 1920 by 1080 at 30 frames per second render fast and look good. Higher specs slow rendering meaningfully. Ask for 4K only when the delivery target needs it, and supersample instead when you can, with --resolution.
5. WebM is not MP4
WebM uses the CPU-heavy VP9 encoder, and transparent WebM is the worst case. If you must render it, you can trade encoding time for compression with --vp9-cpu-used, which takes integers from -8 to 8. Higher values are faster, with a larger quality and size tradeoff.
npx hyperframes render --format webm --vp9-cpu-used 2 --output overlay.webm
6. Find out whether you fell back to screenshot capture
A render on Linux that fell back to screenshot capture used to look like a normal success while being much slower. Since a September 2026 change, hyperframes render prints the capture path, GPU mode and per-stage timings, and local auto GPU mode now requests BeginFrame instead of clamping to screenshot. If your summary says screenshot, there is a hint naming the remaining blockers, such as not using chrome-headless-shell or using a --resolution upscale, which stays on screenshot capture by design.
7. Measure before you change things
npx hyperframes preview
Open Chrome DevTools, choose Performance, record the part that stutters, and look at the longest tasks. Paint or Composite Layers points to filters, shadows or masks. Layout or Recalculate Style points to layout work. Script points to your own code. Change one expensive feature, record again, and keep the version that moves the bottleneck. To tune worker settings for a final render, run npx hyperframes benchmark.
Check it worked
Time a draft render before and after each change, one change at a time, so you know which one paid off.
Keep slow renders out of your edit loop
Editing in GenMotion happens in a live, frame-accurate preview. The MP4 is rendered only when you export, on your own machine, so a heavy scene costs you time once instead of on every change. The studio bundles its own ffmpeg for the encoding, so there is nothing to install or tune.
Related answers
Why does every HyperFrames render take 45 seconds longer than it should?
A composition that never registers a GSAP timeline still makes the renderer wait for one, and gives up after a fixed 45 seconds. The cost is flat on every render. One attribute removes it.
Why do my fonts look wrong in a HyperFrames render, and what is FONT_FETCH_FAILED?
A font that looks right in preview can fall back, change weight or fail the render outright. Embed the font with @font-face, understand what the compiler does with a named Google Font, and know why Arial and Segoe UI behave differently from Helvetica.
Why does my HyperFrames render look different from the preview?
Preview and render run the same runtime, so a real difference has a specific cause: fonts, remote media, a cold-seek state problem, the wrong entry file, or a variable that never arrived. Here is how to find which.
How do I install HyperFrames, and why did npx skills add fail?
The current install routes for Claude Code, Codex, Cursor and others, plus the three real failures people hit: a 60 second clone timeout, a missing git-lfs, and a Codex marketplace error. What each means and how to get past it.
Sources
- HyperFrames: Fix a slow preview or render
- HyperFrames troubleshooting: the render is slow
- HyperFrames rules and anti-patterns: do not over-spec resolution or framerate
- hyperframes#3927: default BeginFrame capture and a capture-mode summary
This answer as plain Markdown, for agents: /answers/hyperframes-render-is-slow.md