# PRNext 0.1.21: menos trabajo en Flight y en los builds PRNext 0.1.21-alpha está disponible en npm. Esta versi?n reduce el trabajo que puede evitarse sin cambiar lo que muestra una aplicación. Los procesos de renderizado pueden preparar el framework antes de la primera petición dinámica. Los builds reutilizan pequeños resúmenes verificados, y los resultados primitivos en caché emplean un formato privado compacto. Los valores complejos de React mantienen la decodificación oficial de Flight. La versión también refuerza los límites entre la petición pública, el proxy conectado directamente y los servicios de control locales. Amplía 0.1.20 sin crear una caché de respuestas entre usuarios. La aplicación sigue siendo responsable de la autorización, la vigencia de los datos y el procedimiento de despliegue. ## Preparar cada proceso antes de la primera respuesta dinámica La opción explícita --prewarm prepara todos los procesos de renderizado y repite esa preparación del framework en sus reemplazos y al despertar tras un periodo inactivo. Se ejecutan como máximo dos preparaciones simultáneas dentro del presupuesto inicial de 15 segundos. Un pequeño modelo RSC y HTML interno ejercita el renderer oficial sin importar rutas de la aplicación ni leer datos de cuentas. La disponibilidad inicial espera esa preparación. Las importaciones de la aplicación, conexiones a bases de datos y datos de la petición todavía pueden añadir trabajo al primer renderizado real. Si un reemplazo posterior no termina la preparación, registra un diagnóstico y conserva la carga diferida para las peticiones normales. Esta sigue siendo la opción predeterminada y no se repiten peticiones fallidas. Conviene medir el arranque y la primera respuesta dinámica, no deducir que React está preparado porque un archivo estático responde. ```sh npx --no-install prnext start --workers 2 --prewarm ``` ## Reducir las asignaciones alrededor de la misma respuesta Flight Los contenedores de mensajes Flight y sus listas de transferencia se reutilizan solo dentro de su respuesta y liberan las referencias a buffers después de transferirlos. Los scripts inline de arranque grandes se codifican directamente en buffers acotados. Otras estructuras se crean cuando son necesarias, y los fragmentos HTML ordinarios completos toman una ruta directa. El contenido codificado, el base64 y el nonce CSP conservan su significado. Se mantienen la cancelación, los créditos de lectura, las copias defensivas para datos de productores externos y el aislamiento entre respuestas. Los atributos entre comillas y el HTML ambiguo siguen utilizando el parser. Reducir este trabajo no permite guardar una respuesta privada para otra petición. ## Observar el tamaño de Flight y el progreso del renderer La inspección opcional agrupa bytes, chunks y resultados de Flight por patrón de ruta y fase de renderizado. Distingue muestras completadas, canceladas, fallidas y caducadas, y muestra cuándo están listos el modelo y el shell si esos hitos se observan. RSC y SSR pueden observar el mismo contenido: no deben sumarse sus tamaños ni sus recuentos de peticiones. Las duraciones incluyen trabajo de la aplicación y esperas asíncronas, no solo CPU del codificador o decodificador. Las muestras ausentes no se convierten en ceros. Los diagnósticos excluyen cuerpos, cookies, valores de autorización y consultas sin procesar. Las métricas opcionales de GC, heap y bucle de eventos aportan otra perspectiva, sin observador GC cuando están desactivadas. Se mantienen los valores V8 predeterminados y las opciones explícitas del operador. ```sh npx --no-install prnext start . --inspect npx --no-install prnext inspect --json ``` ## Reutilizar metadatos sin eliminar las comprobaciones Los builds repetidos pueden reutilizar resúmenes Oxc tipados y acotados con las directivas y exportaciones necesarias para las etapas siguientes. Estos resúmenes inmutables no conservan el texto fuente, un AST ni cierres de la aplicación. Las comprobaciones de identidad y generación siguen validando que cada registro corresponda a la entrada actual. Una entrada ausente o inválida devuelve el proceso a su ruta normal. El descubrimiento de dependencias nativas también reutiliza pruebas limitadas cuando se establece que un grafo no contiene código nativo. Los efectos desconocidos, hooks personalizados y entradas cambiantes mantienen sus controles; no se reutiliza a ciegas un grafo opaco. Las aplicaciones y herramientas de referencia incorporan además actualizaciones seleccionadas, incluidas las bases Next 16.4.4, Better Auth 1.7.15 y el cliente Redis 6.3.1. ## Acotar las copias y entender las fases de compilación Las copias del trazado standalone y del runtime usan concurrencia limitada, tratamiento determinista de alias y presupuestos de admisión. Siguen detectándose cambios del origen durante una copia. Si una operación falla, las escrituras iniciadas terminan antes de descartar el directorio temporal y se conserva el último build publicado. Los chunks del servidor Pages y sus source maps se reescriben en memoria antes de escribirlos por primera vez. build --timings expone las fases React para distinguir una etapa lenta del compilador del trabajo con archivos. Su total excluye el arranque de los módulos CLI y las fases anidadas se superponen, por lo que no deben sumarse todas. Los informes quedan fuera de los manifiestos de despliegue y de los assets del navegador. ```sh npx --no-install prnext build --timings ``` ## Mantener a React al frente de la caché y de la continuación PPR Un callback en caché sigue entrando una vez en el renderer oficial de React, incluido su contexto React.cache. Los resultados primitivos elegibles usan un formato privado compacto y versionado. Objetos, nodos React, funciones y referencias temporales conservan Flight canónico, con los bytes originales para resultados complejos ordinarios. Las cadenas con BOM, UTF-16 mal formado o valores próximos al límite de renderizado también mantienen el tratamiento oficial. Se conservan los ámbitos privados por petición, tags, TTL y objetos recién decodificados. Cambia el codec del resultado, no aparece una caché entre cuentas. En PPR nativo, el análisis inmutable y acotado y la información de prefijos solo se reutilizan tras verificar de nuevo los bytes y el SHA del artefacto actual. Las continuaciones mutables se clonan para cada petición. Las continuaciones anidadas o no directas mantienen la normalización existente cuando es necesaria. Las entradas RSC también usan un nuevo espacio de claves. Tras actualizar, los resultados anteriores no se reutilizan: las primeras llamadas vuelven a llenar las cachés elegibles, un coste que debe incluirse al observar el calentamiento. ## Retirar de la cola las solicitudes abandonadas Una petición de desarrollo cancelada o caducada deja de mantener viva su demanda de compilación en cola. Una compilación compartida que otro solicitante todavía necesita conserva su propio ciclo de vida. Así se evita trabajar solo para una petición desconectada sin cancelar trabajo útil para otra pestaña. Las notificaciones RPC de desarrollo siguen siendo la fuente autorizada tras su primera publicación aceptada. Una instantánea de archivo tardía ya no restaura un diagnóstico que RPC había borrado. Las notificaciones por archivo siguen disponibles hasta establecer RPC, sin mezclar generaciones antiguas. En desarrollo, las navegaciones sucesivas y Fast Refresh también coordinan sus flujos Flight. Una respuesta aún en curso puede ceder el paso a la siguiente ruta sin restaurar un árbol de componentes antiguo y perder el estado del layout compartido. El cambio se limita a los GET de navegación en desarrollo, sin repetir mutaciones; las respuestas de producción y Server Actions conservan la decodificación estricta. Con navigationCache.authCookies configurado para las cookies de sesión, la reautorización tiene prioridad: los borradores de un usuario no se reutilizan para otro. Una Server Action también puede reemplazar la vista mientras se confirma una actualización ya aplicada. Fast Refresh distingue ahora ese cambio de vista de la cancelación de la actualización. Los errores reales, las cancelaciones y los plazos de red siguen siendo fallos, sin reenviar la Action. Esta integración de desarrollo permanece vinculada a la versión de React validada con PRNext. Utiliza una opción experimental del cliente Flight sin activar ese comportamiento en producción. ## Probar Node 26 con los mismos artefactos La CI de Linux incorpora controles con Node 26 para runtime y HTTP, Chromium, el consumidor SaaS y las instalaciones del paquete, con estructuras hoisted y anidadas. Esta cobertura de navegador corresponde a Chromium. No sustituye la matriz principal de Linux, macOS y Windows ni elige el runtime Node de un despliegue. La cobertura funcional no proporciona una cifra de rendimiento para Node 26. Compare un cambio de runtime con los mismos artefactos y dependencias y verifique sus propios recorridos. No se atribuye ninguna mejora numérica de Node 26 a esta campaña, ejecutada con Node 22.23.4. ## Interpretar cada resultado dentro de su alcance La comparación controlada del código publicado de 0.1.20 con el candidato 7c15132a se ejecuta en Linux x64 y Node 22.23.4. Incluye doce pares por ruta y 72 ventanas en total, con dos workers, límites visibles de dos CPU y 5 GiB y afinidad a esas dos CPU. Cada ventana dura quince segundos tras dos de calentamiento, con ocho conexiones SSR, dos para la API JSON y ocho para streaming. Se completaron 774.665 respuestas útiles dentro de las ventanas y 775.089 incluyendo el vaciado. Las 424 completadas durante el vaciado no cuentan para el rendimiento. Los contadores de errores HTTP, transporte y validación son cero. El calentamiento se contabiliza aparte: 51.123 respuestas dentro de sus ventanas y 51.552 con su vaciado. Las medianas de las razones emparejadas candidato/base son 0,9944 para el rendimiento SSR, 0,9941 para la API JSON y 0,9978 para streaming. Las razones p95 correspondientes son 1,0361, 1,0056 y 1,0028. Todos los intervalos emparejados informados incluyen 1. Se cumplen los presupuestos fijados previamente: una caída de rendimiento máxima del 10% y un aumento del p95 máximo del 15%. Estos resultados cercanos a la referencia no demuestran una aceleración general. El archivo JavaScript de referencia coincide exactamente con el publicado para 0.1.20, y el del candidato con la validación Linux de esta fuente. Sin embargo, ambos ejecutables nativos se reconstruyeron por separado y no son los bytes exactos del nativo público histórico ni del nativo validado para la release. El resultado compara esas composiciones vinculadas al código, sin aislar los cambios JavaScript. Las observaciones del kernel y de los procesos están verificadas para las 72 muestras. La memoria sigue siendo muestreada, los límites de ancestros ocultos por namespaces y la contención del runner quedan fuera de esa verificación, y no todas las dependencias de build o transitivas están certificadas byte a byte. Estas tres cargas sintéticas no establecen una reducción global de CPU o RAM, capacidad de producción ni un SLA. ## Definir el origen público y los límites del control local La política guardada de origen público y proxys de confianza se aplica a las entradas de desarrollo, persistentes y nativas para varias aplicaciones, incluido el tráfico HTTP y WebSocket. PRNext comprueba el par que realmente se conecta antes de aceptar la autoridad o el protocolo reenviados. Un origen canónico configurado tiene prioridad; confiar en un proxy no certifica toda una cadena de direcciones IP del cliente. Las URL alternativas de imágenes se construyen por componentes y se verifica su origen normalizado final antes de permitir una excepción de acceso interno. El RPC del compilador y del supervisor autentica ambos extremos y vincula nonces nuevos con los bytes exactos de las órdenes y respuestas. Los mensajes y plazos siguen limitados. El cambio de protocolo exige detener el supervisor anterior antes de actualizar. ## Detener el supervisor anterior antes de sustituir su CLI Si utiliza el supervisor persistente, inspecciónelo y deténgalo con la CLI antigua todavía instalada, bajo el mismo PRNEXT_PM_HOME, antes de reemplazar los paquetes. pdown afecta al supervisor y a todas las aplicaciones gestionadas que comparten ese directorio: planifique su mantenimiento conjuntamente. Actualizar solo la CLI global no sustituye cada runtime. Conserve fuentes, lockfile, configuración, build y una copia de seguridad compatible de la base de datos para volver atrás. ```sh npx --no-install prnext pstatus --json npx --no-install prnext pdown npm install @thomas.f/prnext@0.1.21-alpha npx --no-install prnext check --production --json npx --no-install prnext build ``` Mantenga las dependencias nativas opcionales y alinee sus versiones con el framework. React, React DOM y react-server-dom-webpack permanecen en 19.3.1; los rangos Node admitidos son ^22.23.4, ^24.22.1 o >=26.12.1. Reconstruya cada aplicación habilitada con su nuevo runtime antes de reiniciar el supervisor previsto. La nueva CLI rechaza el protocolo antiguo incompatible en vez de asumir el control silenciosamente. PRNext sigue siendo alpha, con compatibilidad parcial con Next.js. Todavía debe calificarse un piloto representativo y sus objetivos de fiabilidad. Compruebe acceso, cambio de cuenta, navegación, formularios, streaming, fallos de dependencias y rollback en su producto. Actualizar el framework npm no despliega PRNext Host ni servicios externos; volver al código anterior no deshace escrituras en la base de datos. ## Referencias técnicas Los siete paquetes de 0.1.21-alpha están disponibles en npm. El código y la comparación controlada siguientes explican los cambios, sus condiciones y los límites de las mediciones. [PRNext 0.1.21-alpha en npm](https://www.npmjs.com/package/@thomas.f/prnext/v/0.1.21-alpha) [Cambios e implementación del framework](https://github.com/Lorkydey/PRNext/pull/59) [Refuerzo de proxys, imágenes y RPC local](https://github.com/Lorkydey/PRNext/pull/56) [Navegación, Fast Refresh y notas de actualización](https://github.com/Lorkydey/PRNext/pull/60) [Fiabilidad de navegación y Fast Refresh](https://github.com/Lorkydey/PRNext/pull/61) [Código del framework publicado 7c15132a](https://github.com/Lorkydey/PRNext/commit/7c15132ade6da37c8a858873d405b33b4e566874) [Comparación controlada con 0.1.20](https://github.com/Lorkydey/PRNext/actions/runs/42340893273) Publicado: 2026-11-07 Modificado: 2026-11-07 Autor: PRNext --- Idioma: es Canonical: https://prnext.dev/es/blog/prnext-0-1-21-flight-cache-node26-compilacion Index: https://prnext.dev/llms.txt