SWR y el enfoque stale-while-revalidate

El nombre de SWR no es una marca: es un algoritmo, y viene de una cabecera HTTP. Stale-while-revalidate significa sirve la copia vieja ya mismo y, en paralelo, ve a comprobar si hay una nueva. Esa sola frase, nacida en 2010 para las caches de la web en el RFC 5861, se convirtió una década después en la filosofía de toda una familia de librerías de cliente: SWR, TanStack Query, RTK Query, Apollo. Esta lección mira el bosque en vez del árbol: qué idea comparten todas, en qué se diferencian, y cómo elegir sin caer en la trampa de creer que decides entre productos rivales cuando en realidad decides entre acentos de una misma idea.

Stale-while-revalidate: la idea antes que la librería

Antes de ser un hook de React, stale-while-revalidate fue una directiva de cache HTTP. Es una respuesta elegante a un dilema viejo: si sirves solo datos garantizados frescos, el usuario espera; si sirves datos cacheados, el usuario ve cosas viejas.

La tercera vía rompe el falso dilema: sirve lo viejo sin demora, el usuario ve algo al instante, y revalida en segundo plano, el dato se pone al día sin que nadie espere. Se paga con un parpadeo eventual de actualización a cambio de eliminar casi toda espera percibida.

Trasladar eso al cliente fue el salto que dio Vercel con SWR. Lo que en HTTP era una política del servidor de cache pasó a ser el comportamiento por defecto de un hook: al montar, te devuelve al instante lo que tenga en memoria aunque esté viejo, y dispara una revalidación silenciosa. La primera vez no hay nada que servir y esperas; a partir de ahí, casi nunca.

import useSWR from "swr";

const fetcher = (url: string) => fetch(url).then((r) => r.json());

function Perfil({ id }: { id: string }) {
  const { data, error, isLoading } = useSWR(`/api/usuario/${id}`, fetcher);

  if (isLoading) return <Spinner />;
  if (error) return <ErrorBox />;
  return <h1>{data.nombre}</h1>;
}

Fíjate en que la clave de cache aquí es la propia URL, una cadena, en vez de un array. Es la misma idea de identidad de la lección de useQuery, con menos ceremonia: SWR apuesta por lo mínimo.

flowchart LR
M[montar hook] -->|hay copia| SV[sirve stale al instante]
M -->|no hay copia| W[espera primera vez]
SV --> RV[revalida en segundo plano]
W --> RV
RV -->|dato nuevo| UP[actualiza la vista]
style SV fill:#fab387,color:#11111b
style UP fill:#a6e3a1,color:#11111b

El mínimo común de todas las caches

Si pones SWR, TanStack Query y RTK Query una al lado de otra, lo que comparten pesa más que lo que las separa. Las tres cachean por una clave, deduplican peticiones idénticas, revalidan al recuperar el foco y al reconectar, exponen estados de carga y error de primera clase, y reintentan ante fallos de red.

Las tres parten de la misma premisa del nivel: el estado de servidor es una cache, no un store. Aprendida una, las demás son dialectos del mismo idioma.

Hasta las escrituras comparten espíritu. En SWR no hay un invalidateQueries, pero sí un mutate que revalida una clave o le escribe un valor a mano: exactamente el mismo gesto de reconciliación de la lección anterior, con otra sintaxis.

import { useSWRConfig } from "swr";

function BotonRefrescar() {
  const { mutate } = useSWRConfig();
  // revalida la clave tras un cambio: el invalidateQueries de SWR
  return <button onClick={() => mutate("/api/usuario/1")}>refrescar</button>;
}

Cada uno de esos comportamientos —revalidar al foco, al reconectar, en intervalo— es configurable y se puede apagar. La diferencia entre librerías no está en si los tienen, sino en cuánto control fino te dan sobre ellos y cuánta ceremonia cuesta ese control.

Cómo elegir sin creer que eliges bando

La pregunta correcta no es cuál es mejor, sino qué restricciones tengo. Si tu app ya vive en Redux, RTK Query te evita una segunda librería y unas segundas DevTools. Si hablas GraphQL, Apollo o urql explotan el esquema con una cache normalizada por entidad que las de REST no pueden imitar sin esfuerzo.

Si haces sobre todo lecturas y quieres la superficie más pequeña, SWR. Y si tienes mutaciones serias, invalidación fina y quieres independencia del framework, TanStack Query, que es hoy la elección por defecto fuera de esos dos casos.

Ninguna de estas decisiones es fatal, y ese es el punto liberador: como todas comparten el modelo mental de la cache, migrar de una a otra es cambiar de dialecto, no de idioma. Eliges por restricciones presentes, no por miedo a equivocarte para siempre.

Y una advertencia de sensatez: si una pantalla hace una sola lectura que nunca se revalida ni se comparte, quizá no necesites ninguna de estas librerías. La cache brilla cuando hay repetición, concurrencia de lectores o escrituras que invalidan; para un dato que se pide una vez y se muestra, un fetch en el servidor del framework puede bastar. Elegir la herramienta incluye la opción de no meter ninguna.

La frontera que se mueve: los frameworks

Hay una capa más, y es la que más está moviendo la frontera en 2026: los frameworks. Los loaders de Next.js, React Router y TanStack Start hacen parte del trabajo en el servidor, entregando al cliente una cache ya rellena —el prefetch— que hidrata sin un segundo viaje ni un spinner.

En ese mundo la librería de cache de cliente no desaparece, pero se ocupa solo de la parte de verdad interactiva: listas que se refrescan, scroll infinito, mutaciones optimistas. El modelo mental no cambia, sigue siendo una cache de una verdad remota; solo se reparte entre servidor y cliente dónde vive esa cache.

Esa división —el servidor rellena, el cliente refina— explica por qué la discusión de 2026 ya no es tanto qué librería de cache uso, sino cuánto de mi estado de servidor puedo resolver antes de que llegue al navegador. La mejor petición sigue siendo la que no se hace.