Medir: el profiler, contar renders y no optimizar a ciegas

Las cuatro lecciones anteriores construyeron un arsenal: granularidad, comparadores, memoización, cachés con dueño. Esta última introduce lo único que convierte ese arsenal en ingeniería en vez de superstición, que es la medición. El rendimiento es el área del oficio donde la intuición falla con más frecuencia y más confianza, porque el modelo mental que tenemos del coste de un programa se formó leyendo código, y el coste real lo determinan la máquina virtual, el motor de reconciliación, la caché de la CPU y el navegador. La consecuencia es incómoda pero liberadora: no sabes qué es lento en tu aplicación, y cualquier optimización que hagas sin una medición previa es una apuesta con dinero de otro. Aprender a medir no es un apéndice de este nivel, es lo que decide si todo lo anterior te sirve o solo te da vocabulario para justificar cambios que nadie ha comprobado.

El profiler: qué renderiza, cuánto cuesta y por qué

La extensión de herramientas de desarrollo de React trae dos instrumentos que responden preguntas distintas y complementarias. El primero es la señalización visual de actualizaciones: al activarla, cada componente que se renderiza parpadea con un borde de color en la propia pantalla. No da números, pero responde en segundos a la pregunta más importante de todas —qué se está repintando cuando toco esto— y suele bastar para descubrir que media interfaz reacciona a un despacho que solo debería afectar a una esquina.

El segundo instrumento es la grabación de sesiones. Pulsas grabar, ejecutas la interacción sospechosa, detienes y obtienes una serie de confirmaciones, cada una con su duración y su árbol. El mapa de llamas muestra la jerarquía de ese commit con el ancho proporcional al tiempo, distinguiendo lo que se renderizó de lo que se saltó. La vista ordenada por coste acumulado responde a la pregunta complementaria: qué componente sumó más milisegundos a lo largo de toda la grabación, que casi nunca es el más caro por render sino el que se renderizó más veces.

El motivo del render es el dato más valioso para lo que estudia este nivel, porque distingue las dos familias de causa. Si el panel dice que el componente renderizó porque cambió su estado interno enganchado al store, tienes un problema de selector y las lecciones dos, tres y cuatro te dan la respuesta. Si dice que renderizó porque lo hizo su padre, el selector es inocente y el problema está en la estructura del árbol o en la ausencia de memoización de componentes. Optimizar selectores cuando la causa era el padre es el desperdicio de esfuerzo más habitual del oficio.

Contar renders: el número que no miente

El profiler es excelente para explorar y mediocre para comparar. Sus duraciones fluctúan entre ejecuciones y las diferencias pequeñas se pierden en el ruido. Para saber si un cambio mejoró algo hace falta una métrica discreta, reproducible y sin unidades de tiempo: el número de renders. Un contador es tosco, pero tiene la virtud de que veinte renders son inequívocamente más que tres y ninguna variabilidad de máquina altera esa comparación.

// Contador crudo: sobrevive a StrictMode si lo interpretas con cuidado.
function useContarRenders(nombre: string) {
  const n = useRef(0)
  n.current += 1
  console.log(`${nombre} render numero ${n.current}`)
}

// Medicion estructurada: el componente Profiler entrega tiempos por commit.
function alRenderizar(id, fase, duracionReal, duracionBase) {
  registrar({ id, fase, duracionReal, duracionBase })
}

Contar tiene además una ventaja epistemológica sobre cronometrar: los renders son un efecto directo de las decisiones que tomas en los selectores, mientras que los milisegundos son un agregado de tu código, del motor, del recolector y de lo que el sistema operativo estuviera haciendo en ese instante. Si tu hipótesis es que un selector inestable estaba renderizando de más, el número que la confirma o la refuta es el conteo, no el reloj. Deja el reloj para la pregunta final, que es si el usuario lo nota.

El componente Profiler merece más uso del que recibe, porque permite instrumentar una parte concreta del árbol en cualquier entorno, sin extensión y sin interacción manual. Su devolución de llamada recibe el identificador, la fase —montaje o actualización—, la duración real del subárbol y la duración base, que es lo que habría costado sin ninguna memoización. Comparar duración real contra duración base es la forma más directa de saber si tus memoizaciones están sirviendo para algo: si ambas coinciden, no te estás saltando ningún trabajo.

Para el caso concreto de este nivel existe una medida todavía más directa que los renders, y es el número de veces que se ejecuta un selector y el número de veces que su cálculo se recomputa de verdad. Ese par de cifras, contrastado con el número de despachos de la interacción, da la tasa de aciertos de tus cachés y localiza el problema sin ambigüedad: muchas ejecuciones con pocos recomputos indica selectores sanos; tantos recomputos como despachos indica una caché que no acierta nunca.

// Tres contadores bastan para diagnosticar toda una pantalla.
let despachos = 0, ejecuciones = 0, recomputos = 0

const medir = () => (next) => (accion) => { despachos += 1; return next(accion) }
// ejecuciones se incrementa en el cuerpo del selector,
// recomputos dentro de la funcion de resultado del selector memoizado.

Los cuatro sesgos que invalidan una medición

Una medición mal montada es peor que ninguna, porque produce confianza sin información. Hay cuatro sesgos que aparecen una y otra vez y conviene descartarlos antes de creerse cualquier número. El primero es medir en modo desarrollo, donde el código no está optimizado, las comprobaciones extra corren y las advertencias se calculan: las cifras absolutas de ese entorno no dicen casi nada del comportamiento real en producción.

El segundo es la duplicación deliberada de StrictMode, que en desarrollo ejecuta dos veces los renders y ciertos efectos para exponer impurezas. Si cuentas renders sin saberlo, verás el doble y perseguirás un problema inexistente; si lo sabes, la duplicación es inofensiva porque afecta igual al antes y al después. El tercero es medir con datos de juguete: una lista de diez elementos no revela nada de una de diez mil, y casi todos los problemas de este nivel son proporcionales al volumen.

flowchart TD
S[algo va lento] --> M1[medir y localizar la causa]
M1 --> C{la causa es el selector}
C -->|si| O1[estrechar memoizar o comparar]
C -->|no| O2[revisar el arbol o memoizar componentes]
O1 --> M2[medir de nuevo la misma interaccion]
O2 --> M2
M2 --> D{mejoro el numero}
D -->|si| K[conservar el cambio]
D -->|no| R[revertir el cambio]
style K fill:#a6e3a1,color:#11111b
style R fill:#f38ba8,color:#11111b

Presupuestos y evidencia de campo

Una medición sin presupuesto no decide nada, porque un número aislado no es rápido ni lento: solo lo es frente a un umbral. El primer presupuesto que conviene interiorizar es el fotograma, unos dieciséis milisegundos y medio a sesenta imágenes por segundo, que es el tiempo total del que dispone el hilo principal para hacer todo lo suyo antes de que el usuario perciba un salto. El segundo es el de respuesta a una interacción, donde el umbral que se considera bueno en las métricas de experiencia actuales ronda los doscientos milisegundos entre la pulsación y el siguiente pintado.

La distinción entre laboratorio y campo ordena todo el trabajo de esta lección. El campo te dice si hay un problema y a cuánta gente afecta; el laboratorio te dice cuál es su causa y si tu cambio la corrige. Invertir el orden es el error metodológico más caro que se comete en rendimiento: pasar semanas afinando en el laboratorio una pantalla que ningún usuario percibía lenta, mientras la que sí lo estaba no aparecía en tu perfil porque tu máquina la disimulaba.

Queda un último punto, el que cierra el nivel entero: toda optimización tiene un coste permanente y un beneficio hipotético. Una memoización añade una caché con su memoria y su posible obsolescencia; un componente memoizado añade una comparación en cada render y una restricción sobre cómo se le pasan las propiedades; un selector partido en cinco añade indirecciones que el siguiente lector deberá reconstruir. Ese coste se paga siempre, en cada línea leída y en cada bug futuro. El beneficio solo existe si la medición lo confirma.