How to Reduce HTML5 Game Size for Portals: What to Check and AI Prompts That Help

PlayKovo accepts a game zip up to 250 MB (600 MB extracted). That is an upload limit, not a target. Players on a phone and a mobile connection judge your game by how long the first screen takes, and every extra megabyte before that screen costs you players. This guide covers what to measure, what usually makes a game heavy, and how to shrink it. At the end there are prompts you can paste into an AI coding assistant if you build your game with AI.

Do not guess. Open your game in Chrome, open DevTools, go to the Network tab, tick "Disable cache" and reload. Look at two numbers:

• Transferred before the first playable screen. This is what the player waits for. Aim to keep it as small as you can; a few MB is a good goal for a casual game.
• Total size of the game. This matters for storage and for games that load levels later.

Sort the requests by size. In almost every game, three or four files are responsible for most of the weight. Fix those first.

Images are the most common cause of a heavy game.

• Convert PNG and JPG to WebP for UI, backgrounds and sprites. It is usually much smaller at similar quality and works in current browsers.
• Do not ship a 4096 px texture for something that is drawn at 256 px on screen. Resize to the largest size the game actually shows.
• Pack many small sprites into a sprite atlas. Fewer files also means fewer requests.
• For 3D games, GPU texture formats such as KTX2 / Basis reduce memory use as well as download size, but they need a loader in your engine. Check your engine docs first.
• Remove images that are not used. Old test assets stay in the project folder and end up in the zip.

• Music is often the largest single file. Lower the bitrate (for most casual games, a modest bitrate is enough) and use mono for effects.
• Use compressed formats (OGG or MP3/AAC), never WAV, for anything that ships.
• Cut silence at the start and end of each clip.
• Load music after the first screen is playable; only the sounds needed at the start have to be there immediately.

• Use glTF/GLB and compress meshes with Draco or meshopt if your engine supports them.
• Reduce polygon counts for objects that are small on screen.
• Reuse one model many times instead of exporting copies.
• Remove animations and materials that the game never uses.

• Minify your JavaScript and build in production mode.
• Do not ship source maps in the final zip unless you need them.
• Check which libraries you really use. A whole physics or UI library imported for one function is a common waste.
• Subset fonts to the characters you need, or use a font format like WOFF2. Do not include five weights when the game uses one.
• Delete unused scenes, levels and debug tools before you zip.

A smaller game is good, a game that starts early is better. Split loading into two parts:

• Needed to play the first level: load these first and show a clear loading bar.
• Everything else (later levels, extra skins, bonus music): load it in the background or on demand.

Also make sure the files are compressed by the server. Most hosting does this for text files such as JS, JSON and HTML, but already compressed images and audio gain nothing from it.

• How long before the player can touch the game on a mid-range phone, not only on your computer.
• Whether the game works on a slow connection without freezing on a white screen.
• Memory use: a game that crashes the mobile browser tab is rejected faster than a big one.
• That the zip contains only what runs: no duplicate folders, no source project files (.psd, .blend, .fbx), no leftover test builds.

Our developer blog has more on start time and caching, and the submission rules list what is checked on upload.

If you build with an AI assistant (Claude, ChatGPT, Cursor, Copilot and similar), these prompts give it a clear job. Replace the text in brackets. Review what it changes and always test the game afterwards, because AI tools sometimes remove files that are actually used.

Prompt 1: audit

I have an HTML5 game in this project, built with [Phaser / Three.js / Unity WebGL / Construct / plain JS]. It will be uploaded to a game portal and must load fast on mobile.
Do not change anything yet. Audit the project and give me:
1. A list of the 20 largest files in the final build output with their sizes.
2. Which of them are loaded before the first playable screen.
3. Assets in the project that are never referenced by the code.
4. Libraries or modules I include but barely use.
Then propose a plan ordered by the biggest size saving first.

Prompt 2: images

Convert the images used by this game to WebP, resized to the largest size they are drawn at in the game (check the code for the real display size). Keep transparency. Update every reference in the code and keep a list of what you changed. Do not touch images that are not referenced. Tell me total size before and after.

Prompt 3: audio

Check all audio files. Re-encode music to a lower bitrate OGG or MP3, convert sound effects to mono, trim silence, and make sure no WAV files remain in the build. Move music so it loads after the first screen is playable. Keep the game sounding the same in normal play. Report the size before and after for each file.

Prompt 4: build

Configure the production build for a small output: minify JS, remove dead code, remove source maps and console logs, and make sure development-only tools are not included. Show me the build size before and after and list anything you removed that I should double check.

Prompt 5: lazy loading

Change the loading flow so that only what is needed for the first level loads at start, with a loading bar. Later levels, skins and extra music should load in the background or when needed. Keep the game working if the player is quick and reaches the next level before loading finishes (show a short wait instead of an error).

Prompt 6: final check

Before I zip this game, check that: index.html is at the root of the zip, all paths are relative, there are no source project files (.psd, .blend, .fbx, .unitypackage), no duplicate folders, no leftover test builds, and every file in the folder is actually used. List anything suspicious instead of deleting it.

• Network tab measured, biggest files found.
• Images in WebP, resized to real display size.
• Audio compressed, music loaded after the first screen.
• JS minified, no source maps, unused libraries removed.
• Only first-level assets before the first playable screen.
• Tested on a real phone, not only on desktop.

When you are ready, you can upload your game from the developer panel.