The file proxy and caching

Your game runs in an iframe with an opaque origin, and browsers don't store large downloads of such frames in their HTTP cache. To make big files cache anyway, the SDK routes your game's fetch() calls for its own files through the platform page, which downloads them and keeps complete files in the browser's Cache API. The next time a player starts the game, they come straight from the cache: a 100 MB file loads in a fraction of a second instead of downloading again.

You don't change your code: fetch("level1.bin") and WebAssembly.instantiateStreaming(fetch("game.wasm")) just work.

What is coveredCopy Anchor Link

• fetch() (and the wasm loaders built on it) for URLs inside the folder your index.html lives in. Everything else keeps using the browser's normal fetch.
• GET and HEAD, including Range requests (they are answered from the complete file).

What is not coveredCopy Anchor Link

• Element loads: <script>, <link>, <img>, <audio>/<video>, dynamic import(). They work, but aren't cached by this mechanism.
• XMLHttpRequest. Not proxied yet, so engines that load their data with XHR only benefit once support lands.
• Web workers: a fetch() inside a worker isn't proxied.

Load large assets with fetch() to get the benefit.

Rules and limitsCopy Anchor Link

• The platform only ever fetches files below your version's folder. A request that tries to leave it (../, encoded separators such as %2e/%2f, a token query parameter, ...) is refused: the fetch promise rejects with a TypeError saying request refused.
• A response is cached only if it is a complete 200. Partial downloads are never stored.
• Caches are per game version. A new version starts with a fresh cache, and the browser may evict a cache if storage runs low (the platform asks the browser to keep it).
• Response headers reach your game only if they are content-type, content-length, content-range or last-modified.
• At most eight downloads run at the same time per game; the rest queue.
• Data is streamed to your game as it reads it. While a file is being downloaded for the first time, the platform never reads more than a few megabytes ahead of the slower of "your game reads it" and "the browser stores it", so memory use stays small even for very large files.
• Files are written to the cache one at a time. If a large file finishes downloading while another one is still being written, it isn't cached on that run (your game is never held up for it) and is cached on a later one. Small files wait their turn and are cached as usual.

Do I need to do anything to benefit?Copy Anchor Link

Make sure the SDK is the first script (a fetch that happens before the SDK is installed isn't proxied, and so isn't cached). mugon publish warns when it isn't.