Ladezeit und SEO: Warum das Webhosting über Rankings mitentscheidet

Wenn eine Seite langsam lädt, suchen viele die Ursache zuerst bei Bildern, Skripten und Plugins. Der Blick auf diese Punkte ist berechtigt, lässt aber oft den Server außer Acht. Jede Seitenansicht beginnt auf dem Server, der die Anfrage annimmt, die Seite erzeugt und das erste Byte zurückschickt. Erst danach kann der Browser mit dem Aufbau beginnen, und diese Zeit lässt sich im Frontend nicht mehr aufholen. Google fasst die Nutzererfahrung in den Core Web Vitals zusammen, und mindestens einer dieser Werte hängt direkt an der Serverantwort.
 

Die Zeit bis zum ersten Byte liegt in der Hand des Servers

Die Time to First Byte, kurz TTFB, misst die Spanne vom Absenden einer Anfrage bis zum Eintreffen des ersten Bytes der Antwort. Darin stecken Namensauflösung, Verbindungsaufbau samt Verschlüsselung und die Zeit, die der Server zum Erzeugen der Seite braucht. Als gut gelten nach den Richtwerten von Google 0,8 Sekunden oder weniger, Werte über 1,8 Sekunden als schlecht.

Bei einem Content-Management-System wie WordPress entfällt auf ungecachte Seiten oft ein großer Teil dieser Zeit auf das Rechnen. PHP führt Code aus, die Datenbank liefert Inhalte, und erst danach entsteht das HTML. Bekommt der Server dafür zu wenig Rechenzeit, verlängert sich jede einzelne Seitenansicht, ganz gleich, wie schlank das Theme gebaut ist.

Drei Messwerte bilden die Nutzererfahrung ab

Die Core Web Vitals bestehen aus Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). LCP misst, wann das größte sichtbare Element geladen ist, INP die Reaktion auf Klicks und Eingaben, CLS das Verrutschen von Inhalten während des Ladens. Eine träge Serverantwort verschiebt vor allem den LCP nach hinten, weil der Browser erst nach dem ersten Byte beginnt, Bilder und Stylesheets anzufordern.
 

Gemessen wird das Verhalten echter Besucher, und mobile Aufrufe machen dabei häufig den Großteil aus. Seit der Mobile-First-Indexierung bewertet Google Websites zudem vorrangig anhand ihrer mobilen Fassung. Für das Hosting zählt das doppelt, weil langsame Mobilfunkverbindungen jede zusätzliche Verzögerung auf Serverseite noch deutlich spürbar machen.

Serverstandort und Protokoll verkürzen die Laufwege

Jede Anfrage legt eine physische Strecke zurück, und für Verbindungsaufbau und Verschlüsselung gehen mehrere Nachrichten hin und her, bevor die eigentlichen Daten fließen. Steht der Server nahe bei der Zielgruppe, fällt jede dieser Runden kürzer aus. Für eine Website mit Publikum in Deutschland, Österreich und der Schweiz ist ein Rechenzentrum in Mitteleuropa deshalb ein messbarer Vorteil gegenüber einem Standort in Übersee.
 

Moderne Protokolle senken zusätzlich die Zahl der Runden. HTTP/2 bündelt viele Dateien über eine einzige Verbindung, HTTP/3 setzt auf das Transportprotokoll QUIC und spart beim Verbindungsaufbau weitere Umläufe ein. Browser nutzen beide Protokolle nur über verschlüsselte Verbindungen, ein gültiges TLS-Zertifikat ist also Voraussetzung. Welches Protokoll ein Server tatsächlich spricht, zeigt die Netzwerkanalyse in den Entwicklertools des Browsers.

PHP-Version und Caching sparen Rechenzeit

Neuere PHP-Versionen führen denselben Code meist schneller aus und werden mit Sicherheitskorrekturen versorgt. PHP 8.1 bekommt seit dem Jahreswechsel 2025/26 keine Updates mehr, wer noch darauf setzt, verschenkt Tempo und lässt Lücken offen. Ein Wechsel lohnt sich allerdings erst nach einem Test, weil ältere Plugins auf neue Versionen empfindlich reagieren können.
 

Noch mehr bringt Caching. Ein Seitencache legt fertig erzeugte Seiten ab und liefert sie an weitere Besucher aus, ohne PHP und Datenbank erneut zu bemühen. Ein Objektcache hält häufige Datenbankabfragen im Arbeitsspeicher, und der OPcache speichert bereits übersetzten PHP-Code. Je mehr Anfragen aus einem dieser Zwischenspeicher bedient werden, desto niedriger fällt die TTFB aus.

Shared Hosting teilt Rechenzeit und Arbeitsspeicher

Beim Shared Hosting laufen viele Websites auf einem Server, und jeder Account erhält nur einen festgelegten Anteil an Rechenleistung und Arbeitsspeicher. Erreicht eine Seite diese Grenze, etwa während einer Kampagne oder eines umfangreichen Crawls, warten weitere Anfragen in der Schlange, und die TTFB steigt, obwohl sich am Code nichts geändert hat. Für die Wahl des Tarifs zählen deshalb die konkreten Limits mehr als die beworbene Speichermenge.

Das Webhosting von Anbietern wie hosttech staffelt den Arbeitsspeicher von 512 MB im Paket Light bis 3 GB im Paket All-in und weist die Rechenleistung in Stufen von 100 bis 300 Prozent aus. Gespeichert wird durchgehend auf NVMe-Laufwerken, ein Let's-Encrypt-Zertifikat ist vorinstalliert, und das PHP-Setup lässt sich je Projekt selbst konfigurieren. Die FAQ von hosttech führen knappe Ressourcen ausdrücklich als Ursache langer Ladezeiten an und verweisen WordPress-Projekte auf größere oder eigens optimierte Tarife.

Was kein Tarifwechsel ausgleichen kann

Ein schneller Server verkürzt die Zeit bis zum ersten Byte, die übrigen Werte entstehen jedoch größtenteils im Browser. Typische Bremsen im Frontend sind:

• unkomprimierte oder zu große Bilder, die den LCP verzögern
• umfangreiche Skripte und Tracking-Codes, die den INP verschlechtern
• Bilder, Einbettungen und Werbeflächen ohne reservierten Platz, die Layoutverschiebungen auslösen
• Schriftdateien von fremden Servern, die zusätzliche Verbindungen erfordern

Wer nur den Tarif wechselt und das Frontend unverändert lässt, verbessert deshalb meist nur einen Teil der Kennzahlen. Sinnvoll ist es, zuerst die Serverantwort zu verbessern und danach Bilder, Skripte und Schriften anzugehen.

Mit PageSpeed Insights und Search Console messen

Google nennt in der Dokumentation zu den Core Web Vitals als Ziele für eine gute Nutzerfreundlichkeit einen LCP innerhalb von 2,5 Sekunden, einen INP unter 200 Millisekunden und einen CLS unter 0,1. Eine Seite gilt als bestanden, wenn mindestens drei Viertel ihrer Aufrufe diese Ziele erreichen, getrennt ausgewertet für Mobilgeräte und Desktop. PageSpeed Insights zeigt oben die Felddaten echter Chrome-Nutzer aus den vergangenen 28 Tagen, sofern genügend Aufrufe vorliegen, und darunter einen Labortest mit Lighthouse.
 

Für einen Überblick über die gesamte Domain eignet sich der Core-Web-Vitals-Bericht in der Search Console, die URLs mit ähnlichen Problemen gruppiert. Voraussetzung ist eine bestätigte Property, für die Du beim Einrichten der Google Search Console einen persönlichen Schlüssel auf der Website hinterlegst, etwa als hochgeladene HTML-Datei. Miss vor und nach einem Hostingwechsel unter vergleichbaren Bedingungen und rechne damit, dass sich die Felddaten wegen des 28-Tage-Fensters erst nach einigen Wochen vollständig angleichen.

Fazit

Das Webhosting bestimmt, wie schnell das erste Byte eintrifft, und legt damit den Startpunkt für alle weiteren Ladeschritte fest. Dazu tragen ein Standort nahe der Zielgruppe, aktuelle Protokolle und PHP-Versionen, wirksames Caching und zum Projekt passende Ressourcenlimits bei. Ob ein Wechsel etwas bringt, zeigen erst die Felddaten aus PageSpeed Insights und der Search Console, und den übrigen Teil der Arbeit erledigst Du im Frontend.