What it takes to build web games in 2026
Poki engineer Erik Dubbelboer breaks down engine choices, file size trade-offs, and other insights for new developers.
Browser technology has closed much of the gap between web and native games but more capable browsers have not removed the constraints that decide whether players stay. A deep engine feature set means little if the initial download is too heavy, the first ten seconds feel flat or the mobile layout asks players to rotate their phone.
Poki’s Principal Engineer Erik Dubbelboer sees these challenges from both sides. He helps build the developer tools behind the platform and has released two Poki games of his own, Silly Sky and Village Builder.
In a recent conversation with Joe Nash on the Software Engineering Daily podcast, Erik shared practical advice on the technologies powering web games, choosing the right engine, reducing load times, designing effective onboarding, building for portrait mode and testing with real players.
Below are the key lessons for developers building or porting a game to the browser in 2026.
Where the web platform stands now
Before choosing an engine or designing the player experience, developers need to understand what the modern web platform can now handle.
The first thing to note is that WebAssembly, WebGL and WebGPU have expanded what games can do inside a browser.
Toolchains such as Emscripten can compile C and C++ code into WebAssembly, allowing engines such as Unity and Godot to run substantial parts of their runtime on the web. Rather than sending human-readable source code to the browser, WebAssembly provides a compact instruction format that browsers can translate efficiently into machine code.
WebAssembly cannot access browser features directly. When a game needs to interact with the browser, such as drawing to the screen or working with the page, it communicates through JavaScript. For developers using an established game engine, most of that communication is handled behind the scenes.
WebGL has provided stable access to hardware-accelerated graphics in browsers for years. It plays a similar role to OpenGL on desktop platforms and remains widely supported, including on many older Android devices.
WebGPU is the next major step. It is designed around newer graphics APIs such as Vulkan and Metal, allowing rendering commands to be prepared and submitted to the GPU more efficiently. It also introduces features such as compute shaders, which can improve the performance of animation, particle and simulation systems that were previously difficult to run in a browser.
Erik explains why this changes what browsers can handle:
With WebGPU, you can batch a whole bunch of commands and then say ... send this to the GPU to render. I don’t want to wait for the result. I’m going to do other stuff. It’s a lot faster that way
Support is still developing. As of June 2026, devices with WebGPU support account for around 68% of players on Poki. Older phones and graphics drivers remain the biggest limitation, so developers should treat WebGPU as an enhancement rather than assume it is available to every player.
Chrome is actively building a minimal WebGPU fallback for these devices and Safari shipped default support with a recent iOS release. Firefox ships WebGPU on Windows and macOS but is still working on Linux and Android support. Erik expects near-universal coverage by the end of 2026.
Choosing an engine for web
Choosing an engine for a web game often means balancing feature depth against the amount of data a player must download before they can start playing.
Erik mentioned:
For every extra megabyte a person has to download to play your game, you’re going to lose a couple percent of players.
Unity is the most widely used engine among developers on our platform. Web export works, WebGPU export is now experimental, and the feature set is deep. The trade-off is size. Unity compiles to one large WebAssembly blob that must download in full before the game is playable. Most Unity games also load every asset into memory at launch because they weren’t built with Unity’s addressables system, which is difficult to retrofit. That makes conversion to play lower for Unity games than for web-native alternatives.
Godot has the same blob issue, but its web lead (Adam Scott) is actively building a system for lazy-loading assets. That could make Godot a stronger web option in the near future.
PlayCanvas is a web-native engine comparable to Unity in capability, with a visual editor and a JavaScript-first workflow. Because it doesn’t compile to WebAssembly, it sidesteps the blob problem entirely and makes delayed asset loading straightforward.
Construct is another strong web-native option. Phaser and PixiJS sit at the framework end of the spectrum for developers who want low-level control without a full engine.
Every extra megabyte a player has to download before playing costs you a measurable percentage of your audience. Web-native engines make it easier to load only what’s needed for the first few seconds of gameplay and fetch the rest in the background.
Why onboarding decides everything
Web players behave more like TikTok viewers than Steam users. If the first few seconds aren’t interesting, they click through to the next game. There’s no install cost anchoring them to your title.
Erik puts it directly.
If those first couple of seconds are not interesting enough, they’ll just click on another game. They have no incentive to try out your game.
That changes how onboarding needs to work. Text-based tutorials fail. Pop-up instructions fail. If players need to read anything substantial, they leave. The onboarding should feel like playing, not like learning.
He uses a Vampire Survivor-style game as an example to demonstrate this.
If I would be making that for the web, I would start the player off with the most crazy abilities for a couple of seconds or something, like 10 seconds, to really show what is possible and then take them all away and let them regain it quickly, or slowly. You want to pique that interest immediately.
One play test video made the point clearly. A side-scrolling bicycle game showed a space bar icon with the word “space” on it. Multiple players had no idea what a space bar was. They clicked everywhere, pressed every other key, and eventually gave up. The fix was simple: show a picture of a keyboard with the space bar highlighted. That kind of insight only comes from watching real players.
Build for portrait mode first
Portrait mode is winning on mobile web. Erik compares it to the broader shift across platforms: Netflix is composing shots for portrait crops. Instagram and YouTube Shorts are portrait-native. The bottom line is that mobile users default to portrait for everything.
For web games specifically, portrait matters even more than for apps. Players on Poki switch between games frequently. Asking them to rotate their phone is a conversion killer when the next game is one tap away. Every game submitted to Poki needs to work in portrait, and our QA team tests for it.
That creates real design challenges. Portrait is a fundamentally different aspect ratio from the desktop rectangle most developers build in first. UI elements need to account for phone notches and Poki’s own interface elements rendered on top of the game. Game engines like Unity and Godot offer dynamic UI scaling, and our inspector tool shows exactly where our overlay elements sit so developers can avoid placing buttons underneath them.
How Poki’s developer tools help
Three platform features address the problems above directly.
Poki Play Testing lets developers request video recordings of real players trying their game. Within minutes of uploading a build, you get 10 to 20 recordings showing actual player behavior, complete with keyboard and mouse inputs. These are real players from our audience, not hired QA testers, meaning you see genuine first-contact reactions to your onboarding. Developers can upload multiple builds per day and iterate based on what the videos reveal.
Erik explains how this creates a rapid feedback loop:
If you have a day of developing your game, you can upload...multiple versions a day. You request those play test videos, you see those players playing your game. Based on that, you make more changes, upload a new version again...It allows for a very nice fast development cycle, where those players getting to play your game are also your actual audience.
Distribution and player acquisition are handled by the platform. Developers on Poki don’t need to spend time or money on marketing. We match games to interested players through our categorization and recommendation systems. Erik notes that many successful indie developers on the platform have no marketing expertise at all. They focus entirely on building.
Cloud saves work automatically. Games store data in local storage as usual. We periodically sync that data to our servers, so player progress survives browser cookie purges (Safari on mobile is particularly aggressive about clearing storage from iframed content). Players who create a Poki account get persistent saves across devices with zero API integration required from the developer.
Ready to launch your web game?
Thinking about launching a web game? Poki gives developers the tools, audience and support to test, improve and publish games for the browser.
Explore the Poki for Developers guide to see how the submission process works and what your game needs to succeed.