Building HTML5 games that run well on phones: a practical checklist

A browser game has one big advantage over an app: anyone can play it from a link, with nothing to install. It also has a hard constraint. It has to load quickly and run smoothly on whatever phone the player happens to have, including modest Android devices on a mobile connection.

This checklist collects the techniques that make the biggest difference.

Load fast

Players will wait a moment for a game, but not long. Every second of loading loses some of them.

Keep the first download small. Load only what the first screen needs, then load the rest while the player reads the instructions or plays the first level.
Compress images properly. Use modern formats such as WebP where supported, size images for the screen they will be shown on, and combine small sprites into sprite sheets.
Compress audio and avoid long uncompressed sound files. Background music can load after the game starts.
Show progress. A loading bar that moves is far easier to wait for than a blank screen.
Cache assets so returning players start almost instantly.

Keep the frame rate steady

A steady frame rate matters more than a high one. A game that runs at a constant 60 frames per second feels smooth; one that jumps between 60 and 30 feels broken.

Use requestAnimationFrame for the game loop, and base movement on elapsed time so that the game runs at the same speed on fast and slow devices.
Avoid creating objects every frame. Reuse objects through pools to avoid garbage collection pauses, which show up as stutters.
Draw less. Skip anything off-screen, reduce the number of draw calls, and cache static backgrounds.
Be careful with effects. Particles, shadows and blur are expensive on phones. Use them sparingly and test their cost.
Test on a modest phone, not just a flagship. If it runs well on an older mid-range Android device, it will run well almost everywhere.

Handle touch properly

Respond on touch start, not on click, so the game reacts the instant the finger lands.
Prevent unwanted browser behaviour such as scrolling, pull-to-refresh, double-tap zoom and text selection on the game area.
Make touch targets generous. Fingers are much less precise than mouse pointers.
Support both touch and mouse so that the same game works on phones and desktops.
Think about where the thumb rests. Keep important information away from the bottom corners where the player's hand covers the screen.

Scale to any screen

Phones come in many sizes and aspect ratios, and players may rotate them.

Design for a fixed logical resolution and scale it to fit the screen, preserving the aspect ratio.
Decide how extra space is used on unusually tall or wide screens: extend the background, or add borders, but never stretch the game.
Account for the device pixel ratio so graphics are sharp on high-resolution screens, while being careful about the cost on low-end devices.
Respect safe areas around notches and rounded corners.
Handle orientation changes without restarting the game.

Audio that behaves

Mobile browsers block sound until the player interacts. Start audio on the first tap.
Provide a mute button that is easy to find and remembered between visits.
Pause sound when the game is hidden, for example when the player switches apps.

Handle interruptions

Phones are interrupted constantly: calls, notifications, app switching, the screen turning off.

Pause automatically when the page becomes hidden, using the Page Visibility API, and resume only when the player is ready.
Save progress and best scores locally, so that a closed tab does not cost the player their record.
Recover gracefully if the network drops after the game has loaded.

Respect battery and data

Do not keep the loop running when nothing is moving, for example on a menu or a paused screen.
Keep total download size modest, because many players are on limited mobile data.

Make the page itself useful

Every game page should explain, in plain text, what the game is and how to play it. This helps players who prefer to read before they start, makes the page accessible to people using assistive technology, and helps search engines understand what the page is about. A short description, the controls, and a few tips are enough.

Test like a player

Test on real phones, on mobile data, in portrait and landscape.
Play for ten minutes, not one, to catch slowdowns and memory problems.
Switch apps mid-game, take a call, lock the screen, and come back.
Hand the phone to someone who has never seen the game and watch, without helping.

Key takeaways

Load the minimum first and show progress.
Aim for a steady frame rate on a modest phone, not a high one on a flagship.
React on touch start, prevent browser gestures and size targets for fingers.
Scale cleanly to any screen, start audio on the first tap, and pause on interruptions.

You can see these principles in action across the free games at games.mobitoss.com. If you are planning a browser game or interactive experience, we would be glad to help.