Benchmark7 min

How Much CPU and RAM Does ffmpeg.wasm Actually Use? (Measured)

We profiled ffmpeg.wasm on real transcodes — CPU %, peak heap, and wall-clock — across four laptops. Here's what to expect before you ship it in a browser app.

Every measurement was captured locally with Chrome DevTools Performance and Memory panels. No files or telemetry were uploaded.

Short answer: ffmpeg.wasm uses one CPU core (Web Worker), needs 300–700 MB of heap for HD video, and runs 4–10× slower than native FFmpeg on the same machine. Below are numbers from four laptops so you can size expectations before shipping it. See it in action at Zro7 Compress Video and MP4 → GIF.

Test setup

  • ffmpeg.wasm 0.12.10 / ffmpeg-core 0.12.10 (single-thread build; SharedArrayBuffer path noted separately).
  • Chrome 141, one tab, no extensions, Performance panel + performance.memory.
  • Machines: MacBook Air M2 (16 GB), MacBook Pro M3 Max (36 GB), ThinkPad X1 i7-1365U (32 GB), Pixelbook Go i5-8200Y (8 GB).
  • Every job run 3× cold; median reported.

Job 1 — Compress 1080p H.264 (100 MB, 60 s clip, CRF 28)

  • M3 Max: 34 s · 1 core pinned to 100% · peak heap 612 MB.
  • M2 Air: 41 s · 100% core · peak heap 604 MB.
  • X1 (i7-1365U): 63 s · 100% core · peak heap 640 MB.
  • Pixelbook Go: 168 s · 100% core · peak heap 690 MB (fans on).

Job 2 — MP4 → GIF (720p, 10 s clip)

  • M3 Max 6.8 s · M2 Air 8.9 s · X1 12.4 s · Pixelbook 26.1 s.
  • Peak heap 220–260 MB across all four (palette generation dominates).

Job 3 — Extract audio (60 MB MP4 → AAC copy)

  • 3.2–5.1 s everywhere; audio copy is stream-remuxing, effectively I/O.
  • Heap stays under 120 MB.

Job 4 — 4K → 1080p downscale (500 MB, 90 s, H.265)

  • M3 Max 128 s · M2 Air 189 s · X1 302 s · Pixelbook out-of-memory at ~1.3 GB heap.
  • This is the ceiling on 8 GB machines with the current WASM build.

Multi-thread (SharedArrayBuffer) build

  • Requires Cross-Origin-Opener-Policy + Cross-Origin-Embedder-Policy headers (COOP/COEP).
  • On M3 Max: Job 1 drops from 34 s → 12 s (3 threads); heap climbs ~1.4×.
  • On the X1: 63 s → 27 s.
  • Trade-off: COOP/COEP breaks 3rd-party embeds (fonts, images) unless they set CORP headers.

Rules of thumb we now use

  1. Budget 700 MB peak heap for anything HD; abort ≥1.2 GB.
  2. Expect 4–10× the wall-clock of native FFmpeg on the same core.
  3. Multi-thread build is worth it if you control your headers; it roughly cuts transcode time in third.
  4. Keep GIF widths ≤ 480 px unless the user explicitly wants HD — heap and CPU both explode past there.
  5. Show a per-second progress %; the run is long enough that users benefit from ETA.

How to reproduce

  1. Open Compress Video in a fresh tab.
  2. Open DevTools → Performance, start recording.
  3. Drop your sample, run the job.
  4. Stop recording; note main-thread + worker CPU and heap peak.

Updated January 5, 2027 · Zro7 editorial team. Numbers depend on codec, preset, and background load — treat as ±20%.

Frequently asked questions

Why is ffmpeg.wasm so much slower than native FFmpeg?

No hardware acceleration (NVENC, VideoToolbox), and by default one thread. The multi-thread build recovers most of the gap on modern CPUs.

Can ffmpeg.wasm use the GPU?

Not today. WebCodecs can offload H.264/HEVC decode to hardware but the encode side still lands in WASM.

Does GPU-less mean it's useless on phones?

For 720p clips under a minute, mobile Safari and Chrome handle it. Sustained transcodes throttle.

Why does heap keep growing during a job?

FFmpeg allocates per-packet buffers that free at the end. It looks like a leak; it isn't.

Which is the cheapest big win?

Enable COOP/COEP and ship the multi-thread build. 2-3× speed for a header change.

Related posts

← Back to blog