El thermal throttling: el rendimiento que se degrada con el tiempo

Todas las mediciones de este track asumen implícitamente que el dispositivo tiene una velocidad. Un teléfono no la tiene: tiene una velocidad máxima que sostiene unas decenas de segundos y una velocidad sostenida bastante menor a la que acaba cayendo. Eso significa que tu página puede ir bien en la prueba de treinta segundos y mal en el minuto ocho de una sesión real, y que dos ejecuciones consecutivas de la misma medida en el mismo aparato no son comparables entre sí.

Por qué ocurre

Un procesador convierte energía en calor, y la cantidad de calor crece más deprisa que la frecuencia. Un portátil disipa ese calor con ventiladores y masa metálica; un teléfono no tiene ni una cosa ni la otra, y su único mecanismo de refrigeración es la superficie de su propia carcasa, que además está pegada a una mano.

La consecuencia es que la frecuencia máxima que anuncia la ficha técnica es una frecuencia de ráfaga: se puede sostener mientras el aparato esté frío, y en cuanto un sensor interno detecta que la temperatura sube, el sistema baja la frecuencia. Si la carga continúa, sigue bajando, y puede llegar a apagar los núcleos rápidos y dejar el trabajo en los eficientes.

El perfil temporal típico bajo carga sostenida:

Los rangos son amplios a propósito: dependen del modelo, de la temperatura ambiente, de si está cargando y de si tiene funda. Lo que no depende de nada es la forma de la curva: siempre baja, y baja bastante. Un teléfono al que le pides trabajo continuo acaba, al cabo de diez minutos, a una fracción notable de la velocidad con la que empezó.

Hay tres factores que empeoran la curva y conviene conocerlos porque se dan a la vez en el uso real. Cargar calienta, así que un teléfono enchufado se degrada antes; es justo la configuración en la que muchos laboratorios ejecutan sus pruebas, y sesga los resultados hacia abajo. El brillo alto de la pantalla calienta, y una sesión al aire libre lleva el brillo al máximo. Y el modo de bajo consumo, cuando el usuario lo activa o el sistema lo activa solo con la batería baja, reduce las frecuencias de forma deliberada, con lo que se suma un segundo mecanismo de degradación al térmico. Una parte no despreciable de tus usuarios está en ese modo en cualquier momento dado.

No hay ninguna API web que informe del estado térmico. No existe, y no parece que vaya a existir por motivos de huella digital identificable. Así que la única forma de saber si está ocurriendo es inferirlo midiendo.

Detectarlo con un medidor propio

La técnica es sencilla: ejecutar periódicamente un trabajo de referencia idéntico y ver si su duración crece. Si el mismo cálculo tarda cada vez más, el dispositivo se ha degradado.

// Sonda de degradacion. Trabajo pequeno y fijo, cada 30 segundos,
// solo con la pagina visible y en tiempo libre.
const TRABAJO = 40000;

function pulso() {
  const t = performance.now();
  let s = 0;
  for (let i = 0; i < TRABAJO; i++) s += Math.sqrt(i) * 1.0000001;
  return { ms: performance.now() - t, s };
}

export function vigilarDegradacion(alCambiar) {
  let referencia = null;
  let ultimo = null;

  const tomar = () => {
    if (document.visibilityState !== 'visible') return;
    const { ms } = pulso();
    if (referencia === null) {
      referencia = ms;
      return;
    }
    const factor = ms / referencia;
    // Cambio significativo respecto a la ultima notificacion.
    if (ultimo === null || Math.abs(factor - ultimo) > 0.15) {
      ultimo = factor;
      alCambiar({ factor: Number(factor.toFixed(2)), msActual: Math.round(ms) });
    }
  };

  const programar = () => {
    if ('requestIdleCallback' in window) requestIdleCallback(tomar, { timeout: 2000 });
    else tomar();
  };

  programar();
  return setInterval(programar, 30000);
}

vigilarDegradacion(({ factor }) => {
  if (factor > 1.6) {
    // El dispositivo va a un 60 % o menos de lo que iba. Aligera.
    document.documentElement.classList.add('modo-ligero');
  } else if (factor < 1.25) {
    document.documentElement.classList.remove('modo-ligero');
  }
});

Cuatro cosas de este código importan. El trabajo es pequeño: cuarenta mil iteraciones son un puñado de milisegundos incluso en un dispositivo lento, así que la sonda no contribuye al problema que mide. Se ejecuta solo con la página visible, porque en segundo plano los temporizadores se limitan y el resultado no significaría nada. Se ejecuta en tiempo libre para no competir con una interacción. Y la primera medida se toma como referencia en lugar de usar un valor absoluto, con lo que el factor es relativo a ese mismo dispositivo y no hace falta calibrar nada.

El uso más valioso de esta sonda no es reaccionar sino medir: enviar el factor junto a los datos de campo permite comprobar una hipótesis que casi nadie ha verificado en su producto, que es si el INP se degrada con la duración de la sesión. Correlacionar INP con minutos transcurridos, segmentado por clase de dispositivo, produce a menudo un resultado incómodo y accionable.

Y una advertencia sobre reaccionar automáticamente: cambiar la interfaz porque el dispositivo se ha calentado tiene que ser reversible y poco llamativo. Reducir la tasa de refresco de una animación, dejar de precargar, aumentar el intervalo de un sondeo: todo eso es invisible y correcto. Cambiar el diseño o esconder funcionalidad produce una experiencia desconcertante, porque el usuario no tiene forma de saber por qué la aplicación se ha vuelto otra.

Qué provoca la degradación

El calor lo genera el trabajo sostenido, así que el objetivo es reducir el trabajo continuo, no el trabajo puntual. Los cuatro sospechosos habituales, en orden de frecuencia:

Bucles de animación que no paran. Un requestAnimationFrame que se vuelve a programar siempre, aunque no haya nada que animar y aunque el elemento esté fuera de la pantalla, mantiene el dispositivo trabajando a sesenta fotogramas por segundo indefinidamente. Es la causa más común y la más fácil de arreglar:

// Solo anima lo que se ve, y para del todo cuando no hay nada visible.
const visibles = new Set();

const observador = new IntersectionObserver((entradas) => {
  for (const e of entradas) {
    if (e.isIntersecting) visibles.add(e.target);
    else visibles.delete(e.target);
  }
  if (visibles.size > 0) arrancar();
});

let id = null;
function arrancar() {
  if (id !== null) return;
  const paso = () => {
    if (visibles.size === 0 || document.visibilityState !== 'visible') {
      id = null;
      return;   // Se para de verdad, no se sigue programando.
    }
    for (const el of visibles) dibujar(el);
    id = requestAnimationFrame(paso);
  };
  id = requestAnimationFrame(paso);
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible' && visibles.size > 0) arrancar();
});

Sondeos periódicos. Un setInterval que pregunta al servidor cada dos segundos mantiene despierta la radio del móvil, que es de los componentes que más energía consumen. Aquí la mejora no es solo térmica: es de batería, y es de las que el usuario percibe. Un canal de eventos del servidor o una conexión persistente consumen mucho menos que un sondeo frecuente, y si hay que sondear, el intervalo debe crecer con el tiempo de inactividad.

Observadores caros que se disparan mucho. Un observador de mutaciones sobre todo el documento con subárbol incluido se ejecuta en cada cambio del DOM. Un manejador de scroll sin agrupar en fotogramas se ejecuta decenas de veces por segundo. Los dos convierten una interacción normal en trabajo continuo.

Trabajo fuera de la pantalla. Elementos que se siguen calculando, pintando o animando cuando no están visibles. Es exactamente el problema que resuelve el aislamiento de content-visibility, y aquí tiene una segunda justificación además de la del pintado: el trabajo que no se hace no calienta.