Choose an API after defining the browser experience
A browser may render a wheel but fail when the player opens a headset session, loses context or changes to unsupported hardware. Compare WebGL and WebGPU against workload and recovery, not as old versus new. The page must still work without advanced graphics.
WebGL has a longer implementation history; WebGPU supports newer graphics and compute tasks. In September 2026, W3C listed WebGPU as a Candidate Recommendation Draft, while MDN noted limited availability and secure-context requirements. Feature checks and tested fallback remain necessary.
Those statuses can change. At release, recheck the current standard and actual browser matrix. Maturity of the specification, browser support and device performance are separate factors.
Compare the APIs by the workload you have
| Question | WebGL path | WebGPU path |
|---|---|---|
| What does the page render? | Interactive scenes built around established browser graphics workflows. | Graphics or compute work that needs WebGPU's exposed capabilities. |
| What must be supported? | Check context availability, graphics limits and performance on target browsers. | Check secure origin, adapter availability, features, limits and implementation status. |
| What happens when unsupported? | Show a lower-detail scene or flat interface. | Fall back to WebGL or a 2D UI when the feature test fails. |
| Where does content live? | Canvas pixels need a DOM alternative for headings, rules and account controls. | Canvas pixels still need accessible semantic content outside the render surface. |
WebGPU does not automatically make an application faster. If most time goes to downloads or account services, changing graphics APIs will not address the delay. Profile first; a static rules panel with a small animation may be simpler in DOM with a modest canvas.
Build capability detection into launch
An available API does not guarantee the adapter, feature or memory budget a scene needs. Detect required capabilities at runtime. Log browser, adapter class, secure context, API version, features and context loss. Do not rely only on user-agent assumptions.
- Load an HTML shell containing title, instructions, settings and account controls.
- Check whether the chosen API and required features are available.
- initialise the renderer with a tested quality profile for the detected device.
- Load essential game objects before optional visual effects.
- Monitor context loss, memory pressure and frame-time degradation.
- Move to a defined lower-detail or non-canvas route when a check fails.
Tell users what remains available if immersive mode is unsupported. Do not keep asking them to enable experimental flags or weaken security. Supported paths should use ordinary browser settings.
Use WebXR only as one layer in the stack
WebXR lets web pages request sessions with supported immersive devices. The W3C specification covers VR/AR hardware, sensors and headsets; its June 2026 edition remained a Candidate Recommendation Draft. Permissions, browser support and session mode determine what the page can access.
A web XR product depends on both browser rendering and the device runtime. Check session mode, inputs and graphics features. A headset may support VR but not the AR mode needed for a table overlay. Define transitions for exit, focus loss, permission refusal and sleep.
Keep account controls in DOM or a browser-exposed system menu. Do not put limits, help or rules only in a canvas. After XR exit, preserve the account state and avoid sending another game action.
Canvas design has search and accessibility consequences
Canvas is a drawing area, not automatically a semantic heading, control or form for assistive tools. Put page structure in DOM and provide accessible controls for essential tasks. Google's developer guidance also favours semantic HTML and DOM text over information rendered only in canvas.
Expose rules, odds, return-to-player, stake, net position, time and safer-play settings as text. Support keyboard and touch, caption audio and let users control flashing or motion. Canvas can mirror game state while DOM gives reliable access to the details.
Do not draw the whole game in one canvas and attach a single accessibility label. Users need to move between controls, inspect the chosen amount and receive the same confirmation as sighted players. Test zoom, screen readers, keyboard-only operation and reduced motion.
Set a performance budget across network and GPU
Measure downloads, decompression, shader compile, CPU updates, GPU frame time, memory, input latency and service response separately. Large textures may slow launch even if later rendering is fast; complex shaders may work on desktop but fail on phones. Test a full user action through server confirmation.
Use compressed textures and fewer effects in a low-detail profile. Load scene assets only after critical account and game state. Test heat in long sessions and constrained GPU memory. After context loss, retain game state at the service and restore only the view.
Choose fallback around the task. A flat table with rules, amount, action and result is safer than a partial scene missing controls. Removing graphics must not invalidate the game-event record.
Keep wagering rules on the server
Changing graphics APIs cannot alter outcomes. Use the trusted service for wagers and result generation. Send an action ID, mark it pending and wait for confirmation; if the browser retries after timeout, the service should recognise the request rather than accept it twice.
New Zealand's 2026 standards cover game information, deliberate starts, time, limits and recovery from interruptions. Immersive browser games should share account controls with regular pages. Falling back to WebGL or 2D must not bypass limits or self-exclusion.
DIA describes legal availability as changing during the licensing transition. The technology stack does not decide whether an app may operate or advertise. Assign a named owner to apply current New Zealand rules.
Acceptance tests for a graphics API choice
Browser graphics release checklist
- Feature unavailable
- Pass condition:The user receives a usable non-immersive path without a blank canvas.
- GPU context lost
- Pass condition:The server's game state remains intact, and no request is duplicated.
- Slow device
- Pass condition:Rules, money values and controls remain readable while effects reduce.
- Permission refused
- Pass condition:The user can continue with an ordinary browser interface.
- Assistive technology
- Pass condition:Core game information and controls remain navigable outside canvas pixels.
- New browser release
- Pass condition:Capability and performance checks pass before support is announced.
An engine can abstract some assets and rendering, but browser API limits remain. Portability also requires rules and account state to survive a runtime change.
Keep graphics text and account controls outside canvas
A page exposing only one canvas makes individual controls hard to navigate. Use HTML for menus, forms, rules, odds, account values and support, with graphics mirroring the same data. Give every consequential action a visible focus order and keyboard path.
Test context recovery on every graphics path. Memory pressure or browser events can remove WebGL context. Pause rendering, preserve account state, restore where possible and query the service before reopening controls. Users should reach limits and exit without refreshing.
Store compatibility results by browser, OS, GPU family and API features. “WebGPU capable” does not identify the feature set required by a specific shader or compute path.