Übersetzte Version

Ich audite seit Jahren hunderte WordPress-Seiten, und das Gespräch beginnt immer auf die gleiche Weise: „Wir haben ein Caching-Plugin installiert, aber unsere Scores sind immer noch furchtbar." Die Wahrheit, die niemand im WordPress-Ökosystem zugeben möchte, ist, dass die meisten Performance-Probleme nicht durch Plugins lösbar sind. Sie sind architektonisch bedingt. WordPress wurde 2003 gebaut, um Blog-Beiträge mit PHP zu rendern. Wir schreiben 2025, und wir bitten es, komplexe Marketing-Seiten, E-Commerce-Plattformen und Web-Anwendungen zu betreiben — und das alles, während Googles Core Web Vitals zunehmend darüber bestimmen, ob jemand deine Inhalte überhaupt findet.

Dieser Artikel erklärt genau, warum WordPress-Seiten langsam sind, ordnet jedes Problem den Core Web Vitals-Metriken zu, die darunter leiden, und zeigt dir, wie eine headless Next.js-Architektur sie an der Wurzel behebt. Nicht mit Pflastern. An der Wurzel.

Inhaltsverzeichnis

• Core Web Vitals 2025 verstehen
• Warum WordPress architektonisch langsam ist
• Plugin-Überfluss: Der stille Performance-Killer
• Datenbankabfrage-Probleme, die Plugins nicht beheben können
• WordPress-Hosting: Du zahlst wahrscheinlich zu viel für Mittelmäßigkeit
• Wie Next.js jede Core Web Vital behebt
• Die Headless-Architektur: WordPress als CMS, Next.js als Frontend
• Echte Performance-Benchmarks: WordPress vs Next.js
• Migrationspfad: Von monolithischem WordPress zu Headless Next.js
• FAQ

Core Web Vitals 2025 verstehen

Google hat seine Core Web Vitals im März 2024 aktualisiert und First Input Delay (FID) durch Interaction to Next Paint (INP) ersetzt. Diese Änderung ist wichtiger als die meisten Menschen denken. Hier sind die vier Metriken, die deine Website-Performance-Note bestimmen:

Metrik	Was sie misst	Gut	Verbesserung erforderlich	Schlecht
LCP (Largest Contentful Paint)	Wie schnell dein Hauptinhalt lädt	≤ 2,5s	2,5s – 4,0s	> 4,0s
INP (Interaction to Next Paint)	Reaktionsfähigkeit auf Benutzereingaben	≤ 200ms	200ms – 500ms	> 500ms
CLS (Cumulative Layout Shift)	Visuelle Stabilität während des Ladens	≤ 0,1	0,1 – 0,25	> 0,25
TTFB (Time to First Byte)	Server-Antwortzeit	≤ 800ms	800ms – 1800ms	> 1800ms

Laut dem Chrome UX Report von Anfang 2025 erfüllen nur 42% der WordPress-Origins alle drei Core Web Vitals-Schwellwerte. Vergleich das mit 67% für Next.js-betriebene Origins. Das ist kein marginaler Unterschied — es ist eine andere Liga.

Warum diese Metriken tatsächlich wichtig sind

Google ist unmissverständlich: Core Web Vitals sind ein Ranking-Signal. Aber über SEO hinaus korrelieren diese Metriken direkt mit Conversion-Raten. Vodafone stellte fest, dass eine 31%ige Verbesserung bei LCP zu einem 8%igen Anstieg des Umsatzes führte. Shopifys interne Daten zeigen, dass jede 100-ms-Reduktion der Seitenladezeit die Konversion um 1,3% erhöht.

Deine WordPress-Seite ist nicht nur langsam. Sie kostet dich Geld.

Warum WordPress architektonisch langsam ist

Lass mich dich durchgehen, was passiert, wenn jemand eine typische WordPress-Seite besucht:

1. DNS-Lookup → löst deine Domain auf
2. TCP/TLS-Handshake → stellt sichere Verbindung her
3. Request trifft den Server → Apache/Nginx empfängt ihn
4. PHP bootstrapt WordPress → lädt wp-config.php, initialisiert den WordPress-Core
5. Plugin-Initialisierung → jedes aktive Plugin bindet sich in init, wp_loaded etc. ein
6. Theme lädt → functions.php läuft, Template-Hierarchie löst auf
7. Datenbankabfragen ausführen → WP_Query läuft, oft 30-100+ Abfragen pro Seite
8. PHP rendet HTML → Template-Dateien generieren die vollständige Seite
9. HTML an Browser gesendet → endlich beginnt die Antwort
10. Browser parst HTML → entdeckt CSS, JS, Fonts, Bilder
11. Rendering-blockierende Ressourcen laden → Stylesheets von 15 verschiedenen Plugins
12. Seite rendert endlich → Benutzer sieht Inhalt

Die Schritte 4 bis 9 geschehen bei jeder einzelnen uncached-Request. Das ist PHP, das 200+ Dateien parst, Dutzende von Datenbankabfragen ausführt und HTML generiert — alles bevor der Browser ein einziges Byte erhält.

Das PHP-Problem

PHP 8.3 ist deutlich schneller als PHP 7.x, und die meisten WordPress-Hosts unterstützen jetzt PHP 8.3. Aber selbst mit PHP 8.3 und aktiviertem OPcache führst du immer noch einen synchronen, blockierenden Prozess aus. Der WordPress-Core allein lädt ungefähr 100.000 Zeilen PHP-Code bei jeder Request. Füge WooCommerce hinzu und du bist über 400.000 Zeilen.

Hier ist die Sache: Caching-Plugins wie WP Super Cache oder W3 Total Cache funktionieren, indem sie diesen Prozess kurzschließen — sie servieren stattdessen eine vorgenerierte HTML-Datei. Aber sie führen ihre eigene Komplexität ein, brechen mit personalisiertem Inhalt und können immer noch nicht beheben, was im Browser geschieht.

Das Theme-Problem

Die meisten WordPress-Themes sind für Flexibilität gebaut, nicht für Performance. Ein Theme wie Avada, Divi oder Elementor lädt sein gesamtes CSS- und JavaScript-Framework auf jeder Seite, egal ob du diese Features nutzt oder nicht. Ich habe Elementor-Seiten gesehen, die 2,5MB CSS und 1,8MB JavaScript auf einem einfachen Blog-Beitrag laden.

<!-- Typischer WordPress-Head auf einer Page-Builder-Seite -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 weitere Stylesheets -->

Jedes davon ist eine Rendering-blockierende Ressource. Dein LCP kann nicht passieren, bis alle von ihnen heruntergeladen und geparst werden.

Plugin-Überfluss: Der stille Performance-Killer

Die durchschnittliche WordPress-Seite führt 20-30 Plugins aus. Ich habe Seiten mit 70+ gesehen. Jedes Plugin kann potenziell:

• Seine eigenen CSS- und JS-Dateien hinzufügen (oft auf jeder Seite, sogar wo nicht verwendet)
• WordPress-Hooks registrieren, die bei jeder Request ausgeführt werden
• Seine eigenen Datenbankabfragen ausführen
• Seine eigenen PHP-Dateien während der Bootstrap-Phase laden
• Inline-Scripts und -Styles in den <head> hinzufügen

Ein echtes Beispiel

Ich audiere kürzlich eine Marketing-Seite, auf der WordPress mit 34 aktiven Plugins läuft. Hier ist, wie das Netzwerk-Waterfall aussah:

• 47 CSS-Dateien auf der Homepage geladen
• 38 JavaScript-Dateien auf der Homepage geladen
• Gesamtseitengröße: 4,7MB
• Gesamtrequests: 127
• LCP: 6,8 Sekunden auf 4G
• TTFB: 2,1 Sekunden

Der Client hatte bereits ein Optimierungs-Plugin (Autoptimize) und ein Caching-Plugin (LiteSpeed Cache) installiert. Selbst mit beiden aktiv lag das LCP bei 4,2 Sekunden. Immer noch nicht bestanden.

Das Kernproblem? Du kannst den grundlegenden Problem nicht wegoptimieren, Code zu laden, den du nicht brauchst. Das Minimieren und Kombinieren von 47 CSS-Dateien belässt dich immer noch mit einer großen CSS-Payload, die das Rendering blockiert.

Die Plugin-Abhängigkeitsfalle

Hier ist, was das schlimmer macht: Plugins hängen von anderen Plugins ab. Du installierst WooCommerce, dann brauchst du ein Payment-Gateway-Plugin, dann ein Versandrechner-Plugin, dann ein Produktfilter-Plugin. Jedes fügt Gewicht hinzu. Du kannst keines entfernen, ohne die Funktionalität zu beschädigen.

Das ist die WordPress-Falle. Die Architektur ermutigt das Hinzufügen von Plugins für alles, und es gibt keinen Mechanismus zum Tree-Shaking ungenutzter Codes.

Datenbankabfrage-Probleme, die Plugins nicht beheben können

WordPress nutzt eine einzelne MySQL-Datenbank mit einem notorisch flachen Schema. Die wp_options-Tabelle ist mit autoload='yes'-Einträgen bei jeder einzelnen Request geladen. Ich habe wp_options-Tabellen mit 3.000+ autogeladenen Zeilen gesehen, die insgesamt 8MB Daten umfassen.

-- Überprüfe die Größe deiner autogeladenen Optionen
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- Wenn dies > 1MB zurückgibt, hast du ein Problem

Die wp_postmeta-Tabelle ist ein weiteres Albtraum. Sie speichert alles als Schlüssel-Wert-Paare, was bedeutet, dass WordPress effiziente Abfragen nicht durchführen kann. Du möchtest alle Produkte unter 50 $ finden? Das ist ein JOIN auf wp_postmeta mit einem String-Vergleich auf einem Textfeld, das eine Zahl speichert. Kein Index kann dich retten.

Abfrage-Count Realitäts-Check

Installiere das Query Monitor-Plugin auf deiner WordPress-Seite und schau dir die Abfrage-Anzahl an. Eine „einfache" WooCommerce-Produktseite lädt typischerweise 150-300 Datenbankabfragen. Ein Blog-Beitrag mit verwandten Beiträgen, beliebte Beiträge Sidebar und Breadcrumbs? Normalerweise 80-120 Abfragen.

Vergleiche das mit einem Headless-Ansatz, bei dem dein Next.js-Frontend genau einen API-Call tätigt (oder null, wenn statische Generierung verwendet wird), um alle Daten zu bekommen, die es braucht.

WordPress-Hosting: Du zahlst wahrscheinlich zu viel für Mittelmäßigkeit

Lass uns über Hosting sprechen, denn hier wird viel Geld verschwendet.

Hosting-Typ	Monatliche Kosten	Typisches TTFB	Kann Architektur beheben?
Shared (GoDaddy, Bluehost)	$3-15	1,5-4,0s	Nein
Managed WordPress (WP Engine, Flywheel)	$25-300	400ms-1,2s	Nein
Premium Managed (Kinsta, Pagely)	$35-600	200ms-600ms	Nein
VPS/Dedicated (DigitalOcean, AWS)	$20-500	200ms-800ms	Nein
Next.js auf Vercel/Edge	$0-20	50-150ms	Ja

Beachte diese letzte Spalte. Kein Hosting-Upgrade behebt die architektonischen Probleme. Du zahlst Premium-Preise, um PHP schneller laufen zu lassen, wenn die echte Lösung darin besteht, PHP nicht bei jeder Request auszuführen.

Kinsta berechnet $35/Monat für ihren Starter-Plan mit 25.000 Besuchen. Vercels kostenloses Tier verarbeitet 100GB Bandbreite. Selbst Vercels Pro-Plan bei $20/Monat gibt dir Edge-Deployment über ihr globales CDN. Die Mathematik lügt nicht.

Wie Next.js jede Core Web Vital behebt

Lass mich spezifisch werden. Hier ist, wie Next.js (besonders mit dem App Router in Next.js 14/15) jede Metrik anspricht:

TTFB beheben

Next.js gibt dir mehrere Rendering-Strategien:

// Statische Generierung - TTFB praktisch null (vom CDN serviert)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// Dies pre-rendert zur Build-Zeit
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Mit statischer Generierung werden deine Seiten zu vorgenerierter HTML-Dateien, serviert von Edge-CDN-Knoten weltweit. TTFB sinkt auf 50-100ms, unabhängig davon, wo deine Benutzer sind. Keine PHP-Ausführung, keine Datenbankabfragen, keine serverseitige Verarbeitung zur Request-Zeit.

Für dynamische Inhalte unterstützt Next.js ISR (Incremental Static Regeneration), das gecachte statische Seiten serviert, während es im Hintergrund neu validiert:

// Revalidiere alle 60 Sekunden
export const revalidate = 60;

LCP beheben

Next.js beinhaltet die <Image>-Komponente, die alles macht, das WordPress-Plugins versuchen (und scheitern) zu tun:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero banner"
      width={1200}
      height={600}
      priority // Preloaded das LCP-Image
      sizes="100vw"
      // Generiert automatisch srcset, verwendet WebP/AVIF,
      // lazy loads standardmäßig, verhindert CLS
    />
  );
}

Das priority-Prop sagt Next.js, dass es das Image preloaden soll, was direkt das LCP verbessert. Die automatische Format-Verhandlung serviert WebP oder AVIF zu unterstützenden Browsern und reduziert Image-Größe um 30-50% im Vergleich zu JPEG. Kein Plugin nötig.

Next.js beseitigt auch Rendering-blockierendes CSS durch CSS-Module und automatische kritische CSS-Extraktion. Nur das CSS, das auf einer bestimmten Seite verwendet wird, wird geladen.

INP beheben

INP misst, wie schnell deine Seite auf Benutzerinteraktionen reagiert. WordPress-Seiten scheitern bei INP wegen:

• Schwerer JavaScript von Plugins, der den Main-Thread blockiert
• jQuery und seine Plugins, die um Ausführungszeit konkurrieren
• Kein Code-Splitting — alles lädt auf einmal

Next.js verarbeitet dies mit automatischem Code-Splitting. Jede Seite lädt nur das JavaScript, das sie braucht:

// Diese Komponente lädt nur, wenn der Benutzer zu ihr hinabscrollt
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // Rendere nicht auf dem Server
});

React Server Components (Standard im App Router) gehen noch weiter: Komponenten, die keine Interaktivität brauchen, senden Null-JavaScript an den Browser. Ein Blog-Beitrag ohne interaktive Elemente? Null KB Component-JavaScript.

CLS beheben

CLS in WordPress kommt normalerweise von:

• Images ohne explizite Dimensionen
• Ads, die spät laden und Inhalt nach unten schieben
• Webfonts, die FOUT/FOIT verursachen
• Plugin-injizierte Banner, die nach dem Laden erscheinen

Next.js verhindert CLS standardmäßig. Die <Image>-Komponente erfordert Dimensionen (oder verwendet fill mit einem bemessenen Container). Das next/font-Modul inlinet Font-Deklarationen und verwendet font-display: swap ohne Layout-Shift:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Kein FOUT. Kein Layout-Shift von Fonts. Es funktioniert einfach.

Die Headless-Architektur: WordPress als CMS, Next.js als Frontend

Hier ist der Teil, den viele Menschen verpassen: Headless zu gehen bedeutet nicht, WordPress aufzugeben. Es bedeutet, WordPress für das zu nutzen, das es tatsächlich gut kann — Content-Management — während du Next.js das Frontend handhaben lässt.

Die Architektur sieht so aus:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
  Content-Editoren                             Deine Benutzer
  nutzen das vertraute                         bekommen schnelle Seiten
  WP-Dashboard                                 vom Edge serviert

Dein Content-Team behält seinen Workflow. Deine Benutzer bekommen eine schnelle Seite. Du bekommst sauberen, wartbaren Code.

Wir machen viel dieser Art von Arbeit in unserer Next.js-Entwicklungspraxis und Headless-CMS-Entwicklung. Das Muster ist gut etabliert und im Kampf erprobt.

Was ist mit anderen Headless-CMS-Optionen?

WordPress ist nicht die einzige Option für die Content-Layer. Wenn du von vorne anfängst, sind speziell gebaute Headless-CMS-Plattformen wie Sanity, Contentful oder Storyblok oft bessere Wahlmöglichkeiten. Sie sind API-first gebaut, daher gibt es keinen Legacy-Ballast.

Aber wenn du Jahre von Inhalten in WordPress hast und ein Team, das darauf trainiert ist, ist Headless-WordPress mit WPGraphQL ein absolut valider Ansatz.

Echte Performance-Benchmarks: WordPress vs Next.js

Hier sind echte Zahlen aus Migrationen, die wir gemacht haben, und öffentlich verfügbare Case Studies:

Metrik	WordPress (Optimiert)	Next.js (Statisch)	Verbesserung
TTFB	650ms	80ms	87% schneller
LCP	3,8s	1,2s	68% schneller
INP	380ms	90ms	76% schneller
CLS	0,18	0,01	94% besser
Seitengröße	3,2MB	450KB	86% leichter
Requests	85	12	86% weniger
Lighthouse-Score	45-65	95-100	Tag und Nacht

„Optimiert" WordPress bedeutet: PHP 8.3, Redis Object Cache, CDN, Image-Optimierungs-Plugin, Caching-Plugin, Datenbankoptimierung. Alle Dinge, die du tun sollst. Und es ist immer noch nicht nah beieinander.

Migrationspfad: Von monolithischem WordPress zu Headless Next.js

Migration muss nicht alles-oder-nichts sein. Hier ist der phasierte Ansatz, den wir normalerweise empfehlen:

Phase 1: Bewertung (1-2 Wochen)

• Audiere aktuelle WordPress-Seite-Performance mit PageSpeed Insights und CrUX-Daten
• Inventarisiere alle Plugins und ordne sie Frontend vs. Backend-Funktionalität zu
• Identifiziere Content-Modelle und Custom Fields
• Evaluiere, ob WordPress als Headless-CMS behalten oder Inhalte komplett migrieren werden sollen

Phase 2: Frontend-Build (4-8 Wochen)

• Richte Next.js-Projekt mit dem App Router auf
• Installiere und konfiguriere WPGraphQL auf WordPress
• Baue Component Library, die aktuelles Design matched (oder redesign — gute Zeit dafür)
• Implementiere statische Generierung für Content-Seiten
• Richte Preview-Modus für Content-Editoren auf

Phase 3: Launch und Umleitungen (1-2 Wochen)

• Deployiere Next.js Frontend zu Vercel (oder Netlify oder Cloudflare Pages)
• Konfiguriere DNS und Umleitungen
• Verifiziere, dass alle URLs ordnungsgemäß umgeleitet werden (SEO-Konservierung ist kritisch)
• Sperre WordPress-Admin (entferne öffentlichen Zugriff)

Phase 4: Optimierung (fortlaufend)

• Überwache Core Web Vitals in Google Search Console
• Fine-tune ISR Revalidierungs-Intervalle
• Füge Edge-Middleware für Personalisierung hinzu
• Erwäge Migration zu einem speziell gebautem Headless-CMS, wenn WordPress ein Bottleneck wird

Wenn du diese Art von Migration erwägst, kannst du unser Pricing-Seite überprüfen für grobe Zahlen, oder kontaktiere uns direkt, um deine spezifische Situation zu besprechen.

Für Seiten, die mit Astro statt Next.js gebaut sind (besonders content-schwere Blogs und Marketing-Seiten), haben wir auch eine Astro-Entwicklungspraxis, die noch aggressivere Performance für Static-First-Seiten liefert.

FAQ

Kann ich WordPress beschleunigen, ohne zu Next.js zu wechseln? Ja, bis zu einem Punkt. Starten Sie mit einem qualitativen Host (Kinsta oder Cloudways), aktiviere Redis Object Caching, nutze ein leichtes Theme wie GeneratePress, reduziere Plugins auf unter 15 und konfiguriere einen CDN. Du kannst ein WordPress-Site in den „Verbesserung erforderlich"-Bereich für Core Web Vitals auf diese Weise bekommen. Aber konsistent in den „guten" Bereich für alle Metriken zu brechen — besonders INP — ist mit einer traditionellen WordPress-Architektur extremst schwierig.

Wie viel kostet es, von WordPress zu Headless Next.js zu migrieren? Es hängt von der Komplexität der Site ab. Eine einfache Marketing-Seite (10-30 Seiten, Blog) läuft typischerweise $15.000-$40.000 für eine vollständige Migration. E-Commerce-Seiten mit WooCommerce sind komplizierter, reichen von $50.000-$150.000+. Der ROI kommt normalerweise von verbesserten Conversion-Raten und reduzierten Hosting-Kosten. Unsere Pricing-Seite hat mehr Details.

Werden meine SEO-Rankings fallen, wenn ich zu Next.js wechsele? Nicht, wenn du die Migration ordnungsgemäß durchführst. Ordnungsgemäße 301-Umleitungen, identische URL-Strukturen (oder gemappte Umleitungen), valide Meta-Tags, strukturierte Daten und eine XML-Sitemap sind alle wesentlich. Next.js hat tatsächlich SEO-Vorteile — schnellere Core Web Vitals verbessern direkt die Rankings, und die Metadata API macht es einfach, Meta-Tags programmatisch zu verwalten. Die meisten Seiten sehen Ranking-Verbesserungen innerhalb von 2-3 Monaten nach der Migration.

Verlieren Content-Editoren das WordPress-Admin, wenn wir Headless gehen? Nein. In einem Headless-Setup fungiert WordPress weiterhin als Content-Management-Backend. Editoren nutzen das gleiche Dashboard, den gleichen Editor, den gleichen Workflow. Sie sehen nur nicht mehr das Frontend-Theme — stattdessen nutzen sie einen Preview-Button, der die Next.js-gerenderte Version zeigt. Einige Teams finden, dass dies tatsächlich besser ist, denn die Preview ist eine genaue Darstellung der Production-Site.

Was ist mit WooCommerce — kann Next.js E-Commerce handhaben? Ja, aber es ist ein größeres Projekt. Du kannst WooCommerce headless über seine REST API oder WPGraphQL WooCommerce Extension nutzen. Alternativ migrieren viele Teams zu Shopifys Storefront API oder Saleor für das Commerce-Backend, nutzen Next.js als Frontend. Der Checkout-Flow erfordert sorgfältige Handhabung, da er Payment-Processing und PCI-Compliance einvoliert. Es ist machbar, aber plane für zusätzliche Entwicklungszeit.

Ist Next.js die einzige Option für ein schnelles Frontend? Nein. Astro, Remix, SvelteKit und sogar Nuxt (für Vue-Teams) sind alle viable. Astro ist besonders ausgezeichnet für content-schwere Seiten, weil es standardmäßig Null-JavaScript sendet. Next.js gewinnt für Seiten, die bedeutende Interaktivität, dynamische Features oder E-Commerce brauchen. Wir arbeiten mit beiden Next.js und Astro abhängig von den Projectbedarfen.

Wie funktioniert Incremental Static Regeneration (ISR) mit WordPress-Inhalt? Wenn du einen Beitrag in WordPress veröffentlichst oder aktualisierst, feuert ein Webhook ab und sagt deinem Next.js-Deployment, dass bestimmte Seite neu validieren. Der nächste Besucher bekommt eine frisch generierte statische Seite, die dann am Edge gecacht wird. Die Revalidierung geschieht im Hintergrund, daher warten Benutzer niemals auf einen Build. Du kannst auch zeitbasierte Revalidierung setzen (z.B. neu bauen alle 60 Sekunden) als Fallback.

Was ist der größte Fehler, den Teams beim Headless-Gehen machen? Versuchen, ihre WordPress-Site 1:1 in Next.js zu replizieren. Eine Headless-Migration ist eine Gelegenheit, deine Content-Architektur zu überdenken, deine Seitenstrukturen zu vereinfachen und Jahre angesammelter Unordnung zu eliminieren. Teams, die es als einen frischen Start behandeln — den Inhalt behalten, aber die Präsentation überdenken — enden mit dramatisch besseren Ergebnissen als Teams, die jedes Widget und jede Sidebar von ihrem alten Theme versuchen zu kopieren.