El Módulo 7 terminó con un diagnóstico incómodo: CicloUrbano sabe dónde vive cada dato y por qué, pero no va rápida. Hay componentes que se repintan sin motivo, cálculos que se rehacen en cada render y un paquete que el navegador descarga entero antes de enseñar la primera bicicleta. La tentación natural al llegar aquí es abrir el editor y empezar a repartir memo y useMemo por el proyecto hasta que «se note mejor». Esa tentación es exactamente lo que esta lección viene a desactivar. Optimizar sin medir no es optimizar: es añadir complejidad a ciegas y esperar que salga bien. Antes de tocar una sola línea hay que saber qué significa «lento» para el usuario, por qué se vuelve a ejecutar un componente, qué es realmente caro y qué no, y —lo más importante— que la mayoría de los problemas de rendimiento de una aplicación React se resuelven mejor sin memorizar nada. Esta lección es el panorama y el método: las técnicas que casi siempre rinden más que la memorización, el papel del React Compiler de React 19 y el flujo de trabajo que ordena todo el módulo. Las herramientas de memorización llegan en las lecciones siguientes, y llegan mejor preparadas después de esto.

1. La regla que gobierna el módulo: medir primero
2. El coste real de la optimización prematura
3. Qué significa «lento» en una interfaz: las métricas que le importan al usuario
4. Por qué se vuelve a ejecutar un componente
5. El malentendido más caro del ecosistema
6. Técnica 1: bajar el estado al componente que lo usa
7. Técnica 2: pasar children para aislar un subárbol
8. Técnica 3: derivar durante el render en vez de guardar y sincronizar
9. Técnica 4: claves estables en listas
10. Técnica 5: retrasar y limitar las entradas de texto
11. Técnica 6: paginar y virtualizar listas largas
12. Técnica 7: sacar trabajo del hilo principal
13. El React Compiler de React 19: qué automatiza y qué no
14. Presupuesto de rendimiento y flujo de trabajo
15. Mapa del resto del módulo

No optimices lo que no has medido. Si no puedes señalar un número que empeora, no tienes un problema de rendimiento: tienes una sospecha.

Esta regla suena a consejo de manual y es una decisión de ingeniería con consecuencias muy concretas. Los motivos por los que la intuición falla en rendimiento web son sistemáticos:

• Tu máquina no es la del usuario. Desarrollas en un portátil potente con la aplicación en localhost y sin latencia de red. El usuario de CicloUrbano abre el catálogo en un móvil de gama media, con 4G irregular, mientras camina hacia la estación.
• El modo de desarrollo miente. El servidor de Vite sirve módulos sin empaquetar, React registra avisos e información de depuración, y StrictMode ejecuta cada componente dos veces. Un render que en desarrollo tarda 18 ms puede tardar 4 ms en producción.
• Lo que se siente lento y lo que es lento rara vez coinciden. Un render de 300 ms al pulsar un botón es una catástrofe percibida; el mismo trabajo repartido en un setTimeout de fondo no lo nota nadie.
• Los cuellos de botella se esconden. El componente que sospechas es casi nunca el culpable. En CicloUrbano, el culpable de que escribir en el buscador se sienta pastoso no es el <input>: son las tarjetas que se repintan detrás.

La consecuencia práctica es que el orden de trabajo correcto empieza siempre por la lección 08-05 (el Profiler), aunque sea la última del módulo. Este módulo se estudia en orden porque hace falta conocer las herramientas para entender lo que el Profiler enseña, pero se aplica en el orden inverso: medir, localizar, corregir, volver a medir.

Cuando alguien dice que la optimización prematura es cara, suele quedarse en lo abstracto. Estos son los costes reales, uno a uno.

El más grave, con diferencia, es el cuarto. Un memo innecesario ralentiza un poco; un useMemo con dependencias mal puestas produce datos incorrectos en pantalla, y ese fallo es intermitente, difícil de reproducir y suele descubrirlo un usuario.

Un error de rendimiento hace que la aplicación vaya lenta. Un error de memorización hace que la aplicación mienta.

«Lento» no es una sensación: es un conjunto de magnitudes medibles. Estas son las que la industria ha consolidado (las llamadas Web Vitals), con lo que significan y —dato clave para este módulo— cuánto puede hacer React por cada una.

De esta tabla se extraen dos conclusiones que ordenan el módulo entero:

1. INP y TBT son territorio de React. Cuando escribir en el BuscadorBicicletas tarda 400 ms en reflejarse, eso es INP, y se arregla con memorización, useDeferredValue o virtualización (08-02, 08-03).
2. FCP y LCP son sobre todo territorio del empaquetador. Que el navegador tenga que descargar 1,2 MB de JavaScript antes de pintar el catálogo no lo arregla ningún memo: lo arregla la división de código (08-04).

Y una tercera, incómoda: hay causas de lentitud que no son de React en absoluto y ninguna técnica de este módulo va a tocar — imágenes de estaciones sin comprimir ni dimensionar, una consulta a json-server que devuelve las 2.000 bicicletas sin paginar, tipografías que bloquean el pintado, o una petición en cascada que espera a otra. Antes de memorizar nada, comprueba que el problema está donde crees.

En 01-05 quedó establecido el ciclo de React: render → diferencias (diff) → confirmación (commit). Ahora hace falta la parte que aquel modelo dejaba implícita: qué hace que React vuelva a llamar a la función de un componente. Solo hay cuatro causas, y no hay una quinta.

Fíjate en lo que no está en la lista: «que le hayan cambiado las props». Las props no disparan nada por sí solas. Un componente recibe props nuevas porque su padre se ha vuelto a ejecutar (causa 2), y ese es el orden causal correcto.

Aquí está la frase que hay que interiorizar antes de escribir un solo memo:

Que un componente se vuelva a renderizar no significa que el navegador vuelva a pintar nada. Significa que React vuelve a llamar a una función de JavaScript y compara el resultado.

Un render es: ejecutar la función del componente, obtener un árbol de objetos ligeros (elementos de React), compararlo con el anterior y aplicar al DOM solo lo que ha cambiado. Si TarjetaBicicleta devuelve exactamente el mismo JSX que antes, el DOM no se toca. Esto cambia por completo la escala del problema:

La lectura correcta: un render de más no es un error, es un dato. Cien renders de componentes triviales pueden ser irrelevantes; un solo render que ordena un array de 2.000 elementos y formatea 2.000 fechas puede arruinar la interacción. Por eso el objetivo nunca es «reducir el número de renders», sino reducir el tiempo de trabajo por interacción. Con esa distinción clara, las siete técnicas que vienen a continuación se entienden solas: todas eliminan trabajo, no lo aceleran.

Es la técnica más rentable de todas y no requiere ninguna API nueva. Si un estado está más arriba de donde se necesita, cada cambio reejecuta un subárbol mucho mayor del necesario. La solución es moverlo hacia abajo: es la operación inversa a «elevar el estado» de 04-01, y responde a la misma pregunta —¿quién necesita este dato?— con la respuesta contraria.

Cada pulsación en el campo de horas reejecuta PaginaNuevaReserva, y con ella ResumenFlota —que agrega las 2.000 bicicletas por estado— y MigasDePan. El campo escribe un número y el coste es un recuento completo de la flota.

Ahora escribir en el campo reejecuta un solo componente. Sin memo, sin useCallback, sin dependencias que mantener. Y el código es más corto que antes, no más largo: es la señal de que la optimización es estructural y no un parche.

La regla operativa, que ya viste en 07-01 al clasificar el estado: coloca cada estado en el ancestro común más bajo de quienes lo leen, no más arriba.

Cuando el estado no se puede bajar porque lo consume el propio componente que envuelve al resto, queda la segunda técnica estructural, que ya apareció en 04-02 y que aquí revela su verdadera utilidad. El truco está en cómo funciona children: el JSX que se pasa como children se crea en el componente padre, no en el que lo recibe. Si el padre no se reejecuta, esos elementos son literalmente los mismos objetos de antes, y React se salta su render.

Abrir el panel lateral reejecuta Diseno, y con él <Outlet /> y la página completa que hay debajo: el catálogo con sus 2.000 tarjetas. Un cambio puramente decorativo del marco cuesta un render de toda la aplicación.

Ahora setLateralAbierto reejecuta solo MarcoConLateral. La prop children que recibe es el mismo objeto que en el render anterior, React lo detecta por identidad y no baja por esa rama. El catálogo ni se entera.

Esta técnica se llama a veces «memorización estructural»: consigue el efecto de memo sin memo, sin comparación y sin memoria adicional, solo colocando el estado en el sitio correcto del árbol.

La tercera técnica no reduce renders: reduce el trabajo y elimina una clase entera de errores. Es la misma lección de 05-02 sobre efectos innecesarios, leída ahora en clave de rendimiento.

Este componente hace dos renders por cada cambio: uno con el valor viejo y otro tras el efecto. Además, durante un instante muestra un dato incorrecto, y si bicicletas cambia de identidad sin cambiar de contenido, el efecto se dispara igual.

Un solo render, imposible de desincronizar y menos código. La pregunta que surge inmediatamente —«¿y si el cálculo es caro?»— tiene respuesta en 08-03 con useMemo, pero el orden importa: primero se deriva, y solo si se mide que el cálculo pesa se memoriza. Guardar en estado lo que se puede calcular es un problema de corrección antes que de velocidad.

En 03-03 quedó establecido por qué key no es un adorno. Desde la perspectiva del rendimiento, el efecto de una clave mal elegida es brutal y silencioso.

Con 2.000 tarjetas y el orden de sliceCatalogo cambiando de precio a modelo, la diferencia entre la primera y la tercera opción es la diferencia entre una animación fluida y un congelado de medio segundo. Y no cuesta nada: es escribir la clave correcta.

useDebounce ya está en el proyecto desde 05-06 y BuscadorBicicletas lo usa. Merece la pena verlo ahora por lo que es en realidad: una técnica de rendimiento que reduce la frecuencia del trabajo en lugar de reducir su coste.

La clave del patrón: el <input> sigue actualizándose en cada pulsación (es un componente barato y su respuesta debe ser inmediata), pero el filtrado de las 2.000 bicicletas ocurre una sola vez, 300 ms después de la última tecla. De 12 filtrados al escribir «eléctrica» se pasa a 1.

Su pariente cercano es el estrangulamiento (throttle), que en lugar de esperar al silencio garantiza como máximo una ejecución cada X milisegundos. Es el adecuado para eventos continuos que no tienen «final»: desplazamiento, redimensionado, movimiento del ratón.

Cómo elegir entre los dos:

Supongamos que CicloUrbano crece y db.json pasa a tener 2.000 bicicletas repartidas por la ciudad — es el escenario que este módulo usará de aquí en adelante. Pintar 2.000 TarjetaBicicleta significa crear del orden de 20.000 nodos del DOM. Ninguna memorización arregla eso, porque el trabajo es real: el navegador tiene que maquetar y pintar todo lo que existe.

Hay dos respuestas, y la primera es casi siempre la mejor:

Paginar. json-server ya soporta _page y _limit, y en 07-06 se preparó la consulta paginada con placeholderData para que la lista no parpadee. Si el usuario ve 24 bicicletas por página, el problema desaparece de raíz: nunca hay más de 24 tarjetas en el DOM, y además se descargan menos datos.

Virtualizar (o «ventana deslizante»). Cuando el diseño exige una lista continua con desplazamiento infinito, la técnica consiste en montar solo los elementos visibles más un pequeño margen, y simular la altura total con un contenedor vacío para que la barra de desplazamiento sea creíble.

La biblioteca estándar hoy es @tanstack/react-virtual, de los mismos autores que TanStack Query, sin dependencias y agnóstica del marco de trabajo.

Punto por punto:

1. count es el número lógico de elementos; el virtualizador nunca los recorre todos.
2. getScrollElement devuelve el elemento con overflow: auto que genera el desplazamiento.
3. estimateSize puede ser aproximado: si las alturas varían, se corrige midiendo con measureElement.
4. overscan monta unos pocos elementos fuera de la vista para que el desplazamiento rápido no muestre huecos.
5. El contenedor interior tiene la altura total real (2.000 × 120 px = 240.000 px) aunque esté casi vacío.
6. transform: translateY(...) es preferible a top porque no provoca recálculo de maquetación.

El resultado en cifras: de ~20.000 nodos del DOM a ~140. Ninguna otra técnica de este módulo se acerca a esa mejora. Antes de memorizar una lista larga, pregúntate si debería ser corta.

Advertencias honestas sobre la virtualización, porque no es gratis: rompe la búsqueda del navegador (Ctrl+F no encuentra lo que no está montado), complica la accesibilidad y el enfoque por teclado, exige cuidado con las alturas variables e interfiere con la impresión. Por eso paginar suele ser mejor decisión de producto.

El navegador tiene un solo hilo para ejecutar JavaScript, responder a eventos y pintar. Todo lo que ocupe ese hilo más de ~50 ms se convierte en una interfaz que no responde. Las palancas, de más simple a más compleja:

Un ejemplo del último caso, que a menudo se pasa por alto porque no es «código React»:

Dos líneas de CSS que evitan que el navegador maquete tarjetas fuera de la pantalla. No es virtualización —los nodos siguen existiendo en el DOM— pero el coste de maquetación y pintado baja mucho, y no requiere ninguna biblioteca.

React 19 estabilizó el React Compiler, y conviene explicarlo con precisión porque genera dos malentendidos opuestos: quien cree que ya no hace falta aprender memorización, y quien lo ignora por completo.

Qué es. Un compilador que se ejecuta en tiempo de construcción (como un complemento de Babel dentro de Vite), analiza tus componentes y hooks, y inserta automáticamente la memorización que tú habrías escrito a mano con memo, useMemo y useCallback. Convierte el código en una versión equivalente que reutiliza valores, funciones y elementos JSX cuando sus entradas no han cambiado.

Cómo se activa en Vite:

Y la regla de oro para adoptarlo con cabeza: antes de activarlo, pasa el linter de las reglas de React (eslint-plugin-react-hooks incluye las reglas del compilador). El compilador es conservador: si detecta que un componente rompe las reglas de React —muta props, escribe en una variable de módulo durante el render, lee ref.current mientras renderiza— se salta ese componente y lo deja sin optimizar, en silencio. Un proyecto con muchas infracciones obtiene muchas menos mejoras de las que espera.

Qué automatiza y qué no:

Por qué este módulo sigue siendo imprescindible, aunque actives el compilador mañana:

• Para leer código existente. La inmensa mayoría de proyectos React en producción están llenos de memo, useMemo y useCallback escritos a mano. Sin entenderlos no puedes mantenerlos.
• Para depurar. Cuando algo va mal con el compilador activado, el diagnóstico exige saber exactamente qué memorización se esperaba y cuál no llegó.
• Porque muchos proyectos no lo adoptarán. Bases de código grandes, versiones antiguas de React, cadenas de construcción que no usan Babel.
• Porque no elimina el criterio. El compilador memoriza; no decide qué merece la pena calcular, qué debería estar paginado ni dónde debe vivir el estado. Ese sigue siendo el trabajo difícil.
• Porque memorizar no es optimizar. Si el problema es que descargas 1,2 MB de JavaScript o que pides 2.000 registros, el compilador no ayuda en nada.

El React Compiler elimina el trabajo mecánico de memorizar. No elimina la necesidad de entender qué se memoriza, por qué y cuándo eso no es la solución.

Un presupuesto de rendimiento convierte «esto va lento» en una condición verificable. Sin él no hay forma de saber cuándo hay que optimizar ni, sobre todo, cuándo hay que parar. Este es un presupuesto razonable para CicloUrbano:

Y este es el flujo de trabajo que ordena todo el módulo. Léelo como un bucle, no como una lista:

Dos detalles del diagrama que no son decorativos:

• «Aplicar una sola técnica por vez». Si aplicas memo, useCallback y virtualización a la vez y mejora, no sabes cuál sirvió; probablemente estés cargando con dos optimizaciones inútiles para siempre.
• «Revertir el cambio». Una optimización que no mejora de forma medible debe deshacerse. Su coste de legibilidad y memoria sigue ahí aunque el beneficio no exista.

Optimizar en modo de desarrollo. El servidor de Vite, los avisos de React y el doble render de StrictMode distorsionan cualquier medición. Todo lo que se mida en serio se mide con npm run build y npm run preview (08-05).

Perseguir el número de renders como objetivo. «He bajado de 340 renders a 12» no es un logro si la interacción tardaba 30 ms y sigue tardando 28. La métrica es el tiempo, no la cuenta.

Empezar por la memorización. Es el orden invertido. Cuando se llega a memo habiendo descartado bajar el estado, children, derivar, paginar y virtualizar, el memo suele sobrar. Cuando se empieza por memo, casi siempre se acaba con un proyecto lleno de memorización y el problema real intacto.

Consejo: mide en un dispositivo lento. Las herramientas del navegador permiten ralentizar la CPU 4× o 6× (CPU throttling). Un problema que en tu portátil es invisible se vuelve obvio con 4×, que es aproximadamente un móvil de gama media.

Consejo: pon el problema en su capa. Antes de tocar React, comprueba el tamaño de las imágenes, el número de peticiones, si el servidor pagina y si las tipografías bloquean el pintado. Muchas «aplicaciones React lentas» son aplicaciones con 3 MB de imágenes.

Consejo: escribe el presupuesto en el repositorio. Un fichero RENDIMIENTO.md con las cinco cifras del apartado 14 convierte una discusión de opiniones en una comprobación objetiva, y sobrevive a los cambios de equipo.

Consejo: activa las reglas del linter antes que el compilador. eslint-plugin-react-hooks con las reglas del React Compiler te dice qué componentes rompen las reglas de React. Arreglarlos mejora el código aunque nunca actives el compilador, y es requisito para que este sirva de algo.

Ejercicio 1. El siguiente componente de CicloUrbano hace que escribir en el campo de notas repinte todo el panel de reservas, incluido PanelReservas, que agrega el historial completo del usuario. Identifica el problema, di qué técnica de esta lección lo resuelve y reescribe el componente.

Ejercicio 2. Para cada síntoma de CicloUrbano, indica qué métrica del apartado 3 empeora y qué técnica de esta lección (o qué lección del módulo) es la adecuada. No uses memo, useMemo ni useCallback en ninguna respuesta.

Ejercicio 3. Un compañero propone activar el React Compiler y borrar todos los memo, useMemo y useCallback del proyecto «porque ahora son automáticos». Enumera al menos cuatro objeciones técnicas concretas y describe qué comprobación harías antes de aceptar o rechazar la propuesta.

Solución 1. El problema es estado mal colocado: nota solo lo usan el <input> y el botón, pero vive en PaginaReservas, así que cada pulsación reejecuta PanelReservas y ResumenFlota. La técnica es la 1, bajar el estado (apartado 6), extrayendo el campo y su botón a un componente propio.

Ahora escribir reejecuta solo CampoNotaInterna. No hace falta memo en PanelReservas ni en ResumenFlota: React ni siquiera baja por esa rama. Es la lección estructural del módulo: la mejor optimización es la que hace innecesaria la optimización.

Solución 2.

Ninguna de las cinco se resuelve memorizando. Ese es exactamente el objetivo del ejercicio.

Solución 3. Objeciones:

1. El compilador no memoriza lo que no puede analizar. Si un componente rompe las reglas de React, lo omite en silencio; al borrar la memorización manual, esos componentes quedan peor que antes y sin ningún aviso.
2. No cubre las dependencias externas. Una función importada de una utilidad o un objeto de opciones creado fuera del componente siguen necesitando criterio humano; el compilador razona dentro del componente.
3. No hace baratos los cálculos caros. Ordenar y filtrar 2.000 bicicletas cuesta lo mismo la primera vez; el compilador evita repetirlo, no evita hacerlo.
4. Rompe el código para quien no lo tenga activado. Si parte del proyecto se extrae a una biblioteca compartida, o si otro equipo compila sin el complemento, la memorización desaparece.
5. Elimina la documentación implícita. Un useMemo con dependencias explícitas comunica una intención de diseño que el código sin él ya no expresa.
6. Es un cambio irreversible en la práctica. Volver a introducir la memorización manual en cientos de componentes cuesta mucho más que dejarla.

Comprobación previa: medir antes y después con el Profiler (08-05) sobre las interacciones críticas —escribir en el buscador, cambiar el orden, abrir el DialogoReserva— en un build de producción, con y sin el compilador, y con el linter de reglas de React en verde. Si las cifras son equivalentes, el compilador está haciendo su trabajo y la retirada de memorización manual puede plantearse gradualmente, componente a componente, no en una sola operación.

Este módulo empieza por el método porque sin método la optimización es superstición. La regla que lo gobierna todo es medir primero: si no puedes señalar un número que incumple un presupuesto, no tienes un problema, tienes una sospecha, y actuar sobre sospechas cuesta legibilidad, memoria y —lo más grave— errores de dependencias que hacen que la aplicación muestre datos incorrectos.

«Lento» se ha convertido en magnitudes concretas: FCP y LCP dependen sobre todo del tamaño del paquete y del servidor; INP y TBT son el territorio propio de React y de este módulo; CLS se arruina con indicadores de carga mal diseñados. Y se ha fijado el modelo causal: un componente se vuelve a ejecutar por cuatro razones —su estado, un ancestro, un contexto que consume, un almacén externo suscrito—, entre las que no está «le cambiaron las props». De ahí el malentendido más caro del ecosistema, ya desactivado: volver a renderizar no es volver a pintar. Un render es ejecutar una función y comparar el resultado; el DOM solo se toca donde algo cambió. Lo caro no son los renders, es el trabajo por interacción.

Con eso claro, las siete técnicas que casi siempre rinden más que la memorización: bajar el estado al componente que lo usa (la más rentable de todas, y encima acorta el código), pasar children para que un subárbol conserve su identidad y React no baje por esa rama, derivar durante el render en lugar de guardar y sincronizar con un efecto, claves estables en las listas —donde un key={indice} convierte una reordenación en una reescritura completa del DOM—, useDebounce y useThrottle para reducir la frecuencia del trabajo, paginar o virtualizar con @tanstack/react-virtual cuando el catálogo crece a 2.000 bicicletas, y sacar trabajo del hilo principal con precálculo, CSS y content-visibility. Ninguna necesita memo.

El React Compiler de React 19 se ha presentado sin exageraciones: automatiza la memorización mecánica que habrías escrito a mano, no reduce el tamaño del paquete, no abarata un cálculo caro, no razona sobre dependencias externas, omite en silencio el código que rompe las reglas de React y no toma ninguna decisión estructural. Sigue haciendo falta entender la memorización manual para leer el código que existe, para depurar y para los proyectos que no lo adopten. Y el flujo de trabajo que ordena el módulo: medir → localizar → aplicar la técnica más simple, una sola cada vez → volver a medir → revertir si no mejora.

Ahora sí llega el turno de las herramientas. La primera es la que responde a la causa 2 de la lista —«un ancestro se ha vuelto a renderizar»— cuando ya no queda margen estructural para evitarlo: envolver un componente para que React compare sus props y se salte su ejecución si son las mismas. La próxima lección es Memorización con React.memo.