The Limits of a Browser
- #web #webgl #performance
- 301 words, Read time 1 minute, 30 seconds
So I was working on Gesture Quest Web, and after doing full-stack browser dev across two projects now, I wanted to write down how different it is from shipping a standalone game.
My standalone Unity games are small and simple. An ant standing next to the elephant that is a real AAA title. And at that size, I could basically pretend memory was infinite. Load every asset up front, let a sprite be as big as it wants, throw the whole pile into memory the moment the game launches. Is that best practice? Absolutely not. But we were always on a deadline, so we only optimized when something actually caught fire. Saving and loading files was easy too. A standalone build can just reach into the disk and read or write pretty much wherever I want it to.
However, the browser does not let you do any of that.
A browser tab runs in a sandbox with a memory budget, sharing RAM with every other tab and the browser itself. Dump too much in at once and the tab does not just lag, it dies. So instead of loading everything up front, we stream assets in as we need them and let go of what we do not.
File access is locked down for the same reason. A web page cannot go digging through our disk. We only get small sandboxed storage with quotas, and "saving" usually means downloading a file or sending it off to a server (which is what I did), not writing wherever we please.
Is it annoying? A little. But it also meant finally sitting down and seriously optimizing my baby, which I secretly enjoyed. Turns out the browser is just a very strict personal trainer, and my game, just like me, needed to lose some weight.