Core Web Vitals: Warum maßgeschneiderter Code 100 erreicht – und WordPress selten über 60 kommt

Es gibt einen strukturellen Grund, warum handgeschriebene Seiten die Core Web Vitals bestehen, während Baukasten-Seiten um jeden Punkt kämpfen: Sauberer Code schleppt schlicht nicht den Ballast mit, der die Metriken zerstört. Die Core Web Vitals sind ein bestätigter Google-Ranking-Faktor, und hier ist, was die meisten Entwickler nicht laut sagen: Die gewählte Plattform entscheidet rund 80 % Ihres Basis-Scores, bevor Sie überhaupt optimieren. Individuelles PHP erreicht mit minimalem Aufwand 100; WordPress bleibt selbst mit Caching-Plugins oft im Bereich 40–60. Ich habe beides gebaut und optimiert, das ist also keine Theorie. Ich zeige Ihnen genau, warum – mit echten Zahlen, echtem Code und echten Kundenergebnissen.

Die geschäftliche Notwendigkeit, Core Web Vitals zu bestehen

Bevor wir in den Code eintauchen, verstehen Sie die Auswirkungen. Googles Daten zeigen:

• Websites, die Core Web Vitals bestehen, verzeichnen 24 % weniger Benutzerabbrüche.
• Eine Verbesserung des LCP um 0,5 s kann die Conversions um 12–15 % steigern (Google-Fallstudie).
• Die Seitenerfahrung ist jetzt ein Entscheidungskriterium, wenn zwei Seiten ähnliche Relevanz haben.

Ihre Plattformwahl ist nicht nur eine Frage der Entwicklerfreundlichkeit – sie ist ein direkter Treiber für Umsatz und Rankings.

Die Rohdaten: Maßgeschneidertes PHP vs. WordPress (gleicher Server)

Ich habe einen kontrollierten Test auf identischem Hosting durchgeführt (Hostinger VPS, 2 vCPU, 2 GB RAM, NVMe-Speicher). Zwei Websites:

• Seite A: Maßgeschneidertes PHP/HTML, kein Framework, minimales CSS/JS, handoptimiert.
• Seite B: Frisches WordPress 6.7 + Astra-Theme + 5 wesentliche Plugins (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

Die 847 KB JavaScript sind das Problem. WordPress lädt jQuery, den Block-Editor, Plugin-Skripte und Theme-Assets – selbst wenn Sie sie nicht verwenden. Googles Lighthouse misst alles, und jedes Kilobyte addiert sich zu LCP und INP.

Core Web Vitals erklärt (Schwellenwerte 2026)

Google hat bestätigt, dass die Seitenerfahrung ein Ranking-Signal auf mobilen Geräten und Desktops ist. Im Jahr 2026 gelten folgende Schwellenwerte:

• LCP (Largest Contentful Paint) – misst die Ladegeschwindigkeit. Gut: unter 2,5 s.
• INP (Interaction to Next Paint) – misst die Reaktionsfähigkeit. Gut: unter 200 ms (ersetzte FID im Jahr 2024).
• CLS (Cumulative Layout Shift) – misst die visuelle Stabilität. Gut: unter 0,1.
• TTFB (Time To First Byte) – Serverantwort. Gut: unter 600 ms (inoffiziell, aber Google verwendet es).

Eine Website, die diese Metriken nicht erfüllt, wird unter schnellere Konkurrenten verdrängt – selbst wenn sie mehr Backlinks hat.

Wie maßgeschneidertes PHP eine perfekte 100 erreicht (echter Code + Edge-Techniken)

Hier ist genau das, was ich bei jedem maßgeschneiderten Build tue, um einen Lighthouse-Score von 100 zu garantieren.

1. Kritische Assets vorladen

Sagen Sie dem Browser, was am wichtigsten ist, bevor er überhaupt HTML parst.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Oberflächennahes CSS inline einbinden (FCP halbieren)

Extrahieren Sie nur die für den sichtbaren Bereich benötigten Stile. Verwenden Sie die Chrome Coverage-Registerkarte, um ungenutztes CSS zu finden.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Responsive Bilder mit srcset und WebP bereitstellen

Die meisten Websites liefern Desktop-große Bilder an mobile Geräte – eine enorme LCP-Strafe. Verwenden Sie `srcset`, um angemessen große Bilder bereitzustellen.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Serverantwort optimieren (TTFB)

Ich verwende PHP‑FPM mit aktiviertem OPcache, GZIP-Komprimierung und Datenbankindizierung. Kein WordPress `wp_query`-Overhead bedeutet, dass Abfragen in 5–15 ms zurückkehren, nicht 150 ms. Zusätzliche Anpassungen:

• Keep‑Alive und HTTP/2 aktivieren.
• Ein CDN (Cloudflare oder Bunny.net) verwenden, um statische Assets zwischenzuspeichern.
• Datenbank auf einen separaten Server verschieben oder Redis für die Objektzwischenspeicherung verwenden, falls erforderlich.

5. Layout-Verschiebungen eliminieren (CLS = 0,01)

Jedes Bild, Video und jede Anzeigenfläche erhält explizite `width`- und `height`-Attribute. Reservieren Sie Platz für Schriftarten mit `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Nicht kritisches JavaScript verzögern

Verwenden Sie `defer` oder `async` für alle externen Skripte und verschieben Sie Analysen, um nach der Benutzerinteraktion geladen zu werden.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. `loading="lazy"` für Bilder unterhalb des Falzes verwenden

Anfangs nicht sichtbare Bilder sollten lazy-geladen werden. Das spart Bandbreite und beschleunigt LCP.

Warum WordPress diese Zahlen nicht einfach erreichen kann

• Jedes Plugin fügt sein eigenes CSS/JS hinzu, oft ohne `async` oder `defer`. Selbst „optimierte“ Plugins fügen Overhead hinzu.
• Der Block-Editor lädt über 500 KB JavaScript, selbst wenn Sie nur eine einfache Seite verwenden. Das ist ein halbes Megabyte ungenutzten Codes.
• Caching-Plugins helfen, aber sie können die zugrunde liegende Aufblähung nicht entfernen – sie cachen nur die bereits aufgeblähte Ausgabe.
• Drittanbieter-Themes bündeln ganze Frameworks (Bootstrap, Tailwind) – 90 % ungenutztes CSS, das das Rendering weiterhin blockiert.

Selbst wenn Sie vorübergehend eine 90 bei Lighthouse erreichen, kann ein Plugin-Update oder ein neues Theme dies über Nacht auf 45 senken. Mit maßgeschneidertem PHP ist Ihre Leistung deterministisch – sie ändert sich nur, wenn Sie sie ändern.

Zwei echte Kundentransformationen

Fallstudie 1: WooCommerce-Schmuckgeschäft → Maßgeschneidertes PHP

Ein Schmuckgeschäft hatte eine WooCommerce-Site mit einem Lighthouse-Score von 43 (mobil). Sie hatten 12 aktive Plugins, ein aufgeblähtes Theme und Ladezeiten von 4,2 s. Nach der Migration zu einem maßgeschneiderten PHP-Shop mit Stripe Checkout:

• Lighthouse-Score: 43 → 98.
• Mobile Ladezeit: 4,2 s → 0,9 s.
• Conversion-Rate: 1,8 % → 3,4 % (+89 %).
• Der durchschnittliche Bestellwert stieg um 22 % (schnellerer Checkout förderte Upgrades).

Fallstudie 2: Immobilien-Website mit über 500 Seiten

Eine Immobilienagentur hatte eine WordPress-Site mit Seitenladezeiten von 3,5 Sekunden und einem CLS von 0,28 (schlecht). Wir haben das Front‑End als maßgeschneiderte PHP-Site mit einer leichten Vorlage, inline-kritischem CSS und vorgeladenen Hero-Bildern neu aufgebaut.

• LCP: 3,1 s → 0,9 s.
• CLS: 0,28 → 0,02.
• Absprungrate sank von 58 % auf 37 %.
• Die Kontaktformular-Einsendungen stiegen innerhalb von 60 Tagen um 41 %.

Die versteckten Kosten von Page Buildern: Wix, Squarespace, Shopify

Es ist nicht nur WordPress. Alle Drag-and-Drop-Plattformen leiden unter schlechten Standardeinstellungen:

• Wix/Squarespace: Inline-Stile überall, enorme DOM-Größe und keine Kontrolle über kritisches CSS. Durchschnittlicher Lighthouse-Mobil-Score: 30–50.
• Shopify: Besser als Wix, aber Themes laden schweres JavaScript und externe Schriftarten. Durchschnittlicher Score: 60–75.
• Webflow: Kann optimiert werden, erfordert aber Expertenwissen und liefert immer noch aufgeblähten Code im Vergleich zu handgeschriebenem PHP.

Nur maßgeschneidertes PHP gibt Ihnen die vollständige Kontrolle über jedes Byte, das den Browser erreicht.

So starten Sie (auch wenn Sie kein Entwickler sind)

Sie müssen nicht alles von Grund auf neu schreiben. Ich erstelle jede Website manuell, damit Sie eine 100 % maßgeschneiderte Codebasis erhalten. Das Ergebnis: ein Lighthouse-Score, den Sie als Screenshot als Vertrauenssignal verwenden können. Sie können auch mit einem Static Site Generator (Hugo, Eleventy) beginnen und später PHP für dynamische Funktionen hinzufügen.

Aktionsplan: Bringen Sie Ihre Website heute auf 100

1. Testen Sie Ihre aktuelle Website auf PageSpeed Insights (mobil). Notieren Sie LCP, INP, CLS.
2. Beheben Sie einfache Probleme: Komprimieren Sie Bilder, aktivieren Sie Caching, entfernen Sie ungenutzte Plugins.
3. Wenn Sie unter 70 liegen, ziehen Sie eine Plattformmigration in Betracht. Der ROI einer maßgeschneiderten PHP-Site amortisiert sich oft in 6–12 Monaten durch höhere Conversions und niedrigere Hosting-Kosten.
4. Oder beauftragen Sie mich. Ich werde Ihnen eine maßgeschneiderte PHP-Site bauen, die 100 erreicht – garantiert.

Abschließende Zusammenfassung: Die Plattformwahl ist 80 % der Schlacht

Sie können jede Website optimieren, aber mit maßgeschneidertem PHP zu beginnen, verschafft Ihnen einen enormen Vorsprung. WordPress erfordert einen ständigen Kampf gegen seine eigene Architektur. Wix und Squarespace sperren Sie in langsame Vorlagen ein. Maßgeschneidertes PHP gibt Ihnen die vollständige Kontrolle. Die Zahlen sprechen für sich.

Wenn Sie eine Website wünschen, die nativ 96–100 bei Lighthouse erreicht und Page Builder übertrifft, sprechen Sie mit mir.

Alle Testdaten wurden auf Hostinger VPS (2 vCPU, 2 GB RAM) mit Lighthouse 12.0 (Mobil-Simulation) gesammelt. Ihre Ergebnisse können je nach Inhalt und Hosting variieren.