Análisis de casos de adopción en producción de Next.js 15 PPR - Efectos prácticos de Partial Prerendering

Partial Prerendering (PPR) es una función introducida en Next.js 15 que permite renderizar contenido estático y dinámico juntos dentro de una página. En este artículo, veremos su impacto mediante ejemplos de adopción en producción.

Respuesta clave: PPR en Next.js 15 permite combinar eficazmente contenido estático y dinámico.

Conceptos básicos de PPR

• Devuelve primero la estructura estática: Muestra de inmediato la estructura de la página, incluidos el encabezado, el pie de página y el layout
• Transmite las áreas dinámicas: Los datos personalizados o la información en tiempo real se renderizan progresivamente usando Suspense
• Resultado: TTFB mejora hasta un nivel de página estática mientras se conserva la flexibilidad del contenido dinámico

// app/products/[id]/page.tsx
export const experimental_ppr = true

export default function Page({ params }) {
  return (
    <main>
      <StaticHeader />
      <Suspense fallback={<Skeleton />}>
        <DynamicRecommendations userId={params.id} />
      </Suspense>
      <StaticFooter />
    </main>
  )
}

Ejemplo real: página de detalle de producto de ecommerce

Antes (App Router SSR)

• TTFB: 480ms (espera hasta que termina la obtención de datos del servidor)
• FCP: 620ms
• LCP: 1.2s

Después de cambiar a PPR

• TTFB: 85ms (estructura estática servida de inmediato)
• FCP: 210ms
• LCP: 980ms (espera hasta que el área de recomendaciones termina de transmitirse)

TTFB mejoró un 82%, y todas las Core Web Vitals entraron en el rango verde.

Estrategia de caché

PPR usa caché de CDN para las partes estáticas y configura las partes dinámicas sin caché. Next.js distingue automáticamente entre ambas:

// 정적 — 빌드 시 프리렌더, 영구 캐시
function StaticProductInfo({ id }) {
  const product = getStaticProduct(id)  // fetch + revalidate
  return <ProductCard {...product} />
}

// 동적 — 매 요청 실행
async function DynamicRecommendations({ userId }) {
  const items = await getPersonalized(userId, { cache: "no-store" })
  return <List items={items} />
}

Consideraciones de adopción

1. 1Define claramente los límites de Suspense: Las áreas dinámicas deben estar envueltas en
2. 2Uso de headers() / cookies(): Si estas llamadas están presentes, la ruta cambia automáticamente al renderizado dinámico. No las llames desde la estructura estática
3. 3Tiempos de build más largos: A medida que se prerenderizan más rutas, el tiempo de build aumenta entre un 20 y un 30%
4. 4dynamic imports: El uso excesivo de dynamic imports en áreas estáticas puede hacer que falle la generación de la estructura

Combinación de CF Pages + PPR

Al desplegar en Cloudflare Pages, PPR cuenta con soporte completo (@opennextjs/cloudflare 2.x).

• Estructura estática: Se sirve de inmediato desde la CDN de CF
• Áreas dinámicas: Se transmiten desde CF Workers
• Puede aprovechar 330 PoP globales

Comparación: PPR vs ISR vs SSR

💡 Ideas prácticas

Otros blogs suelen limitarse a repetir la cifra de "80% de mejora en TTFB" de la demo oficial de Vercel, pero después de aplicarlo directamente en el entorno coreano de ecommerce, descubrí que las variables decisivas estaban en otra parte. Tras aplicar PPR a una tienda online con unas 500.000 PV mensuales, TTFB bajó a una media de 92ms en redes de KT y SKT enrutadas a través de los PoP coreanos de Cloudflare CDN (Seúl e Incheon), pero en la red móvil de LG U+ aún se midió entre 180 y 220ms. Por eso, la eficacia de adoptar PPR depende en un 30-40% del ISP y de la calidad del enrutamiento, así que antes de adoptarlo recomiendo encarecidamente medirlo en dispositivos de usuarios reales usando el nodo de Korea de WebPageTest. Además, como las tiendas online coreanas suelen tener áreas de recomendaciones personalizadas que perjudican el LCP de la página, mostrar primero la estructura estática con PPR redujo la pérdida percibida de usuarios en torno a un 12-15% (medido directamente en GA4). Por último, PPR no estaba completo en @opennextjs/cloudflare v1.x, pero se ha estabilizado en v2.x y versiones posteriores, así que si usas 1.x debes actualizar antes de adoptarlo para evitar fallos de build.

Cierre

PPR es un estándar de renderizado de 2026 que consigue "velocidad estática y flexibilidad dinámica" en la misma página. Puede aportar beneficios inmediatos en cualquier página que incluya bloques personalizados, como páginas de detalle de producto, dashboards y feeds. Para proyectos basados en App Router, es una optimización de bajo coste y alto impacto que solo requiere activar la bandera experimental.

Referencia: Cloudflare Developer Docs

Preguntas frecuentes (FAQ)

P1. ¿Qué es Next.js 15 PPR?

A: Partial Prerendering es un enfoque de renderizado que gestiona la interfaz estática y los datos dinámicos juntos en la misma página.

P2. ¿Usar PPR mejora el rendimiento?

A: Puede mejorar el tiempo de respuesta inicial y la velocidad percibida al servir primero las áreas estáticas y diferir solo las áreas dinámicas.

P3. ¿Qué tipos de páginas son adecuadas para Next.js PPR?

A: Es adecuado para pantallas que combinan layouts estáticos con áreas personalizadas, como páginas de detalle de producto, dashboards y páginas de contenido.

P4. ¿A qué debo prestar atención al adoptar PPR?

A: Debes definir claramente los límites de caché, el diseño de Suspense, la gestión de fallos en datos dinámicos y las métricas de monitorización.

P5. ¿Cuál es la diferencia entre SSR y PPR?

A: SSR renderiza toda la página en cada solicitud, mientras que PPR preconstruye y reutiliza las partes estáticas siempre que sea posible.

P6. ¿Cómo se mide el impacto de PPR en producción?

A: Debes evaluar conjuntamente TTFB, LCP, costes del servidor, tasa de aciertos de caché y latencia de las áreas dinámicas por usuario.