Información del adaptador WebGPU y privacidad del usuario
Comprende qué representa un adaptador WebGPU, cuándo puede no estar disponible y cómo elegir alternativas gráficas sin crear un perfil del dispositivo.
Quieres la documentación estructurada de Huella digital?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
WebGPU permite que una aplicación solicite un adaptador gráfico capaz de ejecutar un dispositivo WebGPU. El adaptador marca una capacidad para una tarea, no una identidad. Su disponibilidad depende del navegador, el sistema operativo, la pila gráfica, las políticas y los recursos actuales. Una aplicación respetuosa con la privacidad pregunta solo lo necesario para elegir una experiencia y ofrece una alternativa clara si la solicitud falla.
Qué representa un adaptador
La especificación WebGPU del W3C describe el adaptador como un objeto que representa una implementación gráfica física o de software con la que se puede crear un dispositivo. La aplicación puede solicitar un adaptador y después un dispositivo con los límites y funciones necesarios. El navegador puede no devolver ningún adaptador, y una respuesta positiva no garantiza que el dispositivo se cree.
El adaptador no es un inventario del renderizador. Empieza por un objetivo visible, como una escena interactiva, una tarea de cálculo o un modo visual reducido. La referencia de WebGPU en MDN documenta la API pública, pero no promete compatibilidad universal. Para distinguir comprobaciones de capacidad y seguimiento, consulta la guía de capacidades y privacidad de WebGL.
Disponibilidad y límites de permiso
navigator.gpu solo aparece cuando el navegador implementa y permite WebGPU en el contexto actual. La solicitud de adaptador puede fallar o no producir resultado. La solicitud posterior del dispositivo también puede fallar si faltan funciones, límites o recursos. Son ramas normales de compatibilidad, no pruebas sobre una persona o una máquina única.
La especificación W3C define el contrato de la API y la documentación del navegador explica las restricciones de cada versión. No afirmes que WebGPU está disponible en todos los navegadores ni que siempre habrá un aviso o campos estables. Documenta el rango probado y conserva una ruta útil para contextos no compatibles.
Decisiones respetuosas con la privacidad
Usa la decisión mínima que seleccione la experiencia. Si basta saber si puede iniciarse el dispositivo, guarda ese resultado y si se aceptaron las funciones necesarias. No conserves una descripción completa del adaptador, no combines datos gráficos con datos de cuenta o red y no conviertas diferencias de capacidad en un identificador persistente. Una decisión de sesión suele bastar; una preferencia de calidad guardada debe ser una elección comprensible del usuario.
Los diagnósticos tienen otro propósito. Si soporte necesita más información, explica qué se recoge, limita el acceso y fija un plazo de conservación. No pidas por defecto un inventario del adaptador. La guía de privacidad entre superficies explica el impacto de combinar señales.
Alternativas y recuperación accesible
Mantén el contenido y los controles esenciales fuera de la superficie gráfica. Si falla el adaptador o el dispositivo, ofrece una escena reducida, una imagen, una tabla u otra representación que cumpla la misma tarea. Conserva filtros y entradas, informa del cambio y evita un lienzo vacío o reintentos infinitos.
Prueba el éxito, la ausencia de adaptador, el rechazo del dispositivo, el fallo de recursos y la pérdida posterior de contexto. El resultado esperado es una experiencia utilizable, no una explicación detallada del hardware. Usa HTML normal para nombres, estados, controles de teclado e información equivalente. La guía sobre fingerprinting de WebGPU trata el riesgo de seguimiento; aquí nos limitamos a decisiones normales de capacidad.
Planificar la solicitud según el resultado
Define la tarea y el resultado visual imprescindible antes de solicitar.
Mantén navegación, cuenta y ayuda como controles HTML.
Usa modos estándar, reducido y alternativo estático.
Si falta una función, elige el modo documentado sin consultar más campos.
Mantener los datos temporalmente
El resultado de la sesión suele ser suficiente.
Guarda una preferencia elegida, no los hechos del adaptador.
Un diagnóstico puede registrar fase y versión, no el objeto completo.
La capacidad gráfica no demuestra atributos sensibles.
Tratar fallos como producto
Prueba ausencia de WebGPU, adaptador vacío y rechazo del dispositivo.
Separa los fallos de red de los fallos gráficos.
Conserva filtros, estado y controles de teclado en la alternativa.
Registra el rango probado con W3C y MDN sin prometer compatibilidad universal.
Prepara la estructura de la página antes de solicitar.
El modo reducido debe cumplir la tarea principal.
No nombres el hardware para explicar un fallo normal.
Limita el número de reintentos.
Conserva el estado si se pierde el contexto.
El resultado debe existir sin animación.
Revisa también el flujo de datos de las bibliotecas.
Asigna propósito y caducidad a las cachés.
Respeta las políticas administradas.
Explica por separado los errores de red.
Elimina campos de registro que ya no se usan.
Revisa las fuentes públicas antes de publicar.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.