Core Web Vitals und Webhosting: Was kannst du tatsächlich beeinflussen?

Core Web Vitals und Webhosting: Was du tatsächlich beeinflussen kannst

Core Web Vitals sind Googles Kennzahlen zur Benutzererfahrung, die sich direkt auf Suchrankings auswirken. Drei davon – Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) – haben bestimmte Schwellenwerte, anhand derer eine gute von einer schlechten Leistung unterschieden wird. Deine Hosting-Infrastruktur ist direkt für zwei davon verantwortlich und teilweise verantwortlich für…

Die drei wichtigsten Web Vitals und wie sich das Hosting auf jeden einzelnen auswirkt

Größte inhaltsreiche Malfläche (LCP)

LCP misst, wie lange es dauert, bis das größte sichtbare Element auf einer Seite geladen ist. Bei den meisten Websites ist das ein Hero-Bild, ein großer Überschriftenblock oder ein Video-Thumbnail. Ein guter Wert liegt unter 2,5 Sekunden. Schlecht ist alles über 4 Sekunden.

Das Hosting ist der wichtigste Faktor für den LCP. Die „Time to First Byte“ (TTFB) des Servers ist die erste Verzögerung in der LCP-Kette. Bevor der Browser mit dem Laden des Hauptinhalts beginnen kann, muss er das erste Byte des HTML-Dokuments vom Server empfangen. Eine langsame Serverantwort führt zu einem langsamen LCP, ganz gleich, wie gut die Seite auf der Frontend-Seite optimiert ist.

Auf einem gut konfigurierten NVMe liegt die TTFB unter 200 Millisekunden. Bei einem Shared-Hosting-Paket mit einem ausgelasteten Server überschreitet sie häufig 600 bis 800 Millisekunden. Allein dieser Unterschied kann den LCP-Wert von „gut“ auf „verbesserungswürdig“ verschieben, ohne dass auch nur ein einziges Bild zu groß ist.

Interaktion bis zur nächsten Malung (INP)

INP hat 2024 First Input Delay (FID) als Core Web Vital abgelöst. Es misst die Latenz aller Interaktionen auf einer Seite während der gesamten Sitzung, nicht nur der ersten. Der Richtwert liegt unter 200 Millisekunden.

Der INP-Wert hängt in erster Linie von der Ausführung von JavaScript und der Darstellung durch den Browser ab, nicht von der Antwortzeit des Servers. Schwere Frontend-JS-Frameworks, aufgeblähte Plugins und zu viele Skripte von Drittanbietern sind die Hauptursachen für einen schlechten INP-Wert. Das Hosting hat einen indirekten Einfluss: Ein schnellerer Server sorgt dafür, dass die Seite schneller geladen wird, wodurch der Browser mehr Zeit hat, das JavaScript zu verarbeiten, bevor der Nutzer mit der Interaktion beginnt.

Kumulative Layoutverschiebung (CLS)

CLS misst, wie stark sich Inhalte beim Laden der Seite unerwartet verschieben. Ein Wert unter 0,1 ist gut. CLS hängt fast ausschließlich vom Frontend ab und wird von der Serverkonfiguration kaum beeinflusst. Typische Ursachen sind nicht festgelegte Bildabmessungen, spät geladene Schriftarten und dynamisch eingefügte Inhalte.

Zeit bis zum ersten Byte: Der direkte Beitrag deines Servers

TTFB ist die Variable bei der Hosting-Leistung, die sich im Rahmen der Core Web Vitals am besten beeinflussen lässt. Sie gibt die Zeit an, die zwischen dem Absenden einer HTTP-Anfrage durch den Browser und dem Empfang des ersten Bytes der Antwort vergeht. Darin enthalten sind die Zeit für die DNS-Auflösung, den Verbindungsaufbau (TCP und TLS) sowie die Verarbeitungszeit auf dem Server.

Die Server-Verarbeitungszeit hängt direkt von deiner Infrastruktur ab. Eine PHP-Anwendung, die bei jeder Anfrage eine Seite aus einer Datenbankabfrage generieren muss, benötigt länger für die Antwort als eine, die eine zwischengespeicherte HTML-Version ausliefert. Die Hosting-Infrastruktur bestimmt, wie schnell dieser Cache bereitgestellt wird und wie effizient die Datenbank reagiert, wenn der Cache nicht ausreicht.

Was der richtige Hosting-Stack tatsächlich für den LCP leistet

Der Leistungsunterschied zwischen den Hosting-Stufen ist kein theoretisches Phänomen. Unabhängige GTmetrix-Tests der NVMe Infrastruktur InMotion Hostingzeigen durchweg eine TTFB von unter 200 Millisekunden für WordPress auf optimierten VPS-Konfigurationen, verglichen mit 600 bis über 1.000 Millisekunden bei Shared-Hosting-Umgebungen niedrigerer Stufen oder mit schlechter Konfiguration.

UltraStack von InMotion, die bei Managed-VPS- und WordPress verfügbar ist, kombiniert NGINX Reverse-Proxy, PHP-FPM für die Prozessverwaltung, OPcache für das PHP-Opcode-Caching und Redis für das Objekt-Caching. Jede Komponente beseitigt einen anderen Engpass in der Server-Reaktionskette.

NGINX Reverse-Proxy: Bewältigt die Bereitstellung statischer Dateien und das Verbindungsmanagement unter gleichzeitiger Auslastung effizienter als Apache. Statische Inhalte (CSS, JS, Bilder) werden direkt von NGINX bereitgestellt, NGINX PHP zum Einsatz kommt.

PHP-FPM: Verwaltet einen Pool persistenter PHP-Worker-Prozesse. Eliminiert den Overhead, der entsteht, wenn für jede Anfrage ein neuer PHP-Prozess gestartet wird – ein Verhalten, das Apache mit mod_php unter Last verlangsamt.

OPcache: Speichert vorkompilierten PHP-Skript-Bytecode im Arbeitsspeicher. WordPress Dateien werden einmal kompiliert und bei nachfolgenden Anfragen direkt aus dem Arbeitsspeicher ausgeliefert, wodurch sich die PHP-Ausführungszeit deutlich verkürzt.

Redis-Objekt-Cache: Speichert die Ergebnisse rechenintensiver Datenbankabfragen im Arbeitsspeicher. Eine Seite, für die auf einer WordPress ohne Cache 20 Datenbankabfragen erforderlich wären, kann über Redis mit einem einzigen Lesezugriff aus dem Arbeitsspeicher bereitgestellt werden.

Der Serverstandort und seine Auswirkungen auf die Core Web Vitals

Die physische Entfernung zwischen deinem Server und deinen Nutzern führt zu einer höheren Latenz. Pro 100 Meilen Netzwerkstrecke erhöht sich die Round-Trip-Zeit um etwa 1 Millisekunde. Für Nutzer in deinem Hauptmarkt ist das vernachlässigbar. Für Nutzer auf der anderen Seite der Welt summiert sich dies jedoch mit der TTFB und wird zu einem wesentlichen Faktor für den LCP.

InMotion betreibt Rechenzentren in Los Angeles, Kalifornien, und in Amsterdam in den Niederlanden. Für Unternehmen, deren Zielgruppe hauptsächlich in den USA oder Europa ansässig ist, decken diese Standorte den Großteil der Nutzerbasis mit Verbindungen mit geringer Latenz ab. Für ein globales Publikum leitet die CDN-Integration statische Inhalte über Edge-Knoten weiter, die näher an den Nutzern liegen. Dadurch wird die Belastung des Ursprungsservers verringert und die wahrgenommene Leistung verbessert, unabhängig vom Standort des Ursprungsservers.

Die Kennzahlen, die du nicht allein durch das Hosting verbessern kannst

Es gibt zwei Situationen, die zu schlechten Core Web Vitals führen, die sich durch keine noch so großen Verbesserungen beim Hosting beheben lassen.

Das erste Problem ist überladene Frontend-Seiten. Eine Seite, die 40 Skripte von Drittanbietern, ein nicht optimiertes Hero-Bild mit 8 MB und ein Theme mit 200 KB ungetrenntem JavaScript lädt, wird bei LCP und INP schlecht abschneiden, unabhängig von der Servergeschwindigkeit. Sobald die TTFB unter 200 ms liegt, besteht die verbleibende LCP-Zeit fast ausschließlich aus Download- und Renderzeit. Das erfordert Bildoptimierung, Skript-Audits und Maßnahmen zur Verbesserung der Frontend-Performance.

Der zweite Grund ist eine mangelhafte Caching-Implementierung. Selbst eine Managed-Hosting-Umgebung mit NVMe und NGINX liefert NGINX langsame Seiten, wenn die Anwendung das serverseitige Caching nicht korrekt implementiert. WordPress ohne ein geeignetes Caching-Plugin, das für den Server-Stack konfiguriert ist, führen bei jeder Anfrage eine vollständige PHP-Ausführung durch, wodurch die Vorteile der schnellen Hardware zunichte gemacht werden.

Verwandte Themen: Core Web Vitals: Googles neues Ranking-Signal – hier werden Messinstrumente und Diagnoseansätze ausführlich behandelt.

Eine praktische Checkliste für Agenturen, die Kundenwebsites betreuen

Agenturen, die im Auftrag ihrer Kunden für die Core Web Vitals-Werte verantwortlich sind, sollten sich zunächst um die Hosting- und Infrastrukturebene kümmern, bevor sie mit der Frontend-Optimierung beginnen. Ein schneller Server mit korrektem Caching bildet die notwendige Grundlage für die Frontend-Arbeit.

  • Überprüfe mit GTmetrix oder PageSpeed Insights, ob die TTFB unter 200 ms liegt. Liegt sie über 400 ms, solltest du als Erstes die Hosting-Umgebung unter die Lupe nehmen.
  • Stelle sicher, dass das serverseitige Caching aktiviert ist. Bei WordPress verhindert W3 Total Cache „WP Super Cache“, wenn sie für den jeweiligen Serverstack konfiguriert sind, unnötige PHP-Ausführungen.
  • Vergewissere dich, dass NGINX LiteSpeed statische Dateien direkt und ohne Einbindung von PHP bereitstellt. Dies hängt von der Konfiguration ab und sollte mit deinem Hosting-Anbieter abgeklärt werden.
  • Überprüfe, ob das Objekt-Caching mit Redis oder Memcached für die WordPress aktiviert und konfiguriert ist.
  • Überprüfe die PHP-Version. PHP 8.x bietet gegenüber 7.x deutliche Leistungssteigerungen und sollte bei jeder WordPress in der Produktion als Standard verwendet werden.

Siehe auch: „Die schnellsten Webhosting-Anbieter im Vergleich“ enthält Benchmarks und Details zur Infrastruktur, die für die LCP-Leistung relevant sind.

Das NVMe VPS-Hosting von InMotion liefert bei aktiviertem UltraStack durchweg eine TTFB von unter 200 ms. Sieh dir an, wie sich unsere Infrastruktur auf deine Core Web Vitals-Werte auswirkt: inmotionhosting.com/vps-hosting.
Diesen Artikel teilen
Veröffentlicht in SEO auf

Eine Antwort hinterlassen

Deine E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert