Tech-Stack für Webspiele im Jahr 2026
Drei Technologien treiben Webspiele an: WebGL, WebGPU und WebAssembly. Jede löst andere Probleme und bringt unterschiedliche Vor- und Nachteile mit sich. Dieser Leitfaden hilft dir, deine Wahl anhand dessen zu treffen, was du tatsächlich entwickelst – und nicht danach, was gerade am meisten gehypt wird.
Die kurze Antwort
WebGL 2.0 funktioniert überall und reicht für die meisten Spiele vollkommen aus. Nutze es, wenn du eine breite Kompatibilität benötigst, insbesondere auf Mobilgeräten. WebGPU bietet dir Compute-Shader und eine bessere Performance, dafür verlierst du Nutzer mit älteren Browsern und Geräten. WebAssembly beschleunigt deinen CPU-Code und ist daher für Physik und Wegfindung nützlich, hilft dir aber nicht, wenn die GPU dein Engpass ist.
Die meisten Spiele werden 2026 mit WebGL ausgeliefert und bieten WebGPU optional für kompatible Browser an. Wasm wird gezielt für performancekritische Codepfade eingesetzt, nicht für das gesamte Spiel.
WebGL 2.0: Die langweilige Wahl, die funktioniert
WebGL 2.0 ist seit 2017 stabil. Jeder moderne Browser unterstützt es. Dein Spiel läuft in Chrome, Firefox, Safari und Edge, selbst in Versionen, die mehr als fünf Jahre alt sind. Es funktioniert in iOS Safari 15+, Chrome für Android und Samsung Internet. Es läuft sogar in Konsolenbrowsern wie Xbox Edge und dem Browser der PlayStation.
So sieht eine grundlegende WebGL-2-Einrichtung 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 instanziiertes Rendering, sodass du Tausende Objekte mit einem einzigen Draw Call zeichnen kannst. Es unterstützt Transform Feedback für GPU-seitige Partikelsysteme und Simulationen. Du erhältst mehrere Render Targets für Deferred Rendering und G-Buffer, 3D-Texturen für volumetrische Effekte und Integer-Texturen zur präzisen 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, sodass du durch die Anzahl der Texture Units eingeschränkt bist. Kein Persistent Mapping und keine explizite Speicherverwaltung. Keine Mesh-Shader und keine moderne Geometrie-Pipeline.
Für die meisten 2D-Spiele und viele 3D-Spiele spielen diese Einschränkungen keine Rolle. Einige der erfolgreichsten Webspiele aller Zeiten wurden mit WebGL 2 veröffentlicht.
WebGPU: Wenn du mehr brauchst
WebGPU orientiert sich daran, wie moderne GPUs tatsächlich funktionieren. Chrome führte die Unterstützung im Mai 2023 ein, und bis Ende 2025 unterstützten alle großen Browser die Technologie. Chrome 113+, Safari 26+ und Edge 113+ funktionieren vollständig. Firefox aktivierte WebGPU unter Windows ab Version 141 (seit Juli 2025) und unter macOS auf Apple Silicon ab Version 145, während die Einführung unter Linux und Android noch läuft. Chrome für Android unterstützt WebGPU auf neueren Geräten, und iOS Safari 26+ unterstützt es ebenfalls.
Der Haken ist, dass ältere Geräte und Browser WebGPU nicht unterstützen. Du brauchst also eine Fallback-Strategie.
Was du bekommst
Mit Compute-Shadern kannst du allgemeine GPU-Berechnungen für Physik, Partikel, KI und Bildverarbeitung ausführen.
// 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 erhältst du eine explizite Ressourcenverwaltung, die für weniger unerwartete Performanceprobleme sorgt, Render Bundles zum Vorabaufzeichnen von Draw Calls für die wiederholte Verwendung sowie WGSL als moderne Shader-Sprache, die speziell für GPUs entwickelt wurde und nicht nur ein C-ähnlicher Behelf ist.
WebGPU praktisch einrichten
So initialisierst du WebGPU mit einem 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 spielt seine Stärken aus, wenn du Compute-Shader benötigst, um Millionen von Partikeln ohne Umweg über die CPU zu aktualisieren, GPU-beschleunigte Kollisionserkennung und Stoffsimulationen auszuführen, Gelände, Texturen oder Meshes prozedural zu generieren, komplexe Post-Processing-Effekte wie SSAO, Bloom und Tiefenunschärfe umzusetzen oder trainierte Modelle für das Verhalten von NPCs oder für Bildeffekte auszuführen.
Wenn du ein Puzzlespiel oder einen Visual Novel entwickelst, bringt dir WebGPU nichts. Wenn du ein actionreiches Spiel mit vielen Partikeln oder eine komplexe 3D-Welt entwickelst, könnte der Kompromiss bei der Kompatibilität lohnenswert sein.
WebAssembly: Schneller CPU-Code
WebAssembly führt kompilierten Code mit nahezu nativer Geschwindigkeit aus. Dabei geht es nicht um Grafik, sondern darum, deinen CPU-Code zu beschleunigen.
Wann es hilft
Wasm eignet sich gut für Physik-Engines – Box2D, Bullet und Rapier bieten alle Wasm-Builds –, für Wegfindung auf großen Rastern, die Dekomprimierung von Assets, die Emulation alter Spielkonsolen und die Portierung vorhandener C++- oder Rust-Codebasen ins Web.
Wann es nicht hilft
Deiner GPU ist es egal, ob Draw Calls aus JavaScript oder Wasm kommen, daher wird das Rendering nicht schneller. Auch I/O-gebundener Code wie das Abrufen von Assets oder Netzwerkanfragen profitiert nicht davon. Und wenn dein JavaScript bereits in weniger als einer Millisekunde ausgeführt wird, wird Wasm dir keine Zeit sparen.
Ein praktisches Wasm-Beispiel
Hier ist eine minimale, für Wasm kompilierte Rust-Funktion für Physik:
// 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);
}Threads werden kompliziert
Wasm kann Threads zur parallelen Verarbeitung nutzen, benötigt dafür aber SharedArrayBuffer. Das bedeutet, dass du auf deinem Server Header für Cross-Origin Isolation setzen musst:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corpDiese Header können Dinge kaputtmachen. Drittanbieter-Iframes ohne CORP-Header funktionieren nicht mehr, einige Analyseskripte fallen aus und OAuth-Pop-ups können fehlschlagen. Du kannst credentialless anstelle von require-corp verwenden, um die Auswirkungen zu begrenzen, aber die Lösung bleibt kompliziert.
Wenn du diese Header nicht setzen kannst, weil du Shared Hosting oder itch.io verwendest, kannst du keine Wasm-Threads nutzen. Single-Threaded Wasm funktioniert jedoch weiterhin problemlos.
Echte Entscheidungen für echte Spiele
Wenn du einen 2D-Plattformer entwickelst, verwende WebGL 2 über ein Framework wie Phaser oder PixiJS. Verzichte auf WebGPU, weil es dafür überdimensioniert ist, und auf Wasm, weil JavaScript für 2D-Physik schnell genug ist. Breite Kompatibilität ist wichtiger als die neuesten Funktionen, und dein Engpass sind die Inhalte, nicht die Technologie.
Wenn du eine offene 3D-Welt entwickelst, beginne mit WebGL 2, plane aber einen Upgrade-Pfad zu WebGPU ein. Ziehe Wasm für die Physik mit Rapier oder Bullet in Betracht. Aktuell möchtest du möglichst viele Nutzer erreichen, später würden Compute-Shader jedoch bei Vegetation, Partikeln und LOD helfen. Physik in Wasm hält die CPU-Auslastung niedrig.
Wenn du eine C++-Engine portierst, verwende Wasm über Emscripten. Für die Grafik kommt standardmäßig WebGL 2 zum Einsatz oder WebGPU, sofern deine Engine es unterstützt. Du hast den Code bereits, und Emscripten übernimmt die Übersetzung.
Wenn du ein Puzzlespiel entwickelst, verwende Canvas 2D oder WebGL 2 über Phaser. Lass alles andere weg. Einfache Spiele sollten einfach bleiben.
Wenn du unbedingt maximale Performance benötigst und bereit bist, einige Nutzer mit älteren Browsern auszuschließen, entscheide dich für WebGPU plus Wasm. Miss jedoch zuerst die tatsächlichen Auswirkungen auf deine Zielgruppe, bevor du dich festlegst.
Was Spiele tatsächlich schnell macht
Die folgenden Faktoren bestimmen, ob dein Webspiel flüssig läuft – in der Reihenfolge ihrer Bedeutung.
Die Asset-Größe macht etwa die Hälfte der wahrgenommenen Performance aus. Ein 2-MB-Spiel, das in einer Sekunde lädt, fühlt sich schneller an als ein 50-MB-Spiel mit einer besseren Framerate. Komprimiere alles. Für 3D-Modelle erledigt ein glTF-Optimierer die Meshopt-Optimierung und die Größenanpassung der Texturen in einem Durchgang. Lade so viele Inhalte wie möglich erst bei Bedarf.
Draw Calls sind für 3D-Spiele sehr wichtig und machen möglicherweise 30 % deines Performancebudgets aus. Fasse deine Geometrie zusammen. Verwende Texture Atlases. Instanziiere wiederkehrende Objekte. Das ist deutlich wichtiger als die Entscheidung zwischen WebGL und WebGPU.
Die JavaScript-Performance macht vielleicht 15 % aus. Vermeide Speicherallokationen in performancekritischen Schleifen. Verwende typisierte Arrays. Analysiere die Performance, bevor du optimierst.
Die Wahl der Grafik-API? Ehrlich gesagt vielleicht 5 %. Für die meisten Spiele ist die API weniger wichtig als die Art, wie du sie verwendest.
Wenn dein Spiel langsam ist, prüfe zuerst, ob du zu viele Daten vorab lädst. Prüfe danach, ob du zu viele Draw Calls ausführst. Kontrolliere anschließend, ob dein JavaScript in der Spielschleife etwas Ineffizientes tut. Erst danach solltest du dich fragen, ob eine andere Grafik-API helfen würde.
Was ich tatsächlich verwenden würde
Für ein neues Webspiel, mit dessen Entwicklung ich heute beginne, würde ich Three.js oder Babylon.js für das Rendering verwenden, da beide WebGL und WebGPU abstrahieren. Für die Physik würde ich Rapier – in Wasm kompiliertes Rust – verwenden, wenn ich 3D-Physik benötige, oder einfach die integrierte 2D-Physik der Engine für einfachere Spiele. Für Audio würde ich Howler.js oder direkt die Web Audio API nutzen. Vite für den Build, weil es während der Entwicklung schnell ist und gute Produktions-Builds erzeugt. Dazu statisches Hosting auf Netlify, Vercel, GitHub Pages oder itch.io.
Mit diesem Stack kannst du Spiele veröffentlichen, die auf mehr als 98 % aller Geräte funktionieren und zugleich für WebGPU bereit sind, sobald es zum Standard wird.
Teste, bevor du dich festlegst
Bevor du dich auf einen Tech-Stack festlegst, entwickle einen kleinen Prototyp und teste ihn tatsächlich. Prüfe die Ladezeit unter 3G-Bedingungen mit der Netzwerkdrosselung in den Chrome DevTools. Dein Spiel sollte bei einer langsamen Verbindung in weniger als fünf Sekunden spielbar sein. Teste die Performance auf einem leistungsschwachen Android-Smartphone – leihe dir eines aus oder verwende BrowserStack. Wenn es dort läuft, läuft es überall. Teste gezielt in Safari, weil der Browser anders genug ist, um unerwartete Probleme zu verursachen. Und wenn dein Spiel auf Newgrounds oder Kongregate veröffentlicht werden soll, teste es in einem Iframe.
Diese Tests decken mehr echte Probleme auf, als es jede Diskussion über WebGL und WebGPU jemals könnte.
Weiterlesen
Der Vergleich von Webspiel-Engines behandelt vollständige Engines, falls du nicht bei null anfangen möchtest. Three.js + USDC im Browser zeigt, wie du USD-Assets in Three.js lädst. So veröffentlichst du auf itch.io erklärt die Veröffentlichung, sobald du etwas entwickelt hast.
Praxisorientierte Tutorials, die tiefer in die einzelnen APIs einsteigen:
- WebGL-Grundlagen für Spieleentwickler — Shader, Buffer, Texturen und die Render-Schleife
- Erste Schritte mit WebGPU — Geräteeinrichtung, Pipelines und WGSL-Shader
- Web Workers für Spiellogik — Arbeit in Hintergrund-Threads auslagern
- COOP/COEP und SharedArrayBuffer — erforderliche Header für Wasm-Threads
- Bibliotheken für Spielphysik — Rapier, Cannon-es, Ammo.js, Matter.js und mehr
Der richtige Tech-Stack ist der, mit dem du dein Spiel veröffentlichst. Nutze, was du kennst, teste frühzeitig und optimiere später.
WebGL, Physik und Asset-Pipeline sind bereits abgedeckt. Du beschreibst einfach das Spiel.