Caso de estudio 06 / 17Next.js Front-End
Ingeniería de rendimiento integral para una plataforma de monitoreo
Auditoría completa del cliente web, la API y el servicio de mapas 3D: 31 hallazgos medidos, 25 aplicados y 6 descartados con evidencia.
Stack
- React
- Next.js
- MUI
- ECharts
- CesiumJS
- Service Workers
- Node.js
- InfluxDB
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
La plataforma de monitoreo combina un cliente web, una API y un servicio de mapas 3D: los usuarios siguen perfiles en vivo en un tablero y reproducen el historial de forma acelerada.
Leer más
Hice una auditoría de rendimiento completa de las tres capas y llevé un registro de 31 hallazgos medidos. Se aplicaron 25, se descartaron 6 con evidencia, y hoy la plataforma solo trabaja cuando los datos cambian.
4 conexiones· elige un componente para ver su recorrido
- API (historial) a Constructor de cuadros: devuelve historial por lotes
- Reloj de reproducción a Constructor de cuadros: lanza cada cuadro a su hora
- Constructor de cuadros a Gráficos de perfil: mismos objetos, 1 cambio
- Constructor de cuadros a Tablas ligeras: filas del cuadro actual
02Resultados
- R01Cuanto más alto, mejor
Cuadros a tiempo en reproducción a 10×
Antes 0%, después 99%, desde 0. Cuanto más alto, mejor.AntesDespués - R02Cuanto más bajo, mejor
Renderizados de la vista principal en reposo, cada 20 s
Antes 76, después 2, 38× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más bajo, mejor
JavaScript en la página más pesada
Antes 2,512 KB, después 1,762 KB, −30%. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Reproducción del historial a 10×: ningún cuadro a tiempo → 98–99 % a tiempo
- Costo en reposo: repintado continuo de mapas y renderizados → mapas en reposo, 2 renderizados cada 20 s
- Carga de la base de datos: ~305 → ~10 lecturas de fondo por minuto
Leer más
- Trabajo pendiente: opiniones sin medir → 31 hallazgos medidos, 25 aplicados y 6 descartados con evidencia
- JavaScript en la página más pesada: 2.51 MB → 1.76 MB (−30 %)
El desafío
La plataforma consumía recursos cuando no pasaba nada. En reposo, la vista principal se volvía a renderizar 76 veces en 20 segundos, los mapas 3D se repintaban sin parar y un mapa apartado fuera de pantalla seguía dibujando y pidiendo datos. Por debajo, un sondeo consultaba la base de datos unas 305 veces por minuto.
Leer más
La reproducción acelerada del historial dejaba ver el costo completo: a 10× ni un solo cuadro llegaba a tiempo, porque cada paso entregaba objetos nuevos a los gráficos y estos se redibujaban desde cero. El trabajo consistía en encontrar el desperdicio en las tres capas, probar cada causa con una medición y eliminarla sin cambiar nada de lo que ven los usuarios.
Qué aprendí
La medición reescribió el plan. Enviar a los gráficos solo los datos nuevos parecía la corrección obvia; medida, una actualización costaba lo mismo sin importar su contenido, y el costo real era un resaltado que se volvía a aplicar después de cada punto. Unificar tres librerías de gráficos, quitar series de brillo y reconstruir anotaciones con menos frecuencia se descartaron con evidencia.
Leer más
Cuando la propia máquina de pruebas variaba 2.4× entre corridas, comparé conteos de operaciones en vez de milisegundos. Una auditoría de rendimiento se juzga tanto por los cambios que rechaza como por los que aplica.
Stack
- React
- Next.js
- MUI
- ECharts
- CesiumJS
- Service Workers
- Node.js
- InfluxDB
Habilidades
- Ingeniería de rendimiento
- Perfilado full-stack
- Arquitectura de front end
- Visualización de datos
- Auditorías técnicas
