Tutoriales 22 min de lectura

React Server Components en Next.js 15: Streaming, Suspense y Caché Explicados

Domina React Server Components en Next.js 15: obtención de datos con async/await, streaming progresivo con Suspense, estrategias de caché y revalidación, y la directiva use cache. Guía práctica con patrones reales.

Editorial Team

Introducción: El modelo mental que cambia todo

Si vienes del mundo de React tradicional, seguramente estés acostumbrado a un flujo bastante predecible: el componente se monta en el navegador, dispara un useEffect, hace un fetch al servidor, muestra un spinner mientras espera, y finalmente renderiza los datos. Funciona, claro. Pero seamos honestos — que el usuario vea una pantalla vacía (o un spinner genérico) hasta que todo ese viaje de ida y vuelta se complete no es exactamente lo ideal.

Con Next.js 15 y los React Server Components, ese modelo mental se invierte por completo.

Los React Server Components (RSC) ejecutan tu código de renderizado directamente en el servidor. Esto significa que puedes acceder a bases de datos, leer archivos del sistema, llamar a APIs internas — todo sin que una sola línea de esa lógica llegue al navegador del usuario. El resultado es una arquitectura donde la obtención de datos es una ciudadana de primera clase, no un efecto secundario que se dispara después del renderizado.

Pero la historia no termina ahí. Next.js 15 combina los RSC con streaming, Suspense y un sistema de caché completamente rediseñado que te da control granular sobre qué datos se cachean, cuándo se revalidan y cómo fluyen hacia el cliente. En este artículo vamos a desmenuzar cada pieza, ver cómo encajan entre sí y repasar patrones reales que puedes implementar hoy mismo en tu aplicación.

React Server Components: Los fundamentos que necesitas dominar

Componentes del servidor vs. componentes del cliente

En el App Router de Next.js 15, todos los componentes son Server Components por defecto. Este es un cambio fundamental respecto al modelo anterior, y sinceramente, una vez que te acostumbras, no quieres volver atrás. No necesitas hacer nada especial para que un componente se ejecute en el servidor — simplemente lo escribes y Next.js se encarga del resto.

// app/productos/page.tsx
// Este es un Server Component por defecto
// No necesita 'use server' ni ninguna directiva especial

import { obtenerProductos } from '@/lib/db'

export default async function PaginaProductos() {
  // Puedes hacer await directamente en el componente
  const productos = await obtenerProductos()

  return (
    <main>
      <h1>Nuestros Productos</h1>
      <ul>
        {productos.map(producto => (
          <li key={producto.id}>
            <h2>{producto.nombre}</h2>
            <p>{producto.descripcion}</p>
            <span>${producto.precio}</span>
          </li>
        ))}
      </ul>
    </main>
  )
}

Los componentes del cliente, por otro lado, necesitan la directiva 'use client' al inicio del archivo. Solo deberías marcar un componente como cliente cuando requieras interactividad: manejadores de eventos como onClick, hooks como useState o useEffect, o APIs del navegador como window o localStorage.

'use client'

import { useState } from 'react'

export function ContadorProductos({ inicial }: { inicial: number }) {
  const [cantidad, setCantidad] = useState(inicial)

  return (
    <div>
      <button onClick={() => setCantidad(c => c - 1)}>-</button>
      <span>{cantidad}</span>
      <button onClick={() => setCantidad(c => c + 1)}>+</button>
    </div>
  )
}

El patrón de composición: islas de interactividad

La clave para sacarle el máximo jugo a los RSC es pensar en tu aplicación como un océano de componentes del servidor con pequeñas islas de interactividad donde realmente se necesita JavaScript en el cliente. Este patrón reduce drásticamente la cantidad de JavaScript que se envía al navegador, y la diferencia se nota.

// app/productos/[id]/page.tsx — Server Component
import { obtenerProducto, obtenerResenas } from '@/lib/db'
import { BotonAgregarCarrito } from '@/components/BotonAgregarCarrito' // Client Component
import { GaleriaImagenes } from '@/components/GaleriaImagenes'         // Client Component

export default async function PaginaProducto({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const producto = await obtenerProducto(id)
  const resenas = await obtenerResenas(id)

  return (
    <article>
      {/* Isla de interactividad: galería con swipe y zoom */}
      <GaleriaImagenes imagenes={producto.imagenes} />

      {/* Contenido estático renderizado en el servidor */}
      <h1>{producto.nombre}</h1>
      <p>{producto.descripcion}</p>
      <p>Precio: ${producto.precio}</p>

      {/* Otra isla de interactividad */}
      <BotonAgregarCarrito productoId={producto.id} precio={producto.precio} />

      {/* Reseñas renderizadas en el servidor — sin JS en el cliente */}
      <section>
        <h2>Reseñas ({resenas.length})</h2>
        {resenas.map(r => (
          <div key={r.id}>
            <strong>{r.autor}</strong>
            <p>{r.comentario}</p>
          </div>
        ))}
      </section>
    </article>
  )
}

Fíjate cómo GaleriaImagenes y BotonAgregarCarrito son componentes del cliente (porque necesitan interactividad), pero todo lo demás se renderiza completamente en el servidor. Las reseñas, el título, la descripción — nada de eso necesita JavaScript en el navegador. Cero.

Patrones de obtención de datos en Server Components

Obtención directa con async/await

La forma más natural de obtener datos en un Server Component es simplemente usar async/await. Sin hooks, sin useEffect, sin bibliotecas de gestión de estado. El componente es una función asíncrona que espera sus datos y los renderiza. Así de simple.

// app/dashboard/page.tsx
import { db } from '@/lib/database'

export default async function Dashboard() {
  const estadisticas = await db.query(`
    SELECT
      COUNT(*) as totalPedidos,
      SUM(total) as ingresos,
      COUNT(DISTINCT cliente_id) as clientesUnicos
    FROM pedidos
    WHERE fecha >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  `)

  return (
    <div>
      <h1>Dashboard</h1>
      <div className="grid grid-cols-3 gap-4">
        <div>
          <h3>Pedidos (30 días)</h3>
          <p>{estadisticas.totalPedidos}</p>
        </div>
        <div>
          <h3>Ingresos</h3>
          <p>${estadisticas.ingresos.toLocaleString()}</p>
        </div>
        <div>
          <h3>Clientes únicos</h3>
          <p>{estadisticas.clientesUnicos}</p>
        </div>
      </div>
    </div>
  )
}

Observa algo crucial aquí: estamos haciendo una consulta SQL directamente desde el componente. Esto es posible porque el componente se ejecuta en el servidor. El código de la base de datos nunca llega al navegador. Es seguro, eficiente y directo. La primera vez que lo vi funcionando, debo admitir que me pareció casi mágico.

Obtención secuencial vs. paralela

Uno de los errores más comunes al trabajar con Server Components es crear cascadas de datos innecesarias. Y lo digo porque es algo en lo que he caído más de una vez. Veamos la diferencia con un ejemplo concreto.

Patrón problemático — obtención secuencial (cascada):

// ❌ Cada await bloquea el siguiente — cascada de datos
export default async function PerfilUsuario({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params

  const usuario = await obtenerUsuario(id)           // 200ms
  const pedidos = await obtenerPedidos(id)            // 300ms
  const recomendaciones = await obtenerRecomendaciones(id) // 250ms
  // Total: ~750ms (secuencial)

  return (
    <div>
      <h1>{usuario.nombre}</h1>
      <ListaPedidos pedidos={pedidos} />
      <Recomendaciones items={recomendaciones} />
    </div>
  )
}

Patrón óptimo — obtención en paralelo:

// ✅ Todas las solicitudes se ejecutan al mismo tiempo
export default async function PerfilUsuario({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params

  const [usuario, pedidos, recomendaciones] = await Promise.all([
    obtenerUsuario(id),           // 200ms
    obtenerPedidos(id),            // 300ms
    obtenerRecomendaciones(id),    // 250ms
  ])
  // Total: ~300ms (paralelo — limitado por la más lenta)

  return (
    <div>
      <h1>{usuario.nombre}</h1>
      <ListaPedidos pedidos={pedidos} />
      <Recomendaciones items={recomendaciones} />
    </div>
  )
}

Con Promise.all, las tres peticiones se lanzan simultáneamente y el tiempo total es el de la petición más lenta (300ms en vez de 750ms). En aplicaciones reales, la diferencia puede ser aún más dramática — sobre todo cuando tienes cuatro o cinco fuentes de datos distintas.

Deduplicación automática de peticiones

Aquí viene algo que me parece especialmente elegante. Next.js 15 extiende la API nativa de fetch para deduplicar automáticamente las peticiones idénticas que ocurren durante el mismo ciclo de renderizado en el servidor. Básicamente, si varios componentes necesitan los mismos datos, puedes llamar a fetch en cada uno sin preocuparte por peticiones duplicadas.

// lib/api.ts
export async function obtenerConfiguracion() {
  const res = await fetch('https://api.ejemplo.com/config', {
    next: { revalidate: 3600 } // Revalidar cada hora
  })
  return res.json()
}

// app/layout.tsx — Usa obtenerConfiguracion()
// app/header.tsx — Usa obtenerConfiguracion()
// app/footer.tsx — Usa obtenerConfiguracion()
// Solo se ejecuta UNA petición real, las demás reutilizan el resultado

Eso sí, esta deduplicación solo funciona con fetch, no con consultas directas a base de datos u otras funciones personalizadas. Para esos casos, puedes usar la función cache de React y lograr algo similar.

import { cache } from 'react'
import { db } from '@/lib/database'

// Envolver la función con cache() para deduplicar
export const obtenerUsuarioActual = cache(async () => {
  const sesion = await verificarSesion()
  if (!sesion) return null

  return db.usuario.findUnique({
    where: { id: sesion.userId }
  })
})

Streaming y Suspense: La experiencia de usuario que tus visitantes merecen

¿Qué es el streaming y por qué debería importarte?

En el modelo tradicional de SSR, el servidor necesita completar toda la obtención de datos y todo el renderizado antes de enviar una sola línea de HTML al navegador. Si una consulta a la base de datos tarda 3 segundos, el usuario ve una pantalla en blanco durante esos 3 segundos. No importa que el header, la navegación y el footer estén listos al instante — todo queda bloqueado por la parte más lenta.

Frustrante, ¿verdad?

El streaming cambia esta ecuación radicalmente. Con streaming, Next.js envía el HTML en fragmentos a medida que cada parte está lista. El servidor puede enviar inmediatamente el layout, la navegación y el contenido estático mientras las partes dinámicas se siguen procesando. Cuando cada sección dinámica termina, se inyecta en el documento HTML ya cargado en el navegador.

Esto tiene un impacto directo en las métricas de rendimiento web (Core Web Vitals): mejora el Time to First Byte (TTFB), el First Contentful Paint (FCP) y el Time to Interactive (TTI). En términos prácticos, el usuario percibe que la página carga mucho más rápido porque ve contenido casi al instante.

loading.tsx: Streaming a nivel de ruta

La forma más sencilla de implementar streaming en Next.js es con el archivo especial loading.tsx. Este archivo define una UI de respaldo que se muestra instantáneamente mientras el contenido de la página se carga en segundo plano.

// app/dashboard/loading.tsx
export default function CargandoDashboard() {
  return (
    <div className="animate-pulse">
      <div className="h-8 bg-gray-200 rounded w-1/4 mb-6"></div>
      <div className="grid grid-cols-3 gap-4 mb-8">
        <div className="h-24 bg-gray-200 rounded"></div>
        <div className="h-24 bg-gray-200 rounded"></div>
        <div className="h-24 bg-gray-200 rounded"></div>
      </div>
      <div className="h-64 bg-gray-200 rounded"></div>
    </div>
  )
}

Lo que pasa por debajo es que Next.js envuelve automáticamente el contenido de page.tsx en un <Suspense> usando loading.tsx como fallback. El resultado: el usuario ve el skeleton instantáneamente mientras los datos se cargan en el servidor. Sin configuración extra.

Suspense: Streaming a nivel de componente

Para un control más granular, puedes usar <Suspense> directamente. Y aquí es donde la cosa se pone realmente interesante. Esto te permite hacer streaming de secciones individuales de la página de forma totalmente independiente.

// app/dashboard/page.tsx
import { Suspense } from 'react'
import { ResumenVentas } from './ResumenVentas'
import { GraficoIngresos } from './GraficoIngresos'
import { PedidosRecientes } from './PedidosRecientes'
import { ActividadUsuarios } from './ActividadUsuarios'

export default function Dashboard() {
  return (
    <main>
      <h1>Dashboard</h1>

      {/* Sección rápida — probablemente se resuelve en 100ms */}
      <Suspense fallback={<SkeletonTarjetas />}>
        <ResumenVentas />
      </Suspense>

      <div className="grid grid-cols-2 gap-6">
        {/* Sección media — unos 500ms */}
        <Suspense fallback={<SkeletonGrafico />}>
          <GraficoIngresos />
        </Suspense>

        {/* Sección lenta — puede tardar 1-2 segundos */}
        <Suspense fallback={<SkeletonTabla />}>
          <PedidosRecientes />
        </Suspense>
      </div>

      {/* Sección secundaria */}
      <Suspense fallback={<SkeletonActividad />}>
        <ActividadUsuarios />
      </Suspense>
    </main>
  )
}

// Cada componente obtiene sus propios datos
async function ResumenVentas() {
  const datos = await obtenerResumenVentas() // Consulta rápida
  return (
    <div className="grid grid-cols-4 gap-4">
      <TarjetaEstadistica titulo="Ventas hoy" valor={datos.ventasHoy} />
      <TarjetaEstadistica titulo="Ingresos" valor={`$${datos.ingresos}`} />
      <TarjetaEstadistica titulo="Pedidos" valor={datos.totalPedidos} />
      <TarjetaEstadistica titulo="Clientes" valor={datos.clientesNuevos} />
    </div>
  )
}

Con este patrón, cada sección se renderiza de forma independiente. El ResumenVentas aparece primero (es una consulta rápida), luego el gráfico, después los pedidos recientes, y finalmente la actividad de usuarios. El usuario ve contenido progresivamente — no una pantalla en blanco seguida de todo de golpe.

Skeletons de carga que realmente funcionan

Un skeleton bien diseñado no es solo un rectángulo gris parpadeando. Debería imitar la estructura real del contenido que va a reemplazar. Esto reduce la carga cognitiva del usuario y, quizás más importante, evita esos molestos saltos de layout (CLS — Cumulative Layout Shift) que tanto penalizan en Core Web Vitals.

// components/skeletons/SkeletonTabla.tsx
export function SkeletonTabla({ filas = 5 }: { filas?: number }) {
  return (
    <div className="border rounded-lg overflow-hidden">
      {/* Cabecera de la tabla */}
      <div className="bg-gray-100 p-4 flex gap-4">
        <div className="h-4 bg-gray-300 rounded w-1/6"></div>
        <div className="h-4 bg-gray-300 rounded w-1/4"></div>
        <div className="h-4 bg-gray-300 rounded w-1/6"></div>
        <div className="h-4 bg-gray-300 rounded w-1/8"></div>
      </div>
      {/* Filas */}
      {Array.from({ length: filas }).map((_, i) => (
        <div key={i} className="p-4 flex gap-4 border-t animate-pulse">
          <div className="h-4 bg-gray-200 rounded w-1/6"></div>
          <div className="h-4 bg-gray-200 rounded w-1/4"></div>
          <div className="h-4 bg-gray-200 rounded w-1/6"></div>
          <div className="h-4 bg-gray-200 rounded w-1/8"></div>
        </div>
      ))}
    </div>
  )
}

El sistema de caché en Next.js 15: Rediseñado desde cero

Cambio clave: Sin caché por defecto

Si vienes de Next.js 14, presta atención porque este cambio es importante: en Next.js 15, las peticiones fetch ya no se cachean por defecto. En versiones anteriores, las peticiones usaban force-cache automáticamente, lo que causaba más de un dolor de cabeza y comportamientos inesperados. Ahora, el comportamiento por defecto es no-store — cada petición obtiene datos frescos.

// Next.js 14: se cacheaba por defecto (confuso)
const res = await fetch('https://api.ejemplo.com/datos')
// Equivalente a: fetch(url, { cache: 'force-cache' })

// Next.js 15: NO se cachea por defecto (predecible)
const res = await fetch('https://api.ejemplo.com/datos')
// Equivalente a: fetch(url, { cache: 'no-store' })

// Para cachear explícitamente en Next.js 15:
const res = await fetch('https://api.ejemplo.com/datos', {
  cache: 'force-cache'
})

Personalmente, creo que este cambio fue muy acertado. Ahora tú decides explícitamente qué datos se cachean y cuáles no, sin sorpresas.

Revalidación basada en tiempo (ISR)

La Regeneración Estática Incremental (ISR) te permite cachear respuestas de fetch y revalidarlas después de un periodo de tiempo determinado. Es perfecta para datos que cambian de vez en cuando pero no necesitan ser en tiempo real — piensa en un catálogo de productos, artículos de blog o configuraciones del sitio.

// Revalidar cada 60 segundos
const res = await fetch('https://api.ejemplo.com/productos', {
  next: { revalidate: 60 }
})

// También puedes configurar la revalidación a nivel de segmento
// app/productos/layout.tsx
export const revalidate = 60 // Todas las peticiones en este layout se revalidan cada 60s

Cuando un usuario visita la página después de que expire el tiempo de revalidación, Next.js sigue sirviendo la versión cacheada (stale) inmediatamente y, en segundo plano, regenera la página con datos frescos. La próxima visita verá la versión actualizada. Este patrón stale-while-revalidate garantiza que el usuario nunca espera — siempre ve contenido de inmediato.

Revalidación bajo demanda

A veces no quieres esperar un tiempo fijo para actualizar los datos. Imagina que un administrador publica un nuevo producto — obviamente quieres que aparezca ya, no dentro de 60 segundos. Para eso existe la revalidación bajo demanda con revalidatePath y revalidateTag.

// lib/api.ts — Etiquetar las peticiones
export async function obtenerProductos() {
  const res = await fetch('https://api.ejemplo.com/productos', {
    next: { tags: ['productos'] }
  })
  return res.json()
}

export async function obtenerProducto(id: string) {
  const res = await fetch(`https://api.ejemplo.com/productos/${id}`, {
    next: { tags: ['productos', `producto-${id}`] }
  })
  return res.json()
}
// app/actions/productos.ts
'use server'

import { revalidateTag, revalidatePath } from 'next/cache'

export async function crearProducto(formData: FormData) {
  await db.producto.create({
    data: {
      nombre: formData.get('nombre') as string,
      precio: Number(formData.get('precio')),
    }
  })

  // Opción 1: Revalidar por etiqueta (más preciso)
  revalidateTag('productos')

  // Opción 2: Revalidar por ruta
  revalidatePath('/productos')
}

export async function actualizarProducto(id: string, formData: FormData) {
  await db.producto.update({
    where: { id },
    data: {
      nombre: formData.get('nombre') as string,
      precio: Number(formData.get('precio')),
    }
  })

  // Revalidar solo este producto específico
  revalidateTag(`producto-${id}`)
  // Y también la lista general
  revalidateTag('productos')
}

La revalidación por etiquetas es especialmente poderosa porque te permite invalidar exactamente los datos que cambiaron. Por ejemplo, al actualizar un producto, revalidas solo ese producto y la lista general, sin tocar los datos de otros productos que ya están cacheados. Eficiente y limpio.

La directiva 'use cache': El futuro del cacheo

Next.js 15 introduce una nueva directiva experimental que, siendo honesto, tiene muy buena pinta: 'use cache'. Aunque todavía requiere el flag experimental dynamicIO, representa la dirección futura del sistema de caché. La idea es simple pero poderosa: puedes marcar funciones, componentes o archivos enteros como cacheables.

// next.config.ts — Habilitar la característica experimental
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    dynamicIO: true,
  },
}

export default nextConfig
// Con 'use cache' a nivel de componente
async function EstadisticasGenerales() {
  'use cache'

  const stats = await db.query('SELECT COUNT(*) FROM productos')
  return <div>Total de productos: {stats.count}</div>
}

// Con 'use cache' a nivel de función
async function obtenerCategorias() {
  'use cache'

  return db.categoria.findMany({
    orderBy: { nombre: 'asc' }
  })
}

La diferencia clave con el cacheo mediante fetch es que 'use cache' funciona con cualquier operación, no solo con peticiones HTTP. Consultas directas a base de datos, cálculos complejos, cualquier función asíncrona — todo se puede cachear. Y además, puedes configurar perfiles de caché para controlar la duración.

import { cacheLife } from 'next/cache'

async function obtenerProductosDestacados() {
  'use cache'
  cacheLife('hours') // Cachear durante horas

  return db.producto.findMany({
    where: { destacado: true },
    orderBy: { createdAt: 'desc' },
    take: 10
  })
}

Patrones avanzados: Combinando todas las piezas

Patrón 1: Dashboard con streaming progresivo

Este es, en mi opinión, el patrón más impactante en aplicaciones reales. Un dashboard típico tiene múltiples secciones con datos de diferentes fuentes, cada una con distinta latencia. En lugar de esperar a que todo esté listo, haces streaming de cada sección independientemente.

// app/dashboard/page.tsx
import { Suspense } from 'react'
import {
  SkeletonKPIs,
  SkeletonGrafico,
  SkeletonTabla,
  SkeletonNotificaciones
} from '@/components/skeletons'

export default function DashboardPage() {
  return (
    <div className="space-y-6">
      <h1 className="text-3xl font-bold">Panel de Control</h1>

      {/* KPIs — datos rápidos de Redis/caché */}
      <Suspense fallback={<SkeletonKPIs />}>
        <KPIsSection />
      </Suspense>

      <div className="grid grid-cols-12 gap-6">
        {/* Gráfico — consulta moderada a analytics */}
        <div className="col-span-8">
          <Suspense fallback={<SkeletonGrafico />}>
            <GraficoVentas />
          </Suspense>
        </div>

        {/* Notificaciones — lectura rápida */}
        <div className="col-span-4">
          <Suspense fallback={<SkeletonNotificaciones />}>
            <Notificaciones />
          </Suspense>
        </div>
      </div>

      {/* Tabla de pedidos — consulta pesada con joins */}
      <Suspense fallback={<SkeletonTabla filas={10} />}>
        <TablaPedidosRecientes />
      </Suspense>
    </div>
  )
}

// Cada sección es un Server Component asíncrono independiente
async function KPIsSection() {
  const kpis = await obtenerKPIs()
  return (
    <div className="grid grid-cols-4 gap-4">
      {kpis.map(kpi => (
        <div key={kpi.label} className="bg-white p-6 rounded-xl shadow">
          <p className="text-sm text-gray-500">{kpi.label}</p>
          <p className="text-2xl font-bold">{kpi.value}</p>
          <span className={kpi.trend > 0 ? 'text-green-500' : 'text-red-500'}>
            {kpi.trend > 0 ? '↑' : '↓'} {Math.abs(kpi.trend)}%
          </span>
        </div>
      ))}
    </div>
  )
}

async function TablaPedidosRecientes() {
  const pedidos = await db.pedido.findMany({
    include: { cliente: true, productos: true },
    orderBy: { createdAt: 'desc' },
    take: 10
  })

  return (
    <table className="w-full">
      <thead>
        <tr>
          <th>ID</th>
          <th>Cliente</th>
          <th>Productos</th>
          <th>Total</th>
          <th>Estado</th>
        </tr>
      </thead>
      <tbody>
        {pedidos.map(p => (
          <tr key={p.id}>
            <td>#{p.id.slice(0, 8)}</td>
            <td>{p.cliente.nombre}</td>
            <td>{p.productos.length} items</td>
            <td>${p.total}</td>
            <td>{p.estado}</td>
          </tr>
        ))}
      </tbody>
    </table>
  )
}

Patrón 2: Listado con filtros — híbrido servidor/cliente

Un patrón que te vas a encontrar constantemente: un listado de datos que viene del servidor (para SEO y carga inicial rápida) pero con filtros interactivos en el cliente. El truco está en usar los searchParams de la URL para mantener el estado de los filtros en el servidor.

// app/productos/page.tsx — Server Component
import { Suspense } from 'react'
import { FiltrosProductos } from '@/components/FiltrosProductos' // Client Component
import { ListaProductos } from './ListaProductos'

interface Props {
  searchParams: Promise<{
    categoria?: string
    precioMin?: string
    precioMax?: string
    orden?: string
    pagina?: string
  }>
}

export default async function PaginaProductos({ searchParams }: Props) {
  const filtros = await searchParams

  return (
    <div className="flex gap-8">
      <aside className="w-64">
        {/* Client Component para interactividad de filtros */}
        <FiltrosProductos filtrosActuales={filtros} />
      </aside>

      <main className="flex-1">
        {/* key fuerza el re-render cuando cambian los filtros */}
        <Suspense
          key={JSON.stringify(filtros)}
          fallback={<SkeletonProductos />}
        >
          <ListaProductos filtros={filtros} />
        </Suspense>
      </main>
    </div>
  )
}

// ListaProductos.tsx — Server Component asíncrono
async function ListaProductos({ filtros }: { filtros: Record<string, string | undefined> }) {
  const productos = await obtenerProductosFiltrados(filtros)

  if (productos.length === 0) {
    return <p>No se encontraron productos con estos filtros.</p>
  }

  return (
    <div className="grid grid-cols-3 gap-6">
      {productos.map(p => (
        <div key={p.id} className="border rounded-lg p-4">
          <img src={p.imagen} alt={p.nombre} className="w-full h-48 object-cover" />
          <h3>{p.nombre}</h3>
          <p>${p.precio}</p>
        </div>
      ))}
    </div>
  )
}
// components/FiltrosProductos.tsx — Client Component
'use client'

import { useRouter, useSearchParams } from 'next/navigation'
import { useTransition } from 'react'

export function FiltrosProductos({ filtrosActuales }: { filtrosActuales: Record<string, string | undefined> }) {
  const router = useRouter()
  const searchParams = useSearchParams()
  const [isPending, startTransition] = useTransition()

  function actualizarFiltro(clave: string, valor: string) {
    const params = new URLSearchParams(searchParams.toString())
    if (valor) {
      params.set(clave, valor)
    } else {
      params.delete(clave)
    }
    // Resetear a página 1 cuando cambian los filtros
    params.delete('pagina')

    startTransition(() => {
      router.push(`/productos?${params.toString()}`)
    })
  }

  return (
    <div className={isPending ? 'opacity-50' : ''}>
      <h2>Filtros</h2>
      <select
        value={filtrosActuales.categoria || ''}
        onChange={(e) => actualizarFiltro('categoria', e.target.value)}
      >
        <option value="">Todas las categorías</option>
        <option value="electronica">Electrónica</option>
        <option value="ropa">Ropa</option>
        <option value="hogar">Hogar</option>
      </select>

      <select
        value={filtrosActuales.orden || 'recientes'}
        onChange={(e) => actualizarFiltro('orden', e.target.value)}
      >
        <option value="recientes">Más recientes</option>
        <option value="precio-asc">Menor precio</option>
        <option value="precio-desc">Mayor precio</option>
      </select>
    </div>
  )
}

Fíjate en el truco con key={JSON.stringify(filtros)} en el <Suspense>. Cuando los filtros cambian, React desmonta y remonta el componente interno, activando el fallback y disparando una nueva obtención de datos. Y gracias a useTransition, el cambio de filtros no bloquea la interfaz — el usuario puede seguir interactuando mientras la nueva consulta se procesa en el servidor. Es una experiencia bastante fluida.

Patrón 3: Precarga de datos con preload pattern

Cuando sabes que un componente va a necesitar ciertos datos, puedes iniciar la carga de forma anticipada para que esté lista (o casi) cuando el componente se renderice.

// lib/datos.ts
import { cache } from 'react'

// Función cacheada para obtener datos
export const obtenerDetalleProducto = cache(async (id: string) => {
  return db.producto.findUnique({
    where: { id },
    include: {
      categoria: true,
      resenas: { take: 10, orderBy: { createdAt: 'desc' } },
      productosRelacionados: { take: 4 }
    }
  })
})

// Función de precarga — inicia la obtención sin esperar el resultado
export function precargarDetalleProducto(id: string) {
  void obtenerDetalleProducto(id)
}

// app/productos/[id]/page.tsx
import { obtenerDetalleProducto, precargarDetalleProducto } from '@/lib/datos'

export default async function PaginaProducto({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params

  // Iniciar la precarga inmediatamente
  precargarDetalleProducto(id)

  // Otros cálculos o lógica...
  const configuracion = await obtenerConfiguracion()

  // Para cuando llegamos aquí, los datos posiblemente ya están listos
  const producto = await obtenerDetalleProducto(id)

  return <div>{/* renderizar producto */}</div>
}

Errores comunes y cómo evitarlos

Error 1: Pasar funciones como props a Client Components

Este es un clásico. Los Server Components no pueden pasar funciones como props a los Client Components (excepto Server Actions). Las funciones simplemente no son serializables.

// ❌ Esto NO funciona
export default function Pagina() {
  function manejarClick() {
    console.log('click')
  }

  return <MiBoton onClick={manejarClick} /> // Error si MiBoton es 'use client'
}

// ✅ Solución: Usar Server Actions o mover la lógica al Client Component
// Opción A: Server Action
async function accionDelServidor() {
  'use server'
  // lógica del servidor
}

export default function Pagina() {
  return <MiFormulario action={accionDelServidor} />
}

// Opción B: La lógica va dentro del Client Component
// MiBoton.tsx
'use client'
export function MiBoton() {
  function manejarClick() {
    console.log('click')
  }
  return <button onClick={manejarClick}>Click</button>
}

Error 2: Usar hooks en Server Components

Los hooks de React (useState, useEffect, useContext, etc.) solo funcionan en Client Components. Intentar usarlos en un Server Component te dará un error inmediato. Parece obvio una vez que lo sabes, pero cuando estás empezando con RSC es fácil caer en esto.

// ❌ Error: useState no funciona en Server Components
export default async function Pagina() {
  const [estado, setEstado] = useState('') // Error!
  const datos = await obtenerDatos()
  return <div>{datos}</div>
}

// ✅ Solución: Extraer la parte interactiva a un Client Component
// Pagina (Server Component) obtiene los datos
// ComponenteInteractivo (Client Component) maneja el estado
export default async function Pagina() {
  const datos = await obtenerDatos()
  return <ComponenteInteractivo datosIniciales={datos} />
}

Error 3: No considerar los límites de serialización

Los datos que pases de un Server Component a un Client Component deben ser serializables. Esto excluye objetos Date, Map, Set, funciones y clases. Es una restricción que puede pillarte desprevenido si no estás atento.

// ❌ Date no se serializa correctamente
const datos = await db.query('SELECT * FROM eventos')
return <ClientComponent eventos={datos} />
// Si datos contiene campos Date, se convertirán a string

// ✅ Serializar explícitamente antes de pasar
const datos = await db.query('SELECT * FROM eventos')
const datosSerializados = datos.map(e => ({
  ...e,
  fecha: e.fecha.toISOString()
}))
return <ClientComponent eventos={datosSerializados} />

Error 4: Waterfall por anidación de componentes asincrónicos

Cuando un Server Component padre espera sus datos antes de renderizar componentes hijos que también necesitan datos, creas una cascada involuntaria. Este error es más sutil y a veces cuesta detectarlo.

// ❌ Cascada: el padre bloquea al hijo
export default async function Layout({ children }) {
  const config = await obtenerConfig() // 200ms
  return (
    <div>
      <Header config={config} />
      {children} {/* No se renderiza hasta que config esté lista */}
    </div>
  )
}

// ✅ Solución: Usar Suspense para desbloquear
export default function Layout({ children }) {
  return (
    <div>
      <Suspense fallback={<HeaderSkeleton />}>
        <HeaderAsync />
      </Suspense>
      {children} {/* Se renderiza en paralelo */}
    </div>
  )
}

async function HeaderAsync() {
  const config = await obtenerConfig()
  return <Header config={config} />
}

Rendimiento en producción: Lo que de verdad importa medir

Las métricas clave

Para verificar que tus patrones de obtención de datos están funcionando correctamente, estas son las métricas a las que deberías prestar atención:

  • TTFB (Time to First Byte): Con streaming, debería ser significativamente más bajo porque el servidor empieza a enviar HTML antes de que todo esté listo.
  • FCP (First Contentful Paint): Los skeletons y el contenido estático aparecen casi al instante.
  • CLS (Cumulative Layout Shift): Unos skeletons bien diseñados previenen esos saltos de layout cuando el contenido real se carga.
  • INP (Interaction to Next Paint): Al reducir el JavaScript enviado al cliente (gracias a los RSC), las interacciones se sienten más responsivas.

Estrategia de caché según el tipo de dato

No todos los datos deben tratarse igual. Aquí va una guía práctica para decidir tu estrategia de caché:

  • Datos estáticos (información de la empresa, políticas, FAQs): Usa force-cache sin revalidación o con revalidate: 86400 (24 horas). Estos casi nunca cambian.
  • Datos semi-estáticos (catálogo de productos, artículos de blog): ISR con revalidate: 60 a revalidate: 3600 y revalidación bajo demanda cuando haya actualizaciones.
  • Datos personalizados (perfil del usuario, carrito de compras): Sin caché (no-store). Siempre frescos, siempre.
  • Datos en tiempo real (notificaciones, chat, precios de acciones): Sin caché en el servidor, con suscripciones en el cliente vía WebSockets, SSE o polling.

Conclusión: Construyendo la arquitectura correcta

Los React Server Components, el streaming con Suspense y el sistema de caché de Next.js 15 no son herramientas aisladas — son piezas de un puzzle que, cuando encajan correctamente, crean aplicaciones que son rápidas de verdad. Y no solo rápidas según las métricas, sino rápidas en la percepción del usuario.

La clave está en aplicar el principio correcto en cada situación:

  1. Mantén la mayoría de tus componentes en el servidor. Solo marca como 'use client' lo que realmente necesita interactividad.
  2. Mueve la obtención de datos al componente que los necesita. No levantes datos innecesariamente al padre.
  3. Envuelve cada sección independiente en Suspense. Permite que cada parte de la página se cargue a su propio ritmo.
  4. Usa Promise.all para peticiones paralelas cuando un componente necesita múltiples fuentes de datos.
  5. Elige tu estrategia de caché según el tipo de dato. No cachees todo — y no dejes todo sin cachear tampoco.
  6. Diseña skeletons que imiten la estructura real del contenido para evitar saltos de layout.

Con estos fundamentos sólidos, estás preparado para construir aplicaciones Next.js que no solo son rápidas según las métricas, sino que se sienten rápidas para tus usuarios. Y al final del día, eso es lo que realmente cuenta.

Sobre el Autor Editorial Team

Our team of expert writers and editors.

Artículos Relacionados