Device Memory API y rendimiento web: pistas de memoria seguras
Qué puede y qué no puede indicar navigator.deviceMemory, cómo adaptar recursos de forma progresiva y cuáles son sus límites de privacidad.
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.
navigator.deviceMemory es una pista aproximada que ayuda a una aplicación web a elegir un plan de recursos prudente. No es un inventario de RAM, una prueba de rendimiento ni una razón para identificar a una persona. Trátala como una entrada opcional, combínala con señales del tiempo de ejecución y conserva un valor predeterminado útil para los navegadores que no la exponen.
Qué representa Device Memory API
Device Memory API expone navigator.deviceMemory, un valor aproximado de memoria del dispositivo en gigabytes. La especificación del W3C describe un valor reducido y agrupado, no una medición exacta. El navegador puede redondearlo o limitarlo antes de devolverlo, por lo que el código debe interpretarlo como una pista amplia de capacidad.
La propiedad sirve para elegir entre variantes de recursos ya diseñadas: aplazar una imagen grande, reducir una caché inicial o seleccionar una tarea de cliente más ligera. No indica la memoria libre actual ni predice si una página terminará correctamente. Tampoco informa sobre cuota de almacenamiento, velocidad de CPU, calidad de red o preferencias de la persona.
Disponibilidad y límites
La compatibilidad no es universal. MDN documenta Navigator.deviceMemory como una función experimental y de disponibilidad limitada; algunos navegadores pueden omitirla o exponerla solo en contextos seguros. El código debe detectar la propiedad y funcionar cuando falte, sin interpretar su ausencia como memoria baja.
El valor es impreciso por diseño y puede variar según la política del navegador. No debe usarse como barrera de compatibilidad, comprobación de derechos ni umbral para etiquetar un dispositivo o a su propietario. No infieras modelo, ingresos, ubicación o identidad a partir de un grupo. Es una superficie sensible de privacidad, no un perfil fiable del dispositivo.
Adaptación progresiva para cargas reales
Empieza con una experiencia base que funcione sin la API. Si hay una pista, úsala para elegir una variante acotada y observa el resultado con métricas normales, como finalización de carga, fallos de decodificación, tareas largas y cancelaciones. Esas señales describen mejor la tarea actual que una estimación fija del hardware.
Adapta un coste cada vez y haz que la decisión sea reversible. Puedes cargar de forma diferida los medios inferiores, elegir una vista previa menor, reducir los workers simultáneos o posponer un índice opcional. Conserva el mismo contenido semántico y los controles accesibles. No retires una acción necesaria solo porque falte o sea pequeña la pista.
La guía de planificación de capacidad de BrowserContext cubre presupuestos medidos para cargas de navegador prolongadas. La guía de capacidades WebGL y privacidad muestra el mismo patrón de respaldo primero, y señales de almacenamiento y memoria en perfiles explica por qué no deben confundirse valores de recursos distintos.
Alternativas que respetan la privacidad
Mantén la pista local a la decisión que la necesita. No envíes el valor sin procesar a un servidor, no lo añadas a un identificador de cuenta ni lo conserves como atributo estable de perfil salvo que una función explicada claramente lo requiera. Un valor agrupado aún puede contribuir a la identificación por huella al combinarse con otras señales.
Prefiere unas pocas políticas de recursos con un valor predeterminado explícito y documenta que la elección es heurística. Respeta controles como el ahorro de datos y permite pedir la experiencia completa cuando sea posible. Si la adaptación cambia la transferencia de datos, explica el cambio antes y conserva una forma accesible de continuar.
Usa la pista en la capa correcta
La API pertenece a decisiones de presentación o programación, no a identidad, autorización o facturación. La página puede aplazar una vista previa opcional mientras el servidor mantiene los mismos permisos y registros necesarios.
No hagas depender al servidor de un valor que puede faltar o redondearse distinto. Si necesita una preferencia, envía una elección visible y temporal, como ahorro de datos, no el grupo de memoria.
Combina capacidad y resultados
La memoria es solo una parte de la carga. Latencia, decodificación, CPU, almacenamiento, pantalla y preferencias pueden dominar el resultado. Mide lo que importa a la persona, no una estimación fija.
Observa si una imagen se decodifica, si el vídeo empieza, si hay reintentos, la latencia de entrada y la recuperación. Esos resultados guían políticas sin convertir la pista en una etiqueta.
Diseña primero la experiencia base
Incluye contenido necesario, teclado, texto legible y una forma de reintentar mejoras. La variante ligera puede aplazar mejoras, pero no ocultar la única ruta para terminar una tarea.
Prueba sin propiedad, con lectura tardía y con un valor agrupado. También prueba cambios de ahorro de datos durante la sesión. El objetivo es funcionar en todas las ramas.
Elige políticas que resistan cambios
Imágenes adaptables, carga diferida, presión de flujo, cachés acotadas y cancelación siguen siendo útiles aunque falte la API. Reducen presión incluso en dispositivos con memoria suficiente.
Mantén pocas políticas con nombres claros. Cada una debe indicar tamaño máximo, concurrencia, caché y recuperación para facilitar la auditoría.
Registros y conservación
Registra la política y el resultado, no un dato de hardware innecesario. resource_policy=reduced suele explicar un aplazamiento. Si hace falta el valor bruto para depurar, limita acceso y conservación y elimínalo después.
Agrega resultados por política. No construyas paneles que ordenen a personas por memoria; mejorar por resultados evita crear un identificador entre sesiones.
Preguntas antes de publicar
Confirma que la experiencia está completa sin la propiedad, que ningún permiso o cuenta depende de ella y que los registros no guardan el valor bruto. Permite entender y revertir una reducción opcional.
Repite la revisión tras actualizar el navegador o la página. Una prueba pequeña sin la propiedad suele ser más útil que muchas clases de dispositivos supuestas.
Prueba la disponibilidad sin suponer una familia de navegadores
La detección de características debe ser una rama normal, no una prueba del nombre del navegador. Lee la propiedad solo si existe y conserva la experiencia base cuando sea undefined. El contexto seguro, la navegación privada o un iframe pueden cambiar la disponibilidad.
Prueba esa rama en los entornos admitidos. Comprueba el contenido y los controles necesarios, no un valor fijo. Una actualización puede cambiar el redondeo, por lo que las pruebas deben centrarse en el comportamiento.
Separa las pistas de memoria de los presupuestos
La pista puede elegir una política inicial, pero el presupuesto es un compromiso medido contra una carga. Mantén ambos registros separados: la pista pertenece a la página y el presupuesto al lanzamiento, host, carga y ventana de observación.
Si se supera el presupuesto, revisa ciclo de vida, medios, workers, caché y red antes de cambiar la política. Una fuga afecta a todas las clases de dispositivo; también puede haber latencia por CPU aunque la memoria esté dentro del presupuesto.
Usa la intención de la persona como autoridad final
La adaptación no debe anular una elección clara. Si alguien solicita un documento completo, explica el coste y ofrece carga progresiva, pero no reduzcas el contenido en silencio. El ahorro de datos es distinto de la memoria y debe tratarse explícitamente.
Ofrece reintento visible para mejoras opcionales y explica cada demora. No solicites un dato de hardware solo para elegir una imagen menor; presenta el tamaño o modo de transferencia claramente.
Evita la correlación entre sesiones
El uso más respetuoso es efímero: lee la pista para la tarea actual, conserva solo la política elegida y descarta el valor bruto. No la combines con ID, historial de IP, Canvas, fuentes o tiempos para crear un perfil.
Para soporte, registra la política, versión del navegador y carga reproducible, no el grupo de memoria. Los informes agregados pueden comparar políticas sin seguir a una persona.
Planifica cambios y recuperación
Cada política necesita responsable, condición de reversión y fecha de revisión. Repite la carga cuando cambie el navegador, el paquete, los medios o el host. Mantén la vía base hasta tener evidencia suficiente.
La recuperación también es rendimiento: cancela trabajo opcional al salir, libera buffers al cerrar una vista previa y evita bucles de reintento bajo presión. Estas medidas sirven para cualquier memoria.
Documenta el límite público
La documentación debe decir que la API es una pista aproximada y opcional y que existe una ruta base. También debe aclarar que no mide memoria libre, no garantiza rendimiento, no identifica dispositivos ni autoriza cuentas.
Registra las dos fuentes públicas. La especificación W3C respalda el valor reducido y el motivo de privacidad; MDN respalda la advertencia de disponibilidad. Si cambia el soporte, actualiza la compatibilidad y vuelve a probar la alternativa.
La revisión también debe cubrir el fallo de cada recurso opcional: una imagen cancelada conserva su texto alternativo, un worker que no inicia ofrece una ruta principal y una caché no disponible usa solicitudes acotadas. Una pista limitada no ve la presión temporal ni otras pestañas. Verifica con recorridos sintéticos la primera carga, la visita de retorno, cambios de estado, transferencias interrumpidas y cierre. Registra finalización, cancelación, latencia y recuperación sin contenido ni identificadores. Así se mejoran las políticas sin convertir Device Memory API en un perfil de hardware.
Los equipos con varios productos pueden mantener nombres de políticas coherentes y ajustar sus límites por carga. Un visor reduce vistas previas y un editor reduce índices, pero ambos pueden usar la política reduced para soporte. Publica el comportamiento comprensible, no el grupo de memoria. Si la evidencia no basta, conserva la política sencilla en lugar de recopilar más datos identificables.
Mantén los registros de revisión pequeños y reproducibles: definición de política, carga, versión del navegador y resultados suelen bastar. La prueba debe poder repetirse sin acceder a páginas privadas de clientes y conservar evidencia útil para comparar versiones.
En una revisión de producción, registra también qué alternativa se mostró cuando la pista no estaba disponible y si la persona pudo continuar sin cambiar una configuración. Así se relaciona la decisión de la API con la experiencia real: una imagen menor, una vista previa diferida o menos workers deben seguir siendo comprensibles y reversibles. Esta evidencia de comportamiento es más útil que conservar un grupo de hardware y facilita repetir la comprobación tras una actualización.
Si el servidor necesita explicar la elección, registra solo el nombre temporal de la política y el resultado de la tarea. No envíes la pista como atributo de la cuenta; así se conserva la capacidad de revertir y depurar sin convertir una decisión de compatibilidad en un perfil entre sesiones.
Lista práctica de decisiones
- Detecta
navigator.deviceMemory; nunca supongas que existe. - Define una experiencia base independiente de la pista.
- Usa variantes amplias y reversibles, no etiquetas de dispositivos.
- Mide los resultados de la tarea y ajusta los presupuestos según los fallos observados.
- Mantén el valor fuera de identificadores, registros y solicitudes remotas salvo que la persona entienda el propósito.
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.