# PRNext 0.1.18 versus Next.js: CPU, RAM y sueño

PRNext 0.1.18-alpha está disponible. Para acompañar este lanzamiento, publicamos las mediciones tomadas el 29 de octubre utilizando su candidato de desarrollo. En un VPS pequeño, CPU el tiempo y la memoria son tan importantes como la velocidad de solicitud. Comparamos este código con Next.js en dos máquinas Linux y luego restringimos sus recursos para ver cómo cambia el resultado con la carga de trabajo.

El candidato PRNext ofrece 57% más rendimiento en nuestra página 100-row SSR con un presupuesto de dos CPU. En el VPS pequeño, la misma página utiliza aproximadamente 37% menos CPU por respuesta, pero más RAM. En conjunto, estos resultados explican el propósito de esta comparación: establecer dónde ayuda PRNext, cuánto cuesta y dónde le va mejor a Next.js.

## Los resultados de un vistazo

Con dos CPU y 1 GiB, el candidato alcanza 224.70 respuestas por segundo frente a 142.97 en la página 100-row SSR, aproximadamente 57% más de rendimiento. En la página 1,000-row con el mismo presupuesto, lidera Next.js. La hidratación medida también es más rápida con Next.js en ambas máquinas VPS.

En el VPS pequeño, el costo normal de SSR CPU disminuye aproximadamente 37%, pero PRNext usa más memoria. El sueño del trabajador libera RAM a cambio de un despertar más lento. Las siguientes secciones proporcionan versiones, medidas y las limitaciones de cada escenario.

[Explore mediciones por CPU presupuesto, memoria y escenario](/es/benchmarks)

## La versión exacta detrás de los números

Las mediciones de octubre 29, 2026 utilizan el candidato de desarrollo 0.1.18-alpha en el compromiso 2856155.. Su manifiesto todavía llevaba la versión interna 0.1.17-alpha, pero su código y optimizaciones difieren del paquete npm 0.1.17-alpha. Los hashes exactos de fuente y artefacto medidos están vinculados al final de este artículo.

La referencia es Next.js 16.4.3, usando la misma familia React 19.3.1 y fuente de aplicación. El VPS pequeño ejecuta Node.js 22.23.4; el grande ejecuta Node.js 24.22.1. Dentro de cada máquina, cada motor utiliza exactamente el mismo ejecutable de Nodo. Las diferencias entre máquinas no se pueden atribuir únicamente al hardware porque el nodo también cambia.

PRNext ejecuta el perfil Equilibrado y su procesador web predeterminado. Los datos asociados incluyen los hashes completos del paquete binario y candidato Linux, los resultados antes de las correcciones y los rangos de rendimiento. La versión npm 0.1.18-alpha publicada el 30 de octubre proviene del compromiso 05a9ccd, con correcciones adicionales de compilación y desarrollo. Por lo tanto, esta campaña no mide ni el paquete npm 0.1.17-alpha ni los archivos finales 0.1.18-alpha. Los números describen al candidato identificado sin asignar un nuevo punto de referencia a los cambios posteriores.

## lo que medimos

El primer VPS tiene una vCPU y aproximadamente 1.9 GiB de RAM. El segundo tiene ocho vCPU y aproximadamente 23 GiB. Los procesos de destino reciben cgroup v2 CPU y límites de memoria sin intercambio. La máquina pequeña está limitada a 70% de un CPU y 700 MiB; la máquina grande se prueba en un CPU y 384 MiB, dos CPU y 1 GiB, luego cuatro CPU y 2 GiB.

La matriz principal contiene 96 ventanas: cuatro presupuestos, cuatro escenarios, tres variantes y dos pases alternos. Las variantes son PRNext antes de las correcciones, el candidato PRNext medido y Next.js. Cada ventana tiene cinco segundos de calentamiento seguidos de quince segundos medidos, utilizando dieciséis conexiones y gzip. Las tablas comparan al candidato con Next.js e informan la mediana de las dos ventanas para cada métrica.

Los escenarios son una página dinámica 100-row SSR, una página 1,000-row, una JSON API de dieciséis entradas y una página con un retraso de suspenso 40 ms. Los identificadores y las cookies nuevos verifican la corrección y el aislamiento de la respuesta. El rendimiento cuenta solo las respuestas validadas y exitosas. Esta no es una comparación de páginas estáticas servidas desde una CDN.

El p95 es la duración dentro de la cual 95% de solicitudes finalizan en una ventana. CPU son milisegundos de trabajo CPU por respuesta exitosa, no latencia. RAM es el tamaño del conjunto proporcional medio, o PSS, en todo el árbol de procesos de destino, incluido el motor nativo y los trabajadores del nodo. Una respuesta puede tardar 100 ms y utilizar solo unos pocos milisegundos de CPU.

El generador de carga tiene límites separados, pero comparte el único CPU físico del VPS pequeño. Los escenarios rápidos API pueden alcanzar su techo, particularmente en la máquina pequeña y en el escenario de cuatro CPU. Los servicios existentes permanecen activos: las cuotas no eliminan la contienda en estos VPS. Dos pases cortos no proporcionan un intervalo de confianza. Las pequeñas diferencias no deberían convertirse en promesas de marketing.

## VPS pequeño: menos CPU, sin victoria general RAM

En 0.7 CPU y 700 MiB, PRNext sirve 81.33 SSR respuestas por segundo contra Next.js de 51.. Su p95 es 264.25 ms contra 420.90 ms. El costo de CPU cae de 13.39 a 8.46 ms por respuesta, aproximadamente 37% menos. La memoria, sin embargo, es 113.88 MiB frente a 101.38 MiB: PRNext usa aproximadamente 12% más en esta página.

La transmisión alcanza 138.13 solicitudes por segundo frente a 80.03, con aproximadamente 42% menos CPU por respuesta. La página pesada está mucho más cerca, a 11.33 frente a 10.33 solicitudes por segundo. El API favorece a PRNext en esta campaña, pero la competencia del generador por el mismo CPU físico sigue siendo una limitación.

Medianas de dos ventanas por escenario y motor. Los CPU y RAM más bajos son mejores.

| Escenario / motor | Solicitud/s | p95 (ms) | CPU (ms/solicitud) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 81.33 | 264.25 | 8.46 | 113.88 |
| SSR 100 / Next.js | 51.00 | 420.90 | 13.39 | 101.38 |
| SSR 1 000 / PRNext | 11.33 | 1,550.25 | 58.92 | 139.51 |
| SSR 1 000 / Next.js | 10.33 | 1,661.80 | 62.10 | 119.46 |
| API JSON / PRNext | 518.17 | 61.40 | 1.27 | 139.63 |
| API JSON / Next.js | 352.80 | 90.05 | 1.94 | 113.08 |
| 40 ms transmisión / PRNext | 138.13 | 182.65 | 4.98 | 135.32 |
| 40 ms transmisión / Next.js | 80.03 | 307.25 | 8.62 | 115.54 |

PRNext usa más PSS que Next.js en los cuatro escenarios de esta máquina. La ventaja observada es principalmente la eficiencia de CPU en SSR normal y en streaming. Una afirmación general de RAM más bajo tergiversaría estos resultados.

## Un CPU y 384 MiB: una restricción y una compensación diferentes

En el VPS grande limitado a un CPU y 384 MiB, la página SSR alcanza 99.77 solicitudes por segundo frente a 59.90. CPU, el costo es aproximadamente 41% menor y el PSS aproximadamente 13% menor. La transmisión alcanza 220.90 frente a 86.27 solicitudes por segundo, utilizando 4.51 frente a 11.47 ms de CPU por respuesta.

La política de memoria más estricta del candidato también reduce RAM en relación con nuestro código anterior PRNext, pero el API pierde aproximadamente 13% de rendimiento frente a ese código anterior. PRNext todavía lidera a Next.js en esta medición; eso no borra la regresión interna. Es necesario trabajar más en el equilibrio entre la recolección de basura y el rendimiento.

Medianas de dos ventanas por escenario y motor. Los CPU y RAM más bajos son mejores.

| Escenario / motor | Solicitud/s | p95 (ms) | CPU (ms/solicitud) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 99.77 | 227.20 | 9.90 | 109.85 |
| SSR 100 / Next.js | 59.90 | 365.35 | 16.78 | 126.50 |
| SSR 1 000 / PRNext | 13.60 | 1,329.65 | 72.82 | 139.97 |
| SSR 1 000 / Next.js | 10.00 | 1,932.90 | 95.47 | 158.74 |
| API JSON / PRNext | 849.63 | 38.75 | 1.18 | 128.40 |
| API JSON / Next.js | 409.13 | 76.85 | 2.45 | 163.78 |
| 40 ms transmisión / PRNext | 220.90 | 108.50 | 4.51 | 140.27 |
| 40 ms transmisión / Next.js | 86.27 | 299.30 | 11.47 | 167.14 |

## Dos CPU: una ganancia clara de SSR y un límite de renderizado elevado

Con dos CPU y 1 GiB, la página 100-row SSR alcanza 224.70 solicitudes por segundo en PRNext frente a 142.97 en Next.js. Eso es 57% más rendimiento, aproximadamente 26% menos CPU por respuesta y 32% menos PSS. El p95 es 89.80 ms contra 154.60 ms.

La página 1,000-row invierte el resultado: Next.js alcanza 27.63 solicitudes por segundo contra 24, de PRNext con un p95 de 622.20 ms contra 740.80 ms. PRNext usa menos RAM pero aproximadamente 29% más CPU por respuesta. El renderizado pesado React sigue siendo un objetivo de mejora concreto.

Medianas de dos ventanas por escenario y motor. Los CPU y RAM más bajos son mejores.

| Escenario / motor | Solicitud/s | p95 (ms) | CPU (ms/solicitud) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 224.70 | 89.75 | 7.57 | 117.50 |
| SSR 100 / Next.js | 142.97 | 154.55 | 10.29 | 173.30 |
| SSR 1 000 / PRNext | 24.00 | 740.75 | 64.42 | 164.17 |
| SSR 1 000 / Next.js | 27.63 | 622.25 | 49.91 | 198.96 |
| API JSON / PRNext | 2,078.33 | 14.00 | 0.83 | 144.80 |
| API JSON / Next.js | 1,001.40 | 28.25 | 1.22 | 203.93 |
| 40 ms transmisión / PRNext | 341.00 | 55.15 | 4.40 | 154.70 |
| 40 ms transmisión / Next.js | 218.67 | 105.00 | 6.31 | 206.20 |

La transmisión retiene aproximadamente 56% más rendimiento y aproximadamente 30% menos CPU por respuesta. Estos resultados se aplican a esta aplicación dinámica, perfil y presupuesto, no a todos los proyectos React.

## Cuatro CPU: la topología también importa

Con cuatro CPU y 2 GiB, PRNext utiliza dos trabajadores. Next.js utiliza dos procesos detrás de un proxy de Nodo privado, cuyos CPU y RAM están incluidos. Los otros tres presupuestos utilizan servidores directos. Esta diferencia de topología es parte del resultado.

PRNext alcanza 383.30 SSR solicitudes por segundo frente a 247.13 para esta referencia Next.js. Su PSS es 206.60 MiB contra 458.33 MiB. Eso no establece un ahorro universal de 55% RAM: una topología o proxy diferente podría cambiar el resultado. El API también puede alcanzar el techo del generador.

Medianas de dos ventanas por escenario y motor. Los CPU y RAM más bajos son mejores.

| Escenario / motor | Solicitud/s | p95 (ms) | CPU (ms/solicitud) | RAM (MiB) |
| --- | --- | --- | --- | --- |
| SSR 100 / PRNext | 383.30 | 56.35 | 8.49 | 206.60 |
| SSR 100 / Next.js | 247.13 | 133.50 | 11.80 | 458.33 |
| SSR 1 000 / PRNext | 46.37 | 450.10 | 68.28 | 272.22 |
| SSR 1 000 / Next.js | 45.50 | 688.85 | 62.55 | 520.04 |
| API JSON / PRNext | 3,421.17 | 8.20 | 0.91 | 242.97 |
| API JSON / Next.js | 1,582.60 | 24.05 | 1.90 | 525.35 |
| 40 ms transmisión / PRNext | 356.90 | 48.45 | 5.09 | 262.35 |
| 40 ms transmisión / Next.js | 313.77 | 68.75 | 7.98 | 542.40 |

El candidato pierde aproximadamente 10% de rendimiento de SSR y aproximadamente 6% en la página pesada en comparación con nuestro código PRNext anterior con este presupuesto. Más CPU no garantizan que todos los caminos mejoren. La ampliación entre trabajadores y las asignaciones de renderizado pesado aún necesitan trabajo.

## Navegación: arreglando nuestra propia regresión

La primera auditoría encontró un regreso inusualmente lento a una página grande. El transporte de vuelo diferencial produjo demasiados fragmentos pequeños. El candidato limita el trabajo de comparación, agrupa los datos disponibles y conserva una respuesta completa cuando una diferencia no vale la pena. El objetivo es reducir el trabajo sin esperar a futuras transmisiones por secuencias.

En Chromium 153, repetimos un viaje de página grande, página pequeña y regreso a página grande. En cada viaje se verifican 3,000 celdas visibles, estado del contador e identidad del documento. En el VPS pequeño, el retorno de PRNext cae de 1,475.6 a 307.2 ms; en el grande, de 932.1 a 228.6 ms.

Volver a la página grande, mediana de ocho contextos por motor y VPS.

| VPS | PRNext antes (ms) | PRNext probado (ms) | Next.js (ms) |
| --- | --- | --- | --- |
| Pequeño | 1,475.6 | 307.2 | 282.9 |
| Grande | 932.1 | 228.6 | 271.7 |

La ganancia de aproximadamente cuatro a cinco veces va en contra de nuestro código anterior PRNext, no Next.js. El candidato se queda ligeramente por detrás de Next.js en este viaje en el VPS pequeño y avanza en el grande. Ocho contextos por variante se ejecutan en una PC a través de un túnel; estos no son Core Web Vitals recopilados por los visitantes.

La hidratación no muestra la misma mejora. Su mediana es 421.6 ms para PRNext contra 349.8 ms para Next.js en el VPS pequeño, y 399.2 contra 299.1 ms en el grande. Transferir menos bytes no es suficiente para que el cliente interactúe antes.

## Modo de suspensión: suelte RAM entre visitas

Un sitio con poco tráfico no pasa el día saturando un procesador. La memoria inactiva puede importar más que el rendimiento máximo. PRNext puede retirar a sus trabajadores del Nodo después de un período de inactividad mientras mantiene el servidor Rust escuchando. La siguiente solicitud de renderizado recrea los trabajadores que necesita.

Probamos este mecanismo en el VPS pequeño con una página SSR simple y un umbral de inactividad acelerado de dos segundos. La memoria se observa después del retiro del trabajador, que duró aproximadamente dos segundos; el mando de mantenimiento del calor espera unos seis segundos. Se trata de una sonda funcional por configuración, independiente de las pruebas de carga y resistencia.

Sonda de activación en el VPS pequeño. Una observación por configuración, la misma página simple SSR.

| Configuración PRNext | Silencioso RAM (MiB) | Solicitud de activación (ms) |
| --- | --- | --- |
| Jubilación de trabajadores inactivos | 10.5 | 1,130.0 |
| Jubilación precaliente y luego inactiva | 10.4 | 1,126.6 |
| Precalentar y mantener caliente | 106.8 | 22.6 |

En esta investigación, el PSS cae a aproximadamente 10.5 MiB después de la jubilación del trabajador, frente a 106.8 MiB cuando se mantiene caliente. El costo aparece en la solicitud de activación: aproximadamente 1.13 segundos frente a 22.6 ms. La figura 10.5 MiB describe el árbol de procesos de esta aplicación simple en ese estado, no todo el VPS ni cada aplicación.

El precalentamiento de inicio con --prewarm inicializa el marco antes de aceptar solicitudes. No evita el retiro inactivo posterior y no llama a páginas de aplicaciones ni a controladores API. Para conservar los hosts de procesamiento usados, la configuración explícita es --worker-idle-segundos 0. Por lo tanto, el precalentamiento por sí solo no elimina el costo de despertarse después de dormir.

No se probó ninguna configuración de suspensión Next.js equivalente en esta sonda. No establece que la infraestructura externa no pueda detener o reiniciar Next.js.

## Beneficios indirectos del hosting compartido

Para varios proyectos pequeños visitados en diferentes momentos, liberar la memoria de los trabajadores inactivos puede dejar más espacio para aplicaciones activas. Una mejor eficiencia de CPU también puede dejar más trabajo útil dentro de la misma cuota. Esto puede ser relevante para sitios públicos pequeños, demostraciones y herramientas internas intermitentes.

Esta es una inferencia de las mediciones, no un punto de referencia de densidad de hosting. No hemos establecido cuántos proyectos adicionales caben en un servidor ni hemos medido una factura o un ahorro de energía. El sistema operativo, la base de datos, la puerta de enlace, las ráfagas simultáneas y las reactivaciones también consumen recursos.

El marco también tiene un comando local prnext host que puede poner una aplicación completa en suspensión detrás de una puerta de enlace. Esto es independiente de la jubilación de los trabajadores medida aquí. La puerta de enlace permanece activa; Las solicitudes y conexiones rastreadas protegen el trabajo en progreso y una visita posterior puede activar la aplicación. Esta campaña no cuantifica su coste total.

El sueño descarta el estado que se mantiene solo dentro de los procesos. Los datos duraderos pertenecen al disco o a un servicio adecuado; el trabajo en segundo plano sin seguimiento no debe depender de que un proceso se mantenga vivo. El servicio administrado PRNext Host vuelve a ser otra capa. Este artículo no mide su precio ni su rendimiento de implementación.

## Estabilidad observada y límites de la prueba.

Seis ejecuciones de carga mixta de diez minutos cubren las tres variantes de ambos VPS. A cada ejecución le siguen treinta cancelaciones de transmisión y 46 segundos de silencio. En estas campañas finales no se observaron fallas de contenido, errores de carga ni cortes por falta de memoria de los servidores probados.

Diez minutos de carga mixta por motor y VPS. El VPS grande está limitado a 1 CPU y 384 MiB.

| VPS/motor | Solicitud/s | Primer minuto RAM (MiB) | Último minuto RAM (MiB) |
| --- | --- | --- | --- |
| Pequeño / PRNext | 255.6 | 125.3 | 131.3 |
| Pequeño / Next.js | 202.3 | 106.5 | 114.8 |
| Grande / PRNext | 348.5 | 119.0 | 130.4 |
| Grande / Next.js | 317.6 | 152.5 | 158.0 |

Un intento de resistencia inicial expuso la retención de memoria en el generador de carga, no en el servidor probado. Después de arreglar la herramienta, las seis ejecuciones finales se repitieron en su totalidad con el mismo generador corregido. El enlace de la herramienta apunta al compromiso fb59284, separado del compromiso medido del motor.

La memoria aún varía: en el VPS grande restringido, PRNext pasa de 119.0 a 130.4 MiB entre el primer y el último minuto. Su rendimiento mixto es aproximadamente 12% inferior a nuestro código PRNext anterior en esa configuración. Diez minutos no establecen ni la ausencia de fugas ni la estabilidad durante varias semanas.

Después de la cancelación y la espera, los descriptores de archivos de PRNext vuelven a 44.. Esto no es suficiente para declarar una fuga o descartarla durante períodos más largos. La verificación del navegador agrega 48 contextos cronometrados y diez comprobaciones funcionales, incluidas las reservas forzadas. No demuestra compatibilidad completa con todas las aplicaciones Next.js.

## Qué significan estos resultados para PRNext

El argumento más fuerte es la eficiencia de CPU para SSR ordinario y la transmisión en varios presupuestos restringidos. La memoria también puede ser favorable, pero no está en el pequeño VPS físico de esta campaña. Dormir ofrece otra opción para proyectos intermitentes: liberar RAM o conservar una respuesta cálida.

Las próximas prioridades son las asignaciones de mayor rendimiento, la hidratación, las regresiones del rendimiento en algunos presupuestos y la ampliación entre trabajadores. Las pocas mediciones de compilación en esta campaña tampoco respaldan una afirmación general de compilaciones más rápidas.

PRNext sigue siendo experimental y su compatibilidad con Next.js es parcial. Para decidir si se ajusta a su aplicación, reproduzca sus costosas rutas, tráfico, períodos de silencio y despertares con un artefacto identificado. Estos resultados proporcionan un punto de partida verificable, no una clasificación universal de marcos.

[Cómo comparar el rendimiento de React SSR](/es/blog/benchmark-react-ssr)

[¿Cuánto RAM necesita Next.js en un VPS?](/es/blog/nextjs-ram-vps-sizing)

[PRNext y Next.js: guía de compatibilidad y migración](/es/blog/prnext-nextjs-compatibility-migration)

## Sources

[PRNext 0.1.18-alpha: published release / version publiée](https://github.com/Lorkydey/PRNext/releases/tag/v0.1.18-alpha)

[Benchmark data / Données du benchmark (JSON)](/benchmarks/prnext-vs-next-2026-10-29.json)

[PRNext: measured source / code mesuré (2856155)](https://github.com/Lorkydey/PRNext/tree/2856155dc32618d00ea7cbe05d771f589c9df536)

[Application fixture / application de test](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/tests/performance/production-fixture.mjs)

[Corrected load generator / générateur corrigé (fb59284)](https://github.com/Lorkydey/PRNext/blob/fb59284854850ba0293fab30cc215bbd9aba6c72/tests/performance/production-load.mjs)

[PRNext: rendering, prewarming and worker retirement](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/packages/prnext/docs/ai/deployment.md)

[PRNext: local application gateway](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/crates/prnext/src/hosting.rs)

Publicado: 2026-10-30

Modificado: 2026-10-30

Autor: PRNext

---

Idioma: es

Canonical: https://prnext.dev/es/blog/prnext-vs-nextjs-vps-benchmarks

Index: https://prnext.dev/llms.txt