La tabla de formas: si el perfil tiene esta silueta, mira aquí

Un perfil de rendimiento tiene una forma antes de tener números, y esa forma es diagnóstica. Un profesional con experiencia mira la silueta durante cinco segundos y ya sabe en qué familia está el problema, no porque tenga intuición mágica sino porque ha visto las mismas ocho o diez siluetas cientos de veces. Esta lección es esa experiencia escrita: la tabla que traduce forma a hipótesis, y la comprobación que convierte cada hipótesis en un hecho.

La tabla

La columna que importa es la tercera: una hipótesis sin comprobación es una opinión, y las opiniones sobre rendimiento son casi siempre falsas.

Cómo se mira la forma

La forma se aprecia con el rango completo y el gráfico alejado, no con el zoom puesto. El detalle destruye la silueta. El procedimiento son cuatro miradas de diez segundos cada una.

La primera al reparto de colores del resumen. Un perfil dominado por amarillo de script, por morado de estilo y disposición, o por verde de pintado son tres mundos distintos. Este reparto solo es un dato con el rango bien acotado: el reparto de una grabación de veinte segundos donde el problema dura trescientos milisegundos no dice nada.

La segunda a la densidad y a la longitud de las tareas. ¿Pocas y largas, o muchas y cortas? Es la distinción entre un problema de bloqueo y uno de volumen, y tienen arreglos opuestos: partir en un caso, reducir el número en el otro.

La tercera a la relación entre el hilo principal y las demás pistas. ¿Está el hilo principal ocupado mientras el usuario espera, o está vacío? Un hilo vacío con el usuario esperando es un diagnóstico completamente distinto y descarta de golpe media tabla.

La cuarta a la periodicidad. ¿Hay un patrón que se repite a intervalos regulares? La periodicidad delata temporizadores, sondeos y suscripciones, y es una forma que se reconoce de un vistazo y que se busca durante horas si no se mira a propósito.

Las formas que parecen problemas y no lo son

Cuatro siluetas alarmantes que son perfectamente normales y que hacen perder tiempo a quien no las reconoce.

El hilo principal saturado durante el arranque. Una aplicación grande va a ejecutar mucho JavaScript al arrancar. Eso solo es un problema si retrasa el primer contenido útil o si bloquea interacciones tempranas. La pregunta no es si el hilo está ocupado sino si alguien estaba esperando.

Muchos fotogramas largos durante una animación de entrada. Si la animación dura trescientos milisegundos y ocurre una vez al cargar, un par de fotogramas perdidos no los percibe nadie. Los fotogramas perdidos importan en interacción continua: desplazamiento, arrastre, movimiento sostenido.

Un pico de trabajo justo después de un clic. Es el trabajo del clic. Solo es un problema si retrasa la respuesta visible, y para eso está el desglose de la interacción.

Actividad periódica de baja intensidad. Un temporizador que consume dos milisegundos cada segundo es visible en el perfil, tiene una forma muy reconocible y es completamente irrelevante. Que algo se vea no significa que cueste.

El criterio que unifica los cuatro casos: una forma es un problema cuando coincide en el tiempo con alguien esperando. Sin esa coincidencia es solo actividad.

Confirmar antes de arreglar

Cada hipótesis necesita una comprobación barata que la mate o la confirme, y el orden importa: intentar confirmar lo más probable primero es más lento que intentar descartar lo más barato primero.

// Comprobaciones rapidas que descartan o confirman las hipotesis mas comunes
(() => {
  const r = {};

  // Volumen de DOM: descarta o confirma coste estructural
  r.elementos = document.querySelectorAll('*').length;
  r.reglasCSS = [...document.styleSheets].reduce((s, h) => {
    try { return s + h.cssRules.length; } catch { return s; } }, 0);

  // Peso y numero de scripts, y cuanto es de terceros
  const recursos = performance.getEntriesByType('resource');
  const scripts = recursos.filter(e => e.initiatorType === 'script');
  const propios = scripts.filter(e => new URL(e.name).origin === location.origin);
  r.scripts = scripts.length;
  r.scriptsDeTerceros = scripts.length - propios.length;
  r.kbScripts = Math.round(scripts.reduce((s, e) => s + (e.encodedBodySize || 0), 0) / 1024);
  r.kbTerceros = Math.round(scripts.filter(e => new URL(e.name).origin !== location.origin)
    .reduce((s, e) => s + (e.encodedBodySize || 0), 0) / 1024);

  // Temporizadores activos: delata la periodicidad
  let contadorIntervalos = 0;
  const originalSetInterval = window.setInterval;
  window.setInterval = function (...args) { contadorIntervalos++; return originalSetInterval.apply(this, args); };
  setTimeout(() => {
    console.log('Intervalos creados desde que se cargo este snippet:', contadorIntervalos);
    window.setInterval = originalSetInterval;
  }, 10000);

  // Capas de composicion: aproximacion por propiedades que las provocan
  const promotores = [...document.querySelectorAll('*')].filter(el => {
    const s = getComputedStyle(el);
    return s.willChange !== 'auto' || s.transform !== 'none' ||
           s.filter !== 'none' || s.position === 'fixed';
  });
  r.candidatosACapa = promotores.length;

  console.table([r]);
  if (r.elementos > 5000) console.warn('Arbol grande: sospecha de coste de estilo y disposicion.');
  if (r.kbTerceros > r.kbScripts / 2) console.warn('Mas de la mitad del JavaScript es de terceros.');
  if (r.candidatosACapa > 60) console.warn('Muchos candidatos a capa: revisa el compositor.');
})();

Ninguna de estas comprobaciones demuestra nada por sí sola; todas descartan. Un árbol de mil doscientos elementos descarta la hipótesis de coste estructural y ahorra media hora de investigación en la dirección equivocada, que es exactamente el valor de una comprobación barata.