Back to Blog
Dev Log 24 Aug 2026 admin

Shipping a Unity Game to the Browser: What Actually Costs You Frames

Shipping a Unity Game to the Browser: What Actually Costs You Frames

A Unity project that runs at a comfortable 90 FPS in the editor can crawl the moment it becomes a WebGL build. Nothing is wrong with your game — the browser is simply a different machine, with a different memory model, a single main thread and a network connection between the player and every asset you shipped. This post walks through where the frames actually go, and what we change first when a build feels heavy.

1. The download is part of the gameplay

On desktop, a player waits for an install once. On the web, they wait every time they open the page — and they judge the game before it starts. Anything above a few seconds of blank screen loses people who would have enjoyed the game.

Three changes give the largest return:


Measure the build, not the project. The Build Report tells you what shipped; the Project window tells you what exists.

2. Texture memory is the usual culprit

WebGL builds are far more sensitive to texture memory than a native target, and the symptom is rarely a clean error. You get a tab that reloads itself, or a mobile browser that quietly kills the page.


3. Draw calls and the single thread

The browser gives you one main thread for game logic and rendering. Work that a native build hides across cores lands in the same frame here, so the cost of a badly batched scene shows up immediately.

What tends to help


4. Garbage collection is felt, not seen

Frame-time spikes that appear at no particular moment are usually allocations. String concatenation in a UI update, GetComponent in a loop, LINQ in gameplay code, a new array every frame — each is harmless alone and expensive together.

Pool anything you instantiate more than a few times: projectiles, particles, damage numbers, audio sources. Cache component references in Awake(). Build UI strings only when the value behind them changes, not every frame.

5. Test on the device your players use

A build tested only on the machine that compiled it will surprise you. Mid-range Android phones on a mobile connection are the honest test: they expose the download, the texture budget and the thread pressure all at once. A build that holds up there feels effortless everywhere else.

A short checklist before you publish


None of this is exotic. It is the same discipline as any other platform, applied to a target that is much less forgiving about waste — and the payoff is a game that a player can start in one click, with no install and no store page in the way.