What makes a browser game good on a slow connection

A browser game has one advantage over everything else in games: there is nothing to install. You click a link and you are playing. That advantage disappears entirely if the link takes twenty seconds to become a game.

Most browser games are built and tested on a developer's machine with a fast connection, which is roughly the least representative environment possible. The result is a category of game that works beautifully in a demo and poorly in the situation it was supposedly designed for — a phone on a patchy connection, a school laptop, a shared computer, a borrowed tablet with a full storage drive.

Building for that situation is not mainly about optimisation tricks. It is mostly about a handful of decisions made early, most of which are about restraint.

The first five seconds decide everything

There is a fairly brutal relationship between load time and whether anyone plays your game at all. Someone who clicked a link out of mild curiosity has very little invested. A blank screen for eight seconds is enough for them to leave, and they will not describe this as "the game was slow" — they will not remember the game existed.

This means the load budget is not a technical target, it is the whole design constraint. It shapes what kind of game you can make, and pretending otherwise produces games nobody finishes loading.

What that budget means in practice:

Something has to appear almost immediately. Not a loading bar sitting on a blank page — actual content. A title, the game's name, a shape. The gap between "I clicked" and "something is here" is where people leave, and it is closable with a few kilobytes of HTML and CSS that do not wait for anything else.

The first playable moment should not require the whole game. A game that loads every level, every sound, and every sprite before the first frame is making everyone wait for content most of them will never reach. Load enough for the first thirty seconds of play, and fetch the rest while they are playing it.

Sound is not a launch dependency. Audio files are usually the heaviest assets in a small browser game and the least necessary for the first moments. Load them late, after the game is already interactive. A game that is playable without sound for four seconds is better than one that is silent and frozen for four seconds.

Weight is a design decision, not a build step

The instinct when a game is too heavy is to reach for compression and minification. Those help at the margin. They do not fix a game that is heavy because of what it is.

The engine question

The single biggest weight decision is whether to use a game engine at all. A full engine is often several hundred kilobytes of JavaScript before you have written a line of your own game — a reasonable trade for something with physics, scene management, and a large asset pipeline, and an absurd one for a puzzle game that draws coloured rectangles.

For a small 2D game, the browser already provides the things you need: a canvas, a render loop, input events, and local storage. It is genuinely less work than people expect, and the entire game can end up smaller than the engine would have been.

Fonts and images are where the weight actually is

Code is rarely the problem. The problem is usually one of these:

• A display font, loaded as a full character set, for six words of UI. A single weight, subset to the characters actually used, is a fraction of the size. Often the system font stack is fine and costs nothing.
• PNG spritesheets for art that is geometric enough to draw or describe as vectors. SVG or plain canvas drawing commands can be a tenth of the size.
• Uncompressed audio. A short compressed loop instead of a long uncompressed track is the difference between a game that loads on a phone and one that does not.

Generate what you can

Procedural content is often framed as a way to make games bigger. On a bandwidth budget it is the opposite: it is a way to ship less. A background pattern drawn by twelve lines of code weighs twelve lines of code. The same background as an image weighs a hundred times more.

Design for interruption

A slow connection is rarely just slow — it is intermittent. It works, then it does not, then it does again. Games built on the assumption of a stable connection break in ugly ways when that happens, usually at the worst moment.

The fix is to not need the connection during play. A game that loads once and then runs entirely in the browser cannot be interrupted by the network, because it is not using it. Scores go to local storage. Progress goes to local storage. Nothing is lost when the signal drops in a lift.

This has a second benefit that matters more than it sounds: it means the game does not need an account. No account means no sign-up screen between the click and the play, which removes both a network dependency and the most common reason people abandon a casual game before starting it.

Modest hardware, not just modest bandwidth

The devices on slow connections are usually not fast devices either. A few things follow from that.

Frame rate should degrade, not stutter. A game locked to 60fps that cannot hit it becomes unplayable. A game that adapts — fewer particles, simpler effects, a lower internal resolution — stays playable and merely looks a bit plainer. Players notice unresponsive controls immediately and reduced visual effects almost never.

Battery is part of the experience. A game that runs a full render loop while nothing is moving drains a phone for no reason. Pausing when the tab is hidden is a few lines of code and is simply good manners.

Memory limits are real. A mid-range phone with many tabs open has much less headroom than a laptop. Games that allocate generously get killed by the browser, which the player experiences as the game crashing.

Ten seconds to understand

There is one more constraint that belongs with the technical ones, because it comes from the same place. Someone who arrived from a link, on a phone, during a gap in their day, will not read instructions. If the game is not comprehensible within about ten seconds of becoming playable, it does not matter how fast it loaded.

Practically this means the first level teaches the game by being simple enough to survive experimenting with, controls that match what people already expect, and no tutorial screen standing between the player and the first move. If a game needs a wall of text to make sense, the answer is almost always a simpler first level rather than better instructions.

The standard OdDraw is held to

These are the rules being applied to OdDraw, the game hub currently in development: playable quickly on a mid-range phone over a slow connection, working with keyboard or touch, understandable in about ten seconds, and no account before the first play.

They are restrictive rules, and they rule out a lot of otherwise good ideas. That is the point of having them. A short list of games that all work on the device someone actually has is worth more than a long list where half of them stutter on anything but a desktop.

There is more about how projects here get chosen and built in the studio's approach to shipping, and the about page covers why the studio makes both games and tools rather than picking one.