Leer las pistas de rendimiento de React en Chrome DevTools para identificar renders lentos

Cuando una interacción en React parece lenta, la reacción habitual es añadir useMemo, useCallback y React.memo con la esperanza de que mejore. A menudo la página sigue siendo lenta, porque nadie midió qué estaba consumiendo tiempo. React 19.2 introdujo las Rutas de rendimiento, que registran la actividad de React en la línea de tiempo de rendimiento del navegador; aquí se explica qué muestra cada ruta y cómo convertir una grabación en una solución específica.

Por qué la línea de tiempo tradicional era difícil de leer

Al grabar una interacción lenta en el panel de Rendimiento de las Herramientas de desarrollo de Chrome en una aplicación sin estas rutas, el hilo principal suele verse así:

JavaScript
████████████████████
██████████
███
████████████

Es evidente que JavaScript está ocupado, pero ¿qué componente fue el responsable? ¿Qué actualización inició el renderizado? ¿La página estaba esperando datos de la red? ¿Algún efecto dominó el proceso? ¿React realizó el renderizado justo cuando el usuario esperaba una respuesta inmediata? La visión general deja que uno tenga que deducirlo a partir de los nombres de las funciones. Los seguimientos de React proporcionan el contexto que falta.

Qué añaden los seguimientos de React

React ofrece seguimientos dedicados para tres áreas:

Scheduler
Components
Server

Se encuentran junto a las vías habituales del navegador, por lo que un único seguimiento puede leerse más o menos de esta manera:

USER CLICK
    │
    ▼
┌─────────────────────────────┐
│ React Scheduler             │
│ Blocking → Render → Commit  │
├─────────────────────────────┤
│ React Components            │
│ Dashboard                   │
│ ├─ Header                   │
│ ├─ DataTable  ← expensive   │
│ └─ Chart                    │
├─────────────────────────────┤
│ Network / JavaScript        │
└─────────────────────────────┘

El valor radica en la correlación: la actividad de React y la actividad del navegador aparecen en un mismo eje temporal compartido.

Programador de tareas: ¿por qué se ejecutó esta tarea ahora?

React no maneja cada actualización de la misma manera. El Scheduler separa las tareas por prioridad, con categorías como Blocking, Transition, Suspense e Idle, y etiqueta las fases de cada actualización: Update, Render, Commit y cualquier efecto restante.

Esto permite responder a preguntas como “¿por qué hay retrasos al escribir en este campo?”. El seguimiento puede mostrar que una tecla presionada inició un renderizado síncrono intensivo en la categoría Blocking. O bien puede indicar que el trabajo costoso ya estaba correctamente envuelto en una transición, lo que orienta hacia otra dirección. En cualquier caso, se trabaja con evidencias en lugar de intuiciones. Si las transiciones y las prioridades le son nuevas, el modelo detrás de estas categorías se explica en Understanding React Lanes.

Componentes: ¿quién realizó el trabajo?

Para la depuración diaria, este suele ser el método más útil. Muestra en un flamegraph cuánto tiempo dedicó cada componente a renderizar y ejecutar efectos, y en el desarrollo también puede resaltar los cambios en las propiedades y las actualizaciones en cascada. Un resultado como este es típico:

ProductPage        310ms
├── Header           12ms
├── Filters          18ms
├── DataTable       245ms  ←
└── Footer            8ms

En lugar de la queja vaga de que React es lento, ahora se cuenta con una pista precisa: DataTable ocupó la mayor parte del tiempo de renderizado. A partir de ahí, se puede verificar si muestra demasiadas filas, vuelve a calcular los datos en cada iteración o recibe nuevas propiedades de su componente padre cada vez.

Servidor: ¿la página está esperando realmente a React?

En aplicaciones que utilizan React Server Components, las compilaciones de desarrollo también muestran adicionalmente las solicitudes al servidor y el trabajo de los componentes del servidor en la línea de tiempo. Esto revela un diagnóstico erróneo común:

Slow page
   │
   ▼
Assume React render
   │
   X
   │
   ▼
Actually waiting on:
getProducts()
      │
      ▼
Database / API

Si el seguimiento muestra que la página está inactiva mientras getProducts() espera a una base de datos o API, la solución debe buscarse en la obtención de datos, como el uso de caché, solicitudes paralelas o consultas más eficientes; además, envolver los componentes en React.memo no ayudará. Este es precisamente el motivo por el cual se desea ver todo el cronograma de ejecución en una sola vista.

Un flujo de trabajo de depuración reproducible

Cuando una interacción parezca lenta, siga siempre la misma secuencia:

1. Reproduce the problem
          ↓
2. Open Performance
          ↓
3. Record the interaction
          ↓
4. Find the slow React work
          ↓
5. Inspect the component / phase
          ↓
6. Check network and browser work
          ↓
7. Fix the actual bottleneck
          ↓
8. Record again

No omita el paso final. Grabe nuevamente bajo las mismas condiciones y haga una comparación. Una optimización que nunca se vuelva a medir no es más que una hipótesis, y en ocasiones el segundo seguimiento muestra que el cambio ha trasladado la carga a otro lugar en lugar de eliminarla.

Conozca los límites de un seguimiento local

Las pistas de rendimiento son una herramienta para el desarrollo y el análisis. React indica que la instrumentación añade carga adicional y que, por defecto, se desactiva en las versiones de producción, mientras que las pistas del servidor están limitadas a las versiones de desarrollo. Las versiones de desarrollo también funcionan más lentamente en general, por lo que es mejor confiar en las proporciones que en los números absolutos.

Eso significa que un registro limpio en su máquina no demuestra que los usuarios reales tengan una experiencia rápida. El rendimiento en producción sigue requiriendo datos de campo y monitoreo de usuarios reales. Las pistas responden a una pregunta más específica pero muy práctica: ¿qué está haciendo la aplicación, paso a paso, mientras usted reproduce este problema concreto?

Puntos clave

El hábito de rendimiento más costoso no es elegir el hook incorrecto; es optimizar antes de comprender el problema. Un enfoque más sólido sería este:

Slow interaction
       │
       ▼
    Measure
       │
       ▼
 Find the bottleneck
       │
 ┌─────┼──────┐
 ▼     ▼      ▼
React Network Browser
 │      │      │
 ▼      ▼      ▼
Fix    Fix    Fix

• Mida primero: las pistas hacen que registrar y localizar el cuello de botella sea la parte sencilla.
• Utilice la pista Scheduler para comprender la prioridad y la fase, y la pista Components para encontrar el subárbol más costoso.
• Revise la pista Server y las vías de red antes de asumir que el problema está en el proceso de renderizado.
• Vuelva a grabar después de cada cambio para confirmar que la solución funciona.
• Trate las trazas locales como herramienta de diagnóstico, y confíe en los datos obtenidos en el entorno real para conocer lo que experimentan los usuarios.

De esta manera, la conversación pasa de decidir si añadir useMemo a averiguar qué fue lo que realmente consumió esos 200 milisegundos, y esa es la pregunta que conduce a una solución real.

Lecturas relacionadas

Adoptar React 19.2: Actividad para interfaces con pestañas y una lista de verificación para la actualización — Cómo la función Activity de React 19.2 mantiene activas las pestañas ocultas, cuál es el papel de useEffectEvent y del pre-rendering, y cómo decidir si actualizar y corregir las aplicaciones RSC ahora.