Optimizing for Web

The simple goal

A good Buncha Games upload is a small, clean browser build that reaches the first playable moment quickly and behaves well inside the Buncha Games iframe.

Do not optimize blindly. First build the game, inspect the output size and largest files, test from a local static server, then fix the biggest obvious problems.

• Upload the browser-playable export, not the source project.
• Keep index.html at the ZIP root.
• Keep source folders, editor files, secrets, node_modules, caches, and server-only files out of the ZIP.
• Test audio, input, loading, and canvas scaling over HTTP before upload.
• If you claim mobile support, test touch input and readable UI on mobile-sized viewports.

Shared web checklist

• Run a size audit on the final export folder and list the largest files before zipping.
• Compress or resize large PNGs. Prefer WebP or AVIF for large backgrounds and UI art when visual quality holds up.
• Avoid shipping WAV files unless there is a specific reason. Use browser-friendly compressed audio for music and sound effects.
• Keep source/reference art out of shipped folders. Do not copy all of public/ if it contains concept art, source sheets, prompts, screenshots, or old generated assets.
• Load the first menu or first playable screen first. Load match-only maps, effects, audio, and rare screens later.
• Use a static-server preview for QA. Opening index.html with file:// can hide real hosting, MIME, compression, and asset-path issues.
• Handle browser audio unlock from a real click/tap before starting music or Web Audio playback.
• Use the Page Visibility API or engine equivalent to pause or reduce rendering, simulation, audio, and network work when the tab or iframe is hidden.
• Measure before deeper refactors. If the build still feels slow after obvious asset cleanup, use browser performance tools to confirm whether the bottleneck is download size, JS parse, image decode, GPU upload, memory, or game logic.

Unity WebGL

• Package Unity's generated WebGL export folder: index.html, Build/, TemplateData/, StreamingAssets/ if present, and generated compressed files.
• Use a normal release build for upload. Leave Development Build off unless you are debugging a validation issue.
• Keep Unity-generated .br or .gz files with the export. Buncha Games can serve compressed Unity files with matching content-encoding headers.
• Use Decompression Fallback only when your test server or temporary host cannot serve compressed files correctly. It can make the build easier to test, but it is not the ideal production delivery path.
• Review WebGL Player Settings before upload: managed stripping, code optimization, exceptions/stack traces, texture compression, and data caching.
• Reduce texture sizes and audio sizes before code-level refactors. Large textures, uncompressed audio, and first-scene asset pressure are common Unity WebGL load problems.
• If you use AssetBundles or Addressables, test that their URLs, compression, and loading sequence work from the exported browser build and Buncha Games iframe.
• If you use threads or advanced browser features, document the requirement and test the deployed environment. Keep the first upload simpler unless the game truly needs those features.

Godot Web

• Package the Godot Web export files together: index.html, .js, .wasm, .pck, audio worklet/worker files if generated, and compressed files if generated.
• Use Godot export filters so unused resources, editor-only files, source art, and debug assets do not ship in the browser build.
• Godot 4 C#/.NET projects cannot currently export to Web. Use GDScript or another supported web-export workflow for Buncha Games.
• Prefer a non-threaded web export for the first upload unless the game specifically needs threads. Threaded exports can require cross-origin isolation behavior that should be tested explicitly.
• Test the exported folder over HTTP, not file://, to catch MIME, compression, audio, worker, and asset-loading issues.
• For broad compatibility, choose renderer/settings based on the browsers and devices you actually plan to support, then test that target in the Buncha Games iframe.
• Treat PWA/offline features as an intentional product choice, not a default optimization. Buncha Games hosts the game page and wrapper around your export.

Native Web, Phaser, Three.js, and Vite

• Use the production build output, usually dist/ or build/. Zip the contents of that folder so index.html is at the ZIP root.
• For Vite projects, use relative paths such as base: "./" when the build needs to run from a hosted subpath.
• Use an explicit runtime asset allowlist when possible. Avoid shipping an entire public/ folder if it contains design refs, source sheets, screenshots, old exports, or prompt artifacts.
• Split large JavaScript only after measuring. Asset cleanup usually wins first; code splitting helps when the first JS chunk delays menu boot or first play.
• For Phaser, use Scale Manager intentionally, stage loaders by scene, avoid preloading match-only assets in boot, and use atlases where they reduce requests or texture churn.
• For Three.js, use InstancedMesh for repeated objects, cap device pixel ratio, clean up geometries/materials/textures when scenes change, and disable expensive postprocessing on low-end devices.
• For WebGL games, test texture dimensions, mipmaps, preserveDrawingBuffer usage, and GPU memory behavior before promising broad mobile support.
• For multiplayer games, keep service IDs public-safe, disclose connected services, and test offline/error states so the game does not fail before the menu if a service is unavailable.

Buncha Games readiness

• The ZIP root should contain index.html directly. If opening the ZIP shows a folder first, re-zip the contents of the export folder.
• Keep listing media separate from the playable runtime unless the game actually uses those files at runtime. Thumbnail, hero, screenshots, and trailers belong in game media records, not inside the game ZIP.
• Use Connected Services for multiplayer, storage, leaderboard, analytics, cloud save, or API hosts. Do not include direct ad scripts, direct payment scripts, crypto integrations, service-role keys, or private credentials.
• Test at least two desktop layouts before review: a common laptop viewport and a wide desktop viewport. Check menu readability, HUD scale, controls, audio unlock, and first playable screen.
• Only mark mobile support when touch input, mobile layout, orientation behavior, and mobile performance have been designed and tested. A desktop game that merely renders on a phone is not necessarily mobile-ready.
• Add Buncha Games SDK hooks when you want player identity, analytics, Buncha Credits, wallet/IAP, entitlements, ads, and sandbox testing. SDK integration is beneficial for deeper platform features, but the uploaded web build still needs to run cleanly as a browser game.
• Before review, open the Sandbox preview and confirm the game loads inside the Buncha Games wrapper, not just from your local engine/editor.

Optimization report template

If you ask an AI coding agent or teammate for an optimization pass, have them return evidence in this shape. It keeps the advice practical and makes review faster.

# Web Build Optimization Report

## Engine And Build Context
- Engine/runtime:
- Build command:
- Output folder:
- Buncha Games target:

## Optimizations Already Implemented
- Asset packaging:
- Image/texture choices:
- Audio choices:
- Loading strategy:
- Runtime/frame-pacing:
- Mobile/input posture:

## Current Build Evidence
- Output folder size:
- ZIP size if created:
- Largest files:
- JS/CSS/WASM/data size:
- External/connected services found:

## Recommended Optimizations
- Do now:
- Do after measuring:
- Later / optional:

## Buncha Games Readiness
- index.html at ZIP root:
- Source/editor/secrets excluded:
- Static-server smoke test:
- Desktop iframe QA:
- Mobile QA if claimed:
- SDK hooks present or planned:
- Connected services disclosed:

## Commands Or Tests Run
- Build:
- Static server:
- Browser/screenshot checks:
- Size audit: