React Compiler elimina useMemo y useCallback en React 19. Descubre cómo activarlo en Next.js App Router, sus límites y trampas a evitar en 2026.
React Compiler memoriza automáticamente tus componentes y valores, sin que tengas que escribir un solo useMemo o useCallback. En la práctica: el compilador analiza tu código en el build e inyecta él mismo la memorización donde tiene sentido, lo que debería reducir drásticamente el número de re-renders innecesarios en una app React 19.
Pero, ¿funciona realmente en una app Next.js App Router en producción, hoy? Profundizamos en la pregunta, probamos en un proyecto real, y aquí está lo que sacamos en claro: activación, límites, y casos donde es mejor no tocar.
Qué es react compiler, en concreto
React Compiler es una herramienta que se ejecuta durante el build y transforma tu código fuente para inyectar automáticamente memorización. Sin nuevas APIs que aprender, sin hooks adicionales. Lee tus componentes tal como los escribes hoy, con props, states, dependencias, y deduce por sí mismo dónde un useMemo o un useCallback manual hubiera sido necesario.
Antes del compilador, un desarrollador tenía que adivinar qué cálculos costosos merecían ser memorizados, y listar manualmente las dependencias de cada hook. Adivinar, es la palabra justa. Todos hemos olvidado alguna vez una dependencia en un array de useCallback y pasado dos horas debuggeando un state obsoleto.
El compilador elimina esta responsabilidad humana. Aplica una regla simple: si un componente respeta las reglas de React (sin mutación directa de props, sin efectos secundarios en el renderizado), puede ser analizado estáticamente y memorizado automáticamente.
Lo que realmente cambia para tu equipo: el código se vuelve más corto, más legible, y sobre todo más difícil de romper por error. Una observación que sorprende a menudo a los equipos que migran: eliminar manualmente todos los useMemo existentes a veces mejora el rendimiento, porque el compilador hace un trabajo más fino que lo que un humano ocupado hubiera escrito a mano.
Lo que el compilador no hace
No reemplaza la lógica de negocio. Tampoco adivina tus intenciones de negocio, si tu componente tiene un bug de lógica, el compilador nunca lo corregirá. Optimiza el renderizado, punto.
Cómo activarlo en una app next.js app router
La activación se hace a nivel del build, a través de un plugin Babel dedicado configurado en tu proyecto. En un proyecto Next.js App Router existente, el procedimiento típico es así:
- Instalar el plugin del compilador React como dependencia de desarrollo.
- Activarlo en la configuración Next.js (
next.config.js), generalmente a través de una opción experimental mientras la funcionalidad siga madurando. - Lanzar un build completo y comparar el bundle antes/después, el compilador añade código de memorización, el peso del bundle puede aumentar ligeramente.
- Probar en profundidad componentes con estado complejo: formularios multi-paso, listas filtrables, todo lo que dependa de re-renders precisos.
- Eliminar progresivamente los
useMemo/useCallbackmanuales existentes, no todo de una vez.
El punto 5 es el que todos olvidan. Queremos limpiar el código de una vez después de activar. Mala idea. El compilador coexiste muy bien con código ya memorizado manualmente, así que nada obliga a reescribir todo el día de la activación.
Las trampas que encontramos al probar el compilador
Aquí hay que ser honesto: no funciona mágicamente bien en todas partes.
Primera trampa: componentes que violan discretamente las reglas de React, mutación directa de un objeto pasado en props, efecto secundario oculto en un renderizado condicional, simplemente no son optimizados por el compilador. Peor, pueden producir comportamientos inconsistentes entre el modo dev y el modo compilado, lo que hace el debug más difícil que antes.
Segunda trampa: librerías de terceros. Si tu app depende de componentes externos que no respetan estas reglas, el compilador simplemente los deja de lado. Así que no tienes una ganancia uniforme en toda la app, sino una ganancia concentrada en tu propio código.
Tercera trampa, más sutil: en un proyecto donde los desarrolladores ya habían hecho un trabajo riguroso de memorización manual, la ganancia de rendimiento medida era baja. El compilador brilla especialmente donde el equipo no tenía tiempo o disciplina para memorizar correctamente, que es el caso de la mayoría de proyectos, seamos honestos.
Este enfoque tiene un límite claro: no funciona bien si tu codebase contiene muchos componentes de clase heredados, o código que manipula el DOM directamente fuera del ciclo de renderizado de React. En este caso, migrar primero hacia componentes funcionales estándar antes de activar el compilador sigue siendo un requisito obligatorio.
Tabla comparativa: memorización manual vs react compiler
| Criterio | Memorización manual (useMemo/useCallback) | React Compiler |
|---|---|---|
| Esfuerzo del desarrollador | Elevado, cada caso a identificar y codificar | Bajo, automático en el build |
| Riesgo de error | Dependencias olvidadas, bugs de state obsoleto | Reducido, pero depende del respeto de las reglas React |
| Legibilidad del código | Pesada por hooks por todas partes | Código fuente más cercano al renderizado natural |
| Cobertura | Puntual donde el dev pensó en añadirla | Uniforme en todo componente conforme |
| Compatibilidad de librerías terceras | No afectado | No se aplica a componentes externos no conformes |
| Madurez en 2026 | Estándar desde hace años | Disponible pero aún marcado como experimental en algunas configs |
Conclusión
Tres cosas a recordar antes de activar React Compiler en tu próximo proyecto Next.js. Primero, no reemplaza el rigor: código que viola las reglas de React sigue siendo código que el compilador no puede salvar. Segundo, la ganancia real depende del estado actual de tu codebase, cuanto más descuidada sea tu memorización manual, más visible será la ganancia. Finalmente, la migración debe ser progresiva: activar, probar, luego limpiar el código existente, nunca al revés.
Si tu equipo ya está trabajando en una migración Next.js más amplia, justo hablábamos de ello en nuestro artículo sobre el fin de vida de Next.js 15 y el plan de migración hacia la versión 16, el compilador es una de las tareas a integrar en esta hoja de ruta en lugar de tratarlo como un proyecto separado. Y si te interesa en general el tema del build y del compilador, también profundizamos en lo que cambia el compilador TypeScript nativo en Go para tus tiempos de build.
¿Necesitas una auditoría antes de migrar tu app hacia React Compiler? Contacta a fstck.co para que miremos juntos si tu codebase está lista.
Preguntas frecuentes
¿Funciona react compiler con componentes de clase react?
No. El compilador analiza únicamente componentes funcionales y hooks. Una base de código con muchos componentes de clase heredados debe primero ser migrada hacia componentes funcionales antes de poder beneficiarse del compilador.
¿Hay que eliminar todos los usememo y usecallback existentes después de activar el compilador?
No, e incluso se desaconseja hacerlo de una vez. El compilador coexiste sin problemas con código ya memorizado manualmente. Es mejor activar, medir, y luego limpiar progresivamente componente por componente.
¿Ralentiza react compiler el tiempo de build en un proyecto next.js grande?
Sí, el análisis estático añade un costo al build, generalmente moderado en proyectos de tamaño medio. En monorepos muy grandes, este costo merece ser medido antes de la puesta en producción, comparando los tiempos de build antes/después en tu CI.
¿Se puede usar react compiler con next.js pages router, o solo con app router?
El compilador actúa a nivel del build Babel, independientemente del router utilizado. Así que en teoría funciona con Pages Router también, pero la mayor parte de la retroalimentación y documentación se concentra en proyectos App Router en 2026.
¿Cómo saber si mi código respeta las reglas de react necesarias para el compilador?
Un plugin ESLint dedicado permite detectar violaciones incluso antes de activar el compilador en el build. Este es el primer paso recomendado: ejecutar el linter en toda la codebase, corregir las violaciones reportadas, y solo entonces activar el compilador.
