Answers for developers, publishers and site owners on monetizing and distributing web games.
337 posts
Pre-compress .wasm, .data and .js build files with Brotli at build time, serve them with Content-Encoding: br and the correct Content-Type, and set long, immutable cache headers on hashed filenames while keeping the HTML page uncached.
Unity WebGL executes on the browser's single main thread by default, so C# threads and blocking waits (Thread, Task.Wait, synchronous file/network I/O) don't work as on desktop. Multithreading is possible only via WebAssembly threads (Web Workers + SharedArrayBuffer), which requires COOP/COEP headers on the hosting server and browser support.
Cut texture memory with compressed GPU formats and mipmaps sized to actual display size; compress audio to a low-bitrate format like Ogg Vorbis and stream long tracks instead of loading them fully into memory. Then measure the actual build output, not just source asset sizes.
Keep a small entry HTML/JS file, a separate folder for engine build output, a dedicated layer for platform/SDK calls (ads, save data, platform bridge), and assets organized by type. Never let engine code call browser APIs directly - route everything through one bridge module so ports and testing stay simple.
The initial WebGL build size sets a hard floor on startup time because the browser must download, decompress and initialize everything in that package before gameplay starts. Cut it by moving assets to Addressables loaded on demand, enabling Gzip or Brotli compression, and stripping unused code.
Bundle size and load time depend mostly on runtime overhead: engines that ship a compiled runtime (Unity, Godot) add more startup weight than JavaScript-native engines (Phaser, PixiJS, Construct 3, GDevelop). Exact size and timing figures vary by project and are not something to quote as fixed numbers - measure your own build instead.
A standard JavaScript game loop works by calling requestAnimationFrame recursively: the browser supplies a high-resolution timestamp to the callback, which calculates deltaTime, updates game physics and logic scaled by that interval, renders the frame, and requests the next tick. This pattern synchronizes updates with the display refresh rate while preventing animation drift.
The basic architecture splits between an authoritative game server that executes physics, resolves collisions, and broadcasts authoritative state snapshots, and a browser client that captures input, renders visuals, and runs client-side prediction to hide latency. The client sends player inputs over WebSockets, renders the scene, and reconciles its local state against incoming server updates.
HTML provides the page and a canvas element, CSS positions and styles that canvas plus any DOM-based UI, and JavaScript runs the game loop, draws frames via the Canvas or WebGL API, handles input, and manages logic and state.
Build time depends mainly on game scope and complexity, the engine or framework chosen, how much custom code you write versus reuse, art and audio production, and how much platform integration (ads, save data, multiple export targets) you add before launch.