Durante los últimos meses, hemos estado trabajando en mejorar el rendimiento del desarrollo local con Turbopack. En la versión 14.2, el Candidato a Lanzamiento de Turbopack ya está disponible para desarrollo local:
Hemos integrado Lightning CSS, un empaquetador y minificador CSS rápido, escrito en Rust.
Hemos probado extensivamente Turbopack con aplicaciones de Vercel. Por ejemplo, con vercel.com, una aplicación grande de Next.js, hemos observado:
Hasta 76.7% más rápido en el inicio del servidor local.
Hasta 96.3% más rápido en actualizaciones de código con Fast Refresh.
Hasta 45.8% más rápido en la compilación inicial de rutas sin caché (Turbopack aún no tiene caché en disco).
Turbopack sigue siendo opcional y puedes probarlo con:
Terminal
next dev --turbo
Ahora nos enfocaremos en mejorar el uso de memoria, implementar caché persistente y next build --turbo.
Uso de Memoria - Hemos construido herramientas de bajo nivel para investigar el uso de memoria. Ahora puedes generar trazas que incluyen métricas de rendimiento e información general del uso de memoria. Estas trazas nos permiten investigar sin necesidad de acceder al código fuente de tu aplicación.
Caché Persistente - Estamos explorando las mejores opciones de arquitectura y esperamos compartir más detalles en futuras versiones.
next build - Aunque Turbopack aún no está disponible para builds, 74.7% de las pruebas ya pasan. Puedes seguir el progreso en areweturboyet.com/build.
Además de mejoras en empaquetado con Turbopack, hemos trabajado para mejorar el rendimiento general de construcción y producción para todas las aplicaciones Next.js (tanto Pages como App Router).
Identificamos una optimización para el límite entre Server y Client Components que permite eliminar exportaciones no utilizadas (tree-shaking). Por ejemplo, importar un solo componente Icon desde un archivo con "use client" ya no incluye todos los demás iconos del paquete. Esto puede reducir significativamente el tamaño del bundle JavaScript en producción.
Al probar esta optimización en una biblioteca popular como react-aria-components, el tamaño final del bundle se redujo en -51.3%.
Nota: Esta optimización no funciona actualmente con archivos barrel. Mientras tanto, puedes usar la opción de configuración optimizePackageImports:
Para aplicaciones Next.js extremadamente grandes, notamos fallos por falta de memoria (OOMs) durante builds de producción. Tras investigar reportes de usuarios, identificamos que el problema era el sobre-empaquetado y minificación (Next.js creaba menos archivos JavaScript más grandes con duplicación). Hemos refactorizado la lógica de empaquetado y optimizado el compilador para estos casos.
Nuestras pruebas iniciales muestran que en una aplicación Next.js mínima, el uso de memoria y tamaño de archivos de caché disminuyó de 2.2GB a menos de 190MB en promedio.
Para facilitar la depuración del rendimiento de memoria, hemos introducido un flag --experimental-debug-memory-usage en next build. Más información en nuestra documentación.
Actualizamos cómo se optimiza CSS durante builds de producción en Next.js, dividiendo CSS para evitar conflictos de estilos al navegar entre páginas.
El orden y fusión de chunks CSS ahora se define por el orden de importación. Por ejemplo, base-button.module.css se ordenará antes que page.module.css:
base-button.tsx
import styles from './base-button.module.css';export function BaseButton() { return <button className={styles.primary} />;}
page.tsx
import { BaseButton } from './base-button';import styles from './page.module.css';export function Page() { return <BaseButton className={styles.primary} />;}
Para mantener el orden correcto de CSS, recomendamos:
Importar un CSS Module solo en un único archivo JS/TS.
Si usas clases globales, importa los estilos globales en el mismo archivo JS/TS.
No esperamos que este cambio afecte negativamente a la mayoría de aplicaciones. Sin embargo, si observas estilos inesperados al actualizar, revisa el orden de importación de CSS según las recomendaciones en nuestra documentación.
El caché es una parte crítica para construir aplicaciones web rápidas y confiables. Al realizar mutaciones, tanto usuarios como desarrolladores esperan que el caché se actualice para reflejar los últimos cambios. Hemos estado explorando cómo mejorar la experiencia de caché en Next.js con App Router.
El Client-side Router Cache es una capa de caché diseñada para proporcionar una experiencia de navegación rápida almacenando rutas visitadas y pre-cargadas en el cliente.
Basándonos en comentarios de la comunidad, hemos añadido una opción experimental staleTimes para permitir configurar el periodo de invalidación del client-side router cache.
Por defecto, las rutas pre-cargadas (usando el componente <Link> sin el prop prefetch) se almacenan en caché por 30 segundos, y si el prop prefetch está en true, 5 minutos. Puedes sobrescribir estos valores definiendo tiempos de revalidación personalizados en next.config.js:
staleTimes busca mejorar la experiencia actual para usuarios que quieren más control sobre las heurísticas de caché, pero no es la solución completa. En próximas versiones, nos enfocaremos en mejorar la semántica general del caché y proporcionar soluciones más flexibles.
Más información sobre staleTimes en nuestra documentación.
Continuamos iterando en las Rutas Paralelas y Rutas Interceptoras, mejorando ahora la integración con la Caché del Enrutador del lado del cliente (Client-side Router Cache).
Las rutas paralelas e interceptoras que invocan Acciones del Servidor (Server Actions) con revalidatePath o revalidateTag revalidarán la caché y actualizarán los espacios visibles manteniendo la vista actual del usuario.
De manera similar, llamar a router.refresh ahora actualiza correctamente los espacios visibles, manteniendo la vista actual.
En la versión 14.1, comenzamos a trabajar en mejorar la legibilidad de los mensajes de error y los seguimientos de pila (stack traces) al ejecutar next dev. Este trabajo continuó en la 14.2 para incluir mensajes de error más claros, mejoras en el diseño de la superposición (overlay) tanto para el Enrutador de la Aplicación (App Router) como para el Enrutador de Páginas (Pages Router), soporte para modo claro y oscuro, y registros (logs) más claros en dev y build.
Por ejemplo, los errores de Hidratación (Hydration) de React son una fuente común de confusión en nuestra comunidad. Si bien hicimos mejoras para ayudar a los usuarios a identificar la fuente de discrepancias en la hidratación (ver abajo), estamos trabajando con el equipo de React para mejorar los mensajes de error subyacentes y mostrar el nombre del archivo donde ocurrió el error.
Antes:
Un ejemplo de la superposición de errores de Next.js antes de la versión 14.2.
Después:
Un ejemplo de la superposición de errores de Next.js después de la versión 14.2.
En febrero, el equipo de React anunció el próximo lanzamiento de React 19. Para prepararnos para React 19, estamos trabajando en integrar las últimas características y mejoras en Next.js, y planeamos lanzar una versión importante para orquestar estos cambios.
Nuevas características como Acciones (Actions) y sus hooks relacionados, que han estado disponibles en Next.js desde el canal canario (canary channel) de React, ahora estarán disponibles para todas las aplicaciones React (incluidas las aplicaciones solo del lado del cliente). Estamos emocionados de ver una mayor adopción de estas características en el ecosistema de React.
[Docs] Nueva documentación sobre Optimización de Video (PR).
[Docs] Nueva documentación sobre instrumentation.ts (PR)
[Feature] Nueva propiedad overrideSrc para next/image (PR).
[Feature] Nuevo argumento revalidateReason para getStaticProps (PR).
[Improvement] Lógica de transmisión (streaming) refactorizada, reduciendo el tiempo para transmitir páginas en producción (PR).
[Improvement] Soporte para Acciones del Servidor (Server Actions) anidadas (PR).
[Improvement] Soporte para localización en Sitemaps generados (PR).
[Improvement] Mejoras visuales en los registros (logs) de desarrollo y construcción (PR)
[Improvement] La protección contra desfases (skew protection) es estable en Vercel (Docs).
[Improvement] Hacer useSelectedLayoutSegment compatible con el Enrutador de Páginas (Pages Router) (PR).
[Improvement] Omitir advertencias de metadataBase cuando las URLs absolutas no necesitan resolverse (PR).
[Improvement] Corregir Acciones del Servidor (Server Actions) que no se enviaban sin JavaScript habilitado cuando se desplegaban en Vercel (PR)
[Improvement] Corregir error sobre una Acción del Servidor no encontrada en el manifiesto de acciones si se activaba después de navegar fuera de la página de referencia, o si se usaba dentro de un segmento de ruta paralela inactiva (PR)
[Improvement] Corregir importaciones CSS en componentes cargados por next/dynamic (PR).
[Improvement] Advertir cuando a una imagen animada le falta la propiedad unoptimized (PR).
[Improvement] Mostrar un mensaje de error si images.loaderFile no exporta una función predeterminada (PR)
Next.js ahora tiene más de 1 millón de desarrolladores activos mensuales. Estamos agradecidos por el apoyo y las contribuciones de la comunidad. Únase a la conversación en GitHub Discussions, Reddit, y Discord.
Next.js es el resultado del trabajo combinado de más de 3,000 desarrolladores individuales, socios de la industria como Google y Meta, y nuestro equipo central en Vercel. Este lanzamiento fue posible gracias a:
