Next.js App Router caching: revalidate, dynamic y no-store sin folklore
Cometí el error clásico: agregué export const dynamic = 'force-dynamic' a una ruta que tardaba 800ms en responder y me quedé conforme porque "al menos era fresca". No medí nada. No entendí qué dato necesitaba esa frescura. Solo apliqué el flag que resolvía el síntoma visible — datos desactualizados — sin preguntarme si el costo valía la pena. Meses después, revisando la arquitectura, me di cuenta de que el 70% de esas rutas servían datos que cambiaban una vez por hora. Las estaba regenerando en cada request sin ninguna razón técnica válida.
No lo cuento para mortificarme. Lo cuento porque ese error es casi universal en equipos que están aprendiendo App Router.
Mi tesis: el problema no es memorizar las opciones de cache. Es decidir la frescura que necesita cada dato antes de tocar una sola configuración. Los flags son consecuencia de esa decisión, no el punto de partida.
Qué dice la documentación oficial — y qué no dice
