Na jaře 2026 už WebGPU není jen záležitost Chromia nebo preview buildů. Chrome, Edge, Safari i Firefox ho dodávají v produkčních verzích, ale ne na stejných platformách a ne se stejnými limity. Desktop a iOS/iPadOS jsou dál než před rokem, Android rozšiřuje dosah i přes Compatibility Mode, Linux dál závisí na kombinaci prohlížeče, ovladače, backendu a GPU a Firefox ještě nemá hotový Linux ani Android. WebGPU navíc podle aktuální charty pracovní skupiny nemíří z Candidate Recommendation do W3C Recommendation. Pro vývojáře je proto důležitější konkrétní podpora, fallbacky a limity paměti než formální status standardu.

Recommendation není plánovaný cíl charty

Aktuální specifikace WebGPU je ve W3C vedená jako Candidate Recommendation Draft. Publikační přehled W3C k 12. květnu 2026 uvádí WebGPU jako Candidate Recommendation Draft z téhož dne; poslední Candidate Recommendation Snapshot zůstává z 19. prosince 2024. Podstatnější než přesné datum posledního draftu je charta GPU for the Web Working Group z ledna 2025. Ta říká, že pracovní skupina chce publikovat aktuální stav práce jako Candidate Recommendation se snapshoty a dokumenty nehodlá posunout do Recommendation.

To neznamená, že WebGPU zůstává experimentální. Znamená to, že u něj W3C proces nejde číst jako jednoduchou osu „draft → hotový standard“. Pro vývojáře je důležitější, zda API dodávají prohlížeče, zda existují testy, zda frameworky mají fallback a zda se dá spolehnout na konkrétní kombinaci prohlížeče, operačního systému, GPU a ovladače.

Součástí tématu je i WGSL, shaderový jazyk WebGPU. WebGPU nepřebírá GLSL ani SPIR-V jako primární formát pro web, ale používá vlastní textový jazyk, který se dá překládat do shader jazyků a instrukcí konkrétních platforem. Charta ho popisuje jako doprovodnou specifikaci k API, určenou pro grafické i výpočetní úlohy. Historický kontext kompromisů kolem SPIR-V a WGSL dobře popsal Dzmitry Malyshau z Mozilly v textu The horrors of SPIR-V; dlouhodobá kritika WGSL je vidět i ve vlákně gpuweb#566.

Co se změnilo v roce 2025 a na jaře 2026

Zlom nepřišel kvůli finálnímu razítku W3C. Přišel tím, že WebGPU začaly ve výchozím stavu dodávat všechny hlavní prohlížečové enginy aspoň na části podporovaných platforem. Web.dev to v listopadu 2025 shrnul jako podporu napříč Chrome, Edge, Firefoxem a Safari, ale stejný přehled zároveň ukazuje, že „podporováno“ neznamená „všude stejně“. Pro průběžný stav je dobré sledovat i GPUWeb Implementation Status.

Listopad 2025 je proto lepší číst jako bod, kdy se WebGPU přestalo týkat jen Chromia a experimentálních buildů. Neznamená to, že lze zahodit WebGL fallback. Ten pro rok 2026 pořád patří do návrhu produkční aplikace, pokud necílíte na kontrolované prostředí.

Android je jeden z hlavních důvodů. Návrh WebGPU Compatibility Mode vznikl proto, že část zařízení nemá moderní explicitní grafický backend, na kterém stojí core WebGPU. Chrome 146 začal dodávat opt-in Compatibility Mode jako omezenou podmnožinu WebGPU pro starší API, v praxi hlavně OpenGL ES 3.1 na Androidu. Chrome zároveň zmiňuje zkoumání dalších platforem, například ChromeOS s OpenGL ES 3.1 a Windows s Direct3D 11. Aplikace si režim vyžádá přes requestAdapter({ featureLevel: "compatibility" }).

Compatibility Mode je restriktivnější podmnožina WebGPU. Není to automatický fallback na WebGL. Ten musí udělat aplikace, případně framework.

Co WebGPU mění proti WebGL

WebGL je webový obal nad OpenGL ES. Historicky funguje jako globální stavový automat: nastavíte stav, navážete buffery, textury a programy, zavoláte draw call a doufáte, že jste nezapomněli přepnout něco z předchozího průchodu. Výpočetní úlohy se v něm simulují přes fragment shadery a data zakódovaná do textur.

WebGPU je navržené po vzoru moderních nativních API typu Vulkan, Metal a D3D12. Pracuje s explicitními objekty: GPURenderPipeline, GPUComputePipeline, bind groups, command encodery, command buffery a frontou příkazů. Větší část stavu se skládá předem a chyby se dají zachytit dřív než v samotné render loopě. Výsledek je víc setup kódu na začátku, ale menší CPU overhead v hlavní smyčce a lepší prostor pro batching.

Dopad je vidět i v měření. Studie GL2GPU z ACM Web Conference 2025 uvádí, že runtime překlad WebGL volání do WebGPU snížil v testovaných benchmarcích frame time v průměru o 45,05 %. Takové číslo je potřeba brát jako výsledek konkrétního překladače a benchmarku, ne jako univerzální slib. Směr ale odpovídá tomu, co WebGPU přináší: nižší režii na straně CPU a explicitnější řízení práce pro GPU.

Druhá velká změna je compute. WebGPU má GPUComputePipeline jako rovnocennou část API vedle render pipeline. To umožňuje spouštět obecné GPU výpočty přímo v prohlížeči bez triků přes canvas: ML inferenci, fyzikální simulace, zpracování obrazu a videa, geometrii nebo vlastní datové transformace.

Paměťový model je ale jiný, než na co jsou zvyklí autoři nativního Vulkanu nebo CUDA. Přístup CPU a GPU je oddělený přes mapping, staging buffery a asynchronní operace typu mapAsync(). Výchozí limity jsou konzervativní: MDN u GPUSupportedLimits uvádí například maxStorageBufferBindingSize 128 MiB a maxBufferSize 256 MiB. Některé adaptéry umožní požádat o víc přes requiredLimits, ale limity se liší podle hardwaru a prohlížeč je může záměrně zaokrouhlovat do tříd kvůli fingerprintingu. Zjišťujte je za běhu.

Na platformě se core WebGPU mapuje na nativní backend: D3D12 na Windows, Metal na macOS a iOS, Vulkan na Linuxu, Androidu a ChromeOS. Chromium používá Dawn, Firefox staví na wgpu. WebGPU tím zároveň není jen „browser API“ v úzkém smyslu: Dawn i wgpu se používají i mimo prohlížeč jako přenositelná abstrakce nad nativními GPU backendy.

Produkční nasazení: Figma je užitečnější než benchmarky

Nejužitečnější veřejně popsaný příklad produkčního WebGPU dnes není lokální AI, ale Figma. V září 2025 popsala přechod svého rendereru na WebGPU s důrazem na praktické problémy migrace: explicitnější draw-call API, shader processing pro GLSL i WGSL, odlišné chování readbacku, výkonové regrese na části zařízení a postupné nasazování. Figma zároveň zdůrazňuje, že musela zachovat kompatibilitu s WebGL.

Technicky je to užitečnější případová studie než obecné tvrzení „WebGPU je rychlejší“. Renderer Figmy je psaný v C++, pro web se kompiluje do WebAssembly přes Emscripten a v nativních buildech používá Dawn. Figma musela optimalizovat opětovné využití bind groups, batching draw callů do render passů a měřit výkon podle GPU, OS a prohlížeče. U některých tříd zařízení viděla zlepšení, u jiných spíš neutrální výsledky.

Podstatná je i jejich fallback strategie. Figma nejprve plánovala zařízení otestovat při startu, ale kvůli asynchronnímu readbacku by to zhoršovalo načítání. Nakonec nasadila dynamický fallback: aplikace může začít s WebGPU a při selhání nebo ztrátě zařízení přepnout zpět na WebGL. Jde o provozní detail, který odděluje demo od produkčního nasazení.

Ekosystém 3D frameworků se mezitím posunul z experimentu do běžného provozu. Three.js WebGPURenderer zkusí použít WebGPU a při nedostupnosti přejde na WebGL2. Babylon.js ve verzi 9 dál rozšiřuje WebGPU část enginu; hlavní materiály už generují WGSL pro WebGPU a materiálová knihovna se postupně zbavuje nutnosti runtime převodu GLSL do WGSL. PlayCanvas popisuje WebGPU opatrněji jako beta backend, ale má jej jako součást grafického stacku s fallbackem podle podpory prohlížeče.

AI v prohlížeči: běží, ale ne všude a ne bez nákladů

Lokální inference je dnes nejviditelnější oblast, kde se o WebGPU mluví. Transformers.js v4 od Hugging Face přinesl v únoru 2026 nový WebGPU runtime přepsaný do C++ a testovaný zhruba na 200 podporovaných modelových architektur. ONNX Runtime Web má WebGPU execution provider pro náročnější modely, u kterých WebAssembly backend nestačí.

Zajímavé jsou i LLM. Studie WebLLM od MLC ukazuje, že browserová inference přes JavaScript, WebAssembly a WebGPU se na stejném zařízení může přiblížit nativnímu MLC-LLM stacku. Autoři uvádějí na MacBooku Pro M3 Max v Chrome Canary 133 pro 4bitové modely Llama-3.1-8B rychlost 41,1 tokenu za sekundu a pro Phi-3.5-mini 3,8B rychlost 71,1 tokenu za sekundu; ve srovnání s nativním MLC-LLM si WebLLM zachoval až 80 % výkonu.

To ale není obecný příslib pro běžný notebook nebo mobil. Jsou to výsledky na high-end Apple Silicon, s konkrétní kvantizací, konkrétním runtime a předpřipravenými WebGPU kernely. V praxi narazíte na velikost modelu, cache, download stovek megabajtů až jednotek gigabajtů, VRAM limity, zahřívání, throttling a rozdílné chování backendů.

Pro běžné cílení jsou realistické hlavně menší kvantizované modely v řádu jednotek miliard parametrů. Výkonná zařízení zvládnou víc, ale není to dobrá výchozí konfigurace pro webovou aplikaci. Modely a runtime, které v nativním prostředí stojí na CUDA tensor cores, velké paměti nebo specializované knihovně, do browseru nepřenesete jen přepsáním endpointu.

Soukromí je potřeba chápat ve dvou rovinách. Lokální inference může omezit posílání dat na server, ale zároveň vystavuje jinou útočnou plochu: GPU fingerprinting, chyby v ovladačích, režii sandboxu prohlížeče a praktické problémy s aktualizací modelů na klientovi.

Bezpečnost: WebGPU zvětšuje útočnou plochu

WebGPU přináší do prohlížeče výkonnější GPU compute. To je užitečné pro renderery i ML, ale bezpečnostně to není neutrální změna. Studie WebGPU-SPY ukázala website fingerprinting top 100 webů s 90% přesností na Intel iGPU přes GPU cache side-channel. Hohentanner, Kemmerzell a Florschütz na ACM WiSec 2025 popsali hardwarové fingerprinty přes WebGPU a v evaluaci uvádějí 70% přesnost re-identifikace zařízení z poolu 500 zařízení.

Specifikace s tím počítá. W3C dokumentuje mitigace proti fingerprintingu a omezení odhalovaných konfigurací; aktuální text specifikace například mluví o maximálně 32 rozlišitelných konfiguracích nebo bucketech. To je užitečná brzda, ne definitivní řešení. Pokud stavíte aplikaci na argumentu, že lokální inference je soukromější, GPU fingerprinting musí být v modelu hrozeb, ne až v poznámce pod čarou.

Rok 2025 zároveň ukázal, že WebGPU je reálná útočná plocha v běžných prohlížečích. Mozilla ve Firefoxu 145 opravovala několik chyb v Graphics: WebGPU komponentě včetně CVE-2025-13022, CVE-2025-13023, CVE-2025-13025 a CVE-2025-13026, část z nich s dopadem na únik ze sandboxu. U nového rozhraní mezi JavaScriptem, shader kompilátorem, browser sandboxem a GPU driverem to není překvapení, ale při bezpečnostní revizi to nelze ignorovat.

V citlivém prostředí potřebujete politiku verzí prohlížeče, detekci a fallback, omezení sady funkcí, monitoring chyb typu device loss a jasné rozhodnutí, zda WebGPU povolit všem, jen některým konfiguracím, nebo vůbec.

Režie sandboxu a malé dispatch operace

Výkon WebGPU se často měří na velkých úlohách, kde GPU opravdu dominuje: render scény, velká matmul operace, delší běh inference. Tam se režie JavaScriptu, browser sandboxu, validace a submitu rozloží do dostatečně velké práce.

Jiná situace nastává u mnoha malých compute dispatchů. Preprint Characterizing WebGPU Dispatch Overhead for LLM Inference Across Four GPU Vendors, Three Backends, and Three Browsers z roku 2026 upozorňuje právě na režii submitu a dispatch modelu. Autoři ukazují, že pro zátěž složenou z mnoha krátkých kernelů může být WebGPU výrazně dražší než nativní runtime. Proto některé AI benchmarky vypadají velmi dobře a jiné špatně: nejde jen o celkový počet operací, ale o granularitu práce a schopnost runtime slučovat operace.

Pro vývojáře z toho plyne jednoduché pravidlo: WebGPU není automatický urychlovač každého kódu. Pomůže tam, kde dokážete dát GPU dost velkou dávku práce, minimalizovat synchronizaci s CPU, udržet data na GPU a nesekat výpočet na stovky mikrokernelů s velkou režií mezi nimi.

WebNN míří jinam než WebGPU

WebNN je samostatné API pro akceleraci neuronových sítí přes schopnosti operačního systému a hardwaru. W3C u něj k 27. březnu 2026 uvádí Candidate Recommendation Draft. Specifikace jej popisuje jako nízkoúrovňové API pro hardwarovou akceleraci inference neuronových sítí. Prakticky jde o vrstvu, která se může mapovat na systémové ML API typu DirectML, Core ML, TFLite nebo jinou nativní podporu.

WebNN a WebGPU se nepřekrývají dokonale. WebNN je vyšší vrstva pro standardní inference grafy a potenciálně lepší cesta k NPU. WebGPU je nižší, obecnější compute API, kde si runtime nebo framework nese vlastní kernely a optimalizace. ONNX Runtime Web může podporovat obojí jako execution providery; aplikace se k WebNN často dostane nepřímo přes runtime, ne ručním psaním WebNN kódu.

Pro produkční plánování je ale namístě opatrnost. Chromium WebNN Origin Trial se v roce 2026 několikrát posouval. Android byl kvůli nezralé implementaci z trialu vyloučen, protože tam tehdy běžela jen CPU inference a GPU/NPU podpora nebyla hotová. Po dalších blokujících chybách tým trial znovu odložil. V blink-dev vlákně byl 27. března 2026 Origin Trial opět deaktivován s tím, že nový cílový milník bude oznámen později. Jinými slovy: WebNN je důležitý směr, ale v roce 2026 z něj ještě nejde udělat obecnou odpověď na browserovou ML inferenci.

Kdy nasadit, kdy počkat, kdy jít nativně

WebGPU dává smysl nasadit už dnes, pokud máte GPU zátěž, která skutečně profituje z moderního explicitního API: 3D vizualizaci, editor, aplikaci typu CAD, mapový renderer, pipeline pro obraz a video nebo menší lokální inferenci. Nejjistější cílové prostředí je desktopový Chromium/Safari/Firefox na podporovaných platformách a iOS/iPadOS se Safari 26. I tam ale potřebujete telemetrii, blocklist nebo allowlist problematických konfigurací a fallback.

Počkat se vyplatí u produktu primárně pro Android, širokého BYOD prostředí nebo aplikace, kde nechcete nést náklady na WebGL fallback. Compatibility Mode rozšiřuje dosah, ale sám o sobě neřeší srovnatelnou sadu funkcí, výkon ani kvalitu ovladačů.

Nativně je lepší jít tam, kde potřebujete CUDA, tensor cores, FP64, multi-GPU, práci s velkými modely, přímé použití NPU nebo přísnou kontrolu nad driver stackem. WebGPU odstraňuje část stropů WebGL, ale nenahrazuje nativní výpočetní stack.

Electron může dávat smysl, pokud potřebujete kontrolovat verzi Chromia a tím i WebGPU prostředí. Platíte ale velikostí aplikace a dalším runtime. Tauri je úspornější, ale víc závisí na WebView daného systému; u WebGPU to znamená větší variabilitu.

Debugging už má čím začít, ale pořád není tak pohodlný jako u zralých nativních stacků. Existuje WebGPU Inspector, RenderDoc lze použít v kontrolovaných konfiguracích a pro Windows přichází v úvahu PIX nebo Nsight při práci s příslušným backendem. Pořád ale platí, že produkční WebGPU aplikace musí být navržená tak, aby přežila rozdíly mezi GPU, OS, ovladači a browserem.

Pro rok 2026 z toho plyne střízlivé doporučení: WebGPU se dá nasadit, ale ne bez záložní cesty a měření na cílových zařízeních. U vhodné GPU zátěže přinese smysluplný posun; jako univerzální náhrada WebGL, CUDA nebo WebNN však nefunguje. Vývojář tím nezískává jedno hotové řešení, ale přesnější kontrolu nad výkonem za cenu nových rozhodnutí o podpoře, limitech a fallbacku.