Zwei Onlineshops mit identischem Theme, identischen Bildern und identischem Code können sich in der Ladezeit um mehr als eine Sekunde unterscheiden - allein wegen des Servers, auf dem sie laufen. Die Wahl der Hosting-Umgebung ist die grundlegendste Performance-Entscheidung überhaupt, und sie fällt, lange bevor die erste Zeile Frontend-Code optimiert wird. Denn die Server-Antwortzeit, gemessen als Time to First Byte (TTFB), bildet die Untergrenze für jede weitere Ladezeitmetrik: Der Browser kann mit dem Rendern erst beginnen, wenn das erste Byte der HTML-Antwort eintrifft. Google empfiehlt einen TTFB von unter 800 Millisekunden am 75. Perzentil (Quelle: web.dev) - doch nur 42 Prozent der mobilen Websites erreichen diesen Wert (Quelle: HTTP Archive Web Almanac). Dieser Beitrag betrachtet Tempo nicht als Metrik-Mechanik, sondern als Infrastruktur-Entscheidung: Wie unterscheiden sich Shared Hosting, VPS, Managed Hosting und Cloud in Antwortzeit, Verhalten unter Lastspitzen, Skalierung und Serverstandort - und warum lässt sich eine langsame Serverantwort durch noch so gutes Frontend-Tuning nicht ausgleichen. Wie sich der TTFB anschließend im Detail zerlegen und beschleunigen lässt, vertieft unser Beitrag zur Server-Antwortzeit und ihren Bestandteilen; hier geht es um die vorgelagerte Frage: die Wahl und Dimensionierung der Umgebung.
Warum der Server die Obergrenze setzt
Der TTFB misst die Zeit vom Absenden der Anfrage bis zum Empfang des ersten Antwort-Bytes und umfasst laut Chrome for Developers eine Netzwerk-Rundreise, die DNS-Auflösung, etwaige Weiterleitungen und die eigentliche Verarbeitungszeit des Servers (Quelle: Chrome for Developers). Weil dieser Wert jeder sichtbaren Darstellung vorausgeht, setzt er eine harte Grenze: Ein Largest Contentful Paint unter 2,5 Sekunden ist unmöglich, wenn der Server allein zwei Sekunden für die erste Antwort braucht. web.dev beschreibt den TTFB deshalb als Wert, der den nutzerzentrierten Metriken First Contentful Paint und Largest Contentful Paint vorausgeht (Quelle: web.dev). Er ist nicht das Ziel, sondern die Startlinie - und wer zu spät startet, kann das Rennen nicht mehr gewinnen.
web.dev empfiehlt, das LCP-Budget grob aufzuteilen: etwa 40 Prozent auf den TTFB, weitere 40 Prozent auf das Laden der LCP-Ressource und jeweils unter 10 Prozent auf Lade- und Render-Verzögerung (Quelle: web.dev). Bei einem Zielwert von 2,5 Sekunden bleibt für die Serverantwort also rund eine Sekunde - und wer diese Sekunde bereits im Backend verbraucht, hat für Bilder, Schriften und das eigentliche Rendering keinen Spielraum mehr. Das im Mockup gezeigte Budget veranschaulicht das: Der TTFB-Sockel trägt das gesamte darüberliegende Budget. Genau deshalb ist die Serverwahl kein Detail, sondern die Weiche, die entscheidet, ob die Core Web Vitals überhaupt in Reichweite sind.
TTFB ist keine Core-Web-Vitals-Metrik - aber ihre Voraussetzung
Frontend-Tuning hat eine Obergrenze
Die vier Hosting-Modelle im Überblick
web.dev nennt das Hosting den ersten Punkt, den man bei der TTFB-Optimierung überhaupt betrachten sollte (Quelle: web.dev). Vier Grundmodelle stehen zur Wahl, und sie unterscheiden sich weniger im Preis als im Verhalten unter realen Bedingungen. Shared Hosting teilt einen physischen Server unter vielen Kunden auf - günstig, aber anfällig, weil fremde Websites dieselben CPU-Kerne und denselben Arbeitsspeicher beanspruchen. Ein VPS (Virtual Private Server) reserviert feste Ressourcenanteile in einer virtualisierten Umgebung, die man selbst konfiguriert und pflegt. Managed Hosting liefert eine vorkonfigurierte, laufend gewartete Umgebung mit eingebautem Caching. Cloud- und Autoscaling-Plattformen schließlich verteilen die Last dynamisch auf mehrere Instanzen und wachsen mit dem Bedarf.
Shared Hosting
Ein Server, viele Kunden, geteilte Ressourcen. Günstig und wartungsarm, aber der TTFB liegt typischerweise bei 800-2000 Millisekunden und bricht unter Lastspitzen ein. Passt zu kleinen, statischen oder wenig frequentierten Seiten.
VPS (selbst verwaltet)
Feste, dedizierte Ressourcenanteile in einer virtuellen Maschine. Volle Kontrolle über PHP, Webserver und Datenbank - aber auch volle Verantwortung für Sicherheit, Updates und Tuning. TTFB typisch 300-700 Millisekunden.
Managed Hosting
Vorkonfigurierte, laufend gewartete Umgebung mit eingebautem Objekt- und Seiten-Cache. Der Anbieter übernimmt Updates und Server-Feintuning. TTFB typisch 200-500 Millisekunden bei geringerem Betriebsaufwand.
Cloud / Autoscaling
Last wird dynamisch auf mehrere Instanzen verteilt, Kapazität wächst mit dem Bedarf. Edge-nahe Auslieferung und elastische Skalierung halten den TTFB auch bei Spitzen niedrig, erfordern aber Architektur-Know-how.
Die Grenzen zwischen den Modellen verschwimmen: Ein gut dimensionierter VPS mit Reverse-Proxy-Cache kann schneller antworten als ein schlecht konfiguriertes Managed-Paket, und Cloud-Hosting ist ohne durchdachte Architektur nicht automatisch schnell. Entscheidend ist nicht das Etikett, sondern wie das Modell auf drei Fragen antwortet: Wie verhält es sich unter Lastspitzen, wie nahe steht es am Publikum, und wie skaliert es mit wachsendem Traffic. Die folgende Tabelle ordnet die Modelle entlang dieser Achsen ein.
| Modell | Typischer TTFB | Verhalten unter Last | Skalierung | Passt zu |
|---|---|---|---|---|
| Shared Hosting | 800-2000 ms | bricht bei Spitzen ein | kaum, Paketwechsel nötig | kleine, statische Seiten |
| VPS (selbst verwaltet) | 300-700 ms | stabil bis zur Kapazitätsgrenze | vertikal, manuell | wachsende Projekte mit Technik-Team |
| Managed Hosting | 200-500 ms | abgefedert durch Caching | vertikal, betreut | Shops und Sites ohne Ops-Team |
| Cloud / Autoscaling | 100-400 ms | elastisch, fängt Spitzen ab | horizontal, automatisch | hohe oder schwankende Last |
TTFB unter Lastspitzen
Ein einzelner Testaufruf sagt wenig über die reale Serverleistung aus. Entscheidend ist das Verhalten unter Last - genau dort trennen sich die Modelle. Auf Shared Hosting teilen sich viele Websites dieselben Ressourcen; ein Traffic-Schub oder ein rechenintensiver Nachbar kann den eigenen TTFB vervielfachen, obwohl der eigene Code unverändert bleibt. Diese Volatilität erklärt einen Teil der Feldzahlen: Nur 42 Prozent der mobilen und 54 Prozent der Desktop-Websites erreichen 2024 einen guten TTFB (Quelle: HTTP Archive Web Almanac). Der Median wandert unter Last spürbar nach oben, und weil Google am 75. Perzentil bewertet, zählen gerade die schlechten Momente.
Technisch entsteht der Einbruch, weil endliche Ressourcen erschöpft werden. Jede PHP-Anfrage belegt einen Worker-Prozess und Arbeitsspeicher; sind alle Worker beschäftigt, warten neue Anfragen in einer Queue. Datenbankverbindungen sind ebenfalls begrenzt - ist das Limit erreicht, blockieren weitere Abfragen. Ein Server, der einzeln in 250 Millisekunden antwortet, kann bei 50 gleichzeitigen Anfragen auf zwei Sekunden ansteigen. Der Web Almanac zeigt die Konsequenz an den langsamsten Seiten: Websites mit schlechtem LCP verbringen allein rund 2,27 Sekunden im TTFB (Quelle: HTTP Archive Web Almanac) - der Server ist hier nahezu die gesamte Ladezeit.
Unter realistischer Last testen, nicht im Leerlauf
Serverstandort und Latenz zum Publikum
Selbst ein blitzschnelles Backend hilft wenig, wenn die Daten physisch weit reisen müssen. Licht in Glasfaser braucht rund fünf Millisekunden pro 1000 Kilometer, und jede Anfrage legt den Weg mehrfach zurück. Ein Nutzer in Hamburg, dessen Server in Frankfurt steht, hat eine minimale Netzwerklatenz von wenigen Millisekunden; ein Nutzer in New York gegenüber demselben Server dagegen ein Vielfaches. web.dev weist ausdrücklich darauf hin, dass Nutzer weit entfernt vom Origin-Server im Feld weiterhin hohe TTFB-Werte erleben können (Quelle: web.dev). Der Serverstandort ist damit keine Nebensache, sondern muss zum geografischen Schwerpunkt des Publikums passen.
Wenn das Publikum international verteilt ist, löst ein Content Delivery Network dieses Problem, indem es Inhalte von Knotenpunkten nahe am Nutzer ausliefert. web.dev empfiehlt CDNs ausdrücklich, um die Distanz zum Origin zu überbrücken, und nennt als Zusatznutzen schnellere DNS-Auflösung, moderne Protokolle wie HTTP/2 und HTTP/3 sowie optimierte TLS-Aushandlung (Quelle: web.dev). Die Verbreitung wächst, ist aber ungleich: 2024 liefern nur 33 Prozent der HTML-Seiten über ein CDN aus, während es bei den populärsten 1000 Websites bereits 70 Prozent sind (Quelle: HTTP Archive Web Almanac). Wie sich Edge-Caching konkret auf die Auslieferung auswirkt, vertieft unser Beitrag zu CDN und Edge-Caching für Shop-Performance; welche Protokoll-Vorteile HTTP/3 mitbringt, zeigt der Beitrag zu HTTP/3 und QUIC.
- Standort nach Publikum wählen: Ein Rechenzentrum im Kernmarkt schlägt jedes weit entfernte Angebot, auch wenn dessen Spezifikationen auf dem Papier besser klingen.
- CDN bei geografischer Streuung: Sitzt das Publikum in mehreren Regionen, verkürzt ein CDN die physische Distanz für statische wie zunehmend auch dynamische Inhalte.
- Dynamische Inhalte gezielt cachen: HTML mit kurzer Gültigkeit oder Stale-while-revalidate am Edge halten, personalisierte Bereiche bewusst vom Cache ausnehmen.
- Redirect-Ketten vermeiden: Weiterleitungen fließen laut Chrome for Developers direkt in den TTFB ein - jeder Sprung kostet eine zusätzliche Rundreise (Quelle: Chrome for Developers).
Skalierung: vertikal, horizontal, elastisch
Die Frage, wie ein Hosting-Modell mit wachsendem Traffic umgeht, entscheidet über seine Lebensdauer. Vertikale Skalierung bedeutet, demselben Server mehr Ressourcen zu geben - mehr CPU, mehr RAM. Sie ist einfach, hat aber eine harte Obergrenze und erfordert bei Shared Hosting oft einen Paketwechsel, bei einem VPS ein manuelles Resize mit kurzer Ausfallzeit. Horizontale Skalierung verteilt die Last auf mehrere Instanzen hinter einem Load Balancer und hat theoretisch keine feste Decke, verlangt aber eine zustandslose Architektur, in der keine Instanz lokale Sitzungsdaten hält. Elastische Skalierung schließlich fügt Instanzen automatisch hinzu und entfernt sie wieder, wenn die Last sinkt - das Modell der Cloud.
Für die Praxis heißt das: Ein Projekt mit stetigem, planbarem Traffic ist mit einem gut dimensionierten VPS oder Managed-Paket meist besser bedient als mit komplexer Cloud-Infrastruktur, deren Vorteile es nicht ausspielt. Ein Shop dagegen, dessen Last zu Kampagnen, Feiertagen oder Aktionstagen um ein Vielfaches steigt, profitiert von elastischer Skalierung, die den TTFB auch im Spitzenmoment stabil hält. Die richtige Wahl folgt dem Lastprofil, nicht der maximal denkbaren Ausbaustufe. Caching entlastet dabei jedes Modell, weil es die teure Backend-Verarbeitung überspringt - wie mehrschichtiges Caching mit Varnish und Redis das leistet, zeigt der zugehörige Beitrag.
Die richtige Serverdimensionierung folgt dem Lastprofil, nicht dem größten denkbaren Ausbau. Eine Umgebung, die zur realen Last passt, ist schneller und günstiger als eine überdimensionierte, die man kaum ausreizt.
Das richtige Modell wählen
Die Wahl beginnt nicht beim Anbieter, sondern beim eigenen Profil: Wie viel Traffic, wie stark schwankend, mit welcher technischen Betreuung im Haus und mit welchem geografischen Schwerpunkt. Google Search Central formuliert das Ziel klar - LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 (Quelle: Google Search Central) - und betont zugleich, dass gute Werte in der Search Console allein noch kein besseres Ranking bedeuten, wohl aber Teil der Bewertung sind (Quelle: Google Search Central). Der Server ist die Voraussetzung, unter der der LCP-Wert überhaupt erreichbar wird. Die folgende Reihenfolge hilft, das passende Modell einzugrenzen.
- Lastprofil bestimmen: Durchschnitts- und Spitzenlast getrennt betrachten. Konstante Last spricht für VPS oder Managed, stark schwankende für elastische Cloud.
- Betreuung ehrlich einschätzen: Ohne eigenes Technik-Team ist Managed Hosting meist die sicherere Wahl als ein selbst verwalteter VPS, der Updates und Tuning verlangt.
- Standort am Publikum ausrichten: Rechenzentrum im Kernmarkt, CDN bei internationaler Streuung. Die physische Distanz lässt sich nicht wegoptimieren.
- Anwendung berücksichtigen: Ein WordPress-Setup hat andere Engpässe als ein Shopware-Shop; die typischen Bremsen sollten zum Modell passen.
- Reserve einplanen, nicht überprovisionieren: Genug Puffer für Spitzen, aber keine dauerhaft ungenutzte Kapazität - beides kostet, das eine Tempo, das andere Geld.
Dimensionierung statt Überprovisionierung
Ein Server ist nicht schnell, weil er teuer ist, sondern weil seine Ressourcen zur Arbeitslast passen. Die vier kritischen Größen sind Arbeitsspeicher, CPU, die Zahl der PHP-Worker und die Datenbank-Puffer. Zu wenig RAM zwingt die Datenbank, von der langsamen Festplatte statt aus dem Speicher zu lesen; zu wenige Worker führen zu Warteschlangen unter Last; ein zu klein dimensionierter Datenbank-Puffer lässt Cache-Trefferraten sinken. Chrome for Developers weist den Serveranteil separat aus: Die Lighthouse-Empfehlung für die reine Serverantwortzeit liegt bei 600 Millisekunden und damit strenger als der 800-Millisekunden-Schwellenwert für den gesamten TTFB, weil dieser zusätzlich DNS und Weiterleitungen einschließt (Quelle: Chrome for Developers).
Bei Managed Hosting übernimmt der Anbieter diese Feinabstimmung samt Updates und Sicherheits-Patches; bei einem selbst verwalteten VPS liegt sie in der eigenen Verantwortung. Beides kann schnell sein - der Unterschied liegt im Betriebsaufwand, nicht zwangsläufig im Ergebnis. Wichtig ist, die Umgebung nicht nach dem Bauchgefühl zu überprovisionieren, sondern anhand gemessener Last zu dimensionieren. Caching ist dabei der größte Hebel, weil es Anfragen bedient, ohne das Backend überhaupt zu bemühen - passende Caching-Strategien senken den TTFB oft stärker als teurere Hardware.
Erst messen, dann skalieren
Am Ende ist die Hosting-Wahl die Entscheidung, die den Rahmen für alles Weitere absteckt. Ein passend gewählter, richtig dimensionierter Server liefert eine schnelle erste Antwort - und erst auf diesem Fundament entfalten Frontend-Optimierung und Bildkomprimierung ihre volle Wirkung. Wer unsicher ist, ob das aktuelle Modell zu Traffic, Lastspitzen und Publikum passt, findet in unseren Leistungen rund um Web-Performance den passenden Einstieg: Wir messen den TTFB an mehreren Standorten, ordnen die Umgebung ein und benennen den wirksamsten nächsten Schritt - statt pauschal zu größerer Hardware zu raten.
Quellen und Studien