30 vs 60 fps for demo videos
60 fps doesn't always look smoother. The real difference lives in cursor motion and bitrate — not the number on the console.
TL;DR
- **60 fps wins only in demos with fast motion** (a cursor crossing the screen, drag-and-drop). On static UI, 30 fps is indistinguishable.
- HEVC at 60 fps roughly **doubles the file size** without doubling perceived smoothness — Weber's law applies.
- Sgrin's rule: 30 fps by default, 60 only when there's real cursor motion — decided at export.
The metric that matters isn’t frames per second but perceived motion: how fast the content moves between frames. A recording of a static window at 60 fps looks identical to 30 fps because nothing is displacing between frames.
The eye doesn’t count frames — it detects discontinuity in displacement. That’s why a cursor crossing a 1440px display in 0.3s looks choppy at 30 fps and smooth at 60: each frame covers 80px vs 40px, and the threshold where the eye stops integrating motion sits near 60px.
The frame rate doesn’t describe your video. It describes how fast what you recorded was moving.
When 30 fps is enough
If your demo is a tour through static panels with a cursor that moves deliberately, 30 fps is sufficient. The panels aren’t changing between frames, and the cursor displacement stays under the perception threshold. You get a file half the size for no visible loss.
This covers most product walkthroughs, settings tours, and feature explainers — the bulk of what indie founders and small teams actually ship.
When 60 fps earns its size
60 fps pays off when there’s real motion: drag-and-drop, fast scrolling, animated UI transitions, or a cursor that crosses the screen quickly. There the per-frame displacement exceeds the threshold and 30 fps starts to look stepped.
The trade-off is file size. HEVC at 60 fps nearly doubles the bytes without doubling the perceived smoothness — a textbook case of Weber’s law, where the just-noticeable difference scales with the baseline, not in absolute steps.
| Dimension | 30 fps | 60 fps |
|---|---|---|
| Smooth cursor motion | Up to ~40px/frame | Up to ~80px/frame |
| File size (HEVC, 30s) | ~6 MB | ~11 MB |
| Web compatibility | Universal | HEVC restrictive |
How to decide in three steps
- Look at the dominant motion. Static panels with a slow cursor → 30 fps. Drag, fast scroll, or UI animation → consider 60.
- Weigh the file cost. HEVC at 60 fps roughly doubles size without doubling perceived smoothness. If you serve it on a landing page, the weight can hurt LCP more than the smoothness helps.
- Verify the destination. HEVC at 60 fps in Safari without the right container renders a black screen. For universal web delivery, H.264 at 30 fps remains the safest default.
What Sgrin does with this
Sgrin doesn’t make you choose by hand. It reads the motion of the capture and applies the rule above at export.
› In depth — the threshold math
Frequently asked
Is 60 fps always better for screen recordings?
No. For static UI with a slow cursor, 30 fps looks identical and halves the file size. 60 fps only helps when something moves fast between frames.
Does HEVC at 60 fps work everywhere?
Not quite. HEVC is restrictive on the web — Safari needs the right container, and some platforms won't play it at all. H.264 at 30 fps is still the safest default for universal playback.
How does Sgrin pick the frame rate?
It measures peak pointer velocity during the capture. If the cursor exceeds roughly 60px per frame at 30 fps, it raises the export to 60. Otherwise it stays at 30 to keep the file lean.
Record a demo. Let Sgrin direct it.
Free 14-day trial · No card required
More in this series