WebGPU: el nuevo motor de rendimiento del navegador

Durante años, el rendimiento de las tareas intensivas en el browser ha tenido un techo claro: la CPU. Da igual lo bien optimizado que esté nuestro JavaScript, hay operaciones, como procesar píxeles, aplicar filtros a imágenes o ejecutar modelos de ML, que la CPU simplemente no puede hacer con suficiente rapidez para mantener 60 fps.

WebGPU cambia eso. No es una librería ni un framework: es una API del navegador que da acceso directo a la GPU del dispositivo. Y con eso, permite un nivel de rendimiento que la CPU no puede igualar para ciertos tipos de carga.

En este primer artículo de la serie exploraremos qué es WebGPU, cómo encaja en la arquitectura del browser y por qué es relevante desde el punto de vista del rendimiento.

¿Qué es WebGPU?

WebGPU es una API web de bajo nivel para gráficos y computación en la GPU. Fue diseñada por el W3C como sucesor de WebGL, con un modelo de programación más cercano a las APIs modernas de gráficos como Vulkan, Metal y Direct3D 12.

La diferencia clave con WebGL es que WebGPU no está limitado al renderizado de gráficos. Incluye soporte para compute shaders: programas que se ejecutan en la GPU y pueden procesar datos en paralelo de forma masiva, sin necesidad de dibujar nada en pantalla.

Esto abre dos grandes familias de uso:

• Renderizado: escenas 3D, efectos visuales, juegos en el browser
• Computación general (GPGPU): procesamiento de imágenes, vídeo, machine learning

CPU vs GPU: ¿por qué importa para el rendimiento?

Para entender por qué WebGPU tiene impacto en el rendimiento, hay que entender la diferencia entre CPU y GPU.

La CPU tiene pocos núcleos (4-16 en un portátil moderno) pero cada uno es muy potente y capaz de ejecutar código secuencial complejo.

La GPU tiene miles de núcleos más simples, diseñados para ejecutar la misma operación sobre muchos datos al mismo tiempo. Una GPU de gama media tiene más de 1.000 núcleos.

Cuando necesitamos aplicar un filtro a una imagen de 4K (8 millones de píxeles), la CPU tiene que procesar cada píxel uno a uno (o con un paralelismo muy limitado). La GPU puede procesar miles de píxeles en paralelo.

Imagen 4K: 3840 × 2160 = 8.294.400 píxeles

CPU (8 núcleos):    ~1M píxeles/iteración
GPU (2048 núcleos): ~2M píxeles/iteración (en cada paso del shader)

Para procesamiento de datos masivo y uniforme, la GPU gana por goleada.

El modelo de WebGPU

WebGPU introduce conceptos nuevos respecto a lo que estamos acostumbrados en JavaScript. Los más importantes:

Device

Representa la GPU. Es el punto de entrada para crear todos los recursos.

Command encoder

Grabamos una secuencia de comandos GPU (no se ejecutan hasta que los enviamos).

Render pipeline / Compute pipeline

Define cómo se procesa la información: qué shaders se usan, qué formato tienen los datos de entrada y salida.

Buffer

Bloque de memoria en la GPU. Los datos (vértices, píxeles, tensores) viven aquí durante el procesamiento.

Shader (WGSL)

Programa que se ejecuta en la GPU. WebGPU usa su propio lenguaje: WGSL (WebGPU Shading Language).

// Ejemplo mínimo: solicitar acceso a la GPU
const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

console.log(adapter.info);
// { vendor: 'apple', architecture: 'metal-3', device: '', description: '', subgroupMinSize: 32 }

Soporte actual

En iOS, Chrome y Firefox usan el motor WebKit, así que el soporte depende de la versión de iOS, no del navegador.

En Android, Chrome tiene soporte desde la versión 121 (enero 2024), pero con un matiz importante: el soporte depende también de los drivers del GPU del dispositivo. Un Android con Chrome 121+ no garantiza WebGPU disponible en todos los modelos. Siempre hay que comprobar navigator.gpu en tiempo de ejecución.

// Detección de soporte
if (!navigator.gpu) {
  console.warn("WebGPU no está disponible en este navegador");
}

WebGPU en móvil: rendimiento y batería

El soporte está, pero hay que tener en cuenta que la GPU de un móvil no es la GPU de un portátil. Hay dos limitaciones específicas de móvil que afectan directamente al rendimiento:

Throttling térmico: Tras unos segundos de carga GPU sostenida, el dispositivo reduce la frecuencia del chip para no sobrecalentarse. Una operación que tarda 8ms al inicio puede tardar 25ms después de 30 segundos de uso continuo. Esto es especialmente relevante para casos de uso en tiempo real (vídeo, cámara).

Batería: La GPU consume mucho más que la CPU. Para tareas puntuales no es un problema, pero para procesamiento continuo hay que valorar el impacto. La API no expone información sobre el estado de la batería, así que la estrategia más prudente es activar WebGPU solo cuando el usuario lo desencadena explícitamente, no en background.

Recursos para verificar soporte

Para saber si un dispositivo concreto soporta WebGPU:

• webgpureport.org — abre esta URL en cualquier dispositivo y muestra al momento si WebGPU funciona, junto con los detalles del adaptador (vendor, arquitectura, features, límites).
• vulkan.gpuinfo.org — base de datos con más de 20.000 dispositivos Android. Como WebGPU en Android requiere Vulkan, si un dispositivo aparece aquí con soporte Vulkan 1.0+, es candidato a soportar WebGPU.
• Implementation Status (gpuweb wiki) — el wiki oficial del W3C. Lista qué familias de GPU tienen soporte en Chrome Android (Adreno, Mali, Imagination…) y desde qué versión del navegador.
• caniuse.com/webgpu — tabla de soporte por navegador, con filas separadas para Chrome Android, Samsung Internet y Firefox Android.

Para producción, la cobertura ya es suficiente para plantear una estrategia de progressive enhancement: WebGPU cuando está disponible, WebAssembly como fallback de rendimiento, y Canvas 2D para cobertura universal.

¿WebGPU o WebAssembly para procesamiento intensivo?

Una duda habitual: si WebAssembly también acelera el código en el browser, ¿cuándo elegir WebGPU?

El orden de rendimiento para operaciones sobre muchos datos uniformes (píxeles, matrices) es:

WebGPU > WebAssembly (SIMD) > Canvas 2D JS puro

WebAssembly con SIMD procesa 4-8 valores en paralelo (128 bits). WebGPU procesa miles en paralelo. Para una imagen de 1920×1080, WASM se sitúa en el rango de ~50-80ms; WebGPU llega a ~8ms.

WebAssembly gana a WebGPU cuando el algoritmo tiene mucha lógica condicional (la GPU es mala en branching), cuando las imágenes son pequeñas (la latencia de transferencia CPU→GPU puede superar el beneficio), o cuando se necesita soporte en Firefox.

En la práctica: WebGPU para tiempo real y volumen alto, WebAssembly para algoritmos complejos o cobertura de navegadores amplia.

¿Cuándo tiene sentido usar WebGPU?

WebGPU no es la solución para todo. La API tiene una complejidad real: setup verboso, gestión explícita de memoria, un lenguaje de shaders propio. No tiene sentido usarla para operaciones que la CPU resuelve sin problemas.

Tiene sentido cuando:

• Procesamos muchos datos con operaciones uniformes (píxeles, frames de vídeo, matrices)
• Necesitamos resultados en tiempo real (< 16ms por frame para 60 fps)
• La CPU ya es el cuello de botella medido, no asumido
• Ejecutamos modelos de ML en el browser

No tiene sentido cuando:

• La operación es puntual y no hay restricción de tiempo
• Los datos son pocos o la lógica es muy ramificada
• Necesitamos soporte en Firefox o navegadores antiguos sin fallback

Lo que viene en la serie

Este primer artículo establece las bases. En los siguientes exploraremos casos concretos con código real y benchmarks:

1. Procesamiento de imágenes con WebGPU: filtros y transformaciones, comparativa directa con Canvas 2D.
2. ML en el browser con WebGPU: TensorFlow.js con el backend WebGPU, inferencia en tiempo real.
3. Edición de vídeo en el browser con WebGPU: efectos en tiempo real frame a frame.

Si nunca has escrito un shader en tu vida (yo tampoco hasta hace poco), no te preocupes: empezamos desde cero.

Conclusión

WebGPU no es hype. Es una API con soporte real en los principales navegadores que da acceso a un nivel de paralelismo que la CPU no puede igualar para ciertas tareas. Para quien trabaja en rendimiento web, entender cuándo y cómo usarla es una herramienta más en el arsenal.

En el próximo artículo ponemos las manos en el código: procesamiento de imágenes, benchmarks incluidos.