Why load time decides the success of a web game
A web game has no install step to win the player’s commitment. The player clicks a thumbnail, waits, and either starts playing or leaves for the next game. Every second of loading is a second in which they can change their mind.
Data from the wider web shows how sensitive people are to waiting. According to Google data from 2016, 53% of mobile site visits are abandoned if a page takes longer than three seconds to load. Google’s Milliseconds Make Millions report adds that as load time grows from 1 to 3 seconds, the probability of a bounce increases by 32%, and from 1 to 5 seconds by 90%. These studies measured websites, not games, but web game portals describe the same behaviour:
- Poki recommends that the initial download of a web game should not exceed 5 MB and 8 MB in total, and its requirements note that players tend to move to another game if loading takes more than 10 seconds.
- CrazyGames requires an initial download of 50 MB or less, and 20 MB or less for a game to be eligible for the mobile homepage. Its launch guide says top-performing titles typically load in under 10 seconds and have a build size below 20 MB.
- Facebook Instant Games, as summarized in the Defold size optimization manual, should start in less than 5 seconds and preferably less than 3 seconds.
At Codeward we optimize HTML5 games in many client projects, both games we build and games we port from other engines. The techniques below are the ones that consistently make the biggest difference. Most examples use Defold, but the principles apply to any engine.
Measure first: what does the player really download?
Optimization starts with a measurement, not with a guess. The size of the build folder on your disk is not what the player downloads: servers compress files, and browsers cache them. Open the game in Chrome, disable the cache in DevTools, and check the Network tab for the total transferred size and the time to the first playable frame. Repeat it with network throttling to simulate a slower mobile connection, and on at least one older phone.
Then check what the build contains. In Defold, the build report lists every resource and its size, so you can see which textures, sounds or fonts dominate. Portals measure the moment the player can actually play: CrazyGames, for example, measures the initial download up to the first gameplay start event triggered through its SDK, not up to the end of a loading bar.
A reference project: the Defold sample for Poki
To show these techniques in a complete game, I created Starbreaker, the official Defold sample for Poki. It is an open source 3D space shooter with missions, a shop, settings, Poki SDK integration and an in-game guide with tips for web developers. Its configuration is a good map of what to optimize:
- Live Update with a deferred ZIP. Fonts for Persian, Cyrillic and CJK languages, and the music, are placed in excluded collection proxies. They are packed into a separate Live Update archive, downloaded after the game starts and mounted only when needed.
- Graceful failure. The deferred loader handles a failed download: the game keeps working with default content and can retry later, so a lost connection never blocks the first level.
- Texture profiles. The UI atlas uses Basis Universal compression with a maximum size of 1024 pixels, while small VFX textures are limited to 256 pixels.
- Smaller engine. An app manifest removes engine modules the game does not use, such as 2D physics, the WAV decoder and video, and replaces sound recording and image loading with empty stubs.
- Fast start in the browser. WebAssembly streaming is enabled, the “Made with Defold” banner and fullscreen button are hidden, and a custom HTML loader shows progress.
- Compressed audio. All sounds and music use Ogg Vorbis, and the music tracks are compressed versions of the originals.
The in-game tips put it simply: anything an atlas, collection or factory references enters the initial download, even if it is hidden or not used at the beginning.
Deferred loading: split the game into what is needed now and later
The most effective technique is to download only what the first minute of play needs. Poki’s onboarding guide calls progressive loading one of the most important techniques for success on the web: download the menu, tutorial and first stage first, and fetch the rest in the background while the player starts.
In Defold this is done with Live Update. You mark collection proxies or collection factories as excluded, and their content is moved out of the main bundle into an archive you host next to the game. At runtime you download and mount the archive, then load the proxy asynchronously.
- Start with the first level. The bootstrap collection and the first level should reference only the resources they need.
- Defer optional content. Later levels, unlockable characters, skins, music tracks and fonts for other languages are good candidates.
- Load in the background. Start the download while the player is in the tutorial or the menu, so the content is ready before it is needed.
- Plan for failure. A failed download should fall back to default content, show a clear message and offer a retry.
Other engines have equivalents, such as Addressables in Unity or external PCK files in Godot, as described in the CrazyGames loading tips.
Textures: compression, size and atlases
Images are usually the largest part of a 2D web game, and textures also take GPU memory, which matters on budget phones.
- Texture compression. Defold texture profiles support Basis Universal and ASTC. Basis Universal is transcoded at runtime to a format the device’s GPU supports, so one file works across devices. ASTC offers block sizes from 4×4 to 12×12 texels, which means bit rates from 8 down to 0.89 bits per texel, but it is not supported by every graphics card.
- Maximum size per profile. Set a maximum texture size per group of assets. Background art may need a large texture, while icons, particles and effects rarely do.
- Correct source resolution. Export art at the size it is actually shown. An image drawn at 200 pixels on screen does not need a 2048-pixel source.
- Mipmaps only where needed. For 2D UI that is always displayed at the same scale, mipmaps add memory without improving quality.
Texture packers and atlases
Packing sprites into atlases reduces the number of files to download and the number of texture switches during rendering, which helps keep draw calls low.
- Group by usage. Keep sprites used together in the same atlas, for example one atlas for the UI, one for the first level and separate ones for later content. An atlas used by deferred content must not be referenced by the main bundle, or it will be downloaded at the start anyway.
- Trim transparent space. Packers can trim empty borders and use tight packing, which saves space in sprite-heavy games.
- Avoid giant atlases. One huge atlas with everything forces the player to download art for levels they may never reach.
External tools such as TexturePacker can prepare sprite sheets for engines that do not pack atlases automatically.
Images outside the engine: WebP and resizing
The loading screen, the HTML template, the game icon and store or portal thumbnails are downloaded before the engine starts, so they count too.
- Use WebP for images in the HTML template and loading screen, and keep a fallback only if your target browsers require it.
- Resize before export. Scale images to the largest size they are displayed at, instead of relying on the browser to shrink them.
- Keep the loading screen light. A logo and a simple background are enough. The loading screen should not be a noticeable part of the download.
Audio: the hidden heavyweight
Audio often takes more space than expected, especially music.
- Use compressed formats. Defold’s sound component supports WAV and Ogg Vorbis. Use Ogg for music and longer effects, and keep WAV only for very short sounds where it really helps.
- Short, loopable music. The Poki sample tips recommend keeping music short and loopable. One well-made loop is better than several long tracks in the initial download.
- Mono where possible. Most sound effects do not need stereo. CrazyGames also recommends Vorbis audio and forcing mono where possible.
- Defer music. Load music after the first interaction, as the Poki sample does, so the game becomes playable sooner.
Per-device assets and engine size
Not every player needs the same files. A phone with a small screen does not need the textures prepared for a large desktop monitor, and a player who reads English does not need fonts for Japanese.
- Per-device variants. Prepare lighter texture sets for mobile devices and load the heavier set only on desktop, or choose the variant at startup based on screen size.
- Language-specific fonts. Ship the fonts for the default language in the main bundle and load fonts for other scripts with Live Update, as the Poki sample does for Persian, Cyrillic and CJK.
- Remove unused engine features. In Defold an app manifest can exclude engine libraries the game does not use. The Defold build size dashboard shows the engine size for every platform and version.
- Server compression. Make sure the host serves the game files with gzip or Brotli compression. CrazyGames recommends Brotli for exported files.
Runtime performance on weaker devices
A small build that stutters is still a bad first impression. The tips in the Poki sample recommend building HTML5, testing in a browser and including an older or weaker device in the tests, aiming for stable frame pacing, a small number of draw calls and no growing memory use during a session.
- Profile before you optimize. Find the part that costs the most and simplify that first.
- Reuse objects. Creating and deleting many objects every frame causes garbage collection spikes, so reuse projectiles, particles and effects.
- Watch draw calls. Atlases, fewer materials and fewer transparent overlapping layers keep the number of draw calls low.
- Limit the update frequency where possible. Not every system needs to run every frame.
HTML5 optimization checklist
- Measure the transferred size and time to first gameplay with the cache disabled, on a throttled connection and an older phone.
- Check the build report and list the 10 largest resources.
- Make sure the first level references only the resources it needs.
- Move later levels, music, optional characters and extra fonts to deferred loading, with a fallback for a failed download.
- Apply texture compression and maximum sizes per asset group.
- Group sprites in atlases by usage and trim transparent space.
- Convert music and long sounds to Ogg Vorbis, use mono where possible and keep music short and loopable.
- Use WebP and correctly resized images in the HTML template and loading screen.
- Remove unused engine features and enable compression on the server.
- Test frame rate and memory on an older phone during a full session.
How Codeward can help
We have applied these techniques in many client projects, from new web games to existing mobile games ported to the browser, and they consistently reduce loading time and make games run more smoothly. A typical engagement starts with an audit of the current build: what the player downloads, what can be deferred and what slows the game down on weaker devices. Then we implement the changes and measure the result on your target devices.
If your game is built in another engine and is too heavy for the web, porting it to Defold may be the better path. Read our guide to porting a mobile game to web, our comparison of Defold vs Unity for web and mobile games and our article on Defold for HTML5 games, or send us a link to your game for a first assessment.