I run two small tool sites on my own, so every megabyte on the landing page is a bill I pay myself. Last week I recorded a 62-second walkthrough of the admin screens for a new feature — filter by warehouse, open a transfer dialog, scroll a long product table. 1920×1080 at 30 fps, and the file came out at 295.7 MB. Too big to host, too big to email.
The obvious move was to drop the resolution. That is the instinct everyone has, because it is how images work: half the pixels, half the file. For a screen recording that instinct is wrong twice over. Dropping the resolution was the only step in my whole run that damaged the text, and at the first stop it also made the file larger.
Before the numbers, two things about the sample. To isolate one parameter at a time I built the recording myself against a typical warehouse admin layout — the brand "Lanxi Cloud Warehouse", the SKUs, product names and amounts are all invented, nothing from a real system. Small type was deliberate: 11px monospace SKUs in the table, 13px product names, 12px field hints in the dialog. And the source file matters: it came out of the recorder in a near-lossless form, all I-frames, essentially no inter-frame prediction, around 40 Mbps. That is why 62 seconds weighs 295.7 MB. If your recorder already does inter-frame compression, your source may be 15 MB and none of the ratios below will transfer.
I ran everything through ImgIng (https://imging.ai/), which does the decode and encode inside the browser. I kept the network panel open across twelve runs and the video itself never left the machine — which, for someone paying for upstream bandwidth, is the part I noticed before any of the quality settings.
The first surprise was that I barely needed the knobs. Changing nothing at all, the default pass produced 21.34 MB — 7.21% of the original, so 92.8% off, in about nine seconds. Nothing was quietly shrunk: still 1920×1080 at 30 fps, all 1860 frames present, audio intact. Blown up 3×, the table region is letter-for-letter identical to the source.
Then I went after the resolution anyway, expecting the big win. Capping the long edge at 1280 gave me 25.73 MB — 26.6% bigger than the 20.32 MB I got keeping the native resolution. Roughly forty percent fewer pixels and a larger file. The reason is in the bitrate column: the tool budgeted 3200 kb/s for the 1280 tier against 2502 kb/s for the native one. Fewer pixels, so more bits each — a reasonable rule for ordinary footage, and a bad one for a recording that is mostly a still white table. Meanwhile the small-text sharpness in that region fell from 4.13 to 2.81 (the source reads 4.15), and PSNR over the text block dropped 14.28 dB. At 854 the file does shrink, to about 13 MB, but sharpness lands at 1.36 and the SKUs are simply unreadable.
Every other knob left the text alone. The four quality presets took 22.4 MB down to 15.8 MB, another 29%, with sharpness pinned at 4.13 across all four. Cutting 30 fps to 24 saved 14.4%. Switching the output from MP4/H.264 to WebM/AV1 — same preset, same resolution, same frame rate — took 20.3 MB to 6.4 MB, another 67%, sharpness 4.09.
Two honest caveats. The frame-rate row looks free and is not: PSNR and sharpness did not move by a single digit, but sampled-frame comparison is blind to dropped frames by construction. 372 frames, a fifth of the video, are actually gone, and what they carried was the continuity of the cursor and the scroll. I have no measurement for that, only my own eyes. The AV1 result comes from one recording at one preset, and that codec only appears in the UI once the device passes a capability check.
So my order is inverted now: run the default first, then change codec, then frame rate, then walk down the presets, and touch resolution last if at all. The pass/fail test is no longer a number. I scrub to the table section, pause, and try to read a SKU out loud. If I can read it, it ships.
One boundary worth stating: these ratios belong to this kind of content — mostly static, text heavy, local motion. The same default settings gave me 40.7% on a slide-style meeting recording and 45.9% on a clip where the whole frame changes every frame, with quality falling hard on the second one. Nine tenths off is a property of screen recordings, not of compression.
Top comments (0)