El móvil de gama media frente a tu portátil: el factor que lo explica todo

El rendimiento de un sitio es una función del dispositivo, y el dispositivo con el que desarrollas está entre los más rápidos que existen. Esa asimetría es la causa de fondo de que un equipo entero pueda considerar que su aplicación va bien mientras el percentil 75 de sus usuarios reales está esperando cuatro segundos. No es negligencia: es que nadie ha visto nunca la aplicación en el dispositivo en el que corre.

El factor real, y por qué no baja

Los datos que hay que tener en la cabeza, todos referidos a rendimiento monohilo, que es el que importa para JavaScript:

La fila que importa es la del móvil de gama media, porque es donde está la mediana del parque de dispositivos en la mayoría de los mercados. Y el número que hay que interiorizar es que medio segundo de JavaScript en tu portátil son dos o tres segundos en el teléfono de tu usuario mediano.

La razón de que esta brecha no se cierre con el tiempo es económica antes que técnica. Los teléfonos de gama alta han mejorado mucho el rendimiento monohilo en diez años; los de gama baja apenas, porque en ese segmento el precio manda y la mejora generacional se gasta en más núcleos lentos, en mejor cámara y en más pantalla, no en un núcleo rápido. Un teléfono de 120 euros de 2026 tiene un núcleo de rendimiento comparable al de uno de gama media de hace seis años. El parque de dispositivos lentos no envejece hacia arriba, se renueva lateralmente.

Y hay un segundo factor que empeora la comparación: los móviles baratos usan configuraciones con unos pocos núcleos rápidos y varios lentos, y el hilo principal del navegador no siempre acaba en un núcleo rápido. Con la pantalla encendida, la cámara activa o varias aplicaciones en segundo plano, el planificador del sistema puede colocar el hilo principal en un núcleo de eficiencia, y ahí el factor se dobla otra vez.

Por qué 4x, y cuándo se queda corto

El estrangulamiento de CPU de las herramientas de desarrollo multiplica el tiempo de cada operación por un factor configurable. El valor por defecto de las auditorías móviles es 4x, y no es arbitrario: está calibrado para que un portátil de desarrollo de gama media produzca tiempos parecidos a los de un móvil de gama media real. Es una aproximación razonable y es la mejor herramienta de bajo coste que existe.

Tiene dos problemas que hay que conocer.

El primero: el factor depende de tu máquina. Si desarrollas en un portátil especialmente rápido, 4x te deja todavía por encima del móvil real. La calibración correcta es medir el mismo trabajo en tu máquina y en un teléfono real y calcular tu propio factor. Un microensayo suficiente:

// Ejecuta esto en tu portatil y en el movil real. El cociente es tu factor.
function banco() {
  const t0 = performance.now();
  let acc = 0;
  const a = new Float64Array(200_000);
  for (let i = 0; i < a.length; i++) a[i] = Math.sin(i) * Math.cos(i * 0.5);
  for (let rep = 0; rep < 60; rep++) {
    for (let i = 0; i < a.length; i++) acc += a[i] * 1.000001;
  }
  return { ms: Math.round(performance.now() - t0), acc };
}
console.log(banco());

No es un banco de pruebas riguroso y no pretende serlo: es una carga de cálculo que se ejecuta en el hilo principal y cuyo cociente entre dispositivos te da un orden de magnitud honesto en treinta segundos. Si te sale 5,8, usa 6x en tus auditorías y no 4x.

El segundo problema es más profundo: el estrangulamiento ralentiza el JavaScript pero no todo lo demás. Esto es lo que hace que las mediciones simuladas subestimen sistemáticamente el problema real.

Los tres factores que el estrangulamiento no reproduce

La memoria. Un móvil de gama media tiene 4 GB de RAM, de los que el sistema se queda una parte grande. El navegador trabaja con una fracción de lo que tienes tú, la presión de memoria dispara recolecciones de basura más frecuentes y más largas, y las pestañas en segundo plano se descartan. Ninguna de esas tres cosas ocurre en tu portátil de 32 GB, y las tres afectan al rendimiento percibido de forma severa. El síntoma clásico: la aplicación va bien los primeros dos minutos y se degrada después. Eso es recolección de basura, y no lo verás nunca estrangulando CPU.

La limitación térmica. Un teléfono sin ventilador, sostenido en una mano, con la pantalla al máximo, baja su frecuencia de reloj al cabo de unos minutos de carga sostenida. La caída típica está entre el 30 y el 50 por ciento, y es acumulativa con todo lo demás. Un vídeo de fondo reproduciéndose, una animación continua o un bucle de sondeo son suficientes para provocarla. Tu portátil enchufado nunca lo hace.

La decodificación por hardware y la GPU. El estrangulamiento de CPU no toca la GPU ni los decodificadores dedicados. Un móvil de gama media puede tener una GPU sorprendentemente decente y un decodificador de vídeo excelente, o puede no tener decodificador para el códec que sirves. Ambas cosas cambian el resultado y ninguna se simula.

La conclusión operativa: el estrangulamiento a 4x es una buena red de seguridad para integración continua y una mala herramienta para entender el problema real. Para lo segundo hace falta un teléfono.

El banco mínimo que debería tener cualquier equipo

Cuatro piezas, ninguna cara.

Un teléfono real de gama media o baja, conectado por depuración remota, con un guion de uso escrito que cualquiera pueda ejecutar en cinco minutos.

Auditorías automáticas en integración continua con el estrangulamiento calibrado a tu propio factor, no al valor por defecto, y con presupuestos que fallen la compilación. Sirven para detectar regresiones, no para saber cómo va la aplicación.

Métricas de campo segmentadas por clase de dispositivo. Sin la segmentación, la media agregada esconde exactamente el grupo que sufre:

const clase = (() => {
  const mem = navigator.deviceMemory ?? 8;       // GB, redondeado por el navegador
  const nucleos = navigator.hardwareConcurrency ?? 8;
  if (mem <= 2 || nucleos <= 4) return 'baja';
  if (mem <= 4 || nucleos <= 6) return 'media';
  return 'alta';
})();
// Adjunta 'clase' a cada metrica que envies. Es la dimension que mas explica.

deviceMemory está disponible en navegadores basados en Chromium y devuelve un valor redondeado por privacidad; en los que no lo exponen tendrás el valor por defecto, lo cual también es información. hardwareConcurrency sí está en los tres motores.

Un umbral de decisión acordado. «Si el percentil 75 del INP en la clase media supera 200 milisegundos, se para el trabajo de producto y se arregla.» Sin ese acuerdo, todo lo anterior son datos que nadie usa.