SWR – vollständiger Leitfaden: Cache-Strategien und optimistische Updates in der Praxis

Sie starren auf den vertrauten Loading-Spinner – zum N-ten Mal die Benutzerliste neu geladen. Tab wechseln: Loading. Von einer anderen Seite zurück: Loading. Sogar nach einem kurzen Telefonat, bei dem der Browser den Fokus verliert, ist beim Zurückkommen wieder Loading. Am frustrierendsten: Die Daten wurden vor einer Sekunde erst geladen.

In React-Projekten schreibt man für jeden Datenabruf erneut useState, useEffect plus Loading- und Error-Handling. Mindestens 20 Zeilen Code. Noch ärgerlicher: Mehrere Komponenten brauchen dieselben Daten – entweder State nach oben heben (mehr Code) oder jede Komponente fetcht selbst (verschwendete Netzwerkressourcen).

Als ich SWR entdeckte, war das Gefühl vergleichbar mit dem ersten Mal Git statt manuellem Ordner-Kopieren. Drei Zeilen Code, 80 % der Probleme gelöst. Keine Übertreibung.

Heute geht es um SWR – die React-Datenabruf-Bibliothek von Vercel. Das Kernprinzip heißt stale-while-revalidate (veraltet – neu validieren). Klingt technisch? Die Idee ist simpel: Zuerst sehen Sie das gecachte „alte Foto“ (schnell), im Hintergrund wird heimlich ein neues gemacht (aktuell), und wenn es fertig ist, wird es lautlos ausgetauscht (nahtlos).

Warum SWR? Drei Schmerzpunkte klassischer Datenabruf

Schauen wir uns den klassischen React-Datenabruf an. Angenommen, Sie wollen eine Benutzerliste anzeigen:

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    fetch('/api/users')
      .then(res => res.json())
      .then(data => {
        setUsers(data);
        setLoading(false);
      })
      .catch(err => {
        setError(err);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return <ul>{users.map(user => <li key={user.id}>{user.name}</li>)}</ul>;
}

24 Zeilen Code – nur für eine Liste. Noch akzeptabel? Betrachten Sie diese Szenarien:

Schmerzpunkt 1: Wiederholter Boilerplate-Code

Jede datenabhängige Komponente braucht dasselbe Muster. Benutzerliste, Artikelliste, Kommentarliste – drei States, viele if-Abfragen, Error-Handling … Copy-Paste fühlt sich peinlich an. Einmal habe ich gezählt: In einem mittelgroßen Projekt machten solche Snippets etwa 20 % des Codes aus.

Schmerzpunkt 2: Cache? Fehlanzeige

Am bittersten: kein Cache. Vom Start zur Detailseite und zurück zur Startseite – wieder langes Loading. Die Daten waren vor 30 Sekunden da, trotzdem ein neuer Request. Nutzer sagen „Die Seite ist langsam“ – oft nicht, weil die API langsam ist, sondern weil gar nicht gecacht wird.

Man kann globales State-Management bauen – Redux, Zustand, Store, Actions, Reducer … Eine Funktion, die in drei Minuten fertig wäre, wird zu 30 Minuten Architektur.

Schmerzpunkt 3: Datensynchronisation über Komponenten

Mehrere Komponenten, dieselben Daten: Ungelesene Nachrichten in der Kopfzeile, in der Sidebar und auf der Nachrichtenliste. State bis ganz nach oben? Dann Props durch viele Ebenen. Context? Bei jeder Aktualisierung re-rendert der ganze Baum.

Einmal habe ich zwei Tage an einer simplen Benachrichtigungsfunktion verbracht – am Ende nur setState und useEffect im Diff. Das war mir selbst peinlich.

Deshalb ist SWR populär. Kein weiteres Rad – es löst echte Probleme. Derselbe Code mit SWR:

import useSWR from 'swr';

function UserList() {
  const { data, error, isLoading } = useSWR('/api/users', fetcher);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;

  return <ul>{data.map(user => <li key={user.id}>{user.name}</li>)}</ul>;
}

9 Zeilen. Fertig. Mit Cache, automatischer Revalidierung und geteiltem State über Komponenten. Der fetcher ist Ihre fetch-Funktion – meist einmal global definiert:

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

Der Unterschied spricht für sich.

Kernkonzept: Stale-While-Revalidate

Der Name SWR kommt aus der HTTP-Cache-Strategie in RFC 5861. Keine Angst vor „RFC“ – die Idee ist leicht.

Analogie mit Fotos: Sie wollen ein aktuelles Bild eines Freundes. Klassisch: anrufen, warten, bis er eins schickt. Mit SWR: zuerst das alte Foto vom letzten Treffen (vielleicht von letzter Woche), parallel Nachricht schicken „Schick mir ein neues“, bei Ankunft austauschen.

Der Unterschied: Sie warten nicht leer. Sofort Inhalt (evtl. etwas veraltet), parallel Sicherstellung der Aktualität. Das ist stale-while-revalidate – Veraltetes zeigen, gleichzeitig neu validieren.

Ablauf bei SWR:

1. Schritt 1: Cache sofort zurückgeben (stale)

   • Beim Mount prüft SWR den lokalen Cache
   • Cache vorhanden? Sofort zurück, Seite springt auf
   • Kein Cache? undefined, Loading anzeigen

2. Schritt 2: Request im Hintergrund (revalidate)

   • Mit oder ohne Cache: API-Request
   • Nutzer merkt es kaum, Inhalt ist schon da

3. Schritt 3: Daten aktualisieren

   • Nach der Antwort: Cache und UI leise aktualisieren
   • Bei Änderung: React re-rendert
   • Unverändert: nichts passiert

Beispiel – Aktienkurs-Anzeige:

function StockPrice({ symbol }) {
  const { data, error } = useSWR(`/api/stock/${symbol}`, fetcher);

  return (
    <div>
      <h2>{symbol}</h2>
      <p>Preis: {data ? `$${data.price}` : 'Loading...'}</p>
      <span>Aktualisiert: {data?.updatedAt}</span>
    </div>
  );
}

Beim ersten Öffnen ist data undefined – „Loading…“. Nach einer Sekunde der Preis.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Tab wechseln, 10 Minuten E-Mails, zurück – Preis sofort aus dem Cache, kein Loading-Flackern. Parallel startet SWR einen neuen Request. Kurs geändert → UI aktualisiert; gleich → bleibt.

Drei Standard-Zeitpunkte für automatische Revalidierung:

1. Komponente erneut gemountet (revalidateOnMount): Reload oder Route zurück
2. Fenster wieder im Fokus (revalidateOnFocus): Tab zurück zum Browser
3. Netzwerk wieder da (revalidateOnReconnect): nach Offline

Sie müssen nichts extra bauen – SWR hält Daten frisch. Halbe Stunde E-Mail, zurück zur App → automatischer Refresh. U-Bahn offline, wieder 4G → automatisches Nachladen.

Als ich das zum ersten Mal als Standard sah, war ich überrascht. Früher: entweder veraltete Daten oder manuell visibilitychange, online – viel Code. Jetzt: gratis.

Das Key-Konzept:

Der erste Parameter von useSWR ist ein String wie '/api/users' – der Key, zentral wichtig.

// Zwei Komponenten, gleicher Key
function Header() {
  const { data } = useSWR('/api/user', fetcher);
  return <div>Willkommen, {data?.name}</div>;
}

function Profile() {
  const { data } = useSWR('/api/user', fetcher);
  return <div>Profil: {data?.email}</div>;
}

Gleicher Key → geteilte Daten. Ein API-Call, beide Komponenten synchron.

Kein State-Management, kein Context – nur der Key.

Cache-Strategien im Detail

SWR cached und revalidiert automatisch – in der Praxis brauchen unterschiedliche Daten unterschiedliche „Frische“. Avatar ändert sich selten, Aktienkurse sekündlich. Dafür passen Sie die Strategie an.

Standard ist smart, aber nicht universal

SWR ist standardmäßig recht aggressiv:

• Revalidierung bei jedem Mount
• Revalidierung bei Fokus
• Revalidierung bei Reconnect

Perfekt für Echtzeit (Chat, Online-Status). Für stabile Daten (Artikelliste, Profil) oft zu viel – Tab hin und her, jedes Mal Request? Unnötig.

Wichtige Optionen

const { data } = useSWR('/api/articles', fetcher, {
  revalidateOnFocus: false,      // kein Request bei Fokus
  revalidateOnReconnect: false,  // kein Request bei Reconnect
  refreshInterval: 0,            // Polling in ms, 0 = aus
  dedupingInterval: 2000,        // gleiche Requests innerhalb 2 s deduplizieren
});

Die Namen sind selbsterklärend.

Szenario 1: Echtzeit (Aktien, Online-Zähler)

const { data } = useSWR('/api/stock/AAPL', fetcher, {
  refreshInterval: 1000,  // jede Sekunde
  revalidateOnFocus: true // beim Zurückkommen sofort aktualisieren
});

Maximale Aktualität – Polling ist simpel (WebSocket wäre besser, anderes Thema).

Szenario 2: Relativ stabil (Profil, Artikelliste)

const { data } = useSWR('/api/profile', fetcher, {
  revalidateOnFocus: false,
  refreshInterval: 0,
  dedupingInterval: 60000,      // 1 Minute keine Duplikate
});

Profil ändert sich selten – Tab-Wechsel ohne Refresh. Nach manueller Änderung können Sie mutate nutzen (später).

Szenario 3: Fast statisch (Docs, Hilfe)

const { data } = useSWR('/api/docs', fetcher, {
  revalidateOnFocus: false,
  revalidateOnReconnect: false,
  revalidateOnMount: false,
  revalidateIfStale: false,
});

Monatelang unverändert – nach erstem Load praktisch dauerhafter Cache bis manueller Reload.

Global vs. lokal

Einheitliche App-Strategie mit SWRConfig:

import { SWRConfig } from 'swr';

function App() {
  return (
    <SWRConfig value={{
      refreshInterval: 3000,
      fetcher: (url) => fetch(url).then(r => r.json()),
      revalidateOnFocus: false,
    }}>
      <Dashboard />
    </SWRConfig>
  );
}

Alle Kind-useSWR erben die Werte; einzelne Hooks können überschreiben:

// revalidateOnFocus: true überschreibt globales false
const { data } = useSWR('/api/realtime', fetcher, {
  revalidateOnFocus: true
});

Request-Deduplizierung

Drei Komponenten mounten gleichzeitig mit useSWR('/api/user') – SWR sendet einen Request, alle teilen das Ergebnis.

Standard-Fenster: 2 Sekunden (dedupingInterval: 2000). Bei schnellem Tab-Wechsel den Wert erhöhen.

Das hat mir API-Kontingent gerettet: schnelles Scrollen löste kurz hintereinander dieselben Requests aus – mit Deduplizierung sofort ruhiger. Symptom behoben, Ursache im Code trotzdem nachziehen.

Bedingtes Fetching

Erst A, dann B – Key null pausiert:

const { data: user } = useSWR('/api/user', fetcher);

const { data: projects } = useSWR(
  user ? `/api/projects?userId=${user.id}` : null,
  fetcher
);

Ohne user kein Request; sobald user da ist, startet projects. Serielle Abhängigkeit, minimaler Aufwand.

Optimistische Updates: bessere UX

Cache macht es schnell – bei Nutzeraktionen bleibt eine Frage: „Gefällt mir“ erst nach API-Antwort, oder sofort?

Optimistische Updates (Optimistic Update): Erfolg annehmen, UI sofort ändern, bei Fehler zurückrollen. Klingt riskant – die meisten Aktionen gelingen, der UX-Gewinn ist sichtbar.

Klassisch vs. optimistisch

Klassisch:

1. Klick auf „Gefällt mir“
2. Loading oder disabled
3. 500 ms–2 s warten
4. Herz erscheint
5. Nutzer: „Langsam …“

Optimistisch:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

1. Klick
2. Herz sofort
3. Request im Hintergrund
4. Meist Erfolg – nichts weiter
5. Selten Fehler – Herz grau, Hinweis

Latenz gefühlt 0 ms.

mutate: Cache manuell steuern

import { mutate } from 'swr';

// Revalidierung für /api/user auslösen
mutate('/api/user');

Für Optimismus brauchen Sie mehr – Todo-Beispiel:

import useSWR, { mutate } from 'swr';

function TodoList() {
  const { data: todos } = useSWR('/api/todos', fetcher);

  const addTodo = async (text) => {
    const newTodo = { id: Date.now(), text, completed: false };

    mutate(
      '/api/todos',
      async (currentTodos) => {
        const optimisticData = [...currentTodos, newTodo];

        const savedTodo = await fetch('/api/todos', {
          method: 'POST',
          body: JSON.stringify(newTodo)
        }).then(r => r.json());

        return [...currentTodos, savedTodo];
      },
      {
        optimisticData: [...todos, newTodo],
        rollbackOnError: true,
        revalidate: false,
      }
    );
  };

  return (
    <div>
      {todos?.map(todo => <div key={todo.id}>{todo.text}</div>)}
      <button onClick={() => addTodo('New task')}>Add</button>
    </div>
  );
}

Ablauf: Klick → sofort neues Todo (optimisticData) → POST → bei Erfolg Server-Daten (id, Timestamps) → bei Fehler Rollback (rollbackOnError: true).

Vier zentrale Optionen

1. optimisticData – sofort anzeigen

optimisticData: [...todos, newTodo]

Oder als Funktion:

optimisticData: (currentTodos) => [...currentTodos, newTodo]

2. populateCache – Rückgabewert in Cache?

Standard true. Server liefert oft id, createdAt – dann sinnvoll. Unvollständige API-Antwort → false.

3. revalidate – nochmal fetchen?

Meist false – Sie haben manuell aktualisiert. Nur wenn Sie SWR zur Bestätigung brauchen.

4. rollbackOnError – bei Fehler zurück?

Wichtig: Fehler in mutate → automatisch vorheriger Stand. Like-Herz leuchtet, API scheitert → Herz wieder aus.

Feiner steuern:

rollbackOnError: (error) => {
  return error.name !== 'AbortError';
}

Praxis: Todo löschen

const deleteTodo = async (id) => {
  mutate(
    '/api/todos',
    async (currentTodos) => {
      const optimistic = currentTodos.filter(t => t.id !== id);

      await fetch(`/api/todos/${id}`, { method: 'DELETE' });

      return optimistic;
    },
    {
      optimisticData: todos.filter(t => t.id !== id),
      rollbackOnError: true,
    }
  );
};

Klick → Todo weg. Server-Fehler → Todo zurück, Fehlermeldung.

useSWRMutation – sauberer

Ab SWR 2.0:

import useSWRMutation from 'swr/mutation';

async function updateUser(url, { arg }) {
  await fetch(url, {
    method: 'POST',
    body: JSON.stringify(arg)
  });
}

function Profile() {
  const { trigger, isMutating } = useSWRMutation('/api/user', updateUser);

  return (
    <button
      onClick={() => trigger({ name: 'John' })}
      disabled={isMutating}
    >
      Update Name
    </button>
  );
}

trigger startet die Mutation, isMutating ersetzt manuelles Loading.

Wann optimistisch?

✅ Geeignet:

• Like/Favorit (selten Fehler, reversibel)
• Liste hinzufügen/löschen
• Toggle (Benachrichtigungen)
• Entwurf speichern

❌ Ungeeignet:

• Zahlung (Bestätigung abwarten)
• Konto löschen (irreversibel)
• Passwort, Berechtigungen
• Server-generierte Ergebnisse (Report)

Regel: niedrige Fehlerrate, reversibel, UX zuerst → optimistisch. Kritisch oder irreversibel → auf Server warten.

Ein Fehler aus eigener Erfahrung: Kommentare mit Optimismus – langsames Netz, mehrfach „Senden“ geklickt, dutzende identische Einträge in der UI. Lösung: isMutating, Button während Request disabled. Optimismus ja – Randfälle mitdenken.

SWR vs. React Query: Auswahl

Beide sind stark und 2025 aktiv gepflegt. Falsche Wahl ist selten fatal – passende Wahl spart Aufwand.

Größe: SWR leichter

• SWR: 5,3 KB (gzip)
• React Query (TanStack Query): 16,2 KB

Bei strengem Bundle-Budget (Landingpage, Mobile H5) zählt SWR. In vielen Apps sind ~10 KB vernachlässigbar.

Komplexität: SWR einfacher

Kern-API: ein useSWR. In Minuten verstanden.

React Query: QueryClient, useQuery, useMutation, queryKeys, cache time vs. stale time – steilere Lernkurve, lange Docs.

Jüngere Teams → oft SWR.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Funktion: React Query umfangreicher

1. Offizielle DevTools – Queries, Cache, Refetch sichtbar. SWR ohne offizielle DevTools.
2. Feinere Cache-Kontrolle – cache time und stale time getrennt; SWR: Cache + Revalidate.
3. Pagination/Infinite – useInfiniteQuery vs. useSWRInfinite, React Query etwas ausgereifter.
4. Mutationen – useMutation mit globalem State, Retry, Callbacks; useSWRMutation erst ab 2.0, schlanker.

Community

TanStack Query: größere Community, mehr Stack-Overflow-Antworten.

SWR: Vercel, enge Next.js-Integration – bei Next.js oft die naheliegende Wahl.

Empfehlung

Eigene Praxis: MVP → SWR. Wächst die Komplexität → ggf. React Query. Meist reicht SWR.

Migration ist überschaubar – Cache, Revalidate, Mutation sind verwandt. Nicht zu lange grübeln.

Next.js und SWR

Beide von Vercel – Integration fällt leicht.

App Router

Server Components sind Standard; SWR ist Client-seitig:

'use client';

import useSWR from 'swr';

export default function Profile() {
  const { data } = useSWR('/api/user', fetcher);
  return <div>{data?.name}</div>;
}

'use client' nicht vergessen.

SSR + Fallback

Initialdaten aus getStaticProps / getServerSideProps als Fallback:

// pages/profile.js
export async function getStaticProps() {
  const user = await fetch('https://api.example.com/user').then(r => r.json());

  return {
    props: {
      fallback: {
        '/api/user': user
      }
    },
    revalidate: 60
  }
}

export default function Profile({ fallback }) {
  return (
    <SWRConfig value={{ fallback }}>
      <UserProfile />
    </SWRConfig>
  );
}

function UserProfile() {
  const { data } = useSWR('/api/user', fetcher);
  return <div>{data.name}</div>;
}

Erster Besuch: voller Inhalt (SEO), danach SWR-Revalidierung im Client.

Prefetch

import { mutate } from 'swr';

function ArticleLink({ id }) {
  const prefetch = () => {
    mutate(`/api/article/${id}`, fetch(`/api/article/${id}`).then(r => r.json()));
  };

  return (
    <Link href={`/article/${id}`} onMouseEnter={prefetch}>
      Read more
    </Link>
  );
}

Hover lädt schon – Klick oft aus dem Cache.

Infinite Scroll: useSWRInfinite

import useSWRInfinite from 'swr/infinite';

function ArticleList() {
  const getKey = (pageIndex, previousPageData) => {
    if (previousPageData && !previousPageData.length) return null;
    return `/api/articles?page=${pageIndex + 1}&limit=10`;
  };

  const { data, size, setSize, isLoading } = useSWRInfinite(getKey, fetcher);

  const articles = data ? data.flat() : [];
  const isLoadingMore = isLoading || (size > 0 && data && typeof data[size - 1] === 'undefined');

  return (
    <div>
      {articles.map(article => (
        <div key={article.id}>{article.title}</div>
      ))}
      <button
        onClick={() => setSize(size + 1)}
        disabled={isLoadingMore}
      >
        {isLoadingMore ? 'Loading...' : 'Load More'}
      </button>
    </div>
  );
}

setSize(size + 1) lädt die nächste Seite; jede Seite bleibt gecacht.

Performance in Next.js

1. Revalidate-Frequenz

   • Statisch: Auto-Revalidate aus
   • Nutzerdaten: Fokus-Revalidate
   • Echtzeit: refreshInterval

2. API-Route-Cache

   • Cache-Control auf API-Routen
   • SWR respektiert HTTP-Cache

3. Keine Request-Wasserfall

   • Abhängige Daten ggf. serverseitig bündeln
   • oder paralleles Fetching in Next.js

Praxis: Blog-Liste mit SWR + ISR – statisches HTML sofort, im Hintergrund neue Artikel. Schnell und SEO-tauglich.

Statische Performance plus dynamische Frische – das ist Next.js + SWR.

Fazit

SWR adressiert drei Probleme: Boilerplate, fehlender Cache, Sync über Komponenten. stale-while-revalidate ist schnell und aktuell. Revalidierung, Deduplizierung, Optimismus decken die meisten Fälle ab.

Best Practices:

1. Cache je nach Datentyp – Echtzeit pollend, Stabiles länger cachen
2. Optimismus bei reversiblen Aktionen – niedrige Fehlerrate voraussetzen
3. Keys zum Teilen – kein Redux nur für geteilte API-Daten
4. Next.js: Fallback für SSR
5. Einfach → SWR, komplex → React Query – kein Over-Engineering

SWR ist kein Wundermittel – schlechte APIs und Architektur ersetzt es nicht. Bei soliden APIs wird Frontend-Code deutlich schlanker.

Im nächsten Projekt ausprobieren – Sie werden den Unterschied merken.