Tech-Stack für Webspiele im Jahr 2026
Drei Technologien treiben Web-Games an: WebGL, WebGPU und WebAssembly. Der beste moderne Stack für ein leistungsstarkes Browser-Game im Jahr 2026 ist ein Renderer, der sowohl WebGL2 als auch WebGPU beherrscht (Three.js oder Babylon.js), Wasm für Physik (Rapier) und statisches Hosting, wobei WebGPU für die rund 87 % der Browser mit Unterstützung aktiviert ist und WebGL2 für den Rest. Jede Technologie löst unterschiedliche Probleme und bringt unterschiedliche Kompromisse mit sich. Dieser Leitfaden hilft dir, basierend auf dem, was du tatsächlich baust, die richtige Wahl zu treffen – nicht basierend darauf, was gerade am meisten gehypt wird. Der Browser-Support ist Stand September 2026 geprüft.
Die schnelle Antwort
WebGL 2.0 funktioniert überall und bewältigt die meisten Games problemlos. Nutze es, wenn du breite Kompatibilität brauchst, besonders auf Mobilgeräten. WebGPU bietet Compute-Shader und bessere Performance, aber du verlierst Nutzer mit älteren Browsern und Geräten. WebAssembly beschleunigt deinen CPU-Code, ist also nützlich für Physik und Pathfinding, hilft aber nicht, wenn dein Flaschenhals die GPU ist.
Die meisten Games in 2026 shippen WebGL mit optionalem WebGPU für fähige Browser. Wasm wird selektiv für Hot-Code-Pfade eingesetzt, nicht für das gesamte Spiel.
WebGL 2.0: Die unspektakuläre Wahl, die funktioniert
WebGL 2.0 ist seit 2017 stabil. Jeder moderne Browser unterstützt es. Dein Game läuft auf Chrome, Firefox, Safari und Edge – zurück bis über 5 Jahre. Es funktioniert auf iOS Safari 15+, Chrome für Android und Samsung Internet. Es läuft sogar in Konsolen-Browsern wie Xbox Edge und dem PlayStation-Browser.
So sieht ein grundlegendes WebGL-2-Setup aus:
const canvas = document.getElementById('game');
const gl = canvas.getContext('webgl2');
if (!gl) {
// Fallback to WebGL 1 or show error
const gl1 = canvas.getContext('webgl');
if (!gl1) {
showError('Your browser does not support WebGL.');
return;
}
}
// Now you have a GL context
gl.clearColor(0.1, 0.1, 0.1, 1.0);
gl.clear(gl.COLOR_BUFFER_BIT);Was du bekommst
WebGL 2 bietet Instanced Rendering, mit dem du Tausende Objekte mit einem einzigen Draw-Call zeichnen kannst. Es hat Transform Feedback für GPU-seitige Partikelsysteme und Simulationen. Du bekommst mehrere Render-Targets für Deferred Rendering und G-Buffers, 3D-Texturen für volumetrische Effekte und Integer-Texturen für präzise Datenspeicherung.
gl.drawArraysInstanced(gl.TRIANGLES, 0, vertexCount, instanceCount);Was du nicht bekommst
Du kannst keine Compute-Shader für allgemeine GPU-Berechnungen ausführen. Es gibt keine Bindless-Textures, du bist also durch die Anzahl der Textureinheiten limitiert. Keine Persistent Mapping oder explizite Speicherkontrolle. Keine Mesh-Shader oder moderne Geometrie-Pipeline.
Für die meisten 2D-Games und viele 3D-Games spielen diese Einschränkungen keine Rolle. Mit WebGL 2 wurden einige der erfolgreichsten Web-Games überhaupt veröffentlicht.
WebGPU: Wenn du mehr brauchst
WebGPU ist darauf ausgelegt, wie moderne GPUs tatsächlich funktionieren. Chrome hat es im Mai 2023 ausgeliefert, und bis Ende 2025 unterstützten es alle großen Browser. Chrome 113+, Safari 26+ und Edge 113+ funktionieren alle, und Firefox hat es in 141+ unter Windows aktiviert (seit Juli 2025) sowie 145 für Apple Silicon macOS, wobei Linux und Android noch ausgerollt werden. Chrome für Android unterstützt es auf aktuellen Geräten, und iOS Safari 26+ unterstützt es ebenfalls.
Hier ist die Support-Matrix, Stand September 2026, von der Seite gpuweb implementation status und den Release Notes der jeweiligen Browser.
| Browser | Standardmäßig aktiviert | Noch nicht |
|---|---|---|
| Chrome / Edge | 113+ unter Windows, macOS und ChromeOS. Linux ab 144 (Intel Gen12+) und 147 (NVIDIA unter Wayland). Chrome für Android 121+ unter Android 12+ | Windows on ARM (hinter einem Flag) |
| Safari | 26 unter macOS Tahoe, iOS, iPadOS und visionOS (September 2025, laut WebKit) | Ältere macOS-Versionen |
| Firefox | 141 unter Windows (Juli 2025), 145 auf Apple-Silicon-Macs mit macOS 26, 147 auf allen macOS-Versionen mit Apple Silicon (Januar 2026) | Linux und Android (nur Nightly, Linux für 2026 anvisiert) |
| Samsung Internet | 24+ |
Das entspricht laut caniuse-Zählung rund 87 % der globalen Seitenaufrufe, weshalb die Engines nachgezogen haben. Unity 6.6 (August 2026) hat WebGPU zu einer vollständig unterstützten Web-Grafik-API mit automatischem WebGL2-Fallback gemacht, Three.js r185 und Babylon.js 9.25 betreiben beide WebGPU-Renderer mit eigenem Fallback, PlayCanvas 2.22 hat einen ausgereiften WebGPU-Pfad, und Godot 4.7 sowie Phaser 4 sind im Browser weiterhin nur WebGL2. Siehe unseren Leitfaden WebGPU vs. WebGL für Games für die Rendering-Kompromisse, und nutze den WebGL- und WebGPU-Checker, um zu sehen, was ein bestimmtes Gerät meldet.
Der Haken: Die verbleibenden Geräte und Browser unterstützen es nicht, also brauchst du eine Fallback-Strategie.
Was du bekommst
Compute-Shader ermöglichen allgemeine GPU-Berechnungen für Physik, Partikel, KI und Bildverarbeitung.
// A compute shader that processes data in parallel
const computeShaderCode = `
@group(0) @binding(0) var<storage, read_write> data: array<f32>;
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3<u32>) {
data[id.x] = data[id.x] * 2.0;
}
`;Außerdem bekommst du explizites Ressourcenmanagement, was zu weniger Performance-Überraschungen führt, Render-Bundles zum Vorabaufzeichnen von Draw-Calls für wiederholten Einsatz, und WGSL als moderne Shader-Sprache, die für GPUs entworfen wurde statt ein C-artiger Hack zu sein.
Praktisches WebGPU-Setup
So initialisierst du WebGPU mit WebGL-Fallback:
async function initGraphics(canvas) {
// Try WebGPU first
if (navigator.gpu) {
const adapter = await navigator.gpu.requestAdapter();
if (adapter) {
const device = await adapter.requestDevice();
const context = canvas.getContext('webgpu');
context.configure({
device,
format: navigator.gpu.getPreferredCanvasFormat(),
});
return { type: 'webgpu', device, context };
}
}
// Fall back to WebGL 2
const gl = canvas.getContext('webgl2');
if (gl) {
return { type: 'webgl2', gl };
}
// Last resort: WebGL 1
const gl1 = canvas.getContext('webgl');
if (gl1) {
return { type: 'webgl', gl: gl1 };
}
throw new Error('No graphics API available');
}Wann es wirklich hilft
WebGPU glänzt, wenn du Compute-Shader brauchst, um Millionen Partikel ohne CPU-Roundtrips zu aktualisieren, GPU-beschleunigte Kollisionserkennung und Cloth-Simulation, prozedurale Generierung von Terrain, Texturen oder Meshes, komplexe Post-Processing-Effekte wie SSAO, Bloom und Depth of Field, oder wenn du trainierte Modelle für NPC-Verhalten oder Bildeffekte laufen lassen willst.
Wenn du ein Puzzle-Game oder eine Visual Novel machst, bringt dir WebGPU nichts. Wenn du ein partikellastiges Action-Game oder eine komplexe 3D-Welt baust, könnte sich der Kompatibilitäts-Kompromiss lohnen.
WebAssembly: Schneller CPU-Code
WebAssembly führt kompilierten Code mit nahezu nativer Geschwindigkeit aus. Es geht nicht um Grafik. Es geht darum, deinen CPU-Code schneller zu machen.
Wann es hilft
Wasm eignet sich gut für Physik-Engines (Box2D, Bullet und Rapier haben alle Wasm-Builds), Pathfinding auf großen Grids, Asset-Dekompression, das Emulieren alter Spielekonsolen und das Portieren bestehender C++- oder Rust-Codebasen ins Web.
Wann es nicht hilft
Deiner GPU ist es egal, ob Draw-Calls von JavaScript oder Wasm kommen, das Rendering wird also nicht schneller. E/A-lastiger Code wie das Laden von Assets oder Netzwerkanfragen profitiert ebenfalls nicht. Und wenn dein JavaScript bereits in unter einer Millisekunde läuft, rettet dich Wasm auch nicht.
Ein praktisches Wasm-Beispiel
Hier ist eine minimale Rust-Funktion, die zu Wasm für Physik kompiliert wird:
// src/lib.rs
#[no_mangle]
pub extern "C" fn step_physics(dt: f32) {
// Your physics code here
}Kompilieren mit:
wasm-pack build --target webVerwendung in JavaScript:
import init, { step_physics } from './physics_bg.wasm';
await init();
function gameLoop(dt) {
step_physics(dt); // Runs at near-native speed
render();
requestAnimationFrame(gameLoop);
}Threading wird kompliziert
Wasm kann Threads für parallele Verarbeitung nutzen, aber das erfordert SharedArrayBuffer, was bedeutet, dass du Cross-Origin-Isolation-Header auf deinem Server brauchst:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corpDiese Header brechen Dinge. Drittanbieter-iFrames ohne CORP-Header funktionieren nicht mehr, manche Analytics-Skripte brechen, und OAuth-Popups können fehlschlagen. Du kannst credentialless statt require-corp verwenden, um den Schaden zu begrenzen, aber es bleibt trotzdem unübersichtlich.
Wenn du diese Header nicht setzen kannst, weil du auf Shared Hosting oder itch.io bist, kannst du keine Wasm-Threads nutzen. Single-threaded Wasm funktioniert trotzdem einwandfrei.
Echte Entscheidungen für echte Games
Wenn du einen 2D-Platformer machst, nutze WebGL 2 über etwas wie Phaser oder PixiJS. Verzichte auf WebGPU, weil es übertrieben ist, und verzichte auf Wasm, weil JavaScript für 2D-Physik schnell genug ist. Breite Kompatibilität zählt mehr als die neuesten Features, und dein Flaschenhals sind Inhalte, nicht Technologie.
Wenn du eine 3D-Open-World machst, starte mit WebGL 2, aber plane einen WebGPU-Upgrade-Pfad ein. Ziehe Wasm für Physik mit Rapier oder Bullet in Betracht. Du willst jetzt die größte Reichweite, aber Compute-Shader würden später bei Vegetation, Partikeln und LOD helfen. Physik in Wasm hält das CPU-Budget niedrig.
Wenn du eine C++-Engine portierst, nutze Wasm über Emscripten. Die Grafik läuft standardmäßig über WebGL 2, oder über WebGPU, falls deine Engine das unterstützt. Du hast bereits den Code, und Emscripten übernimmt die Übersetzung.
Wenn du ein Puzzle-Game machst, nutze Canvas 2D oder WebGL 2 über Phaser. Verzichte auf alles andere. Einfache Games sollten einfach bleiben.
Wenn du unbedingt maximale Performance brauchst und bereit bist, ein paar Nutzer mit älteren Browsern zu verlieren, setze auf WebGPU plus Wasm. Miss aber vorher die tatsächliche Auswirkung auf deine Zielgruppe, bevor du dich festlegst.
Was Games tatsächlich schnell macht
Hier ist, was darüber entscheidet, ob dein Web-Game gut läuft, nach Wichtigkeit sortiert.
Asset-Größe macht etwa die Hälfte der wahrgenommenen Performance aus. Ein 2-MB-Game, das in 1 Sekunde lädt, fühlt sich schneller an als ein 50-MB-Game mit besserer FPS-Zahl. Komprimiere alles, und für 3D-Modelle erledigt ein glTF-Optimizer den Meshopt-Durchgang und die Texturgrößenanpassung in einem Schritt. Lade lazy, was du kannst.
Draw-Calls sind bei 3D-Games sehr wichtig, vielleicht 30 % deines Performance-Budgets. Fasse deine Geometrie in Batches zusammen. Nutze Texture-Atlanten. Instanziere wiederholte Objekte. Das zählt weit mehr als WebGL vs. WebGPU.
JavaScript-Performance macht vielleicht 15 % aus. Vermeide Allokationen in Hot Loops. Nutze Typed Arrays. Profile, bevor du optimierst.
Die Wahl der Grafik-API? Ehrlich gesagt vielleicht 5 %. Bei den meisten Games zählt die API weniger als die Art, wie du sie einsetzt.
Wenn dein Game langsam ist, prüfe zuerst, ob du zu viel im Voraus lädst. Prüfe dann, ob du zu viele Draw-Calls absetzt. Prüfe danach, ob dein JavaScript in der Game-Loop etwas Dummes macht. Erst nach all dem solltest du dich fragen, ob eine andere Grafik-API helfen würde.
Was ich tatsächlich nutzen würde
Für ein neues Web-Game, das heute startet, würde ich Three.js (r185, Juli 2026) oder Babylon.js (9.x) fürs Rendering nutzen, da sie WebGL und WebGPU abstrahieren. Für Physik: Rapier (Rust, zu Wasm kompiliert), wenn ich 3D-Physik brauche, oder einfach die eingebaute 2D-Physik der Engine für einfachere Games. Howler.js oder direkt die Web Audio API für Sound. Vite zum Bauen, weil es in der Entwicklung schnell ist und gute Produktions-Builds erzeugt. Und statisches Hosting auf Netlify, Vercel, GitHub Pages oder itch.io.
Dieser Stack liefert Games aus, die auf 98 %+ der Geräte funktionieren, und ist gleichzeitig bereit für WebGPU, wenn es zum Standard wird.
Teste, bevor du dich festlegst
Bevor du dich auf einen Tech-Stack festlegst, baue einen kleinen Prototyp und teste ihn wirklich. Prüfe die Ladezeit unter 3G mit Chrome-DevTools-Drosselung. Dein Game sollte in unter 5 Sekunden auf einer langsamen Verbindung spielbar sein. Teste die Performance auf einem Low-End-Android-Handy – leih dir eins aus oder nutze BrowserStack. Wenn es dort läuft, läuft es überall. Teste speziell auf Safari, weil es sich genug unterscheidet, um Überraschungen zu verursachen. Und wenn dein Game auf Newgrounds oder Kongregate landet, teste es in einem iFrame.
Diese Tests decken mehr echte Probleme auf, als die Debatte WebGL vs. WebGPU es je könnte.
Häufige Fragen
Was ist der beste moderne Tech-Stack für ein leistungsstarkes Browser-Game?
Ein Renderer, der beide APIs beherrscht, Wasm dort, wo die CPU der Flaschenhals ist, und ein schlanker Build. Konkret: Three.js oder Babylon.js (WebGPU mit automatischem WebGL2-Fallback), zu Wasm kompiliertes Rapier für 3D-Physik, Howler.js oder rohe Web Audio für Sound, Vite für Builds, KTX2-Texturen und Meshopt-komprimiertes glTF für Assets, und statisches Hosting hinter einem CDN. Wenn du lieber mit einer vollständigen Engine starten möchtest: PlayCanvas und Unity 6.6 bieten beide WebGPU mit Fallback, und Godot bietet einen schlanken WebGL2-Build. Der Vergleich von Web-Game-Engines bewertet alle davon nach Build-Größe und Ladezeit.
Lohnt sich WebGL 2026 noch?
Ja, und es ist weiterhin die Basis. WebGL 2.0 läuft auf jedem Browser und Gerät, das deine Spieler besitzen, einschließlich der Firefox-Builds unter Linux und Android und der älteren Handys, die immer noch kein WebGPU haben. Nichts an der Einführung von WebGPU sorgt dafür, dass WebGL-Builds aufhören zu funktionieren, und bei 2D-Games und den meisten 3D-Games war WebGL2 nie der Flaschenhals. Liefere WebGL2 aus, füge WebGPU als Upgrade hinzu, wo der Renderer es dir kostenlos mitgibt, und stecke deinen Aufwand stattdessen in Asset-Größe und Draw-Calls.
Kann ich einfache Games mit WebGPU bauen?
Sie können es, aber Sie brauchen es selten. Ein Puzzlespiel, ein Plattformer oder ein Kartenspiel läuft auf WebGPU nicht besser als auf WebGL2, und Sie verlieren die Spieler, deren Browser es noch nicht unterstützen. WebGPU verdient sich seinen Platz in einem einfachen Spiel dort, wo ein einzelner Effekt Compute-Funktionen braucht: Tausende Partikel, ein Flüssigkeits- oder Stoff-Spielzeug, eine GPU-gesteuerte Menschenmenge. Verwenden Sie in diesem Fall eine Bibliothek mit automatischem Fallback (Three.js oder Babylon.js), statt rohes WebGPU zu schreiben, oder beschreiben Sie das Spiel und lassen Sie Cinevva es für Sie auf WebGPU bauen. Unser Einstiegstutorial zu WebGPU behandelt die rohe API, falls Sie das möchten.
Weiterführende Lektüre
Vergleich der Web-Game-Engines behandelt vollständige Engines, falls Sie nicht von Grund auf bauen möchten. Three.js + USDC im Browser zeigt, wie man USD-Assets in Three.js lädt. Wie man auf itch.io veröffentlicht behandelt die Veröffentlichung, sobald Sie etwas gebaut haben.
Für praxisnahe Tutorials, die tiefer in jede API eintauchen:
- WebGL-Grundlagen für Game-Entwickler: Shader, Buffer, Texturen und die Render-Schleife
- Einstieg in WebGPU: Geräte-Setup, Pipelines und WGSL-Shader
- Web Worker für Spiellogik: Arbeit auf Hintergrund-Threads auslagern
- COOP/COEP und SharedArrayBuffer: Header, die für Wasm-Threading nötig sind
- Physik-Bibliotheken für Spiele: Rapier, Cannon-es, Ammo.js, Matter.js und mehr
Der richtige Tech-Stack ist der, mit dem Sie Ihr Spiel tatsächlich fertigstellen. Wählen Sie, was Sie kennen, testen Sie früh und optimieren Sie später.
WebGL, Physik und Asset-Pipeline sind erledigt. Sie beschreiben nur das Spiel.