WPGraphQL vs. REST API: ehrliche Entscheidungshilfe

Zwei Punkte verdienen Vertiefung, weil sie in der Praxis am häufigsten falsch eingeschätzt werden: der Daten-Vorteil von GraphQL und die Caching-Realität von REST.

Ist WPGraphQL wirklich schneller als REST?

Nicht pauschal — aber bei verschachtelten Daten spürbar effizienter. WPGraphQL bündelt mehrere REST-Aufrufe in einen Request und liefert nur die angeforderten Felder; mehrere unabhängige Messungen beziffern die Payload-Reduktion durch wegfallendes Over-Fetching übereinstimmend auf 30 bis 50 % — sowohl in einer vergleichenden akademischen Analyse (IJAMSR, 2025) als auch in Praxis-Benchmarks aus dem CMS-Umfeld (Contentstack, 2026). Geschwindigkeit ist hier ein Nebeneffekt von Präzision, nicht von der Technologie an sich.

Der oft genannte GraphQL-Vorteil lautet: ein Request, exakt die benötigten Felder. Das ist kein Marketing, sondern ein struktureller Unterschied — und er wirkt sich genau dort aus, wo ein Frontend viele zusammenhängende Datentypen anzeigt.

Wichtig ist, dabei zwei Probleme auseinanderzuhalten, die oft in einen Topf geworfen werden. Over-Fetching heisst: zu viele Felder pro Antwort — der Endpunkt liefert auch Daten, die die Seite gar nicht anzeigt. Zu viele Round-Trips (verwandt mit dem N+1-Problem) heisst: zu viele einzelne Requests, um eine Ansicht zusammenzubauen. GraphQL adressiert beide Achsen, aber mit unterschiedlichen Mechanismen — Feldauswahl gegen das eine, Verschachtelung in einem Aufruf gegen das andere.

Ein Beispiel macht es konkret. Eine Beitrags-Detailseite braucht den Beitragstext, den Autorennamen samt Avatar, die zugeordneten Kategorien, drei verwandte Beiträge und das Beitragsbild in zwei Auflösungen. Über die REST API bedeutet das im Standardfall mehrere Aufrufe: einen für den Beitrag, einen für den Autor, gegebenenfalls weitere für Medien und verwandte Inhalte — das ist die Round-Trip-Achse. Und jeder dieser Aufrufe liefert zusätzlich die volle Standard-Antwort des Endpunkts, also Felder, die diese Seite nie rendert — das ist die Over-Fetching-Achse. In einem datenreichen Magazin-Frontend kann eine einzige GraphQL-Abfrage so durchaus ein halbes Dutzend separater REST-Aufrufe ersetzen; das ist ein typisches Muster aus unseren Projekten, keine exakte Messung.

Über WPGraphQL beschreibt das Frontend in einer einzigen Abfrage genau diese Struktur — Beitrag mit Autor, Kategorien, verwandten Beiträgen und exakt den zwei Bildgrössen. Der Unterschied wird im Code direkt sichtbar:

# WPGraphQL: ein Request, exakt die Felder der Detailseite
query DetailSeite($slug: ID!) {
  post(id: $slug, idType: SLUG) {
    title
    content
    author { node { name avatar { url } } }
    categories { nodes { name slug } }
    featuredImage { node { sourceUrl(size: LARGE) } }
  }
}

# REST API: dieselbe Ansicht, mehrere GET-Aufrufe + Over-Fetching
GET /wp-json/wp/v2/posts?slug=mein-beitrag        # liefert ~25 Standardfelder
GET /wp-json/wp/v2/users/{author_id}              # zweiter Round-Trip
GET /wp-json/wp/v2/media/{featured_id}            # dritter Round-Trip
# (_embed bündelt einiges, _fields beschneidet die Felder — manuell pro Endpunkt)

Das kollabiert die Round-Trips auf einen einzigen Aufruf (gegen das Zuviel an Requests) und liefert nur die angeforderten Felder (gegen das Zuviel an Daten). Bei einer einfachen Inhaltsseite fällt beides kaum ins Gewicht. Bei einem Frontend mit verschachtelten, datenreichen Ansichten trägt es.

GraphQLs Vorteil ist nicht Geschwindigkeit an sich — es ist Präzision. Das Frontend bestimmt die Antwortform, nicht der Server.

Die REST API kann gegensteuern: Der Parameter _fields reduziert die Antwort auf ausgewählte Felder, und _embed zieht verknüpfte Ressourcen in eine Antwort. Damit lässt sich Over-Fetching dämpfen. Was REST aber nicht kann, ist eine beliebig tiefe, frei kombinierbare Verschachtelung über mehrere Datentypen in einem einzigen, vom Frontend definierten Aufruf. Genau das ist GraphQLs Domäne.

Warum REST beim Caching punktet

Hier dreht sich der Vorteil um. Die REST API arbeitet mit HTTP-GET — und GET-Antworten sind das natürliche Futter für jede Caching-Schicht, vom Browser über den CDN-Rand bis zum Reverse-Proxy. Eine REST-GET-Antwort lässt sich am CDN zwischenspeichern und für tausende Besucher ausliefern, ohne dass WordPress den Request je sieht. Das ist der grösste, oft unterschätzte Performance-Hebel der REST API.

WPGraphQL läuft dagegen typischerweise über HTTP-POST an einen einzigen Endpunkt. POST-Requests sind per Konvention nicht cachebar — jede Anfrage erreicht den Server. Das heisst nicht, dass GraphQL nicht cachebar wäre, aber das Caching verlagert sich auf eine andere Ebene und kostet zusätzliche Bausteine:

• Persisted Queries — die Abfrage wird als ID gespeichert und kann dann auch per GET aufgerufen und damit gecacht werden.
• WPGraphQL Smart Cache — ein offizielles Cache-Plugin, das GraphQL-Antworten serverseitig zwischenspeichert und gezielt invalidiert.
• Statisches Rendering im Frontend — bei Next.js oder vergleichbaren Frameworks werden Seiten zur Build-Zeit oder inkrementell generiert, sodass GraphQL-Aufrufe gar nicht zur Laufzeit jedes Besuchs anfallen. Welche Hosting-Strategie dazu passt, ordnet der Beitrag zu Headless-WordPress-Hosting 2026 ein.

In der Praxis ist diese letzte Variante der Normalfall: In einer sauberen Headless-Architektur fragt nicht der Besucher live WordPress ab, sondern das Frontend-Framework holt die Daten beim Build oder bei Revalidierung. Dann verliert die POST-vs-GET-Debatte viel von ihrer Schärfe — relevant bleibt sie für stark dynamische Bereiche, die wirklich pro Request frische Daten brauchen.

Mehrsprachigkeit de/fr/it — der Schweizer Sonderfall

In Schweizer Projekten ist Mehrsprachigkeit kein Randthema, sondern der Regelfall: Eine Site liefert dieselben Inhalte oft auf Deutsch, Französisch und Italienisch aus. Genau hier zeigt sich ein praktischer Unterschied zwischen den beiden Schnittstellen. Dieser Abschnitt bleibt bewusst bei der API-Mechanik — wie hreflang, Sprach-Routing und die Gesamtstrategie für eine mehrsprachige Headless-WordPress-Site in der Schweiz zusammenspielen, behandelt der eigene Beitrag dazu in der Tiefe.

Bei der nativen REST API ist die Sprachlogik nicht eingebaut — sie hängt am Übersetzungs-Plugin und dessen Endpunkten. Polylang etwa filtert die WP-Query standardmässig auf die aktuelle Sprache, was über die API zu sprachgebundenen Aufrufen oder Custom-Endpunkten führt. Für WPGraphQL gibt es dagegen gepflegte Erweiterungen, die das Schema um Sprachdaten ergänzen: Die Polylang-Erweiterung hängt die Sprachinformation an jeden Inhaltstyp und erlaubt das Filtern per language-Argument; WPML GraphQL liefert Übersetzungen für Beiträge, Taxonomien und Optionen und gibt zu jedem Inhalt die Sprachinformation zurück.

Der praktische Gewinn: Ein Sprachumschalter, der für denselben Beitrag die fr- und it-Variante samt übersetzter Slugs auflöst, lässt sich über WPGraphQL als eine verschachtelte Abfrage formulieren. Über REST sind dafür meist mehrere sprachgebundene Aufrufe nötig. Eine Einschränkung bleibt ehrlicherweise bestehen: Die WPML-Erweiterung liefert pro Abfrage Inhalte nur in einer Sprache — mehrere Sprachen in einem Request erfordern den dokumentierten Workaround mehrerer Teilabfragen (WPML GraphQL).

Eine zweite, oft übersehene Schweizer Dimension liegt nicht in der API, sondern dahinter: Wo liegen die Daten? Die Schnittstellen-Wahl ändert nichts an der Datenresidenz — beide greifen auf dieselbe WordPress-Datenbank zu. Wenn Datenschutz oder Kundenvorgaben einen Backend-Standort in der Schweiz oder der EU verlangen, ist das eine Hosting-Frage des WordPress-Backends, unabhängig davon, ob das Frontend per GraphQL oder REST anfragt. Die Schnittstellen-Entscheidung lässt sich also losgelöst von der Datenresidenz treffen — beides sind getrennte Stellschrauben.

Wann WPGraphQL statt REST — die Matrix

Kurzregel: WPGraphQL, sobald das Frontend mehrere Datentypen verschachtelt oder ein eigenes ACF-Datenmodell anzeigt; REST, sobald Einfachheit und HTTP-Caching wichtiger sind als Abfrage-Präzision. Die folgende Matrix legt die sieben Achsen auf konkrete Projekt-Profile — sie ersetzt kein Architektur-Review, gibt aber eine belastbare Vorab-Einordnung.

Wer die Profile auf das eigene Vorhaben legt, landet meist bei einer eindeutigen Spalte — und in den Grenzfällen, in denen zwei Profile zutreffen, gibt die Caching-Achse den Ausschlag. Beide Wege führen ohnehin zu einer schnellen, gut zu wartenden Site — die Vorteile einer Headless-Architektur hängen nicht an dieser einen Wahl.

Das ehrliche Fazit — kein Dogma

Wer in Foren liest, gewinnt manchmal den Eindruck, die Schnittstellen-Wahl sei eine Glaubensfrage. Das ist sie nicht. Beide Optionen sind ausgereift, beide werden gepflegt, beide tragen über Jahre.

WPGraphQL hat mit dem Statuswechsel zum kanonischen Plugin und dem Wechsel des Maintainers zu Automattic (WP Tavern, Oktober 2024) seine grösste historische Schwäche — die Frage nach der langfristigen Pflege — weitgehend abgelegt. Maintainer Jason Bahl ordnete den Schritt selbst so ein: «WPGraphQL has always been and will continue to be free open-source software» (WP Tavern, Oktober 2024). Ganz ohne Wartungsrisiko ist auch ein kanonisches Plugin aber nicht: Erweiterungen für nischige Plugins hinken Updates mitunter hinterher, und grössere Versionssprünge können das Schema brechen — der Wechsel auf WPGraphQL v2.0 etwa brachte dokumentierte Breaking Changes, die Frontend-Builds bis zur Anpassung stillstehen lassen können (WPGraphQL, Dezember 2024). Das ist beherrschbar — Staging-Tests vor jedem Update —, gehört zur ehrlichen Bilanz aber dazu. Die REST API wiederum ist Core und verschwindet nicht; sie ist die sichere Wahl, wann immer Einfachheit und HTTP-Caching wichtiger sind als Abfrage-Präzision.

In der Praxis schliessen sich beide nicht aus. Eine pragmatische Architektur bezieht den Grossteil der Inhalte über die Schnittstelle, die zum Daten-Profil passt, und nutzt für einzelne Plugin-Endpunkte oder Webhooks die jeweils andere. Wichtiger als die Schnittstellen-Wahl ist die saubere Modellierung der Daten dahinter — ein Punkt, der bei Migrationen regelmässig unterschätzt wird, wie die Stolperfallen bei der Headless-Migration zeigen.

Unsere Tendenz aus eigenen Projekten: Sobald ein Frontend mehrere Datentypen verschachtelt anzeigt oder ein eigenes Datenmodell mit ACF fährt, greifen wir zu WPGraphQL — der Präzisions-Gewinn rechtfertigt das zusätzliche Plugin. Bei schlanken, statisch gerenderten Marketing-Sites mit wenigen Seitentypen bleibt die REST API oft die ruhigere Wahl. Dogma steckt in keiner der beiden Richtungen.

Nächster Schritt

Welche Schnittstelle zu Ihrem Projekt passt, entscheidet sich am Daten-Profil — und das lässt sich in einem kurzen Gespräch sauber einordnen. Wenn Sie eine Headless-Architektur planen oder ein bestehendes Setup hinterfragen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos. In dieser Zeit klären wir Datenmodell, Frontend-Anforderungen und die passende Schnittstellen-Strategie.

Wer zuerst die grössere Architektur-Linie verstehen will, findet auf der Themenseite zu Headless WordPress die Einordnung, wie API-Layer, Backend und Frontend zusammenspielen — und wann sich der Aufwand wirtschaftlich lohnt.