Godot Web Build Size: Why It's Big and How to Optimize It

Godot Web Build Size: Why It’s Big and How to Optimize It

Honesty note: I built a full Godot 4 prototype (Merge Fish 2048, originally Merge Fish Pond) and measured its web export directly. This article is that measurement plus the official optimization paths — and the honest conclusion about when they’re worth it.

TL;DR

1. My measured Godot 4 web export: ~40.5 MB raw, ~12.3 MB gzipped — and 37.7 MB of that raw size is the engine’s own index.wasm binary, before a single line of your game.
2. Why so big: the default export bundles the full engine. The wasm is the runtime; the .pck (2.5 MB in my build) is your game. Most of what you ship is the engine, not your game.
3. The official optimization path is real but heavy: build a custom export template with only the modules you need — which means downloading the engine source and compiling it yourself (headless builds, module selection). That’s a real cost for a beginner.
4. Compare with the alternative: my Phaser build of the same game is ~4.4 MB raw / ~1.8 MB gzipped — no engine binary at all. Full side-by-side in the engine deep-dive.

The measurement (my actual Godot 4 build)

The .wasm is the entire engine compiled to WebAssembly. The .pck is your scenes and scripts. On first load, the browser downloads and parses ~12 MB gzipped — before the game can even start — and that’s the number portals and embedded platforms care about (see the size guide for the limits).

Why the default export is so heavy

Godot’s web export is the whole engine unless you tell it otherwise:

• The wasm includes every module — 2D, 3D, physics, audio, navigation, networking, editor-adjacent systems — regardless of what your game uses.
• There’s no “export only what I use” toggle in the editor — that’s the crux. The official way to slim it is a custom export template.
• Compression: Godot’s official export supports gzip/brotli compression of the wasm — my 40.5 → 12.3 MB numbers above are with gzip. That’s the first optimization and it’s free.

The real optimization paths (in order of effort)

1. Compress the export (free, do this first). Enable gzip/brotli in export settings or compress the wasm on your server. Cuts ~40 MB → ~12 MB gzipped. Zero code changes. This is why “my build is 40 MB” is misleading — the delivered size is the gzipped number.

2. Serve with correct headers (free). The wasm must be served with Content-Encoding: gzip (or brotli) and the right MIME type — otherwise browsers download the full 40 MB and you’ve gained nothing. Most static hosts (Cloudflare Pages, Vercel) do this automatically.

3. Custom export template (the official slim path, real effort). Download the Godot engine source, select only the modules your game needs (e.g., disable 3D, navigation, or networking), and compile a custom web export template with headless tools. This is documented but requires:

• downloading the engine source (~GBs),
• a working compile toolchain,
• maintaining your template as the engine updates.

For a casual 2D game this can get you meaningfully smaller — but it’s a serious time cost.

4. Split your game data from the engine (moderate win). Keep the .pck small (2.5 MB in my build) by compressing textures (AVIF/WebP instead of PNG where possible) and trimming audio (OGG/Vorbis at 96-128kbps, or compressed formats). Your game data is the only part of the export you fully control without touching the engine.

5. Consider whether Godot is the right delivery stack for web (the honest one). If your target is casual HTML5 portals, the engine-binary tax is structural — every player pays ~12 MB gzipped for an engine, and every portal size gate counts it. A code-first stack (Phaser, ~1.8 MB gzipped, no engine binary) removes the tax entirely. My measured comparison and why I switched are in the engine deep-dive.

What I actually did

I compressed the export (12.3 MB gzipped), verified the server headers, and kept the .pck lean — then switched the delivery of this game to Phaser while keeping Godot as a learning tool. The game’s core (board logic, save system) is stack-independent; the engine choice is a delivery decision. For my casual-web goal, the 6.8x size difference made Phaser the honest choice (engine comparison, beginner selection guide).

Pitfalls

1. Quoting raw size instead of gzipped — portals and players pay the gzipped number; always measure delivered size.
2. Serving wasm without gzip headers — your careful compression is wasted; verify with a header check.
3. Building a custom template before compressing — compression is free and gets you most of the way; do it first.
4. Textures and audio as afterthoughts — a fat .pck is 100% yours to fix; engine tax isn’t.
5. Choosing Godot “because it’s popular” without checking the export — test the web export size before committing (my own mistake, documented in the beginner guide).

Bottom line

Godot’s web export is heavy because it ships a full engine — my measured 40.5 MB raw / 12.3 MB gzipped. Compression is free and should always be first. A custom export template is the official slim path but demands engine-source compilation. And if your target is casual web portals, a code-first stack removes the tax entirely — which is the honest reason I ship this game on Phaser. Measure your delivered size, compress first, and let the size gate be part of your engine decision.