WebGPU: which mobile titles should ship web-native now

Direct answer — which mobile titles should ship web-native now that WebGPU is everywhere? WebGPU is supported by roughly 84% of tracked browser usage and, since Safari 26, is enabled by default on iOS, iPadOS and macOS — the last meaningful gap is closed. But GPU capability is no longer the binding constraint for web-native mobile distribution: initial download size, thread availability and Android GPU coverage are. Ship web-native now for hyper-casual, puzzle, idle/merge, card, .io-style real-time multiplayer and short-session stylised 3D — titles that can land under a 20 MB initial download and run single-threaded. Hold back long-session mid-core, open-world 3D and anything that depends on multi-threaded physics or a trusted client, because the engine-side WebGPU backends most studios actually use are still labelled experimental.

The web-native conversation changed tone in the last eighteen months, and a lot of that tone is wrong in a specific way. “WebGPU is here, so mid-core can ship on the web now” is not what the data says. What the data says is narrower and more useful: the graphics ceiling moved up, while the delivery ceiling barely moved at all. If you plan a web-native channel around the first fact and ignore the second, you will ship a title that renders beautifully and never gets played, because it never finished downloading.

This is a decision guide, not a trend piece. If you want the channel-level view — portals, CPMs, ad mediation, the 12-week launch sequence — that lives in our web-native distribution guide, and the revenue terms behind each surface are broken down in our HTML5 monetisation guide. This article is about whether your title’s technical shape survives contact with the browser.

What WebGPU actually changed — and what it didn’t

The standardisation and shipping picture, as of July 2026:

• The WebGPU specification is a W3C Candidate Recommendation Draft dated 14 July 2026 — stable enough to build against, still formally pre-Recommendation.
• Chrome has shipped WebGPU on Mac, Windows, ChromeOS and, critically for mobile, Android 12+ on ARM, Qualcomm and Intel GPUs since Chrome 121, per the gpuweb implementation status wiki.
• WebKit shipped WebGPU in Safari 26.0 for macOS, iOS, iPadOS and visionOS, enabled by default. That is the event that changed the arithmetic: iOS Safari was the last major surface without it.
• Firefox has shipped on Windows (141+) and macOS (147+); Firefox on Android is still disabled by default, with Mozilla expecting to do Android work during 2026.
• Samsung Internet supports it from version 24.
• caniuse.com puts the aggregate at 82.17% full support plus 1.46% partial — about 84% of tracked global browser usage.

So far, so good. Here is what did not change.

The headline WebGPU performance wins mostly come from patterns that gameplay scenes don’t have. Babylon.js’s snapshot rendering is the clearest example. The engine’s own documentation says the perf improvements “can be quite large, especially when using the fast SR mode” — and in the same page states that “the scene should be mostly static for this mode to work as expected”, that adding or removing meshes won’t work, and that in fast mode even animating a light breaks the snapshot. That is a fantastic optimisation for a product configurator. It is not something a match-3 with a spawning board or a shooter with pooled enemies can lean on. Read WebGPU demo benchmarks with that filter on.

Engine support is real but not production-default. Unity’s own manual for the 6.3 LTS line still states plainly that WebGPU is experimental and “not supported by all browsers and devices”. PlayCanvas has arguably the most mature WebGPU renderer of the web engines, but it shipped as an opt-in beta with the stated plan that “once we are satisfied WebGPU support has matured enough, it will become the default” — and two years later it is still not the default. Godot’s web export is genuinely usable, but compute shaders and the Forward+ renderer are not on the table in the browser.

The practical read: WebGPU is an optimisation layer you opt into, on top of a WebGL 2 baseline you must still ship. Any title plan that treats WebGPU as the floor rather than the ceiling is mis-scoped. That is also why we treat web-native as an engineering decision before a channel decision inside our interactive practice — the channel economics only matter once the build passes the delivery gates below.

The three constraints that actually decide web-native fit

1. Initial download budget — the real gatekeeper

Portals do not negotiate on this, and the numbers are public.

Surface	Initial download	Other hard limits
Poki	Target under 8 MB	16:9 canvas, scaling to 640×360 / 836×470 / 1031×580
CrazyGames (general)	≤ 50 MB	Total files ≤ 250 MB, max 1,500 files
CrazyGames (mobile homepage eligibility)	≤ 20 MB	Time to reach gameplay ≤ 20 seconds

Sources: Poki requirements, CrazyGames technical requirements.

That 20 MB mobile-homepage threshold at CrazyGames is the single most useful number in web-native planning, because it is where discovery placement actually lives. WebGPU does nothing for it. Your WASM heap, your texture atlases and your audio bank are the same size whichever graphics API you bind.

2. Threads — and the header you probably can’t set

Multi-threaded WASM requires SharedArrayBuffer, which requires cross-origin isolation via COOP and COEP response headers. Godot’s engineering team stated the operational problem precisely in their web export progress report: “Most Web games are being published on third-party publishing platforms where the game authors may not even be able to set the required headers for SharedArrayBuffer support.” Their conclusion was to make single-threaded export the practical default.

Translate that into a design constraint: on portal-distributed web builds, budget for one thread. Physics solvers, navmesh queries, asset decompression and gameplay logic share a single core. Titles whose frame budget assumes a worker pool do not port cleanly; titles that are server-authoritative (most .io games) or genuinely light on simulation do.

3. Memory and GPU coverage — the two silent failure modes

Memory64 shipped in Chrome 133 and Firefox 134, so a WASM linear memory above 4 GB is now technically possible. It is also not free: SpiderMonkey’s team measured that the wasm64 penalty “can range from just 10% to over 100% — a 2x slowdown just from changing your pointer size”. For a game, that is a bad trade. Stay in wasm32 and treat 4 GB as a hard ceiling you should be nowhere near on mobile.

On GPU coverage, the gpuweb status page is explicit that Chrome’s Android support landed for ARM, Qualcomm and Intel GPUs, while Samsung’s Xclipse GPUs are still listed as in progress. In practice that means a meaningful slice of Exynos-based Galaxy devices will fall back to WebGL 2. If your title only holds frame rate under WebGPU, you have shipped a title that is broken on hardware you can’t enumerate in advance. Query the adapter, fall back cleanly, and QA the fallback path as a first-class build.

Which mobile genres should ship web-native now?

Readiness here means: can this genre clear the download, thread and fallback gates without a rewrite?

Genre	Web-native readiness	Deciding factor	Move now?
Hyper-casual / arcade	Ready	Fits Poki’s 8 MB budget; WebGL 2 baseline is sufficient	Yes — portals first
Puzzle, match, word	Ready	Small asset footprint, short sessions, single-thread friendly	Yes
.io-style real-time multiplayer	Ready	Server-authoritative; thin client; WebGPU helps with draw-call volume	Yes
Idle, merge, management	Ready	UI-bound rather than GPU-bound	Yes
Card, board, social casino	Ready	Trivial render load; payment flow is the real design work	Yes
Short-session stylised 3D (racing, arena, runner)	Conditional	Passes only with an aggressive asset budget; WebGPU is genuinely load-bearing here	Pilot one title
Mid-core RPG / 4X / strategy with large content	Not yet	Initial download and streaming architecture blow past every portal limit	First-party PWA only
Open-world or long-session 3D (20+ min)	Not yet	Thermal throttling, memory ceiling, browser tab lifecycle	No
Competitive shooters with anti-cheat requirements	Not yet	Client trust model doesn’t survive the browser	No

Two nuances worth internalising. First, “not yet” is not “never” — mid-core titles can still run a first-party web build on your own domain, where you control headers, cache policy and load sequencing, and where the 8 MB portal rule doesn’t apply. That is a retention and DTC play, not a discovery play. Second, the conditional row is where WebGPU actually earns its keep: short-session stylised 3D is the only band where the API’s draw-call and compute advantages translate into a title that ships instead of one that doesn’t.

If you’re deciding where a web-native channel sits relative to alt-stores, OEM and carrier billing rather than whether to build it at all, the sequencing logic is in our multi-channel distribution framework. And if the target surface is Telegram, TikTok or Messenger rather than a games portal, the constraints shift again — that channel is covered in the instant-games playbook.

How do you validate readiness in two weeks?

Do not commission a port on a genre table. Run a measurement sprint and let the numbers decide.

1. Days 1–3 — build a size floor. Export a stripped build with no content: engine runtime, one scene, one input. Compress with Brotli. If the empty build is already above 15 MB, your engine choice is the decision, not your art budget.
2. Days 4–6 — measure time-to-first-input, not load time. On a mid-range Android device over throttled mobile data, measure from URL open to the first frame the player can act on. CrazyGames’ ≤ 20 second gate to reach gameplay is the outer bound; portals that feature titles are looking for a fraction of that.
3. Days 7–8 — audit thread dependencies. Grep for worker usage, SharedArrayBuffer, and any engine subsystem that assumes a job system. Assume you cannot set COOP/COEP headers on partner surfaces.
4. Days 9–11 — test the fallback, not the happy path. Force WebGL 2 and measure frame time on a Samsung Exynos device and a three-year-old mid-tier Android. This is where web-native ports die quietly.
5. Days 12–14 — memory ceiling on iOS Safari. Run a 20-minute session and watch for tab reloads. Mobile Safari reclaiming your tab mid-session is a retention bug that never appears in desktop QA.

If steps 1, 2 and 4 pass, you have a web-native title and the remaining work is channel work. If step 1 fails, the honest answer is that this title is not a web-native title this year — and the correct move is to pick a different one from your catalogue rather than to spend two quarters fighting an engine.

FAQ

Is WebGPU required to ship a web-native mobile game in 2026?

No. WebGL 2 remains the baseline you must ship, because Firefox on Android and Samsung Xclipse GPUs on Chrome do not yet have WebGPU enabled. Treat WebGPU as an opt-in performance path with a mandatory WebGL 2 fallback, and QA the fallback as a first-class build.

Does WebGPU let mid-core titles ship on game portals now?

Not by itself. Portal gates are about delivery, not rendering: Poki targets an initial download under 8 MB, and CrazyGames requires ≤ 50 MB initially with ≤ 20 MB for mobile homepage eligibility. WebGPU does not reduce build size, so mid-core titles usually remain first-party PWA candidates rather than portal candidates.

Can I use multi-threaded WebAssembly on a game portal?

Usually not. Multi-threaded WASM needs SharedArrayBuffer, which requires COOP and COEP headers you generally cannot set on third-party publishing platforms. Godot’s team cited exactly this when making single-threaded export the practical default. Plan for a single-thread frame budget on portal builds.

Is Unity’s WebGPU backend production-ready?

Unity’s own 6.3 manual still describes WebGPU as experimental and not supported by all browsers and devices. It is usable for pilots and prototypes, but a commercial launch plan that depends on Unity’s WebGPU path carrying performance is taking on real schedule risk today.

Should I use WebAssembly Memory64 to get past the 4 GB limit?

For games, almost certainly not. SpiderMonkey measured a wasm64 penalty ranging from 10% to over 100% depending on workload. If a title needs more than 4 GB of linear memory in a browser tab, the right conclusion is that it is not a web-native title, not that it needs 64-bit pointers.

---

If you’re holding a catalogue and trying to decide which two titles get a web-native build this year — and which portal, PWA or embedded surface each one belongs on — that’s the conversation our interactive practice exists for. Talk to us with your build sizes and target devices, and we’ll give you a straight read on which titles clear the gates.