Building an open world in the browser, part 3: The unflashy spikes that saved us
By Oleg Sidorkin, CTO and Co-Founder of Cinevva
New here? Use the series guide. It explains what a spike is and links all parts.
This part has fewer shiny screenshots and more architecture insurance.
After Spikes 1 and 2, we ran three risk checks that looked small but had product level impact.
First was broadcast fan out with Durable Objects. We tested multi client position distribution at game-like tick rates and tracked latency distribution, CPU per tick, and delivery integrity. If this had failed, we would have moved to early sharding instead of single island ownership.
Second was mobile constraint validation. Not a desktop preset renamed to mobile, but an explicit low-cost profile from the same baseline terrain.
Open the mobile profile in a new tab ↗ · View source
We reduced segment density, object count, render resolution pressure, and fog range. The question was simple. Can this world remain readable and responsive on mobile class constraints without rewriting the entire renderer.
Third was behavior generation reliability for creator workflows. We evaluated valid JSON rate, semantic correctness against expected primitives, and response latency. If this had failed, we would have moved to strict form based behavior authoring.
The key insight from this chapter is that these unflashy spikes changed architecture faster than visual spikes did. They set hard boundaries on network topology, mobile promises, and tool UX.
In part 4 we return to visible terrain work and test movement-time streaming behavior, not just static loading screenshots.
Technology referenced in this chapter
Cloudflare Durable Objects. Edge-deployed stateful serverless instances with built-in persistence and WebSocket support. Each Durable Object holds authoritative state for a world shard (or chunk). Players connect via WebSocket and receive position broadcasts from other players in the same shard. When the player moves to an adjacent chunk, they connect to that chunk's Durable Object. Durable Objects auto-persist state to disk and scale to thousands of concurrent instances. See Cloudflare Durable Objects docs and our browser 3D tech guide on multiplayer networking.
Spatial sharding. Dividing the world across server instances by geographic region. Each shard owns a rectangular area of the world grid. As player density shifts, shards can split or merge. Players near a shard boundary see both shards' content through cross-shard visibility queries. This is how EVE Online handles thousands of players in one universe.
WebSocket broadcast fan-out. Distributing real-time position updates from one server to many connected clients. At game-like tick rates (20-30 Hz), each player generates ~800 bytes/second of position data. With 200 players in view, that's ~160 KB/s per client. The server must serialize, filter by relevance (spatial interest management), and push to each connection within the tick budget. See our networking guide for delta compression and update frequency tradeoffs.
Mobile rendering constraints. Mobile GPUs have 1/5 to 1/10 the throughput of desktop GPUs, ~1 GB memory limit (vs 2-4 GB on desktop), and thermal throttling under sustained load. A mobile quality profile reduces segment density, object count, render resolution, draw distance, and shadow quality. The goal isn't parity with desktop but maintaining readability and responsiveness. See browser 3D performance numbers for real GPU benchmarks.
Part 3 of 12.
Previous: Part 2 - Worker physics and the input lag fear
Next: Part 4 - Streaming before fancy terrain
Series guide: /blog/2026-02-25-open-world-browser-series-guide