Core Web Vitals für PHP-Sites: So beheben Sie LCP, INP und CLS

Core Web Vitals für PHP-Sites sind kein reines Frontend-Thema. Eine langsame PHP-Seite kann eine Sekunde damit verbringen, nur HTML zu erstellen, und keine noch so große Bildoptimierung kann das wiederherstellen. Gleichzeitig hilft ein sehr schneller Server nicht, wenn ein 1,5 MB großes Hero-Image den größten Paint blockiert. So gehen wir auf unseren eigenen PHP-Seiten (integrono.com führt PHP-FPM hinter nginx und Cloudflare aus) und bei Kundenprojekten auf beide Seiten ein.

Was Core Web Vitals messen

• LCP ( Largest Contentful Paint): wenn das größte sichtbare Element (normalerweise ein Hero-Bild oder ein Überschriftenblock) gerendert wird. Gut ist 2,5 Sekunden oder weniger.
• INP ( Interaction to Next Paint): Wie schnell die Seite während des gesamten Besuchs nach Klicks, Tippen und Tastendrücken visuell reagiert. Gut ist 200 ms oder weniger.
• CLS ( Cumulative Layout Shift): Gibt an, wie viel Inhalt beim Laden hin und her springt. Gut ist 0,1 oder weniger.

Google wertet sie anhand von Felddaten von echten Chrome-Nutzern im 75. Perzentil aus, getrennt für Mobilgeräte und Desktops. Das bedeutet, dass eine langsame Vorlage oder ein langsames Land die gesamte Gruppe scheitern lassen kann. Labortools wie Lighthouse dienen dem Debuggen, nicht der Endbewertung.

Schritt 1. Messen Sie richtig

1. Öffnen Sie den Core Web Vitals -Bericht in Google Search Console um zu sehen, welche URL-Gruppen bei welcher Metrik fehlschlagen.
2. Überprüfen Sie PageSpeed Insights auf eine URL aus jeder fehlerhaften Gruppe. Der oberste „Felddaten“-Block ist das, was zählt; Der Lighthouse unten ist ein Labortest, der erklärt, warum.
3. Verwenden Sie das Leistungsfenster in Chrome DevTools mit CPU-Verlangsamung um das Vierfache und „Langsam 4G“, um ein typisches mobiles Erlebnis zu reproduzieren.
4. Erfassen Sie zur fortlaufenden Überwachung reale Benutzerdaten mit der JavaScript-Bibliothek web-vitals und senden Sie diese an Ihre Analyse.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Schritt 2. Korrigieren Sie zunächst die Server-Antwortzeit ( TTFB).

LCP umfasst die Zeit, bevor das erste Byte eintrifft. Wenn die Generierung Ihres HTML-Codes 800 ms dauert, haben Sie bereits ein Drittel des Budgets ausgegeben. Auf PHP-Seiten sind die üblichen Hebel:

• Aktivieren Sie OPcache und stellen Sie sicher, dass es groß genug ist, um alle Skripte aufzunehmen. Ohne sie kompiliert PHP die Dateien bei jeder Anfrage neu.
• PHP-FPM optimieren. Zu wenige Worker-Warteschlangenanfragen, zu viele erschöpfen den Speicher. Achten Sie auf der PHP-FPM -Statusseite auf „Listen Queue“ und „Max. Kinder erreicht“.
• Ganze Seiten für anonyme Besucher zwischenspeichern (nginx fastcgi_cache, ein Laravel Antwort-Cache oder Cloudflare -Cache-Regeln) und Fragmente oder Abfrageergebnisse mit Redis zwischenspeichern.
• Beheben Sie langsame Abfragen. Aktivieren Sie das langsame Abfrageprotokoll, suchen Sie nach N+1-Mustern und fügen Sie Indizes hinzu. Eine Seite, die 120 Abfragen ausführt, ist unabhängig von der PHP-Version langsam.
• Halten Sie PHP aktuell. Neuere PHP-Versionen sind schneller und verbrauchen weniger Speicher.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Legen Sie pm.max_children aus dem realen Speicher fest: Teilen Sie den Speicher, den Sie PHP geben können, durch die durchschnittliche Größe eines Arbeitsprozesses (überprüfen Sie dies mit ps). Denken Sie bei validate_timestamps=0 daran PHP-FPM nach jedem Deployment neu zu laden, da sonst alter Code im Speicher verbleibt.

Aktivieren Sie auf Webserverebene HTTP/2 oder HTTP/3, Brotli oder gzip und langlebige Caching-Header für statische Dateien:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Verwenden Sie versionierte Dateinamen oder eine ?v=-Abfrage basierend auf der Änderungszeit der Datei, damit „unveränderlich“ niemals veraltete Assets bereitstellt.

Schritt 3. Befestigen Sie das LCP -Element

Suchen Sie das LCP Element in PageSpeed Insights oder im DevTools-Leistungsfenster. Auf den meisten Inhaltsseiten handelt es sich um ein Heldenbild. Dann:

• Laden Sie es nicht zu langsam. loading="lazy" auf dem LCP Image verzögert es. Verwenden Sie stattdessen fetchpriority="high".
• In der richtigen Größe servieren. Ein 2400-Pixel-Bild für einen 900-Pixel-Slot verschwendet Bytes. Verwenden Sie srcset und sizes.
• Verwenden Sie WebP oder AVIF. Typische Einsparungen liegen bei 30 bis 60 Prozent gegenüber JPEG bei ähnlicher Qualität.
• Vermeiden Sie Ketten. Ein über CSS-Hintergrund eingestelltes oder per JavaScript eingefügtes Bild wird spät entdeckt. Fügen Sie es als <img> in den HTML-Code ein.
• Drittanbieter-Ursprünge, von denen das LCP abhängt (Schriftarten, Bild-CDN), vorab verbinden oder selbst hosten.

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Dies ist das Muster, das der Artikel in diesem Blog behandelt: zwei WebP Größen, explizite Abmessungen und eine hohe Abrufpriorität für den Helden.

Schritt 4. Layoutverschiebungen entfernen ( CLS)

• Legen Sie immer width und height (oder aspect-ratio in CSS) für Bilder, Videos und Iframes fest, damit der Browser den Platz reserviert.
• Reservieren Sie Platz für Banner, Cookie-Hinweise und Anzeigen. Setzen Sie sie in einen Behälter mit einer festen Mindesthöhe ein, anstatt den Inhalt nach dem Beladen nach unten zu drücken.
• Schriftarten: Verwenden Sie font-display: swap oder optional, laden Sie die Hauptschriftartdatei vor und legen Sie eine Teilmenge davon fest. Wählen Sie eine Ersatzschriftart mit ähnlichen Metriken.
• Fügen Sie keine Inhalte über vorhandenen Inhalten ein, es sei denn, der Benutzer hat dies ausgelöst.
• Animieren Sie mit transform und opacity, nicht mit Eigenschaften, die das Layout ändern (top, height).

Schritt 5. INP verbessern: weniger JavaScript im Hauptthread

INP ist die neueste Metrik und wird von PHP-Entwicklern vernachlässigt, da der Server keinen direkten Einfluss darauf hat. Die Ursachen liegen im Browser: lange Aufgaben aus großen Bundles, umfangreiche Skripte von Drittanbietern (Analysen, Chat-Widgets, Tag-Manager) und Handler, die zu viel synchron arbeiten.

• Überwachen Sie Skripte von Drittanbietern. Entfernen Sie, was niemand verwendet, laden Sie den Rest mit defer oder nach der ersten Interaktion.
• Teilen Sie lange Aufgaben auf. Teilen Sie die Arbeit mit requestIdleCallback, setTimeout oder der Scheduler API in Blöcke auf. Verschieben Sie umfangreiche Berechnungen auf einen Web Worker.
• Halten Sie das DOM klein. Tausende Knoten machen jedes Update langsam.
• Vermeiden Sie erzwungene synchrone Layouts in Schleifen (abwechselndes Lesen und Schreiben von Layouteigenschaften).
• Zeigen Sie sofortiges Feedback (einen gedrückten Zustand oder einen Spinner), bevor Sie mit der langsamen Arbeit beginnen.

Schritt 6: Schützen Sie es in Ihrem Bereitstellungsprozess

Die Leistung nimmt leise ab: ein neues Tag, ein schwererer Held, eine zusätzliche Abfrage auf der Startseite. Fügen Sie Lighthouse CI oder eine geplante PageSpeed-API-Prüfung für Ihre fünf wichtigsten Vorlagen hinzu, legen Sie Budgets fest ( LCP, JS-Gesamtgröße, Bildgewicht) und benachrichtigen Sie, wenn diese überschritten werden. Vergleichen Sie TTFB vor und nach jeder Veröffentlichung. Wenn es springt, ist die Ursache fast immer eine Abfrage oder ein Cache, der nicht mehr trifft.

Eine realistische Arbeitsordnung

1. Messen Sie Felddaten und identifizieren Sie fehlerhafte URL-Gruppen.
2. Aktivieren Sie OPcache, überprüfen Sie PHP-FPM -Einstellungen und fügen Sie Ganzseiten-Caching für anonymen Datenverkehr hinzu.
3. Heldenbilder korrigieren: Format, Größe, Priorität, Abmessungen.
4. Reservieren Sie Platz für alles, was spät lädt.
5. JavaScript reduzieren und zurückstellen; Entfernen Sie ungenutzte Dritte.
6. Führen Sie die Messung nach 28 Tagen erneut durch, da es sich bei den Felddaten um ein rollierendes Fenster handelt.

Erwarten Sie, dass die Verbesserungen nach und nach in Search Console sichtbar werden: Der Bericht verwendet ungefähr die Daten der letzten 28 Tage, sodass ein heute ausgelieferter Fix erst nach etwa einem Monat vollständig sichtbar ist.

Wie wir helfen können

Wir führen Performance-Arbeiten an PHP- und Laravel -Projekten im Rahmen eines technischen SEO-Auftrags und als einmalige Optimierungen durch: Caching, Abfragen, Bilder und Front-End-Korrekturen, die im Code geliefert werden. Wenn Sie wissen möchten, welche der oben genannten Änderungen sich auf Ihrer Website auszahlen würden, buchen Sie eine Beratung oder eine Serveranalyse. Eine umfassendere Checkliste rund um Crawling und Indexierung finden Sie in unserer technischen SEO-Audit-Checkliste.