React
Explica cómo medir rendimiento con React Profiler, interpretar commits y duración, localizar renders costosos y optimizar solo después de identificar el cuello de botella.
El objetivo de optimizar React no es conseguir cero renders, sino reducir el trabajo que afecta una interacción real. Un render puede ser barato y no producir ningún cambio del DOM.
El rendimiento de una interfaz depende de varias capas:
red y servidor
↓
JavaScript descargado
↓
render de React
↓
commit y DOM
↓
style, layout y paint
↓
respuesta percibidaReact Profiler muestra una parte del sistema. Para comprender la experiencia completa también necesitas las herramientas de rendimiento y red del navegador.
Cuando un componente vuelve a ejecutarse, React calcula un siguiente árbol. Puede concluir que el DOM no necesita cambios.
function Greeting({ name }: { name: string }) {
return <p>Hola, {name}</p>;
}Un render del padre puede ejecutar Greeting aunque name sea igual. Eso no significa que el párrafo real haya sido recreado.
Optimiza cuando el trabajo medido sea relevante, no porque un contador aumente.
Un componente puede renderizar cuando:
memo puede omitir algunos renders por props, pero no evita actualizaciones de state, Context o stores consumidos dentro del componente.
Define primero el escenario:
Después registra qué trabajo domina la latencia.
Evita optimizar una pantalla en reposo cuando el problema ocurre durante scroll o input.
El Profiler permite observar commits y componentes que participaron.
Flujo recomendado:
La duración en desarrollo puede incluir Strict Mode, warnings y tooling. No la tomes como equivalente exacto a producción.
State colocado demasiado alto obliga a recalcular una región grande:
function App() {
const [search, setSearch] = useState("");
return (
<>
<SearchInput value={search} onChange={setSearch} />
<LargeDashboard />
</>
);
}Si LargeDashboard no necesita search, considera una frontera que mantenga el state cerca del input o composición con children.
function SearchPanel() {
const [search, setSearch] = useState("");
return <SearchInput value={search} onChange={setSearch} />;
}No muevas state hacia abajo si varias regiones necesitan una única fuente de verdad. Colocation es un criterio, no una regla absoluta.
function MovablePanel({ children }: { children: React.ReactNode }) {
const [position, setPosition] = useState({ x: 0, y: 0 });
return (
<div style={{ transform: `translate(${position.x}px, ${position.y}px)` }}>
{children}
</div>
);
}El padre puede crear children una vez y React puede reutilizar esa referencia mientras MovablePanel actualiza su state. La composición a veces evita recalcular descendientes sin memoización manual.
const ProductRow = memo(function ProductRow({ product }: ProductRowProps) {
return <li>{product.name}</li>;
});memo compara props mediante Object.is por defecto. Puede saltar el render cuando las props conservan identidad.
No garantiza:
Úsalo cuando el componente renderiza con frecuencia, tiene trabajo relevante y suele recibir props iguales.
<ProductList filters={{ category, activeOnly }} />El objeto es nuevo en cada render, por lo que rompe una comparación superficial de memo.
Eso no significa que crear objetos sea malo. Solo importa si una optimización depende de conservar la referencia.
const filters = useMemo(
() => ({ category, activeOnly }),
[category, activeOnly],
);No añadas useMemo si ProductList no está memoizado, el cálculo es trivial y no existe otro requisito de identidad.
useMemo almacena el resultado de un cálculo entre renders mientras sus dependencias sean iguales:
const visibleProducts = useMemo(
() => expensiveFilter(products, filters),
[products, filters],
);Úsalo para:
No lo uses como garantía semántica. React puede descartar caches en ciertos escenarios; el código debe seguir siendo correcto sin ellas.
const handleSelect = useCallback((productId: string) => {
setSelectedId(productId);
}, []);useCallback conserva la función, no evita crear todo el concepto de closure ni hace más rápido su cuerpo.
Aporta cuando:
Toda función no necesita useCallback.
Memoización añade:
Una optimización que ahorra microsegundos y dificulta el código puede ser un retroceso.
React Compiler puede aplicar memoización automática a componentes y expresiones compatibles, reduciendo la necesidad de memo, useMemo y useCallback manuales.
En el ecosistema actual se utiliza mediante tooling compatible y requiere que el código respete las Rules of React.
No elimina la necesidad de:
Mantén memoización manual cuando exista una razón semántica o una integración que la necesite, y verifica la configuración concreta del proyecto.
Cuando cambia un provider, los consumers actualizan:
<AppContext value={{ user, theme, notifications }}>Un contexto amplio puede propagar cambios no relacionados.
Estrategias:
No memoices todo el árbol para ocultar un Context mal diseñado.
useSyncExternalStore permite que React lea snapshots consistentes y se suscriba a una store externa.
Stores con selectores pueden actualizar solo consumidores de la parte modificada. Esto aporta en state compartido y frecuente, pero añade una dependencia y un modelo adicional.
Empieza con state local, lifting state o Context cuando resuelvan el problema.
Renderizar miles de filas puede afectar JavaScript, DOM, layout y memoria.
Opciones:
Virtualización renderiza una ventana visible y elementos de buffer. Debe conservar:
No virtualices una lista pequeña por anticipación.
const chartData = transformThousandsOfPoints(points);Primero pregunta:
useMemo evita repeticiones bajo dependencias iguales, pero no hace más barato el cálculo inicial ni lo saca del main thread.
Un input debe actualizarse con prioridad:
const [query, setQuery] = useState("");
const deferredQuery = useDeferredValue(query);La UI del input usa query; la lista pesada utiliza deferredQuery.
Esto permite que React posponga el árbol costoso. No reduce el coste total y no sustituye un debounce de red cuando quieres evitar requests.
useEffect(() => {
setFilteredProducts(filterProducts(products, query));
}, [products, query]);Este effect produce un render adicional. Calcula durante render o memoiza solo si el cálculo lo requiere.
Las cadenas de effects suelen ser una fuente de trabajo y estados intermedios evitables.
const AnalyticsPage = lazy(() => import("./AnalyticsPage"));Divide código por rutas y funcionalidades grandes poco frecuentes.
Considera:
Muchos chunks diminutos pueden empeorar la navegación.
React no compensa:
Una mejora de arquitectura de datos puede superar cualquier memoización del render.
Un commit pequeño puede causar layout costoso si modifica propiedades que afectan geometría en muchos nodos.
Usa las herramientas del navegador para observar:
React Profiler no reemplaza este análisis.
Mide con un build de producción y dispositivos representativos:
El modo desarrollo prioriza diagnósticos, no rendimiento final.
Las métricas de experiencia pueden señalar problemas de carga, respuesta y estabilidad visual. Relaciónalas con flujos concretos; una media global puede ocultar usuarios afectados.
React es solo una parte de esas métricas.
useCallback a toda función.useMemo, useCallback y memo tienen coste y dependencias.useCallback?useMemo en un cálculo pesado?Seguridad en interfaces React revisa qué riesgos continúan existiendo aunque React escape texto por defecto y cómo proteger los límites cliente-servidor.