Zwei Punkte im SEO-Check leuchten gleichzeitig auf. „Server response time (TTFB) 259 ms, sollte unter 200 ms liegen." Und direkt darüber: „Largest Contentful Paint 1,4 s, sehr langsam, Besucher springen ab, bevor die Seite sichtbar wird." Die meisten überlesen das, weil 1,4 Sekunden sich nicht nach viel anhört. Genau das ist der Denkfehler. Auf einer Webseite sind 1,4 Sekunden bis zum sichtbaren Inhalt eine kleine Ewigkeit, und 259 Millisekunden, bis der Server überhaupt anfängt zu antworten, sind ein vermeidbarer Vorsprung, den du der Konkurrenz schenkst. Beide Zahlen messen verschiedene Phasen desselben Vorgangs, und beide lassen sich gezielt verbessern.
Was TTFB und LCP wirklich messen
Stell dir vor, ein Besucher klickt auf deinen Link in den Suchergebnissen. Was dann passiert, läuft in einer festen Kette ab, und die zwei Zahlen markieren zwei Punkte auf dieser Kette.
TTFB steht für Time to First Byte, die Zeit bis zum ersten Byte. Sie misst, wie lange dein Server braucht, um auf die Anfrage des Browsers überhaupt zu reagieren. Der Browser fragt an, der Server denkt nach, sucht die Seite zusammen, fragt vielleicht die Datenbank, und schickt dann das erste Stück Antwort los. 259 Millisekunden bedeuten: Ein Viertel einer Sekunde vergeht, bevor irgendetwas zurückkommt. In dieser Zeit sieht der Besucher noch eine weiße Seite.
LCP steht für Largest Contentful Paint, das Erscheinen des größten Inhaltselements. Es misst, wann der größte sichtbare Block auf dem Bildschirm fertig geladen ist, meist das Titelbild, die Hauptüberschrift oder ein großer Textblock. Erst wenn dieses Element steht, hat der Besucher das Gefühl, die Seite sei da. 1,4 Sekunden LCP heißt: Anderthalb Sekunden Warten, bis die Seite nutzbar wirkt.
Der entscheidende Punkt: TTFB ist Teil von LCP. Die 259 Millisekunden Server-Zeit stecken in den 1,4 Sekunden bereits drin. Wenn der Server langsam antwortet, kann die schönste Optimierung am Rest nichts mehr retten, weil die Uhr schon läuft, bevor der Browser auch nur ein Byte hat. Deshalb fängt jede ernsthafte Ladezeit-Optimierung beim TTFB an und arbeitet sich von dort nach vorne.
Warum langsame Seiten Rankings und Umsatz kosten
Geschwindigkeit ist kein kosmetisches Detail. Sie wirkt auf zwei Ebenen gleichzeitig.
Die erste Ebene ist der Nutzer. Mit jeder zusätzlichen Sekunde Ladezeit steigt die Absprungrate spürbar. Ein Besucher, der auf eine weiße Seite starrt, wartet nicht geduldig, er klickt zurück und nimmt das nächste Suchergebnis. Auf dem Handy, mit wackeligem Mobilfunk, ist die Geduld noch kürzer. Wer einen Shop betreibt, sieht das direkt im Umsatz: langsame Produktseiten verkaufen weniger, weil ein Teil der Kunden den Kauf nie startet.
Die zweite Ebene ist Google. Die Core Web Vitals, zu denen LCP gehört, sind ein offizielles Ranking-Signal. Google hat in der Dokumentation zur Page Experience klar gemacht, dass Geschwindigkeit und Stabilität einer Seite in die Bewertung einfließen. Bei zwei inhaltlich gleichwertigen Seiten gewinnt die schnellere. Und weil Google denselben schnellen Rücksprung sieht, den auch der genervte Nutzer auslöst, verstärkt sich der Effekt: langsame Seiten verlieren Position, verlieren dadurch Klicks, und das wiederum bestätigt Google im Eindruck, dass die Seite nicht die beste Antwort ist.
Dazu kommt ein technischer Nebeneffekt, den viele übersehen. Ein langsamer Server bremst auch den Googlebot. Wenn jede Seite 259 Millisekunden zum Antworten braucht, crawlt Google in derselben Zeit weniger Seiten deiner Domain. Bei großen Seiten heißt das: neue Inhalte werden später entdeckt und indexiert. Schnelligkeit zahlt also nicht nur auf Rankings ein, sondern auch darauf, wie schnell überhaupt etwas im Index landet.
Googles Schwellen und warum 1,4 Sekunden trotzdem rot ist
Hier wird es interessant, weil sich zwei Maßstäbe widersprechen. Google selbst stuft einen LCP-Wert erst ab 2,5 Sekunden als „verbesserungswürdig" und ab 4 Sekunden als „schlecht" ein. Nach dieser offiziellen Skala wären 1,4 Sekunden grün. Warum schlägt der Check trotzdem Alarm?
Weil „gut genug für Google" und „wirklich schnell" zwei verschiedene Dinge sind. Die offiziellen Schwellen sind eine Untergrenze, ab der Google nicht mehr abstraft, kein Ziel, das man anstreben sollte. Eine wirklich schnelle Seite liefert das größte Element in unter einer Sekunde, oft in unter 500 Millisekunden. Wer sich mit 2,4 Sekunden zufrieden gibt, weil das ja noch im grünen Bereich liegt, lässt genau den Vorsprung liegen, der den Unterschied macht, wenn die Konkurrenz inhaltlich gleichauf ist.
Ein strenger Check warnt deshalb früher. Er behandelt 1,4 Sekunden nicht als Fehler im Sinne von „Google bestraft dich", sondern als Hinweis: Hier ist Luft, und die Konkurrenz nutzt sie vielleicht schon. Dasselbe gilt für TTFB. Google nennt etwa 0,8 Sekunden als Orientierung, ein gut konfigurierter Server schafft aber 100 bis 200 Millisekunden. 259 Millisekunden sind nicht katastrophal, aber sie verraten, dass beim Hosting oder beim Caching etwas nicht optimal läuft.
Probier es selbst: Der kostenlose SEO-Check unter yourseo.app/analyse misst LCP und TTFB deiner Seite live mit und ordnet die Werte ein, zusammen mit zehn weiteren Onpage-Feldern. So siehst du in unter 30 Sekunden, ob deine Ladezeit nur „okay" oder wirklich schnell ist.
TTFB senken: an der Server-Seite ansetzen
Weil der TTFB ganz am Anfang der Kette steht, ist er der Hebel mit der größten Wirkung. Hohe Werte haben fast immer eine von vier Ursachen.
Das Hosting ist zu schwach. Billige Shared-Hosting-Pakete teilen einen Server unter hunderten Webseiten auf. In Stoßzeiten reagiert er träge. Der Wechsel auf ein besseres Paket oder einen Server mit garantierten Ressourcen ist oft der schnellste Gewinn, ohne eine Zeile Code zu ändern.
Es fehlt ein Cache. Wenn der Server jede Anfrage neu berechnet, also bei jedem Aufruf die Datenbank befragt und die Seite frisch zusammenbaut, kostet das Zeit. Ein Server-seitiger Cache liefert fertige Seiten aus dem Speicher, statt sie jedes Mal neu zu erzeugen. Bei einem CMS wie WordPress halbiert ein gutes Caching-Plugin den TTFB oft auf Anhieb.
Der Server steht weit weg. Sitzt dein Server in den USA, deine Besucher aber in Deutschland, reist jede Anfrage einmal über den Atlantik und zurück. Ein Content Delivery Network legt Kopien deiner Seite auf Server in der Nähe deiner Besucher und verkürzt diese Strecke drastisch.
Die Datenbank ist langsam. Bei dynamischen Seiten mit vielen Abfragen kann eine einzige unsaubere Datenbankabfrage den TTFB in die Höhe treiben. Das ist der aufwendigste Fall, weil er echtes Profiling braucht, aber bei Shops mit großem Sortiment oft der entscheidende.
Welche Ursache bei dir greift, lässt sich eingrenzen, indem du dieselbe Seite mehrmals lädst. Sinkt der TTFB beim zweiten Aufruf stark, fehlt ein Cache. Bleibt er konstant hoch, liegt es eher am Hosting oder an der Distanz.
Ein Beispiel aus der Praxis zeigt, wie groß der Hebel ist. Ein Onlineshop für Bürobedarf hatte auf den Produktseiten einen TTFB von rund 700 Millisekunden, gemessen mehrfach zu verschiedenen Tageszeiten. Die Bilder waren bereits komprimiert, das Theme schlank, trotzdem lud die Seite zäh. Der Grund lag tiefer: Das Caching-Plugin war zwar installiert, aber für eingeloggte Sessions komplett deaktiviert, und durch einen Konfigurationsfehler galt jeder Besucher als eingeloggt. Nach einer halben Stunde Korrektur lag der TTFB bei 130 Millisekunden, der LCP fiel von 2,1 auf 0,9 Sekunden. Es musste kein einziges Bild angefasst werden. Genau das meint „erst messen, dann handeln": Die sichtbare Ursache war nicht die echte.
LCP verbessern: an der Render-Seite ansetzen
Wenn der Server schnell antwortet, der LCP aber trotzdem hoch bleibt, liegt das Problem im Browser, beim Laden und Anzeigen. Hier sind die häufigsten Bremsen.
Das größte Element ist ein riesiges Bild. Bei den meisten Seiten ist das LCP-Element ein Bild, oft das Titelbild ganz oben. Wenn dieses Bild zwei Megabyte groß ist und im falschen Format vorliegt, dauert das Laden. Die Lösung: modernes Format wie WebP, passende Größe statt eines überdimensionierten Originals, und das wichtigste Bild bevorzugt laden, statt es wie alle anderen erst spät anzustoßen. Wie man Bilder insgesamt sauber aufsetzt, vom Format bis zum Alt-Text, gehört ohnehin zur Pflicht jeder Seite.
Render-blockierende Dateien stehen im Weg. Bevor der Browser etwas zeichnet, muss er bestimmte CSS- und JavaScript-Dateien laden. Liegen die ungünstig oder sind sie zu groß, wartet der Browser, obwohl der Server längst geantwortet hat. Kritisches CSS direkt in die Seite einbetten und unwichtiges JavaScript ans Ende verschieben oder verzögert laden hilft hier spürbar.
Schriften blockieren den Text. Wenn der Browser auf eine Schriftart wartet, bevor er den Text zeigt, bleibt die Seite länger leer. Die Schrift mit font-display: swap zu laden und sie lokal statt von einem fremden Server zu holen, beschleunigt den Aufbau und vermeidet nebenbei ein Datenschutz-Problem.
Lazy Loading am falschen Ort. Lazy Loading, also das verzögerte Laden von Bildern, ist nützlich, aber tödlich, wenn man es auf das LCP-Element anwendet. Das Titelbild lazy zu laden bedeutet, dem Browser zu sagen „lad das wichtigste Element zuletzt". Lazy Loading gehört unter die Bilder, die erst beim Scrollen sichtbar werden, nie auf das oberste.
Google bündelt diese Hebel in der eigenen Anleitung zu Core Web Vitals und beschreibt die Reihenfolge ähnlich: erst die Server-Antwort, dann das Laden der Ressourcen, dann das Rendern. Wer in dieser Reihenfolge vorgeht, verschwendet keine Zeit an der falschen Stelle.
Häufige Fehler bei der Ladezeit-Optimierung
Drei Muster sehe ich immer wieder, und alle drei kosten Zeit, ohne etwas zu bringen.
Das erste ist das Optimieren am falschen Ende. Jemand komprimiert wochenlang Bilder, während der eigentliche Engpass ein TTFB von 800 Millisekunden ist. Die Bilder waren nie das Problem. Immer zuerst messen, wo die Zeit verloren geht, dann handeln.
Das zweite ist die Plugin-Sammlung. Bei WordPress installieren viele drei verschiedene Performance-Plugins gleichzeitig, die sich gegenseitig ins Gehege kommen und am Ende mehr Code laden als sie sparen. Ein gutes Caching-Plugin, sauber konfiguriert, schlägt drei halbherzig eingerichtete.
Das dritte ist das Vertrauen in einen einzigen Testlauf. Ladezeiten schwanken je nach Tageszeit, Server-Last und Messpunkt. Eine Seite einmal zu testen und das Ergebnis für bare Münze zu nehmen führt in die Irre. Verlässlicher sind echte Felddaten aus der Search Console, die zeigen, wie schnell die Seite bei echten Besuchern lädt. Wie man diese Daten richtig liest, erklärt der Beitrag zum Lesen der Search-Console-Daten. Und bevor man einzelne Werte jagt, lohnt der Blick auf das ganze Bild über einen vollständigen Onpage-Check, der Ladezeit zusammen mit den übrigen Feldern bewertet.
Quick-FAQ
Ist LCP wichtiger als TTFB? Sie hängen zusammen. TTFB steckt in LCP drin, also bringt ein niedriger TTFB automatisch einen besseren LCP. Wer beide rot hat, fängt beim TTFB an, weil das die Ursache weiter vorne in der Kette ist.
Mein Tool zeigt grün, der Check hier zeigt rot. Wer hat recht? Beide, mit unterschiedlichem Maßstab. Googles offizielle Schwelle für grün liegt bei 2,5 Sekunden LCP, ein strenger Check warnt schon bei 1,4 Sekunden, weil das langsamer ist als technisch nötig. Grün heißt „nicht abgestraft", nicht „optimal".
Wie schnell sollte eine Seite realistisch laden? Ein TTFB unter 200 Millisekunden und ein LCP unter einer Sekunde sind erreichbare Ziele für die meisten Seiten. Alles darunter ist exzellent, alles deutlich darüber lässt Vorsprung liegen.
Bringt ein CDN immer etwas? Wenn deine Besucher geografisch verteilt sind oder weit vom Server entfernt, ja, deutlich. Sitzen Server und Besucher in derselben Region, ist der Effekt kleiner, aber selten schädlich. Für eine rein lokale Seite mit Besuchern aus einer einzigen Stadt ist ein gut konfigurierter Cache meist wichtiger als ein CDN.
Wie lange dauert es, bis sich eine Verbesserung auf das Ranking auswirkt? Die Felddaten in der Search Console brauchen einige Wochen, weil sie über einen rollierenden Zeitraum von 28 Tagen gemittelt werden. Den Effekt auf die Absprungrate siehst du dagegen oft sofort, weil echte Besucher die schnellere Seite sofort spüren, lange bevor Google die neuen Werte verarbeitet hat.
Auf einen Blick
TTFB und LCP messen zwei Punkte derselben Ladekette, und TTFB steckt in LCP. 259 Millisekunden Server-Zeit und 1,4 Sekunden bis zum sichtbaren Inhalt sind nicht katastrophal, aber sie verschenken Vorsprung, den die Konkurrenz nutzt. Wer zuerst den Server beschleunigt, dann die wichtigsten Ressourcen entlastet und das größte Element bevorzugt lädt, holt das Meiste heraus. Googles grüne Schwelle ist die Untergrenze, nicht das Ziel. Wirklich schnell zu sein zahlt auf Rankings, auf den Crawl und auf den Umsatz gleichzeitig ein. Tempo ist damit einer von vielen Bausteinen, die zusammen die Sichtbarkeit bei Google ausmachen.