WordPress zu Next.js Migration: Wie wir SleepDr von Lighthouse 35 zu 94 gebracht haben

Letztes Quartal führten wir ein Projekt durch, das perfekt illustriert, warum WordPress nicht immer das richtige Werkzeug für die Aufgabe ist. SleepDr.com — eine Website für Schlafgesundheit mit 228 Blogbeiträgen, einem Kontaktformular und einem mobilen Lighthouse-Score von 35 — kam verzweifelt zu uns, um schneller zu werden. Der organische Traffic war seit Monaten gesunken. Googles Core Update vom März 2026, das eine ganzheitliche Core-Web-Vitals-Bewertung auf Site-Ebene einführte, hatte sie hart getroffen. Jeder langsame Blogbeitrag zog die gesamte Domain herunter.

Wir migrieren sie zu Next.js 15 + Payload CMS 3 + Supabase + Vercel. Das Ergebnis: Mobile Lighthouse 94, Desktop 99. Der organische Traffic erholte sich innerhalb von 6 Wochen. Dies ist die vollständige Geschichte, wie wir dorthin gelangten — jede Optimierung, jede Metrik, jede Entscheidung — damit Sie das gleiche Denken auf Ihre eigenen Projekte anwenden können.

Inhaltsverzeichnis

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94)

Vorher: Warum WordPress SleepDr tötete

SleepDrs WordPress-Setup war ein Lehrbuchbeispiel für angesammelte technische Schulden. Über drei Jahre installierten sie 34 Plugins. Das Theme lud jQuery plus zwei zusätzliche JavaScript-Bibliotheken. Jede Seitenanfrage traf eine MySQL-Datenbank, generierte HTML im Handumdrehen und servierte unoptimierte Bilder über einen gemeinsamen Hosting-Plan, der bereits unter Last kämpfte.

So sah das erste Lighthouse-Audit auf Mobilgeräten aus:

  • Gesamtscore: 35 (rot, fehlgeschlagen)
  • FCP: 4,2 Sekunden
  • LCP: 6,8 Sekunden — fast dreimal der „Gut"-Schwellenwert
  • CLS: 0,28 — das Layout springte überall herum durch Anzeigen, Bilder ohne Abmessungen und Web-Font-Laden
  • TBT: 1.200ms — der Hauptthread war über eine Sekunde lang gesperrt
  • TTFB: 2,1 Sekunden — der Server selbst war langsam, bevor überhaupt etwas gerendert wurde

Die Website war nicht nur langsam. Sie war aktiv feindselig gegenüber Benutzern auf Mobilgeräten. Da Googles Lighthouse-Mobil-Simulation ein Mittelklasse-Telefon mit gedrosselter 4G-Verbindung nachahmt, spiegeln die Scores das wider, was echte Benutzer unter weniger als idealen Bedingungen erleben.

Nach Googles Core Update vom März 2026, das ganzheitliche CWV-Bewertung einführte — wobei die Leistung auf der gesamten Domain aggregiert wird statt pro Seite — SleepDrs 228 langsame Blogbeiträge vergifteten ihre Ranglisten seite-weit. Frühe Daten aus dem Rollout zeigten Verkehrsrückgänge von 20-35% für betroffene Sites. SleepDr sah einen Rückgang von etwa 30%.

Etwas musste sich ändern.

Der Migrations-Stack: Warum wir das gewählt haben

Wir haben diesen Stack nicht gewählt, weil er trendy ist. Wir haben ihn gewählt, weil jede Komponente ein spezifisches Problem löst, das SleepDr hatte.

  • Next.js 15 (App Router): Hybrid-Rendering. Statische Generierung für Blogbeiträge, Server-Side-Rendering wo nötig. React Server Components zur Minimierung von Client-seitigem JavaScript. Dies ist unser Kerngeschäft — wir haben Dutzende von Projekten darauf gebaut durch unsere Next.js-Entwicklungspraxis.
  • Payload CMS 3: Selbst gehostetes Headless-CMS, das SleepDrs Content-Team die gleiche Bearbeitungserfahrung gab wie bei WordPress, minus dem Ballast. Wir handhaben viele Headless-CMS-Implementierungen und Payload 3 ist unser Standard für Content-reiche Sites geworden.
  • Supabase: PostgreSQL-Datenbank mit Echtzeit-Fähigkeiten. Verwaltet die Kontaktformular-Einreichungen, Analyseereignisse und alle dynamischen Daten.
  • Vercel: Edge-Deployment. Die Website wird vom Knoten aus serviert, der dem Benutzer am nächsten liegt. TTFB wird fast unbedeutend.

Die gesamte Migration dauerte 7 Wochen. Die Content-Migration — alle 228 Beiträge mit ihren Bildern, Metadaten und URL-Strukturen — nahm etwa 2 Wochen davon in Anspruch. Wir schrieben ein benutzerdefiniertes Skript, um Content aus der WordPress REST API zu ziehen, zu transformieren und in Payload CMS zu pushen.

Vorher und Nachher: Die Zahlen

Hier ist die vollständige Übersicht. Dies sind Lighthouse-Scores für Mobilgeräte, wo die echte Geschichte liegt.

Metrik Vorher (WordPress) Nachher (Next.js 15) Verbesserung
First Contentful Paint (FCP) 4,2s 1,1s -3,1s (74% schneller)
Largest Contentful Paint (LCP) 6,8s 1,8s -5,0s (74% schneller)
Cumulative Layout Shift (CLS) 0,28 0,01 -0,27 (96% Reduktion)
Total Blocking Time (TBT) 1.200ms 50ms -1.150ms (96% Reduktion)
Time to First Byte (TTFB) 2,1s 0,3s -1,8s (85% schneller)
Gesamt Mobile Score 35 94 +59 Punkte
Gesamt Desktop Score 61 99 +38 Punkte

Ich möchte klar sein: Dies sind keine aus einer einzelnen Seite herausgepickten Zahlen. Wir führten Lighthouse auf 20 repräsentativen Seiten aus und mittelten die Ergebnisse. Der Mobile Score reichte von 91 bis 97 über alle getesteten Seiten hinweg. Desktop war 97 bis 100.

Nun lasse mich Sie durch genau wie wir jede dieser Verbesserungen erreicht haben.

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94) - architecture

Optimierung 1: Bildoptimierung (LCP -3s)

Bilder waren der einzeln größte Performance-Killer auf der alten Site. SleepDrs Blogbeiträge waren voll von Produktfotographie und Infografiken — oft hochgeladen als vollständig auflösungsstarke PNGs direkt von der Maschine eines Designers. Manche Bilder waren 3-4MB groß.

Was wir taten

Verwendung von next/image für jedes einzelne Bild. Diese Komponente macht viel Schwerarbeit:

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Hero über dem Falz: preload it
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Hier ist, was next/image automatisch handhabt:

  • Format-Konvertierung: Serviert WebP (oder AVIF wo unterstützt) statt PNG/JPEG. Dies allein reduzierte Bildgrößen um 60-80%.
  • Responsive srcset: Generiert mehrere Größen, damit Mobile-Benutzer nicht Desktop-große Bilder herunterladen.
  • Lazy Loading by default: Bilder unter dem Falz laden nicht, bis der Benutzer in ihre Nähe scrollt.
  • Explizite Abmessungen: Die width und height Props reservieren Platz im Layout, was CLS direkt behebt.

Der Schlüssel-Einblick: Priority Loading für LCP Elements

Die priority Prop auf dem Hero-Bild war kritisch. Ohne sie lazy-loaded Next.js das Bild. Aber wenn das Hero-Bild das LCP-Element ist — was es auf den meisten von SleepDrs Seiten war — lazy loaded es tatsächlich schadet Ihrer LCP-Score. Sie möchten, dass es sofort beginnt herunterzuladen.

Wir audittieren jede Seiten-Template, identifizierten das LCP-Element und markierten es mit priority. Blogbeitrag-Seiten verwendeten das ausgewählte Bild. Die Homepage verwendete das Hero-Banner. Einfach, aber es machte einen 3-Sekunden-Unterschied auf LCP.

Image CDN

Vercels integrierte Bildoptimierung dient als CDN. Bilder werden bei der ersten Anfrage an der Edge verarbeitet und gecacht. Nachfolgende Besucher erhalten die gecachte, optimierte Version in Millisekunden. Kein Cloudinary-Abonnement erforderlich. Kein WordPress-Plugin, das das gleiche tut, aber schlimmer.

Netto-Impact: LCP sank von 6,8s auf ungefähr 3,8s durch Bildoptimierung allein. Die verbleibenden LCP-Gewinne kamen von TTFB-Verbesserungen und Schriftladen.

Optimierung 2: Schriftoptimierung (FCP -1,5s)

SleepDrs WordPress-Theme lud drei Google Fonts über externe Stylesheet-Links. Jeder war eine Rendering-blockierende Anfrage an fonts.googleapis.com, gefolgt von einer weiteren Anfrage an fonts.gstatic.com für die tatsächlichen Schriftdateien. Das sind sechs Netzwerk-Hin- und Herbringungen, bevor der Browser Text malen konnte.

Was wir taten

Self-hosted Fonts mit next/font:

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

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

Was next/font anders macht:

  • Self-hosted Schriftdateien: Keine externen Netzwerkanfragen. Die Fonts werden mit dem Build gebündelt und vom gleichen CDN serviert.
  • Automatisches Subsetting: Enthält nur die Zeichensätze, die Sie tatsächlich benötigen. Der Latin-Subset von Inter ist etwa 20KB statt der vollständigen 100KB+ Datei.
  • display: 'swap': Text rendert sofort mit einer Fallback-Schrift, dann wechselt zur Web-Font, wenn sie geladen ist. Kein unsichtbarer Text. Kein Flash von unstyled Content, der FCP blockiert.
  • CSS-Variable Injection: Die Schrift wird über CSS-Eigenschaften angewendet, was bedeutet, dass keine Layout-Verschiebung auftritt, wenn die Schrift wechselt, weil wir die Fallback-Font-Metriken sorgfältig abgestimmt haben.

Wir ließen die dritte Schrift auch komplett fallen. Die alte Site verwendete eine dekorative Schrift für Überschriften, die visuelles Rauschen hinzufügte, ohne die Lesbarkeit zu verbessern. Zwei Fonts. Das ist es.

Netto-Impact: FCP verbessert sich um ungefähr 1,5 Sekunden durch Beseitigung von Rendering-blockierenden Font-Anfragen.

Optimierung 3: JavaScript-Reduktion (TBT 1200ms → 50ms)

Dies war die dramatischste einzelne Verbesserung. Ein TBT von 1.200ms bedeutet, dass der Browser-Hauptthread für über eine volle Sekunde blockiert war — der Benutzer konnte nicht klicken, scrollen oder während dieser Zeit mit etwas interagieren.

Woher kam das ganze JavaScript?

Die WordPress-Site lud:

  • jQuery (87KB minified) — verwendet vom Theme und den meisten Plugins
  • 34 Plugin-Skripte — Kontaktformular, Analytik, Social Sharing, Cookie Consent, zwei verschiedene Slider-Bibliotheken, eine Lightbox und mehr
  • Theme JavaScript — weitere 150KB von Menu-Toggles und Animations-Bibliotheken
  • Inline-Skripte — zufällige Snippets von verschiedenen Plugins injiziert in den <head>

Gesamt-JavaScript beim Laden: ungefähr 1,8MB. Auf einer gedrosselten Mobile-Verbindung dauert das Parsen und Ausführen über eine Sekunde.

Was wir taten

Zero jQuery. Next.js verwendet React. Wir brauchen jQuery nicht.

Zero Plugins. Jedes Feature wurde als eine Zweck-gebaute Komponente neu geschrieben:

  • Kontaktformular: 4KB React-Komponente + Supabase Server Action
  • Cookie Consent: 2KB Komponente mit next/script Strategie
  • Social Sharing: Native Web Share API mit Fallback-Links — keine Bibliothek nötig
  • Analytik: Lightweight Plausible-Skript (< 1KB)

Dynamische Imports für alles unter dem Falz:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Nur auf Client, nur wenn nötig
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

React Server Components handhabten das meiste Rendering. Blogbeitrag-Inhalte, Header, Footer, Navigation — alles Server-rendered mit null Client-seitigem JavaScript. Nur interaktive Elemente (das Mobile-Menu-Toggle, Kontaktformular, Newsletter-Signup) schifften JS zum Browser.

Gesamt-JavaScript beim Laden nach der Migration: ungefähr 85KB. Das ist eine 95% Reduktion.

Netto-Impact: TBT sank von 1.200ms auf 50ms. Der Hauptthread ist praktisch frei.

Optimierung 4: Server-Side Rendering und Edge Deployment (TTFB -85%)

TTFB misst, wie lange es dauert, bis der Server beginnt, das erste Byte der Antwort zu senden. SleepDrs WordPress-Site hatte eine 2,1-Sekunden-TTFB auf Mobile. Das bedeutet, bevor alles passiert — bevor Bilder geladen, bevor Fonts heruntergeladen, bevor JavaScript ausgeführt wird — starrte der Benutzer auf einen leeren Screen für über zwei Sekunden, während er auf die Server-Antwort wartete.

Warum WordPress so langsam war

Jede Seitenanfrage auf WordPress:

  1. Traf den gemeinsamen Hosting-Server (bereits langsam)
  2. Lud PHP
  3. Führte WordPress-Kern aus
  4. Lief durch 34 Plugin-Hooks
  5. Fragte MySQL mehrmals ab
  6. Generierte HTML dynamisch
  7. Sendete die Antwort

Selbst mit WP Super Cache installiert war die Cache-Hit-Quote inkonsistent und der Server selbst war unterpowered.

Was wir taten

Statische Generierung für alle 228 Blogbeiträge. Zur Build-Zeit pre-rendert Next.js jeden Blogbeitrag zu statischem HTML. Das Ergebnis ist ein Satz .html Dateien, die auf Vercels Edge Network sitzen — verteilt über 80+ globale Standorte.

Wenn ein Benutzer einen Blogbeitrag anfordert, wird ihm eine pre-gebaute HTML-Datei vom nächsten Edge-Knoten serviert. Keine Datenbankabfrage. Keine Server-seitige Verarbeitung. Nur ein Datei-Read von einem CDN.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

Für die Kontaktformular-Seite verwendeten wir Server-Side-Rendering, da es dynamisches Verhalten brauchte. Aber selbst SSR auf Vercels Edge Functions läuft in unter 100ms, da die Berechnung an der Edge stattfindet, nicht in einem zentralisierten Datenzentrum.

Netto-Impact: TTFB sank von 2,1s auf 0,3s — eine 85% Verbesserung. Bei wiederholten Besuchen mit Caching ist es näher an 50ms.

Optimierung 5: Verwaltung von Drittanbieter-Skripten

Drittanbieter-Skripte sind die stillen Killer der Web-Performance. SleepDrs WordPress-Site lud Google Analytics (GA4), Google Tag Manager, ein Facebook-Pixel, ein Hotjar-Recording-Skript und einen Cookie-Consent-Manager — alle Rendering-blockierend im <head>.

Was wir taten

Next.js bietet die next/script Komponente mit Lade-Strategien. Wir verwendeten sie absichtlich:

import Script from 'next/script';

{/* Analytik: laden nachdem die Seite interaktiv wird */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Cookie Consent: laden wenn Browser untätig ist */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

Die afterInteractive Strategie lädt das Skript, nachdem die Next.js-Hydration abgeschlossen ist. Der Benutzer kann die Seite bereits sehen und mit ihr interagieren. Die lazyOnload Strategie wartet, bis der Browser völlig untätig ist — großartig für nicht-kritische Skripte.

Wir ersetzten auch Google Analytics mit Plausible (< 1KB, Privacy-fokussiert, Cookie-Consent nicht nötig in den meisten Jurisdiktionen). Entfernten Hotjar komplett — SleepDr überprüfte die Recordings nicht aktiv. Entfernten das Facebook-Pixel, da sie sechs Monate zuvor Facebook-Anzeigen eingestellt hatten.

Unnötige Drittanbieter-Skripte zu killen ist der einfachste Performance-Gewinn in der Web-Entwicklung. Ich sage das immer wieder. Die meisten Sites laden Skripte für Services, die niemand im Team aktiv nutzt.

Optimierung 6: CSS-Optimierung (800KB → 35KB)

SleepDrs WordPress-Theme versendete ungefähr 800KB CSS. Das enthielt das Theme-Stylesheet, Plugin-Stylesheets, ein vollständiges Bootstrap-Grid-System (ungenutzt) und Font Awesome (für etwa 12 Icons).

Was wir taten

Tailwind CSS mit automatischem Purging. Tailwind scannt Ihre Template-Dateien zur Build-Zeit und generiert CSS nur für die Utility-Klassen, die Sie tatsächlich verwenden. Unser Production-CSS-Bundle: 35KB (gzipped: ~8KB).

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

Für die 12 Icons verwendeten wir inline SVGs. Keine Icon-Bibliothek. Jedes SVG ist etwa 500 Bytes. Gesamt Icon-Gewicht: ~6KB versus Font Awesome's 70KB+.

Das Ergebnis ist null Rendering-blockierende CSS-Anfragen. Tailwinds Output wird von Next.js in die initiale HTML-Payload eingefügt, damit der Browser sofort mit dem Rendering beginnen kann.

Netto-Impact: CSS reduziert um 96%, trägt zu FCP und TBT Verbesserungen bei.

Die Schritt-für-Schritt-Checkliste

Wenn Sie ähnliche Performance-Probleme haben, hier ist die exakte Reihenfolge, in der ich Dinge anpacken würde. Dies ist nach Impact-zu-Aufwand-Verhältnis priorisiert.

Phase 1: Quick Wins (Woche 1)

  • Lighthouse auf Ihren 10 höchsten Traffic-Seiten ausführen (Mobile-Modus)
  • LCP-Elemente auf jeder Seiten-Template identifizieren
  • Explizite width und height zu allen Bildern und iframes hinzufügen
  • loading="lazy" zu Bildern unter dem Falz hinzufügen
  • fetchpriority="high" zu LCP-Bildern hinzufügen
  • Drittanbieter-Skripte audittieren — alles Ungenutzte entfernen
  • Verbleibende Drittanbieter-Skripte zu async oder defer verschieben

Phase 2: Schrift und CSS (Woche 2)

  • Web Fonts self-hosten (externe Font-Anfragen beseitigen)
  • font-display: swap zu allen @font-face Deklarationen hinzufügen
  • Fonts zu nur benötigten Zeichensätzen subsetten
  • CSS audittieren — ungenutzte Stylesheets entfernen
  • Icon Fonts durch inline SVGs ersetzen

Phase 3: JavaScript (Woche 3)

  • Bundle analysieren, um größte JS-Abhängigkeiten zu identifizieren
  • jQuery entfernen, wenn möglich
  • Nicht-kritische Komponenten dynamisch importieren
  • Nicht-essentielles JavaScript aufschieben
  • Code Splitting pro Route implementieren

Phase 4: Infrastruktur (Woche 4+)

  • CDN / Edge Deployment Optionen evaluieren
  • Statische Generierung für Content-Seiten implementieren
  • Richtige Cache-Header einrichten
  • Vollständige Migration zu modernem Framework erwägen, wenn WordPress der Engpass ist

Wenn Sie jenen letzten Punkt in Betracht ziehen — eine vollständige Migration — nehmen Sie Kontakt mit uns auf. Wir haben diesen exakten Projekttyp viele Male durchgeführt. Unsere Pricing-Seite hat Details über das, was Headless-Migrationen typischerweise kosten.

Was die 2026 Core Web Vitals für Ihre Website bedeuten

Googles Core Update vom März 2026 änderte das Spiel. CWV wird nicht mehr pro-Seite evaluiert — es wird über Ihre gesamte Domain aggregiert, gewichtet nach Traffic. Dies bedeutet:

  • Eine einzelne langsame Seiten-Template, die von 200 Blogbeiträgen verwendet wird, wird Ihre ganze Site-Ranglisten in den Keller ziehen
  • High-Traffic-Seiten haben mehr Gewicht in der aggregierten Score
  • Sie können nicht einfach Ihre Homepage optimieren und es damit belassen

Frühe Daten aus dem Rollout zeigen Sites mit schlechtem CWV erlebten organische Traffic-Rückgänge von 20-35%. Einige sahen Verluste über 50%. Die Sites, die am schnellsten wiederhergestellt wurden, waren diejenigen, die Performance auf Infrastruktur-Ebene adressierten — nicht durch Tweaks an einzelnen Seiten, sondern durch Behebung der zugrundeliegenden Architektur.

Dies ist genau warum SleepDrs Migration so effektiv war. Wir optimierten nicht 228 einzelne WordPress-Seiten. Wir bauten das gesamte Delivery-System neu, damit jede Seite standardmäßig schnell ist.

Für Sites, die noch nicht für eine vollständige Migration bereit sind, bieten Frameworks wie Astro einen anderen überzeugenden Weg — besonders für Content-reiche Sites, wo Sie standardmäßig fast null JavaScript haben möchten.

Ansatz Typische Kosten Zeitrahmen Erwarteter Lighthouse-Gewinn
WordPress Plugin-Optimierung (WP Rocket, ShortPixel) $100-500/Jahr 1-2 Wochen +10-20 Punkte
WordPress Theme Austausch $2.000-5.000 2-4 Wochen +15-25 Punkte
Headless CMS Migration (Next.js/Astro) $15.000-50.000 4-10 Wochen +30-60 Punkte
Vollständiger Platform Rebuild $30.000-100.000+ 8-20 Wochen +40-65 Punkte

SleepDrs Projekt fiel in den $20.000-25.000 Bereich für die vollständige Migration, einschließlich Content-Transfer aller 228 Beiträge, CMS-Setup, benutzerdefinierte Komponenten und Performance-Optimierung. Vercel-Hosting läuft $20/Monat auf dem Pro-Plan. Das ist ungefähr $740/Jahr in Hosting versus die $300/Jahr, die sie für gemeinsames Hosting zahlten, das TTFB nicht unter 2 Sekunden halten konnte.

Der ROI? Ihr organischer Traffic erholte sich innerhalb von 6 Wochen und übertraf Pre-Decline-Levels um Woche 10. Für ein Business, das von organischer Suche abhängt, zahlte sich die Migration innerhalb des ersten Quartals selbst.

FAQ

Wie lange dauert es, bis Core Web Vitals Verbesserungen die Google-Ranglisten beeinflussen? Aus unserer Erfahrung mit SleepDr und ähnlichen Projekten beginnt Search Console, aktualisierte CWV-Daten innerhalb von 28 Tagen nach dem Deployment zu zeigen. Ranking-Verbesserungen folgen typischerweise 2-3 Monate später. Google muss Ihre Seiten neu durchsuchen, frische Field-Daten von echten Chrome-Benutzern sammeln (CrUX-Daten) und das in seine Ranking-Algorithmen einbinden. Erwarten Sie keine Sofortverbesserungen — aber erwarten Sie messbare Verbesserung innerhalb eines Quartals.

Ist ein Lighthouse-Score von 94 tatsächlich für eine echte Production-Website erreichbar? Ja, aber es erfordert absichtliche Architektur-Entscheidungen von Anfang an. Lab-Scores über 90 auf Mobile sind mit modernen Frameworks wie Next.js oder Astro erreichbar, wenn Sie Ihre Drittanbieter-Skripte kontrollieren, Bilder richtig optimieren und auf einem Edge-Network deployen. Der Schlüssel ist, dass jede Komponente performance-bewusst sein muss. Ein schlechtes Embed oder unoptimiertes Drittanbieter-Widget kann Sie zurück zu den 70ern werfen.

Muss ich von WordPress wegmigrieren, um gute Core Web Vitals Scores zu bekommen? Nicht unbedingt. WordPress-Sites können gut abschneiden mit dem richtigen Theme, aggressivem Caching (WP Rocket + Cloudflare), optimiertem Hosting (Kinsta, WP Engine) und minimalen Plugins. Realistisch werden die meisten WordPress-Sites, die wir audittieren, zwischen 30-60 auf Mobile geranked, weil von angesammeltem Plugin-Ballast und Theme-Overhead. Wenn Sie unter 50 sind, wird Plugin-Optimierung allein Sie wahrscheinlich nicht über 75 bringen. Ein Headless-Ansatz — wo WordPress als Content-API dient, während ein Frontend-Framework das Rendering handhabt — ist oft der zu erforschende Mittelweg.

Was ist der Unterschied zwischen Lighthouse-Scores und echten Core Web Vitals-Daten? Lighthouse ist ein Lab-Tool — es simuliert ein Mittelklasse-Telefon auf gedrosseltem 4G und gibt dir synthetische Scores. Core Web Vitals in Search Console sind Field-Daten — echte Messungen von echten Chrome-Benutzern, die Ihre Site über ein 28-tägiges Rolling-Fenster besuchen. Google verwendet Field-Daten für Ranking-Signale, nicht Lab-Scores. Lighthouse ist nützlich zum Diagnostizieren von Problemen und zum Testen von Fixes, aber Dein Ziel ist grüner CWV-Status in Search Console am 75. Perzentil.

Was ist die einflussreichste einzelne Optimierung für LCP? Bildoptimierung. In ungefähr 60% der Sites, die wir audittieren, ist das LCP-Element ein Bild. Richtige Größung, Servieren im WebP/AVIF-Format, Hinzufügen von fetchpriority="high" und Sicherstellen, dass es nicht lazy-loaded wird, wird typischerweise LCP um 2-4 Sekunden schneiden. Bei SleepDr machte Bildoptimierung allein ungefähr 3 Sekunden LCP-Verbesserung.

Wie funktioniert Googles 2026 ganzheitliche CWV-Bewertung? Seit dem Core Update vom März 2026 aggregiert Google Core Web Vitals-Daten über Ihre gesamte Domain statt Seiten einzeln zu evaluieren. High-Traffic-Seiten haben mehr Gewicht in der Berechnung. Das bedeutet eine langsame Blog-Archiv-Template, die auf Hunderten von Seiten verwendet wird, wird auch Ihre Homepage-Ranglisten mit sich ziehen. Der Fix ist architektonisch — Sie brauchen jede Seiten-Template, um CWV-Schwellenwerte zu passieren, nicht nur Ihre Key-Landing-Pages.

Wie viel kostet typischerweise eine WordPress zu Next.js Migration? Für eine Content-Site ähnlich SleepDr (200+ Seiten, Standard-Blog-Layout, Kontaktformulare, kein E-Commerce), erwarten Sie $15.000-30.000 von einer erfahrenen Agentur. E-Commerce-Migrationen sind höher — $30.000-75.000+ je nach Komplexität. Laufendes Hosting auf Vercel Pro ist $20/Monat. Der ROI hängt davon ab, wie viel organischer Traffic für Ihr Business wert ist, aber für Sites, die Traffic-Rückgänge von schlechtem CWV erlebten, zahlt sich die Migration typischerweise innerhalb von 3-6 Monaten selbst.

Sollte ich mich auf Mobile oder Desktop Lighthouse-Scores konzentrieren? Mobile. Immer Mobile First. Google nutzt Mobile-First-Indexierung, und Lighthouse Mobile-Bewertung ist signifikant stärfer als Desktop, da sie ein begrenztes Gerät und Netzwerk simuliert. Wenn Ihr Mobile-Score 94 ist, wird Ihr Desktop-Score fast sicher 95+ sein. SleepDrs Desktop-Score von 99 erforderte zusätzliche Arbeit über das hinaus, das wir für Mobile-Optimierung taten.