Caso de estudio 10 / 17React Front-End
Instrumentación y presupuestos de rendimiento dentro de un cliente web
Monitor de desarrollo: traza páginas, rutas de API y gráficos, evalúa cada KPI una vez y señala el archivo culpable. 0 bytes en producción.
Stack
- React
- Next.js
- TypeScript
- Node.js
- Web Performance APIs
- Server-Timing
- IndexedDB
- Puppeteer
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Un monitor solo para desarrollo dentro del cliente web de la plataforma de monitoreo: sobre la aplicación en ejecución muestra si cada parte está dentro de su presupuesto, adónde se va el tiempo y si un cambio la empeoró.
Leer más
Cada funcionalidad nueva se mide con él antes y después, y un control en el build demuestra que nada de su código llega a producción. Lo diseñé y construí, y después lo usé para devolver la aplicación a sus propios presupuestos.
6 conexiones· elige un componente para ver su recorrido
- Sondas página/API/mapa a Juez único de estado: valores actuales, hasta 4 Hz
- Mapa KPI → archivo a Juez único de estado: archivo y pista por KPI
- Juez único de estado a Insignia de estado: conteos de rojo y ámbar
- Juez único de estado a Pestaña de estado: filas por gravedad y archivo
- Juez único de estado a Tabla en consola: imprime las mismas filas
- Juez único de estado a Registro de sesión: guarda culpable cada minuto
02Resultados
- R01Cuanto más alto, mejor
Rutas de la API con desglose de server-timing
Antes 34%, después 100%, 2.9× mayor. Cuanto más alto, mejor.AntesDespués - R02Cuanto más bajo, mejor
Puntos del código que calculan el estado de un KPI
Antes 7, después 1, 7× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más bajo, mejor
KPI en rojo o ámbar sostenido en reposo
Antes 60%, después 0%, a cero. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Lógica de estado: siete cálculos independientes → un solo motor de estado, 0 discrepancias entre insignia, encabezado y pestaña
- Trazas: 34 % de las rutas de API con desglose de server-timing → 100 %, y una sonda propia en cada página
Leer más
- Cobertura de gráficos: 2 de 17 con sonda de renderizado → 14 de 17
- Salud en reposo: 9 de 15 KPI en rojo o ámbar → 0 de 27
El desafío
La primera versión recogía los datos correctos, pero no se podía confiar en su juicio. Dieciocho KPI estaban repartidos en diez pestañas y siete módulos calculaban cada uno un estado con sus propios umbrales, así que la insignia, el encabezado y una pestaña podían discrepar sobre qué estaba en rojo. Un instrumento que se contradice deja de usarse.
Leer más
La cobertura también era menor de lo que informaban sus propios controles: dos de cada tres rutas de la API no tenían desglose de server-timing, la mayoría de los gráficos no tenía sonda de renderizado y el control de cobertura aprobaba cada página con sondas genéricas. Una vez que el monitor evaluó de forma consistente, mostró que la aplicación incumplía sus propios presupuestos en reposo.
Qué aprendí
Tratar lo que sugiere el código como una hipótesis y hacer que el instrumento la pruebe; el registro de sesión ahora guarda el culpable detrás de cada valor. El monitor también me corrigió a mí: un vaciado por lotes más lento, pensado para reducir las escrituras a la mitad, no tuvo efecto, así que lo revertí.
Leer más
Un ámbar que nunca se apaga no advierte a nadie, por eso el ámbar ahora cuenta solo tras cinco minutos sostenidos. Donde una corrección habría cambiado lo que ven los usuarios, mantuve lo visual y ajusté el presupuesto; reducir a la mitad el latido de las teselas del mapa bajó las tareas largas de 25 a 5 por minuto.
Stack
- React
- Next.js
- TypeScript
- Node.js
- Web Performance APIs
- Server-Timing
- IndexedDB
- Puppeteer
Habilidades
- Herramientas para desarrolladores
- Diseño de observabilidad
- Instrumentación
- Presupuestos de rendimiento
- Arquitectura front-end
