Renderizado Estatico Con Soporte De Modo De Edicion

Esta guía explica cómo el sitio de documentación logra cargas rápidas de páginas estáticas mientras mantiene la funcionalidad del modo de edición del CMS.

Arquitectura de doble ruta

Usamos dos rutas para el mismo contenido:

app/
├── [...slug]/page.tsx          # Producción: force-static (rápido)
└── preview/[...slug]/page.tsx  # Modo de edición: force-dynamic (lee searchParams)

Un middleware proxy reescribe de forma transparente las solicitudes de modo de edición:

Solicitud del usuario: /en/headless/quickstart?edit_mode=true
       ↓
El proxy detecta ?edit_mode=true
       ↓
Reescritura interna a: /preview/en/headless/quickstart?edit_mode=true
       ↓
La ruta dinámica se renderiza con envoltorios de edición

El usuario nunca ve /preview en su URL: es una reescritura interna.

Cómo funciona

Ruta de producción (predeterminada)

// app/[...slug]/page.tsx
export const dynamic = 'force-static';
export const revalidate = 60;

export default async function Page({ params }) {
  // Sin searchParams: la página es completamente estática
  

• Las páginas se prerenderizan en tiempo de compilación
• Se sirven al instante desde la caché perimetral del CDN
• Se revalidan cada 60 segundos (ISR) como red de seguridad

Ruta de modo de edición

// app/preview/[...slug]/page.tsx
export const dynamic = 'force-dynamic';

export default async function PreviewPage({ params, searchParams }) {
  // searchParams disponibles: puede detectar edit_mode
  return <ParametricRoutePage params={params

• Se renderiza en cada solicitud
• Puede leer ?edit_mode=true de la URL
• Se renderiza con envoltorios editables del CMS y contornos de bloques

La reescritura del proxy

// src/proxy.ts
export const proxy = async (request: NextRequest) => {
  const { pathname, searchParams } = request.nextUrl;

  const editMode = searchParams.get('edit_mode');

Comparación de rendimiento

Comprender ISR (Incremental Static Regeneration)

La configuración revalidate = 60 habilita ISR. Esto NO significa que las páginas se vuelvan a calcular cada 60 segundos.

ISR utiliza un patrón de stale-while-revalidate:

Llega una solicitud:
  → ¿La página en caché tiene menos de 60 s? → Servir desde la caché (instantáneo)
  → ¿La página en caché tiene más de 60 s? → Servir la caché obsoleta (instantáneo)
                                + revalidar en segundo plano para la siguiente solicitud

No hay solicitudes = No hay recálculo. Nunca.

Ejemplo:

• Página en caché a las 10:00 a. m.
• Sin visitantes hasta las 3:00 p. m.
• El primer visitante a las 3:00 p. m. recibe la caché obsoleta al instante
• Ocurre la actualización en segundo plano, el siguiente visitante obtiene contenido actualizado

La ventana de 60 segundos es una red de seguridad. Idealmente, usaríamos revalidación bajo demanda mediante webhooks cuando cambia el contenido del CMS.

Cuándo usar cada ruta

¿Por qué no usar simplemente renderizado dinámico?

El enfoque simple (sin force-static, sin ruta de vista previa) funciona, pero es lento:

// Enfoque simple: funciona pero tarda ~1-2 s por solicitud
export default async function Page({ params, searchParams }) {
  return <ParametricRoutePage params={params} searchParams={searchParams} />;
}

Esto se renderiza dinámicamente en cada solicitud. Para un sitio de documentación con muchas páginas, esto significa:

• Arranques en frío en cada página
• Sin beneficio de caché perimetral del CDN
• Tiempos de carga de 1-2 segundos frente a milisegundos

La arquitectura de doble ruta nos da lo mejor de ambos mundos: velocidad estática para los lectores y funcionalidad dinámica para los editores.