NexusCMS: Mejorando el rendimiento del CMS

Hoy tocó una de esas jornadas menos visibles para el usuario, pero probablemente de las más importantes a largo plazo: optimización y limpieza interna del sistema.

Durante estos días hemos estado revisando cómo se comporta NexusCMS bajo carga, especialmente en páginas con muchas consultas, paneles administrativos y sistemas de analítica. El objetivo no era “arreglar algo roto”, sino detectar pequeños cuellos de botella que, acumulados, terminan afectando la fluidez general del sitio.

Tras la auditoría aplicamos una serie de mejoras enfocadas en reducir tiempos de carga, disminuir consumo de memoria y evitar trabajo innecesario en cada petición.

¿Qué encontramos?

La mayoría de problemas no eran errores graves, sino decisiones antiguas o procesos que simplemente habían crecido demasiado con el tiempo.

Entre los principales puntos detectados estaban:

Procesos de analítica ejecutándose durante cada carga de página.
Consultas repetidas innecesariamente.
Cachés inconsistentes.
Consultas pesadas sin límites claros.
Uso de memoria excesivo en algunas estadísticas.
Recalculo constante de datos que apenas cambian.

Individualmente el impacto parecía pequeño, pero juntos terminaban generando una carga bastante mayor de la necesaria, especialmente en servidores con muchos usuarios concurrentes.

🔧 Mejoras aplicadas

Analítica movida a segundo plano

Uno de los cambios más importantes fue sacar parte del sistema de analítica fuera del flujo principal de navegación.

Hasta ahora, cada visita realizaba varias operaciones adicionales antes de responder al usuario. Ahora esas tareas pasan a ejecutarse en background mediante colas, permitiendo que la página responda mucho más rápido mientras el sistema procesa los datos en segundo plano.

Resultado esperado:

Navegación más fluida.
Menor carga en la base de datos.
Mejor rendimiento bajo tráfico alto.

Optimización de consultas repetidas

También encontramos varias zonas donde el sistema hacía más consultas de las necesarias al cargar información relacionada, especialmente en cuentas enlazadas y paneles internos.

Se reorganizó la carga de datos para traer toda la información necesaria de forma mucho más eficiente.

Resultado esperado:

Menos consultas por página.
Reducción importante en tiempos de respuesta.
Mejor escalabilidad con usuarios conectados.

Reducción de consumo de memoria

Otra parte importante del trabajo estuvo en el sistema de estadísticas y análisis.

Había procesos que cargaban grandes cantidades de datos en memoria simultáneamente. Ahora el procesamiento se hace por bloques más pequeños, reduciendo muchísimo el uso de RAM y evitando ralentizaciones en dashboards grandes.

Resultado esperado:

Paneles más rápidos.
Menor consumo de recursos.
Mayor estabilidad en servidores con mucha información acumulada.

Caché más consistente

También reorganizamos varias capas de caché internas.

Algunos componentes usaban múltiples claves separadas para datos relacionados, lo que provocaba inconsistencias y recálculos innecesarios. Ahora el sistema agrupa mejor esos datos y aprovecha mucho más la caché disponible.

Resultado esperado:

Menos trabajo repetido.
Respuestas más rápidas.
Información más consistente entre páginas.

Índices y optimización de base de datos

En la parte de base de datos añadimos nuevos índices para acelerar búsquedas frecuentes dentro de analítica y estadísticas.

Esto permite que consultas que antes tardaban segundos ahora se resuelvan prácticamente al instante incluso con tablas grandes.

Resultado esperado:

Consultas mucho más rápidas.
Menor carga del servidor SQL.
Mejor rendimiento general en administración y métricas.

Limpieza general y estabilidad

Además de las optimizaciones principales, también aprovechamos para:

Reducir logs innecesarios en producción.
Limitar consultas potencialmente pesadas.
Mejorar comportamiento de fallback en cachés.
Limpiar partes antiguas del sistema Redis.
Preparar mejor el proyecto para futuras optimizaciones.

📈 Impacto esperado

Aunque seguiremos monitorizando resultados durante los próximos días, las estimaciones actuales apuntan a:

Entre un 30% y 40% menos tiempo de carga en rutas críticas.
Mejor respuesta del panel administrativo.
Reducción notable de consumo de memoria.
Menor carga general sobre la base de datos.

La mayoría de estos cambios no son visibles directamente, pero son fundamentales para que NexusCMS pueda seguir creciendo sin comprometer estabilidad ni rendimiento.

Y probablemente lo más importante: todas estas mejoras se han aplicado manteniendo compatibilidad total con el sistema actual.

— Devlog cerrado, 17 de Mayo de 2026

NexusCMS: Improving CMS Performance

Today was one of those updates that users may not notice immediately, but that are extremely important for the long-term health of the project.

Over the last few days we reviewed how NexusCMS behaves under load, especially around analytics, admin panels and database-heavy pages. The goal was not fixing something “broken”, but identifying small bottlenecks that slowly accumulated over time.

After the audit, we implemented several improvements focused on reducing load times, lowering memory usage and eliminating unnecessary work during requests.

What did we find?

Most issues were not critical bugs, but rather old patterns and systems that had grown inefficient as the platform evolved.

Main findings included:

Analytics running during every page request.
Repeated database queries.
Inconsistent cache usage.
Heavy queries without limits.
Excessive memory usage in statistics processing.
Constant recalculation of data that rarely changes.

Individually the impact was small, but together they created noticeable overhead under high traffic.

🔧 Implemented Improvements

Analytics moved to background processing

One of the biggest changes was moving analytics tracking out of the main request flow.

Instead of performing several database operations before responding to the user, those tasks now run asynchronously in the background.

Expected result:

Faster navigation.
Reduced database load.
Better performance under heavy traffic.

Reworked repeated queries

We also optimized several areas where the CMS was requesting related data inefficiently, especially around linked accounts and internal panels.

The system now loads related information much more efficiently.

Expected result:

Fewer database queries.
Faster page responses.
Better scalability.

Lower memory usage

The analytics dashboard was also consuming far more memory than necessary in some scenarios.

Processing now happens in smaller batches instead of loading everything at once.

Expected result:

Faster dashboards.
Lower RAM usage.
Better server stability.

Improved cache consistency

Several cache layers were reorganized as well.

Previously, related data was sometimes stored separately, causing unnecessary recalculations and inconsistent cache hits. That behavior has now been unified.

Expected result:

More efficient caching.
Faster responses.
More consistent data delivery.

Database optimization

New indexes were added for frequently used analytics queries.

This dramatically improves query speed on large datasets.

Expected result:

Faster SQL queries.
Reduced database pressure.
Better admin performance.

General cleanup and stability improvements

Additional cleanup included:

Reducing unnecessary production logs.
Limiting potentially heavy queries.
Improving cache fallback behavior.
Cleaning up older Redis-related code.
Preparing the project for future optimizations.

📈 Expected Impact

We’ll continue monitoring the results over the coming days, but current estimates point to:

Around 30–40% faster load times on critical routes.
Faster admin panel responsiveness.
Lower memory usage.
Reduced overall database load.

Most of these changes are invisible to end users, but they are essential for keeping NexusCMS scalable, stable and responsive as the platform grows.

— Devlog closed, May 17, 2026