Qué es WebGPU: una API de GPU, no una biblioteca de gráficos
Qué expone WebGPU exactamente, qué problema vino a resolver, qué reemplaza y qué deliberadamente no hace, para que no lo confundas con una versión nueva de WebGL.
WebGPU se presenta con frecuencia como «el sucesor de WebGL», y esa frase es responsable de la mitad de las decisiones equivocadas que se toman al empezar. No es una versión nueva de nada: es una interfaz distinta, con un modelo de objetos distinto, un lenguaje de shaders distinto y una filosofía de validación opuesta. Antes de escribir una línea conviene tener claro qué territorio ocupa, porque casi todo lo que resulta incómodo de la API se explica por el terreno que decidió no ocupar.
- Definir qué expone WebGPU y en qué se diferencia de una biblioteca de gráficos.
- Explicar los dos usos de primera clase de la API: render y cómputo general.
- Enumerar qué garantías de seguridad y portabilidad impone la especificación y qué cuestan.
- Distinguir qué reemplaza WebGPU de qué convive con ella en 2026.
Una interfaz sobre la GPU, no sobre los gráficos
Una GPU moderna es un procesador masivamente paralelo con su propia memoria, su propio planificador y su propio conjunto de instrucciones. Durante treinta años la única forma de hablarle desde un navegador fue una API pensada para dibujar triángulos: OpenGL ES a través de WebGL. Eso funcionaba mientras el objetivo fuese dibujar triángulos, y se rompía en cuanto querías usar el hardware para otra cosa.
WebGPU cambia el sujeto de la conversación. Lo que expone no es «un rasterizador que puedes configurar», sino el dispositivo: memoria que reservas y llenas, programas que compilas y lanzas, y una cola por la que envías trabajo. Sobre esa base hay dos maneras de lanzar trabajo, y las dos tienen el mismo rango:
Render. Un GPURenderPipeline describe un pase por el rasterizador: qué shader transforma vértices, qué shader colorea fragmentos, cómo se interpretan los datos de entrada, cómo se prueba la profundidad, cómo se mezcla el resultado. Es el camino clásico.
Cómputo. Un GPUComputePipeline describe un único programa que se lanza sobre una rejilla de invocaciones, sin rasterizador, sin vértices y sin fragmentos. Lee y escribe memoria arbitraria. Es el camino que WebGL nunca tuvo y el que justifica por sí solo la existencia de la API.
Por debajo de esos dos caminos todo es común: los mismos búferes, las mismas texturas, el mismo lenguaje de shaders, el mismo mecanismo de agrupación de recursos, la misma cola. Esa simetría es el rasgo de diseño más importante de WebGPU y la razón de que un sistema de partículas simulado en cómputo pueda dibujarse leyendo exactamente el mismo búfer que escribió la simulación, sin copias intermedias.
Lo que WebGPU no te da es igual de definitorio. No hay escena, ni nodos, ni cámara, ni matriz de proyección, ni carga de modelos, ni tipos vectoriales en JavaScript, ni gestión de materiales, ni iluminación. No hay una sola función que dibuje un cubo. Todo eso vive en la capa de arriba, la que ocupan Three.js, Babylon o el motor que escribas tú. WebGPU es al 3D web lo que fetch es a un cliente de API REST: la primitiva correcta, no la comodidad.
WebGPU es una especificación del W3C desarrollada por el GPU for the Web Community Group, con participación directa de Google, Apple, Mozilla, Intel y Microsoft. WGSL, el lenguaje de shaders, es una especificación hermana. Las implementaciones de referencia son Dawn en Chromium, wgpu en Firefox y la implementación propia de WebKit. Dawn y wgpu se usan además como bibliotecas nativas fuera del navegador, lo que significa que el mismo código de WebGPU puede ejecutarse en un binario de escritorio.
El precio de ser portable y seguro
WebGPU corre en una página web, y una página web es código hostil por defecto. Eso impone dos restricciones que explican buena parte de la forma de la API.
La primera es la ausencia de comportamiento indefinido. En Vulkan, leer fuera de un búfer es comportamiento indefinido: puede devolver basura, puede leer memoria de otro proceso, puede colgar el driver. En WebGPU, cada acceso indexado desde un shader está acotado: un acceso fuera de rango se recorta al rango válido o devuelve cero, según el caso, pero nunca lee memoria ajena. Los recursos se inicializan a cero antes del primer uso, de modo que no puedes ver los píxeles que dejó otra pestaña en la VRAM. Esas garantías no son gratis; el compilador de shaders inserta comprobaciones y el runtime inserta limpiezas, y ese es el impuesto que paga la web por no ser un vector de exfiltración.
La segunda es la portabilidad estricta. La especificación define un conjunto mínimo de capacidades que todo dispositivo conforme tiene que ofrecer, y cualquier cosa por encima se pide explícitamente y puede no estar. No existe la extensión silenciosa: si tu código usa una capacidad que no pediste, falla la validación aunque el hardware la tenga. Suena rígido y lo es, pero convierte un problema de depuración imposible —«funciona en mi portátil y no en el móvil del cliente»— en un error determinista que aparece en tu máquina.
Hay una tercera restricción que la gente descubre tarde: no hay sincronización explícita. En Vulkan colocas barreras de memoria a mano y decides qué escritura tiene que ser visible para qué lectura. En WebGPU no existe esa API. La implementación deduce las dependencias entre pases a partir de los recursos que tocan e inserta las barreras por ti. Ganas correctitud por defecto y pierdes la capacidad de decirle al driver «esto en realidad no depende de aquello». En la práctica es un intercambio muy bueno, porque el 95% del código de sincronización manual en Vulkan es conservador de todas formas.
Qué reemplaza y qué no
La respuesta honesta es que en 2026 WebGPU no reemplaza a WebGL2 en cobertura, y quien te diga lo contrario está mirando su propio portátil.
WebGPU está implementado por defecto en los tres motores de navegador desde que Safari 26 lo trajo en septiembre de 2025 para macOS, iPadOS, iOS y visionOS. Chromium lo lleva desde 2023 y Firefox lo activó por defecto durante 2025. Pero «implementado en el motor» y «disponible en el dispositivo de tu usuario» son dos frases distintas: cada implementación tiene su matriz de sistemas operativos, versiones y controladores soportados, y esa matriz se ha ido ampliando trimestre a trimestre en lugar de aparecer completa de golpe. Un móvil de gama media de hace cinco años ejecuta WebGL2 sin problema y probablemente no exponga navigator.gpu.
De modo que la relación correcta entre las dos APIs no es sustitución sino mejora progresiva. WebGL2 sigue siendo la base más segura por cobertura de dispositivos antiguos. WebGPU es la ruta rápida y la única ruta cuando necesitas cómputo. Un producto serio detecta cuál hay y decide, y esa decisión se toma en un if de tres líneas al arrancar, no reescribiendo la aplicación.
Lo que WebGPU sí reemplaza sin discusión es el conjunto de técnicas que existían solo porque WebGL no tenía cómputo: dibujar un cuadrilátero a pantalla completa para hacer una reducción, codificar números en canales de color de una textura de punto flotante, usar transform feedback como si fuera un búfer de salida. Todo eso era ingeniería de rodeo y ha dejado de tener sentido.
Todo el mundo que llega de WebGL dice lo mismo: «para pintar un triángulo hacen falta cien líneas». Es cierto, y la conclusión que se saca suele ser falsa. Esas cien líneas no son complejidad accidental de la API: son las decisiones que WebGL tomaba por ti en tiempo de dibujado, cada fotograma, sin decírtelo. El formato del canvas, la disposición de los recursos, el estado de mezcla, la topología de las primitivas: todo eso existía también en WebGL, solo que lo llevaba una máquina de estados global que adivinaba tus intenciones a partir de lo último que hubieras enlazado. WebGPU te obliga a escribirlo una vez, en un objeto, y a cambio no vuelve a preguntártelo.
El corolario práctico: no intentes reducir la verbosidad hasta que la entiendas. La tentación de escribir un envoltorio propio con valores por defecto en la primera semana es enorme y es una trampa, porque los valores por defecto que elegirías son exactamente los que aún no sabes que importan. Escribe las cien líneas a mano tres o cuatro veces. Cuando el envoltorio salga, saldrá con la forma correcta y con la mitad de opciones, porque ya sabrás cuáles no usas nunca.
Con eso el terreno está delimitado. La pieza que falta para tener el mapa completo es de dónde viene la forma de la API, y eso se explica mirando las tres APIs nativas de las que WebGPU es denominador común.