Procesamiento que consume mucha CPU dentro de los controladores de solicitudes<\/li>\n<\/ul>Compara la lectura bloqueante de un archivo con una versión asíncrona:<\/p>
\/\/ Bloqueante: las demás peticiones quedan en espera\n\nconst data = fs.readFileSync('\/path\/to\/large-file.txt', 'utf8');\n\nres.send(data);\n\n\/\/ No bloqueante: el bucle de eventos sigue disponible\n\nconst data = await fs.promises.readFile('\/path\/to\/large-file.txt', 'utf8');\n\nres.send(data);<\/pre>La versión asíncrona permite que Node gestione la lectura del archivo fuera del hilo principal de JavaScript. Mientras se lee el archivo, el bucle de eventos puede seguir gestionando otras peticiones.<\/p>
Usa async\/await<\/code> y las API de Node.js basadas en promesas, como fs.promises<\/code>, de forma predeterminada.<\/p>Los controladores de bases de datos modernos como pg<\/code>, mysql2<\/code> y Mongoose funcionan de forma similar: gestionan la E\/S de forma asíncrona, por lo que esperar una respuesta de la base de datos no suele bloquear el bucle de eventos. Sin embargo, los conjuntos de resultados grandes y el procesamiento intensivo de las respuestas sí pueden provocar bloqueos, así que limita el tamaño de las consultas y los datos devueltos.<\/p>El código asíncrono evita los bloqueos mientras se espera a que termine una operación de E\/S, pero no soluciona las tareas que dependen de la CPU. Si una función dedica 500 ms a realizar cálculos, seguirá bloqueando el hilo principal aunque uses await<\/code>. Los worker threads solucionan este problema ejecutando los cálculos en otro hilo.<\/p>Si tu app usa llamadas síncronas dentro de los controladores de solicitudes, sustituirlas por versiones asíncronas puede ser una de las formas más rápidas de mejorar el rendimiento.<\/p>
2. Optimiza el middleware de Express y las respuestas de la API<\/h2> Optimizar la configuración de Express y los datos que devuelve la API reduce el tiempo de respuesta al eliminar procesos que el servidor no debería ejecutar en cada solicitud.<\/p>
El middleware aplicado con app.use()<\/code> se ejecuta en todas las solicitudes que coincidan. Si la autenticación, el registro, el análisis del cuerpo de las solicitudes, CORS, la limitación de solicitudes y la compresión se aplican globalmente, algunas rutas pueden ejecutar procesos que no necesitan. Siempre que sea posible, aplica el middleware solo a las rutas que lo necesiten:<\/p>\/\/ En lugar de aplicar la autenticación a todas las rutas\n\napp.use(authMiddleware);\n\n\/\/ Aplícala solo donde sea necesaria\n\napp.get('\/dashboard', authMiddleware, dashboardHandler);\n\napp.get('\/public-page', publicHandler);<\/pre>Ahora, las rutas públicas omiten por completo el proceso de autenticación.<\/p>
A continuación, revisa qué datos acepta y devuelve la API. Establece un límite para el tamaño de los datos JSON entrantes:<\/p>
app.use(express.json({ limit: '100kb' }));<\/pre>Ajusta el límite según los datos que acepte realmente la API. En las respuestas, devuelve solo los campos que necesite el cliente. Enviar registros completos de la base de datos cuando el frontend solo utiliza tres campos consume tiempo de procesamiento y ancho de banda innecesariamente.<\/p>
Pagina las respuestas grandes para evitar que los endpoints devuelvan miles de registros sin ningún límite.<\/p>
Si sirves archivos estáticos a través de Express, pásalos a una CDN o a un proxy inverso como Nginx. Si la CDN o el proxy inverso ya se encargan de la compresión, no uses compression()<\/code> en Express. Comprime los archivos una sola vez y en una sola capa.<\/p>Aunque hayas optimizado todo esto, el tiempo de respuesta depende de toda la cadena de la solicitud: middleware, validación, consultas a la base de datos, API externas, formateo de datos y transferencia de red. Analiza las rutas lentas para averiguar qué parte provoca más retraso.<\/p>
¿Cómo puedes reducir el tiempo de respuesta de la API de Node.js?<\/h3> Puedes reducir el tiempo de respuesta de la API solucionando el punto más lento de cada ruta. Las medidas con mayor impacto son:<\/p>
\nElimina el middleware innecesario de la ruta<\/li>\n\n\n\n Devuelve solo los campos necesarios<\/li>\n\n\n\n Pagina los resultados extensos<\/li>\n\n\n\n Almacena en caché las respuestas repetidas<\/li>\n\n\n\n Optimiza las consultas a la base de datos<\/li>\n\n\n\n Configura tiempos de espera para las peticiones externas lentas<\/li>\n<\/ul>Si una ruta espera cinco segundos la respuesta de una API externa, establece un tiempo de espera y devuelve una respuesta alternativa cuando sea posible. Así, los usuarios reciben una respuesta controlada en lugar de tener que esperar a que falle la solicitud.<\/p>
3. Almacena en caché los datos solicitados con más frecuencia<\/h2> La caché reduce las consultas repetidas a la base de datos, las llamadas a API externas y los cálculos que consumen muchos recursos. Si una consulta tarda 50 ms y devuelve el mismo resultado muchas veces, puedes ejecutarla una sola vez y atender las solicitudes posteriores desde la caché.<\/p>
Para valores pequeños y de corta duración en un solo servidor, suele bastar con una caché sencilla en memoria. Limítala con un TTL o un tamaño máximo para evitar que acabe causando problemas de memoria.<\/p>
Usa Redis o Memcached cuando ejecutes varios procesos, necesites compartir la caché entre servidores o quieras guardar los datos de sesión fuera del proceso de la app.<\/p>
\n\t\t\t\n\t\t\t\t<\/path>\n\t\t\t<\/svg>\n\t\t<\/button><\/figure><\/div>Tipo de almacenamiento en caché<\/strong><\/p><\/td>Ideal para<\/strong><\/p><\/td>Ventaja principal<\/strong><\/p><\/td>Ten cuidado con<\/strong><\/p><\/td><\/tr>En memoria<\/span><\/p><\/td>
Valores pequeños y temporales<\/span><\/p><\/td>
Lecturas rápidas, sin conexión a Internet<\/span><\/p><\/td>
No se comparte entre procesos<\/span><\/p><\/td><\/tr>Redis\/Memcached<\/span><\/p><\/td>
Datos compartidos, sesiones<\/span><\/p><\/td>
Funciona en todas las instancias<\/span><\/p><\/td>
Añade un salto de red<\/span><\/p><\/td><\/tr>CDN<\/span><\/p><\/td>
Archivos estáticos, recursos públicos<\/span><\/p><\/td>
Menor carga en el servidor de origen y menor latencia<\/span><\/p><\/td>
Unos encabezados incorrectos pueden hacer que se sirvan archivos obsoletos<\/span><\/p><\/td><\/tr>Encabezados HTTP<\/span><\/p><\/td>
Visitas repetidas, recursos estáticos<\/span><\/p><\/td>
Controlan cómo se reutilizan las respuestas<\/span><\/p><\/td>
Unos encabezados mal configurados pueden almacenar en caché más contenido del necesario<\/span><\/p><\/td><\/tr><\/tbody><\/table><\/figure>Sea cual sea el tipo que uses, la caché necesita dos ajustes: el TTL y la invalidación.<\/p>
El TTL (time to live) determina cuánto tiempo se mantiene válido un valor almacenado en caché. Un TTL corto mantiene los datos actualizados, pero implica repetir operaciones con más frecuencia. Un TTL largo mejora la velocidad, pero aumenta el riesgo de servir datos obsoletos. La invalidación determina cómo se eliminan o actualizan los valores almacenados en caché cuando cambia la fuente.<\/p>
Controla la tasa de aciertos de la caché. Si el 90% de las solicitudes se atienden desde la caché, la base de datos solo tendrá que gestionar el 10% de ese trabajo. Si la tasa de aciertos sigue siendo baja, puede que el TTL sea demasiado corto, que las claves de caché sean demasiado específicas o que los datos cambien con demasiada frecuencia para aprovechar bien la caché.<\/p>
4. Optimiza las consultas a la base de datos y la gestión de las conexiones<\/h2> Las consultas a la base de datos suelen ser una de las principales causas de las respuestas lentas de una API, ya que la app tiene que esperar a que la base de datos responda antes de poder devolver una respuesta.<\/p>
Empieza por las soluciones con mayor impacto:<\/p>
\nSelecciona solo las columnas que necesites<\/li>\n\n\n\n Evita SELECT *<\/code><\/li>\n\n\n\nAñade índices a las columnas que se usan con frecuencia para filtrar, ordenar o hacer joins<\/li>\n\n\n\n Evita las consultas N+1<\/li>\n\n\n\n Pagina los conjuntos de resultados grandes<\/li>\n\n\n\n Usa connection pooling<\/li>\n\n\n\n Revisa los planes de ejecución de las consultas lentas<\/li>\n<\/ul>Compara una consulta sin optimizar con otra más eficiente:<\/p>
\/\/ Lenta: recupera todas las columnas y todas las filas\n\nconst users = await db.query('SELECT * FROM users');\n\n\/\/ Más rápida: recupera solo los campos y las filas necesarios\n\nconst users = await db.query(\n\n'SELECT id, name, email FROM users ORDER BY created_at DESC LIMIT 20'\n\n);<\/pre>En una tabla con, por ejemplo, 100.000 filas y 30 columnas, la primera consulta hace que la app recupere y envíe muchos más datos de los necesarios. La segunda devuelve 20 filas con tres columnas. Con un índice adecuado en created_at<\/code>, la base de datos puede recuperar los registros más recientes sin tener que escanear toda la tabla.<\/p>La consulta es solo una parte del proceso. También importa cómo se conecta la app a la base de datos. Sin connection pooling, la app abre una conexión nueva para cada solicitud, lo que añade retraso y puede saturar la base de datos. Un pool mantiene las conexiones disponibles y las reutiliza.<\/p>
La mayoría de los controladores de Node.js, incluidos pg<\/code> y mysql2<\/code>, admiten connection pooling. Ajusta el tamaño del pool en función del tráfico, la capacidad de la base de datos y el número de instancias de la app. Si hay muy pocas conexiones, las solicitudes se acumulan en la cola. Si hay demasiadas, la base de datos puede sobrecargarse.<\/p>¿Cómo mejoran los índices el rendimiento de las apps de Node.js?<\/h3> Los índices permiten que la base de datos encuentre más rápido las filas que coinciden con una consulta, lo que reduce el tiempo de consulta y agiliza las respuestas de la API.<\/p>
Si la ruta de inicio de sesión busca usuarios por email, por ejemplo, un índice en email<\/code> ayuda a la base de datos a encontrar la fila correspondiente sin tener que revisar todos los registros:<\/p>SELECT id, name, email\nFROM users\nWHERE email = $1;<\/pre>Los valores de email suelen ser únicos o casi únicos, por lo que este tipo de índice suele ser útil.<\/p>
Para las consultas paginadas que filtran y ordenan datos, un índice compuesto como (active, created_at)<\/code> puede ser útil, dependiendo de la base de datos y de cómo estén distribuidos los datos.<\/p>No indexes todas las columnas. Los índices aceleran las lecturas, pero aumentan el tiempo de escritura y ocupan espacio de almacenamiento, ya que la base de datos debe actualizar el índice cada vez que cambian las filas.<\/p>
5. Usa streams para archivos grandes y respuestas de gran tamaño<\/h2> Los streams procesan los datos por partes en lugar de cargar archivos completos en la memoria. Por ejemplo, si cargas de la forma habitual un archivo CSV de 500 MB, ocupará 500 MB de RAM. En cambio, al procesarlo mediante streams, solo se utiliza un pequeño búfer en cada momento.<\/p>
Evita cargar archivos grandes de esta forma:<\/p>
app.get('\/download', async (req, res) => {\n\nconst data = await fs.promises.readFile('large-file.csv');\n\nres.send(data);\n\n});<\/pre>En su lugar, usa un stream:<\/p>
const fs = require('node:fs');\n\nconst { pipeline } = require('node:stream\/promises');\n\napp.get('\/download', async (req, res, next) => {\n\ntry {\n\nawait pipeline(\n\nfs.createReadStream('large-file.csv'),\n\nres\n\n);\n\n} catch (err) {\n\nnext(err);\n\n}\n\n});<\/pre>La versión con streams empieza a enviar datos de inmediato y consume menos memoria, ya que Node procesa el archivo por partes.<\/p>
Los streams también gestionan las diferencias de velocidad entre el emisor y el receptor mediante un mecanismo conocido como backpressure. Si la conexión del usuario es lenta, Node pausa la lectura hasta que el stream de respuesta pueda seguir procesando los datos. Usa pipeline()<\/code> en producción, ya que gestiona mejor que .pipe()<\/code> los errores de los streams y la liberación de recursos.<\/p>En producción, comprueba también que el archivo exista, configura los encabezados adecuados y gestiona las desconexiones de los clientes.<\/p>
6. Reduce las tareas que consumen mucha CPU en el hilo principal<\/h2> Las tareas que consumen mucha CPU bloquean el hilo principal e impiden que el bucle de eventos gestione otras solicitudes. El código asíncrono no soluciona este problema porque el motor de JavaScript sigue ejecutando los cálculos en un solo hilo.<\/p>
Entre las tareas que suelen consumir mucha CPU se encuentran:<\/p>
![\"Página](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/32\/2026\/08\/1778753978115-0-te-lo-digo-1.png\/public\")