Browser games with Three.js and WebGL

A browser game built with Three.js and WebGL is the right choice when reach matters more than graphical ceiling. Players open a link and play within seconds, with no install, no store review and no account. It suits campaign and marketing games, interactive product pages, casual games and prototypes you want many people to try. The price is a strict budget on download size and frame time, because the game has to load fast and run smoothly on an ordinary laptop or a mid-range phone.

#When a browser game is the right choice

The browser removes every step between a player and the first frame. That matters most in four cases:

• Campaign and marketing games. A short game tied to a launch, a season or a brand lives on a link in an ad, an email or a social post.
• Shareable casual games. A daily puzzle or a score-chasing arcade game spreads because a friend can open the same link on whatever device they have.
• Interactive product pages. A 3D configurator or a playable demo inside a website uses the same technology as a game.
• Prototypes and playtests. Sending testers a URL is faster than distributing builds, and you can update the game between sessions without asking anyone to reinstall.

The browser is a weaker fit for long sessions in large worlds, for games that need hundreds of megabytes of assets, and for titles that must be in the App Store and Google Play with in-app purchases from day one. Those usually belong in a native build. If you are still deciding what the first version should contain, our guide to planning a game prototype and vertical slice covers that step.

#What WebGL and Three.js actually do

WebGL is the browser API that gives JavaScript access to the graphics card. It is low level: you supply vertex buffers, shader programs and textures yourself. All current major desktop and mobile browsers support it. Newer browsers also offer WebGPU, a more modern graphics API, but support still depends on the browser and the device, so check its current status before you rely on it.

Three.js is an open-source JavaScript library on top of WebGL and, in recent versions, WebGPU. It gives you a scene graph, cameras, lights, materials, a glTF model loader, animation playback and post-processing. Three.js is a rendering library. It has no built-in physics, no scene editor, no networking and no rules for a game loop. You add those yourself: a physics library such as Rapier or cannon-es, your own state management, an audio layer, and a build tool such as Vite. You get full control and a small runtime, and more decisions sit with your team.

#Budget the download before you build

In a browser game, loading is the first thing the player experiences. Set an asset budget at the start and check every build against it.

• Models: use glTF in its binary .glb form, and compress geometry with Draco or meshopt. Remove faces the camera never sees and match polygon counts to how close the camera gets.
• Textures: these are usually the heaviest files. Use the smallest size that looks right on screen, and consider KTX2 with Basis Universal compression., which stays compressed in GPU memory.
• Audio: compress music and effects, and stream long tracks instead of loading them up front.
• Code: import only the Three.js modules you use and let the bundler drop the rest.
• Loading order: load what the first screen needs, let the player start, and fetch later levels in the background.

Serve every file compressed, with long cache lifetimes on versioned file names, so returning players download almost nothing. To find your real number, throttle the browser's network panel to a mobile connection and time the click to the first playable frame.

#Frame rate on ordinary laptops and phones

Your development machine is the fastest device you will test on. Test early on an older laptop with integrated graphics and on a mid-range Android phone. The usual costs and their fixes:

• Draw calls. Every separate mesh and material costs CPU time. Merge static geometry, share materials, and use instancing for repeated objects such as trees or coins.
• Pixel count. Cap the renderer's pixel ratio on high-density phone screens.
• Shadows and post-processing. Real-time shadows, bloom and screen-space effects are expensive. Bake lighting into textures where the scene allows it, and offer a lower quality setting.
• Garbage collection. Creating new objects every frame causes stutter. Reuse vectors and keep pools of objects in the game loop.
• Heat. Phones slow down when they get warm, so a game that runs well for two minutes can drop frames after ten. Test long sessions, and consider capping the frame rate.

Pause rendering when the tab is hidden. requestAnimationFrame already slows down in background tabs, but your audio and timers may keep running. Dispose of geometries, materials and textures when the player leaves a level, because the browser will not free them for you.

#Input, reduced motion and accessibility

A link can be opened on anything, so plan input for several devices from the start. Pointer Events let mouse, pen and touch share one code path. On touch screens, add on-screen controls sized for thumbs and keep them clear of the edge gestures the browser uses itself. On keyboards, allow key remapping or at least sensible alternatives. The Gamepad API works in modern browsers. For first-person controls, the Pointer Lock API hides and captures the cursor, but it only starts after a user gesture, and browsers also wait for a gesture before they play sound. A simple "Tap to start" screen solves both.

Camera shake, fast panning and flashing make some players dizzy or ill. Operating systems have a reduce-motion setting, and the browser exposes it through the prefers-reduced-motion media query. Read it in JavaScript and respond: soften camera movement, turn off shake and screen flashes, and drop parallax backgrounds. Offer an in-game toggle as well, since not every player sets the system option. Also build menus and the HUD in HTML where you can, so text stays readable, and avoid colors that rely on red and green alone.

#Limits compared with Unity or Godot web exports

Unity and Godot can both export to the web through WebAssembly. That route makes sense when the same game also ships on other platforms, or when the team already works in one of those editors.

	Three.js	Unity or Godot web export
Download size	Small runtime, and you control every byte	The engine runtime adds to every download
Tools	Code first, with no visual editor of its own	A full editor with physics, animation and UI tools
Web integration	Lives in the page and shares its HTML, CSS and analytics	Runs inside a canvas and talks to the page through a bridge
Other platforms	The web, unless you wrap it in an app	One project can target desktop, mobile and consoles
Best for	Short, light games and 3D on websites	Larger games where the web is one of several targets

Engine web exports also have their own requirements, such as specific server headers for multithreading or limits on mobile browsers. These change between versions, so read the current export documentation for the engine you pick. With all three options the ceiling is lower than in a native build: the browser limits memory, and you cannot count on the same GPU features as a desktop game.

#How PN Scripts can help

PN Scripts builds games in Unity, Unreal, Godot and WebGL with Three.js, along with the online services behind them when a game needs accounts, scores or saves. For a browser game, the asset budget and the target devices go into the written scope before work starts. You can see how we run game projects on the game development page.