SWR Core Concepts: Stale-While-Revalidate

SWR stands for Stale-While-Revalidate, an HTTP cache strategy defined in RFC 5861. The strategy is: serve stale (cached) data immediately to the user, then revalidate in the background, and update the UI when fresh data arrives.

This approach prioritizes perceived performance: users see data instantly rather than waiting for a network round-trip.

With traditional loading patterns, users see a spinner on every navigation. With SWR, they see the last known data immediately and the UI updates silently in the background if the data has changed.

This makes applications feel significantly faster and reduces the cognitive disruption of loading states.

SWR automatically revalidates data when: the browser window regains focus (user switches tabs and returns), the network connection is restored after going offline, explicit mutate() is called, or a configurable refreshInterval timer fires.

These automatic triggers keep data fresh without the developer manually managing refetch logic.

A SWR key can be in one of several states: loading (no cached data, first fetch in progress), revalidating (has cached data, background refresh in progress), error (request failed), or success (fresh data available).

Understanding these states helps you build accurate loading skeletons and error UIs.

SWR maintains a global in-memory cache keyed by the request key (typically a URL string). Any component that requests the same key gets the same cached value and participates in the same revalidation cycle.

This automatic deduplication means 10 components can each call useSWR with the same key and only one network request is made.

SWR separates the cache management logic from the actual data fetching. You provide a fetcher function: an async function that accepts the key and returns the data.

The fetcher is swappable: use fetch, axios, graphql-request, or any async data source. SWR handles caching and revalidation regardless of how the fetcher works.

Wrap your app in SWRConfig with a value prop containing a fetcher function: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Every useSWR call that omits a fetcher argument uses this global default.

This centralizes API configuration (base URL, auth headers) in one place without repeating it in every hook call.

The classic pattern uses useEffect + useState to manage loading, data, and error states manually. SWR replaces all of that with a single hook call that handles caching, deduplication, background refresh, and error retry automatically.

The code reduction is significant: a typical data-fetching component shrinks from 20+ lines to 3 lines.

The key uniquely identifies a request. Use the URL string for simple cases. For parameterized requests, use an array key: [url, params] where params is a stable object or string. Null disables the request.

A good key design ensures that related requests share cache entries and that unrelated requests do not collide.

SWR is smart about revalidation: the dedupingInterval (default 2 seconds) prevents multiple revalidations from firing simultaneously if many components mount at once. Only one request goes out per key within the dedup window.

This prevents thundering-herd problems common in large component trees where many components fetch the same data.

SWR is built by Vercel, the company behind Next.js, and the integration is seamless. getServerSideProps or getStaticProps can prefetch data, and SWR hydrates from that prefetched value on the client.

This gives you server-rendered initial HTML with automatic client-side revalidation on mount, combining the best of SSR and SWR.

Which of the following does NOT trigger SWR revalidation by default?

SWR implements the Stale-While-Revalidate strategy: serve cached data immediately, revalidate in background, update UI when fresh. It triggers revalidation on focus, reconnect, mutate, and polling. The global cache deduplicates requests across components, and the fetcher function is fully swappable.

This model dramatically simplifies data fetching code while delivering faster perceived performance.