El caché es uno de los problemas más difíciles en ingeniería, y Next.js 15 está cambiando la forma en que lo manejamos. Si trabajas con este framework, necesitas entender cómo controlar el caché en páginas, fetch y la nueva directiva use cache para optimizar el rendimiento de tu aplicación.

El equipo de Next.js dejó de tomar tantas decisiones automáticas y ahora te entrega el control. Eso significa más poder, pero también más responsabilidad sobre cuándo invalidar, cuándo revalidar y cuándo forzar contenido estático.

¿Cómo controlar el caché de una página en Next.js?

Dentro de cualquier page.tsx puedes exportar una constante reservada llamada dynamic que define el comportamiento de renderizado. Debe escribirse exactamente así para que Next.js la reconozca [2:00].

Las opciones disponibles son cuatro:

• force-dynamic: obliga a la página a ir siempre al servidor para validar la información. Útil cuando necesitas datos súper frescos.
• force-static: le dice a Next.js que prerenderice la página durante el build, sin importar que crea que no es estática. Esto es básicamente Static Site Generation.
• auto: el valor por defecto. Next.js hace su mejor intento por prerenderizar.
• error: intenta render estático y si encuentra cookies, params asíncronos u otro problema, falla el build explícitamente.

¿Qué hace force-static en Next.js? Convierte la página en estática durante el build. Si encuentra cookies, las trata como vacías; si hay errores, los omite y entrega HTML prerenderizado.

¿Cómo usar revalidate para refrescar datos?

La constante revalidate también es reservada y se exporta con un valor en segundos [4:30]. Si pones revalidate = 10, la respuesta se considera fresca durante 10 segundos. Pasado ese tiempo, el siguiente request va al servicio externo, trae la información y la vuelve a almacenar.

Los valores especiales son:

• Infinity o 0: nunca revalidar, equivalente a tratar la información como totalmente estática.
• false: ignora la directiva por completo.

¿Cómo funciona el caché en fetch dentro de Next.js?

Next.js parchó la API nativa de fetch para extenderla con funcionalidades propias. Y aquí viene lo interesante: la propiedad cache se comporta distinto según dónde la uses [6:30].

Si estás dentro de un effect en un componente cliente, las opciones force-cache y no-cache afectan el caché del navegador, porque la comunicación es entre el usuario y el navegador.

Si en cambio estás en un React Server Component haciendo await fetch(...), esas mismas opciones afectan el caché entre el servidor de Next.js y el servicio externo. El mismo código, dos comportamientos según el contexto.

¿Qué son los tags de caché en Next.js?

Dentro de fetch, Next.js agregó la propiedad personalizada next que incluye revalidate y tags. Los tags son identificadores que le pones a un request para invalidarlo después de forma manual [9:00].

Por ejemplo, si tu fetch a la API de bookmarks tiene el tag bookmarks, puedes invalidarlo desde un server action cuando agregues uno nuevo:

ts import { revalidateTag } from 'next/cache'

export async function addBookmark() { // crear bookmark revalidateTag('bookmarks') }

Cuando llamas revalidateTag, Next.js elimina esa entrada de su diccionario interno de caché. El próximo request va al servicio y vuelve a almacenarse fresco.

¿Qué hace revalidateTag? Borra del caché de Next.js la entrada asociada a ese identificador. La siguiente petición vuelve a ir al servicio y se almacena de nuevo.

Si has trabajado con SWR o React Query, esto te va a sonar familiar: funciona igual que las query keys, y muy probablemente el equipo de Next.js se inspiró en esas herramientas.

¿Qué es la directiva use cache en Next.js 15?

La comunidad reclamó que tener tantas opciones repartidas entre dynamic, revalidate y la propiedad next dentro de fetch era confuso. Por eso, en la versión 15 llega una nueva directiva: use cache [13:00].

Funciona como use client o use server. La pones al inicio de una página, un componente o una función, y Next.js se encarga del caché automáticamente. Hoy todavía es experimental y no viene activada por defecto, pero se espera que llegue como estable antes de la versión 16.

¿Cómo se configuran tags y expiración con use cache?

La nueva API trae dos funciones desde next/cache (aún marcadas como unstable):

• cacheTag: equivalente a los tags anteriores, te permite identificar el caché para invalidarlo manualmente.
• cacheLife: define la revalidación, pero ahora con unidades humanas como seconds, minutes, hours, days o weeks.

Si configuras cacheLife('minutes'), por defecto Next.js usa un stale de 300 segundos y un expire configurable. Estos valores se ajustan desde la configuración global. Es el mismo patrón stale-while-revalidate del protocolo HTTP, llevado a la API de Next.js.

ts 'use cache' import { cacheTag, cacheLife } from 'next/cache'

cacheTag('bookmarks') cacheLife('minutes')

¿Cuándo deberías personalizar el caché de tu aplicación?

La verdad incómoda es que no existe una fórmula mágica. La invalidación de caché depende de cómo funciona tu negocio, qué páginas visitan más tus usuarios y dónde está el estrés en tus servidores.

Para aplicaciones con menos de un par de cientos de visitas al día, las opciones por defecto de Next.js son más que suficientes. Pero si estás en ese porcentaje donde el rendimiento marca la diferencia, mide todo: flujos, páginas populares y carga del servidor. Solo con esos datos podrás decidir si necesitas force-static, tags personalizados o cacheLife ajustado.

¿Ya probaste use cache en algún proyecto? Cuéntame en los comentarios cómo te fue y qué estrategia de invalidación estás usando.