Limitar CPU y red: cómo calibrarlo contra un dispositivo real · Rendimiento Web

Limitar el procesador y la red es la forma barata de aproximarse al dispositivo del usuario sin comprar uno, y funciona razonablemente bien siempre que se sepa qué está haciendo por debajo. El error frecuente no es usarla, es usar el multiplicador que viene por defecto sin comprobar contra qué corresponde en tu máquina, porque ese número no es una propiedad del teléfono que quieres imitar: es una propiedad del portátil desde el que mides.

🎯 Al terminar esta lección sabrás

Distinguir los tres tipos de limitación y qué reproduce y qué no cada uno.
Calibrar el multiplicador de CPU contra un dispositivo real con un procedimiento repetible.
Enumerar los cuatro efectos de red que la limitación del navegador no simula.
Elegir el tipo de limitación adecuado según la pregunta que quieras responder.

Los tres tipos de limitación

Limitación aplicada al procesador. El navegador introduce pausas artificiales en la ejecución para que todo el trabajo del hilo principal tarde N veces más. Es una multiplicación uniforme: si tu tarea tardaba 40 milisegundos, con un factor de cuatro tarda 160. Es la más fiel de las tres para lo que mide, con una salvedad grande que veremos abajo.

Limitación aplicada a la red. El navegador retiene las respuestas para respetar un ancho de banda y añade un retardo fijo a cada petición para simular la latencia. Es una simulación en la capa de peticiones, no en la de paquetes.

Limitación simulada. Es la que usa por defecto la herramienta de auditoría automática, y es de naturaleza distinta: la página se carga sin limitar la red, se registra la traza completa, y después un modelo calcula qué habría pasado con la red y la CPU limitadas. Los números que ves no son medidas, son la salida de un modelo, con la ventaja de ser mucho más rápidos y estables, y la desventaja de que el modelo puede equivocarse con patrones de carga poco habituales.

Esa distinción es más importante de lo que parece y explica una confusión muy común. Cuando la auditoría automática y tu prueba manual con limitación aplicada no coinciden, no es que una esté mal: es que una es un modelo y la otra una medida, y responden a preguntas distintas. Para comparar dos versiones de tu sitio, la simulación es excelente porque es estable. Para entender qué pasa de verdad en un dispositivo, no sirve.

Pregunta	Herramienta adecuada
¿He empeorado respecto a ayer?	Simulada, por su baja varianza
¿Cuánto tarda esto en un móvil concreto?	Dispositivo real
¿Dónde está el cuello de botella del hilo principal?	Aplicada al procesador, con el panel de rendimiento
¿Qué pasa con una red mala de verdad?	Limitación a nivel de sistema o dispositivo real

Por qué un factor de cuatro no significa nada

Aquí está el problema de fondo. Un multiplicador de CPU es relativo a la máquina desde la que mides. Cuatro veces más lento que un portátil de hace cinco años y cuatro veces más lento que un portátil reciente son dos velocidades muy distintas, y el segundo puede seguir siendo más rápido que el teléfono que pretendes imitar.

La consecuencia práctica es que los perfiles de referencia de las herramientas automáticas envejecen sin que nadie los cambie: el multiplicador se mantiene, las máquinas de desarrollo se hacen más rápidas, y lo que ese multiplicador representa se aleja cada año del dispositivo real. Los navegadores han empezado a ofrecer perfiles calibrados que miden tu máquina antes de elegir el factor, precisamente por esto, y merece la pena usarlos cuando estén disponibles. Pero el procedimiento manual es de todos modos útil, porque calibra contra tu dispositivo objetivo y no contra uno genérico.

El procedimiento completo, que lleva unos veinte minutos y solo hay que hacerlo una vez cada varios meses:

Uno. Elige el dispositivo objetivo. No el más barato que encuentres: el que corresponde al percentil 75 de tu tráfico según la clasificación de la lección anterior.

Dos. Publica una página de calibración accesible desde los dos aparatos:

<!doctype html>
<html lang="es">
<head><meta charset="utf-8"><title>Calibracion</title></head>
<body>
<pre id="salida">Midiendo...</pre>
<script>
  function trabajoDeReferencia() {
    const n = 200000;
    const datos = new Float64Array(n);
    for (let i = 0; i < n; i++) datos[i] = (i * 2654435761) % 1000;
    let suma = 0;
    for (let paso = 0; paso < 12; paso++) {
      for (let i = 0; i < n; i++) suma += Math.sqrt(datos[i]) * 1.0000001;
    }
    return suma;
  }

  // Cinco pasadas, se descarta la primera, se toma la mediana del resto.
  const tiempos = [];
  for (let i = 0; i < 5; i++) {
    const t = performance.now();
    trabajoDeReferencia();
    tiempos.push(performance.now() - t);
  }
  const utiles = tiempos.slice(1).sort((a, b) => a - b);
  const mediana = utiles[Math.floor(utiles.length / 2)];
  document.getElementById('salida').textContent =
    'mediana ' + Math.round(mediana) + ' ms\n' +
    'todas   ' + tiempos.map((t) => Math.round(t)).join(', ');
</script>
</body>
</html>

Tres. Ejecútala en el teléfono real. Pantalla encendida, sin cargador, sin nada más abierto, y repítela tres veces con dos minutos de descanso entre ellas. Anota el peor resultado de los tres, no el mejor: es el que representa una sesión de uso real y no un dispositivo recién despertado. La razón la vemos en la lección siguiente.

Cuatro. Ejecútala en tu portátil sin limitación. Anota la mediana.

Cinco. Divide. Ese es tu multiplicador.

Telefono objetivo, tercera pasada     2.180 ms
Portatil sin limitar                    247 ms
Multiplicador calibrado                 8,8  -> usa 8 o 10, no 4

El resultado sorprende a casi todo el mundo la primera vez, y sorprende siempre en la misma dirección: el factor real es bastante mayor que el que se venía usando. Que es tanto como decir que las pruebas de meses anteriores describían un dispositivo que no existe en el parque.

Dos avisos honestos sobre lo que la calibración no arregla. La limitación multiplica uniformemente el tiempo de CPU, pero un teléfono lento no es un portátil lento: tiene menos caché, menos ancho de banda de memoria, almacenamiento más lento y una GPU muy inferior. Así que el trabajo dominado por accesos a memoria o por composición gráfica se desvía del multiplicador. Y la limitación no afecta al arranque del proceso, a la lectura de la caché de disco ni al decodificado de imágenes acelerado por hardware. La calibración acerca mucho; no sustituye al dispositivo.

Los cuatro efectos de red que no se simulan

La limitación de red del navegador reproduce dos variables: ancho de banda y latencia media. Una red móvil real tiene al menos cuatro características más, y son las que producen los peores momentos:

Pérdida de paquetes. Una red móvil con cobertura mediana pierde paquetes con regularidad. Cada pérdida en una conexión con control de congestión clásico provoca una retransmisión y una reducción de la ventana, lo que hunde el rendimiento durante segundos. La limitación del navegador no pierde ni un paquete: sirve todo, más despacio, pero perfecto.

Variabilidad de la latencia. La latencia real no es un valor fijo sino una distribución con cola larga: la mayoría de los paquetes llegan en el tiempo típico y algunos tardan cinco veces más, sobre todo al despertar la radio del móvil tras un rato inactiva. Esa cola es la que produce los percentiles altos que ves en campo y que nunca reproduces en el laboratorio.

Encolado excesivo en los equipos intermedios. Los enlaces móviles tienen colas grandes, y cuando se llenan la latencia se dispara mientras el ancho de banda parece bueno. Es el escenario en el que una descarga en segundo plano arruina la latencia de todo lo demás, y no aparece en ninguna simulación.

Cambios de estado de la red. Pasar de wifi a datos, perder cobertura en un ascensor, cambiar de celda en un tren. La conexión no se degrada: se corta y se restablece. Todo lo que hayas escrito asumiendo que una petición o va bien o falla rápido se comporta de forma imprevisible aquí.

Para reproducir esto de verdad hay dos caminos. Uno es limitar a nivel de sistema operativo, con las herramientas que introducen pérdida y variabilidad de latencia en la interfaz de red: son mucho más fieles porque actúan sobre los paquetes y no sobre las peticiones. El otro es usar un servicio de pruebas con dispositivos reales en redes reales, que es lo más fiel de todo y lo que conviene tener en la ejecución nocturna.

Y hay un tercer camino, más barato y muy revelador, que es simplemente usar el sitio en un tren o en un aparcamiento subterráneo con un teléfono real. Media hora de eso encuentra clases enteras de fallo que ninguna simulación produce: el estado de carga que no termina nunca, el reintento que se dispara cien veces, el formulario que pierde lo escrito, la petición sin tiempo límite que deja la interfaz colgada. No es una medida, es un descubrimiento de modos de fallo, y no hay sustituto.

⚡

La limitación responde a la pregunta de qué pasaría si tu máquina fuera más lenta, no a la de qué le pasa a tu usuario, y confundirlas produce optimizaciones que no mejoran nada

Aquí hay una distinción epistemológica que parece pedante hasta que te ahorra un trimestre. Cuando limitas la CPU de tu portátil por ocho, lo que has construido es un modelo con una única variable modificada: tu máquina, tu red, tu perfil de navegador, tu caché caliente, tu sesión iniciada, y solo la velocidad del procesador cambiada. Eso es exactamente lo que necesitas para responder a una pregunta causal muy concreta —¿este cambio de código mejora las cosas cuando la CPU es el cuello de botella?— y es precisamente por eso que la limitación es la herramienta correcta para el trabajo de optimización: aísla una variable y hace comparables el antes y el después. Pero no es un modelo del usuario, y tratarlo como si lo fuera lleva a un error caro y muy frecuente: optimizar durante semanas contra un perfil limitado, ver mejoras claras en el laboratorio, desplegar, y no mover el percentil 75 de campo ni un milisegundo. La explicación cuando esto pasa casi siempre es la misma: el cuello de botella real de tus usuarios no era la CPU. Era la latencia de una red variable, o una caché que nunca acierta porque los usuarios vuelven cada tres semanas, o un servidor lento en una región concreta, o una cascada de peticiones que en tu red rapidísima se resolvía en nada. Ninguna de esas cosas aparece al limitar la CPU de tu portátil, porque en tu modelo esas variables tienen tu valor y no el suyo. La disciplina que evita esto cabe en una frase y merece la pena convertirla en hábito de equipo: el campo dice qué hay que arreglar, el laboratorio dice si lo has arreglado. En ese orden y sin invertirlo nunca. Empiezas mirando datos reales segmentados por dispositivo y por geografía hasta identificar qué población sufre y por qué causa; formulas una hipótesis concreta sobre el mecanismo; construyes en el laboratorio el escenario que aísla ese mecanismo, con la limitación calibrada que corresponda; iteras ahí, que es rápido y comparable; y vuelves al campo a comprobar que la mejora se ha materializado en la población que sufría. Cuando ese ciclo se cierra y el campo confirma, has aprendido algo. Cuando el laboratorio mejora y el campo no se mueve, también has aprendido algo, y es igual de valioso: tu modelo del problema era falso, y lo que toca no es optimizar más, es volver a mirar los datos.

⚔️ Calibra tu laboratorio

Publica la página de calibración y mídela en tu portátil y en dos teléfonos distintos. Calcula los dos multiplicadores.
Compara el número que sale con el multiplicador que venías usando por defecto. Ajusta tus perfiles de prueba.
Ejecuta la misma auditoría con limitación simulada y con limitación aplicada y anota la diferencia en cada métrica.
Instala una herramienta de limitación a nivel de sistema, añade un dos por ciento de pérdida de paquetes y vuelve a cargar tu sitio. Anota qué se rompe.
Usa tu sitio media hora en movimiento con cobertura irregular y apunta cada modo de fallo que encuentres.