El soporte real de WebGPU en 2026

WebGPU está en los tres motores. Es verdad y es la frase que más daño hace, porque la gente la oye y entiende otra cosa: que si el navegador del usuario es reciente, WebGPU funcionará. Esa inferencia es falsa en las dos direcciones, y la diferencia entre las dos afirmaciones se mide en el porcentaje de usuarios que ven una pantalla negra.

La tabla, motor por motor

El hito que cambió la conversación fue Safari 26, en septiembre de 2025, que implementó WebGPU en macOS, iPadOS, iOS y visionOS. Con eso la API pasó de estar en un motor y medio a estar en los tres. Pero el reparto por plataformas es desigual y el detalle está en las filas, no en la columna:

Esa tabla es lo que hay que interiorizar, y en particular las tres ausencias de Firefox y la condición de Chrome en Linux. Un desarrollador en un portátil con Linux y una gráfica AMD, usando Firefox, no tiene WebGPU en 2026, y lo mismo le pasa a cualquiera con un Mac Intel. No son casos exóticos: son fracciones perfectamente reales de un público técnico.

Hay además una asimetría por contexto que rompe arquitecturas: Firefox soporta WebGPU en todos los contextos menos en los service workers. Si tu diseño descarga y descomprime texturas en un service worker con la GPU, ese camino no existe ahí.

Cobertura de navegadores no es cobertura de dispositivos

Aquí está el núcleo de la lección. Que un navegador implemente WebGPU es condición necesaria y no suficiente, porque entre la implementación y el usuario hay cuatro filtros más.

El primero es la lista de bloqueo de drivers. Todos los navegadores mantienen listas de combinaciones de GPU, driver y sistema operativo donde la aceleración se desactiva por fallos conocidos o por agujeros de seguridad. Un usuario con un driver de hace cuatro años puede tener un Chrome al día y ningún adaptador. No es un caso raro: es la causa más frecuente de “a mí no me funciona” en portátiles corporativos, donde los drivers los congela el departamento de sistemas.

El segundo es el hardware. WebGPU necesita por debajo Direct3D 12, Metal o Vulkan. Un equipo con una gráfica de la era de Direct3D 11 no tiene backend, aunque el navegador esté actualizado y aunque WebGL2 funcione perfectamente en él. Ese es el hueco exacto que WebGL2 cubre y WebGPU no.

El tercero es la virtualización. Máquinas virtuales, escritorios remotos, contenedores y entornos de integración continua a menudo exponen una GPU emulada sin los backends necesarios. Si tus pruebas automatizadas corren en un contenedor sin GPU, no están probando tu ruta de WebGPU aunque el navegador sea el correcto.

El cuarto es la política. Perfiles gestionados, extensiones que desactivan la aceleración, modos de ahorro de energía agresivos y ajustes de privacidad pueden apagar la API o el adaptador.

La traducción a código de todo esto es una sola línea de comportamiento que hay que tratar como normal y no como excepción: navigator.gpu puede existir y requestAdapter() devolver null. No es un error, es el mecanismo por el que la plataforma te dice “aquí no”. Y todavía hay un caso más: puede devolverte un adaptador de reserva, que es una implementación por software o muy limitada, capaz de ejecutar tu código a una velocidad que no sirve para nada interactivo.

const adapter = await navigator.gpu?.requestAdapter();

if (!adapter) {
  // Ni WebGPU ni adaptador. Es un resultado esperado, no un fallo.
  usarRutaDeReserva('sin-adaptador');
} else if (adapter.info.isFallbackAdapter) {
  // Hay adaptador, pero es de reserva: probablemente por software.
  usarRutaDeReserva('adaptador-de-reserva');
} else {
  arrancarWebGPU(adapter);
}

Puedes forzar ese camino para probarlo, que es lo que hace útil la comprobación:

// Pide deliberadamente el adaptador de reserva para ver cómo se comporta tu app.
const reserva = await navigator.gpu?.requestAdapter({ forceFallbackAdapter: true });

Y el segundo criterio, el que de verdad protege al usuario: no decidas la calidad por la existencia de la API, decídela midiendo. Arranca en la configuración más barata que aún se vea bien, mide el tiempo de fotograma durante uno o dos segundos, y sube la calidad solo si sobra presupuesto. Un adaptador válido no dice nada sobre si vas a llegar a sesenta fotogramas por segundo, y la única fuente fiable sobre eso es el reloj.

El modo de compatibilidad

La respuesta del grupo de trabajo al hueco de hardware se llama modo de compatibilidad y se pide en la creación del adaptador:

const adapter = await navigator.gpu?.requestAdapter({
  featureLevel: 'compatibility',
});

La idea es que WebGPU pueda implementarse también encima de APIs más antiguas (Direct3D 11 y OpenGL ES 3.1), a cambio de rendimiento y de un conjunto de capacidades recortado. La forma en que la especificación lo expresa es elegante: existe una feature llamada core-features-and-limits que todos los adaptadores normales tienen activada, y un adaptador de compatibilidad es precisamente uno que no la tiene. Así puedes comprobar en qué mundo estás con la misma API que usas para todo lo demás:

if (!adapter.features.has('core-features-and-limits')) {
  // Estamos en modo de compatibilidad: recorta lo que no vaya a funcionar.
}

El detalle que hace que esto sea usable en la práctica: un adaptador de compatibilidad solo se crea en dispositivos que no soportan WebGPU completo. En un equipo capaz, pedir featureLevel: 'compatibility' te devuelve igualmente un adaptador con todas las capacidades, así que puedes pedirlo siempre y comprobar la feature después, sin bifurcar el arranque.

Ahora la parte honesta del estado en 2026: el modo de compatibilidad es experimental y solo está en Chromium, desde Chrome 146, y de momento únicamente en Android 10 o superior con OpenGL ES 3.1 o superior. Ni Firefox ni Safari lo implementan. Es la dirección correcta y todavía no es una herramienta con la que se pueda contar; trátalo como una mejora que quizá amplíe tu cobertura en Android y no como la solución al problema de los equipos antiguos.

Cómo mantener este dato al día

Todo lo anterior tiene fecha de caducidad, y la peor manera de usar esta lección es memorizar la tabla. Lo que no caduca es el método.

Consulta la fuente primaria, no los artículos. Los datos de compatibilidad de MDN salen del repositorio de datos de compatibilidad de navegadores, que es público y donde cada entrada lleva sus notas por plataforma y sus enlaces a los informes de error correspondientes. Ese nivel de detalle (que Firefox no tiene macOS con Intel, que Chrome en Linux está restringido a cierta familia de gráficas) es justo el que se pierde en cualquier resumen, incluido este.

Distingue tres preguntas distintas y no las mezcles nunca: si la especificación define algo, si un motor lo ha implementado, y si el dispositivo del usuario lo ejecuta. La primera se responde en la especificación, la segunda en los datos de compatibilidad, y la tercera solo con telemetría tuya.

Mide tu público, no el mundo. El porcentaje global de navegadores con WebGPU es un dato de titular. El que te sirve es el de tus usuarios, y lo obtienes con una sonda de tres líneas que registre si hubo adaptador, si era de reserva, y qué dice adapter.info.

export async function sondearSoporte() {
  const resultado: Record<string, unknown> = { api: 'gpu' in navigator };
  if (resultado.api) {
    const adapter = await navigator.gpu.requestAdapter();
    resultado.adaptador = adapter !== null;
    if (adapter) {
      resultado.reserva = adapter.info.isFallbackAdapter;
      resultado.vendor = adapter.info.vendor;
      resultado.arquitectura = adapter.info.architecture;
      resultado.core = adapter.features.has('core-features-and-limits');
    }
  }
  return resultado;
}

Dos semanas de esa sonda valen más que cualquier tabla, incluida la de esta lección.