navigator.hardwareConcurrency y planificación de Web Workers
Cómo interpretar navigator.hardwareConcurrency, elegir el tamaño de un grupo de Web Workers y probar la concurrencia sin confundir una pista del navegador con el número de núcleos.
Quieres la documentación estructurada de Plataforma?
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.hardwareConcurrency es una pista de concurrencia que ofrece el navegador, no una promesa de que una página pueda ejecutar ese número de tareas a la vez. Úsalo como una entrada de una política acotada para un grupo de Workers y mide después la espera en cola, el tiempo de finalización, la presión de memoria y la capacidad de respuesta. Un buen plan mantiene el trabajo por debajo del punto en que más Workers solo añaden contención.
El valor representa la cantidad de procesadores lógicos expuestos a la página, y el navegador puede reducirla para limitar la concurrencia. La guía de dispositivo y ventana gráfica muestra otro límite: un valor expuesto por el navegador sirve para compatibilidad, no describe todo el dispositivo.
Qué significa el valor
La referencia de MDN sobre Navigator.hardwareConcurrency define el número de procesadores lógicos disponibles para ejecutar hilos en el ordenador del usuario. También indica que el navegador puede informar menos procesadores de los que tiene la máquina. Por eso sirve como estimación inicial, pero no demuestra cuántos núcleos físicos hay, la carga actual de CPU ni la memoria disponible para la página.
La propiedad se puede leer desde navigator en una ventana y desde el ámbito global de un Worker. No crea hilos, no reserva tiempo de CPU ni convierte una tarea en paralela. Un Worker sigue comunicándose mediante mensajes, y la página sigue pagando los costes de serialización, planificación, asignación y sincronización.
Trata los cambios como eventos normales de compatibilidad. Otra versión del navegador, una política del sistema operativo, el modo de energía, una configuración de privacidad o un contexto distinto pueden exponer otra pista. No uses el número como señal de identidad, decisión de autorización ni motivo para recoger un perfil de hardware más detallado.
Convierte la pista en una política de Workers
Empieza con un grupo pequeño y una cola. Para trabajos independientes y limitados por CPU, el límite inicial no debería superar la pista informada y a menudo debe ser menor. Reserva capacidad para la página, la entrada, la red, el renderizado y el sistema operativo. En trabajos limitados por I/O, pueden bastar menos Workers porque pasan tiempo esperando.
El modelo de Workers de WHATWG define los Workers como contextos de ejecución separados que se comunican con su creador mediante mensajes. Por eso la cola es importante: envía lotes acotados, transfiere búferes grandes cuando corresponda y define qué ocurre al cancelar un trabajo o cuando falla un Worker. El grupo debe poder dejar de aceptar trabajo en lugar de crecer sin límite.
Usa una política como min(availableHint, configuredMaximum) en vez de copiar directamente la pista como tamaño del grupo. Define un máximo distinto para móviles o contextos con poca memoria, y deja que el límite de la aplicación prevalezca cuando el coste del trabajo sea conocido. El máximo configurado es una decisión del producto; la pista del navegador solo es una entrada.
Mide la saturación y la respuesta
Prueba el trabajo real, no un bucle vacío. Registra la espera en cola, el tiempo de ejecución, la finalización de extremo a extremo, los trabajos fallidos o cancelados, el uso de memoria y la respuesta del hilo principal. Compara un Worker, un grupo pequeño y grupos mayores con datos representativos. Deja de aumentar la concurrencia cuando el rendimiento se aplana o empeoran la latencia, la memoria o la interacción.
Separa las pruebas en frío y en caliente. El arranque del Worker y la carga del script pueden dominar un trabajo corto, mientras que un flujo largo puede estar limitado por el cálculo o la transferencia de mensajes. Anota la versión del navegador, el tamaño de entrada, la clase de dispositivo y el estado de energía para comparar resultados. No deduzcas la topología física de la máquina solo a partir de tiempos.
Incluye las rutas de fallo. Un Worker terminado, un mensaje rechazado, un fallo por memoria o un cambio de visibilidad de la página debe devolver el trabajo a una cola acotada o a un estado de error claro. La cancelación debe liberar búferes y sacar el trabajo de las métricas. Limita los reintentos para que un trabajo fallido no mantenga saturado el grupo.
Mantén los límites de privacidad y compatibilidad
La pista es deliberadamente aproximada y puede estar reducida. La página debe seguir funcionando si falta, es pequeña o no coincide con una observación anterior. Detecta el soporte de Workers y ofrece una alternativa en el hilo principal o secuencial para trabajos cortos. No combines hardwareConcurrency con mediciones de tiempo, gráficos, fuentes o almacenamiento para identificar a una persona o un dispositivo.
Explica la elección de recursos cuando afecte a la batería, los datos o una carga. Un grupo local de Workers no autoriza a enviar datos a otro lugar. Si un flujo cambia del procesamiento local a un servicio remoto, pide una elección explícita e indica qué datos salen del dispositivo. Conserva en los registros solo las mediciones necesarias para operar la cola, sin contenido bruto ni detalles de hardware innecesarios.
Clasifica el trabajo antes de elegir el grupo
Es más fácil elegir el número de Workers cuando el trabajo tiene una forma clara. Una transformación limitada por CPU puede beneficiarse de varios Workers hasta ocupar el procesador. Una tarea limitada por la red pasa tiempo esperando, por lo que añadir Workers puede aumentar la presión sin mejorar la página. Un trabajo que comparte estado puede necesitar menos Workers porque la coordinación es el límite.
Separa el trabajo independiente del trabajo ordenado. Los elementos independientes pueden terminar en cualquier orden y recuperar el orden de presentación con un número de secuencia. Las etapas ordenadas deben conservar sus dependencias en vez de crear un Worker para cada paso. Define la unidad de trabajo incluyendo preparación, transferencia, ejecución, resultado y limpieza antes de medirla.
Diseña el ciclo de vida de la cola
Una cola acotada necesita reglas de admisión, ejecución y finalización. La admisión puede rechazar trabajo, reemplazar una actualización o mostrar progreso al alcanzar el límite. La ejecución debe marcar el trabajo activo y tener cancelación o tiempo límite. La finalización libera el Worker, resuelve el trabajo una sola vez y actualiza las mediciones.
La contrapresión forma parte de la experiencia. Si se seleccionan más archivos de los que la página puede procesar, explica si esperan, se descartan o se procesan después. No hagas crecer silenciosamente una lista ilimitada de cargas. Un límite claro protege la memoria y permite cancelar o reanudar.
Deja un único dueño para el estado de la cola. La página puede controlar admisión y orden, mientras cada Worker controla su tarea. Los mensajes llevan un identificador y los datos necesarios; las respuestas indican éxito, fallo o cancelación. Así una respuesta tardía no cambia un trabajo que el usuario ya sustituyó.
Cuenta los costes de transferencia y memoria
El paralelismo no elimina el movimiento de datos. El clonado estructurado puede copiar objetos, mientras los búferes transferibles pueden mover la propiedad cuando la API lo permite. Mide ambas opciones con cargas representativas. Un grupo que copia durante casi todo el tiempo no es más rápido para el usuario.
Limita las cargas y libera referencias al terminar. Los datos retenidos por página, cola y Worker pueden multiplicar la memoria aunque haya pocas tareas activas. Al cancelar, elimina la carga en espera y detén el Worker cuando sea posible. Un fallo de asignación es un error normal, no motivo para aumentar el grupo.
Los resultados también necesitan una política de retención. Renderiza solo lo necesario para la vista, pagina listas grandes y evita copias duplicadas. Si guardas un resultado, define su duración y cuándo se invalida. Estas decisiones suelen mejorar la respuesta más que añadir otro Worker.
Adapta el trabajo a la visibilidad y la energía
Una página oculta puede tener otras restricciones de planificación. Detén el trabajo no esencial cuando el documento esté oculto, o baja su prioridad y deja que la cola se vacíe. Al volver, comprueba si los trabajos siguen siendo útiles, porque una búsqueda o vista previa pudo cambiar.
En móviles, un grupo sostenido puede consumir batería y generar calor. Ofrece un modo que favorezca la respuesta y la batería para tareas interactivas o de fondo. El modo debe cambiar el máximo configurado, no tratar la pista como medida de la batería.
No uses visibilidad ni energía como señales de identidad. Son entradas operativas que cambian durante una sesión. Mantén la decisión en la tarea, explica las pausas y no envíes esas observaciones sin elección del usuario.
Haz observable el comportamiento de reserva
Detecta la capacidad en el punto de uso. Comprueba el constructor de Worker y la mensajería, y ofrece una ruta secuencial cuando no estén disponibles. La alternativa puede procesar un elemento, ceder entre bloques o pedir otro intento, conservando el formato de resultado y la cancelación cuando sea posible.
Muestra estados útiles sin detalles internos: preparando, procesando, en pausa o no se pudo completar. Ofrece reintentar solo si puede cambiar el resultado y explica un fallo permanente. El número de Workers no es una garantía de velocidad.
Prueba un Worker cerrado, un resultado mal formado, un tiempo límite, una cancelación durante la transferencia y una navegación. Cada caso debe resolver su trabajo, liberar recursos y dejar utilizables los demás. Un trabajo defectuoso no debe bloquear la cola.
Lee las mediciones como decisiones, no promesas
Los resultados responden a una pregunta limitada: para esta carga, tamaño, navegador y dispositivo, qué política ofrece un equilibrio aceptable. No establecen un tamaño universal. Mantén una matriz representativa y repite pruebas para distinguir cambios estables del ruido de arranque.
Compara distribuciones, no solo promedios. El percentil lento, la tasa de cancelación, el pico de memoria y las tareas largas del hilo principal pueden mostrar una regresión oculta. Registra la pista, el máximo, la versión del script y si la prueba fue fría o caliente.
Convierte el resultado en una política reversible. Empieza con un valor prudente, limita contextos restringidos y cambia el límite cuando nuevas mediciones lo apoyen. Si cambia el trabajo, mide de nuevo. La pista sigue siendo aproximada aunque coincida con los procesadores físicos.
Para operar la cola basta registrar su longitud, las cancelaciones y la latencia de extremo a extremo. No guardes entradas originales ni detalles de hardware que no sean necesarios.
Fuentes
Para decisiones relacionadas sobre capacidades del navegador, consulta la guía de coherencia de WebAssembly y la guía de planificación de capacidad de contextos. Mantén esas mediciones operativas separadas de la pista de concurrencia del navegador.
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.