Kurzfassung für Entscheider
Eine Sekunde mehr Ladezeit senkt die Conversion-Rate um rund 17 Prozent. Auf Mobilgeräten brechen 53 Prozent der Nutzer ab, wenn die Seite länger als drei Sekunden braucht. Die Bounce Rate verfünffacht sich zwischen zwei und fünf Sekunden Ladezeit.
Das ist keine Spielerei für Page-Speed-Nerds. Es ist die Grundlage jedes Marketingbudgets, das in Google Ads, Meta Ads oder Performance-Kampagnen fließt.
Der entscheidende Hebel sitzt nicht im Frontend. Er sitzt im Server-Stack:
Time to First Byte (TTFB)
+ Server-Standort
+ NVMe-Storage statt SATA-SSD
+ Server-level Page Caching
+ Object Cache im RAM (Redis)
+ DNS via Anycast
+ System-Cron statt wp-cronWenn TTFB über 600 Millisekunden liegt, fängt Google an, die Landingpage-Erfahrung schlechter zu bewerten. Der Qualitätsfaktor sinkt, der Klickpreis steigt, derselbe Werbeeuro liefert weniger Klicks. Conversion-Rate und CPC arbeiten gleichzeitig gegen den Betrieb.
Wer TTFB systematisch unter 200 Millisekunden bringt, gewinnt an drei Stellen gleichzeitig: mehr Nutzer kommen überhaupt an, mehr starten die Vorqualifizierung, und Google senkt den durchschnittlichen Klickpreis.
1. Was TTFB ist — und warum es keine Tech-Diskussion ist
Time to First Byte misst, wie schnell der Server auf eine Browseranfrage mit dem ersten Datenpaket antwortet. Es ist der Moment zwischen Klick und „die Seite fängt an zu laden".
Alles, was danach passiert — Render, Hero-Bild, Formular, Tracking-Pixel — baut auf diesem ersten Byte auf. Wenn der Server 800 Millisekunden braucht, bis er antwortet, hat der schnellste Frontend-Code schon verloren.
Google misst TTFB als Teil der Core Web Vitals. Werte gelten als gut bei unter 200 Millisekunden, als kritisch ab 600. Bei langsamer Server-Antwort kippt nicht nur die User Experience, sondern auch die Bewertung der Landingpage im Werbeauktionssystem.
2. Wie TTFB den Qualitätsfaktor und den CPC bewegt
Der Qualitätsfaktor in Google Ads bewertet drei Dimensionen: erwartete Klickrate, Anzeigenrelevanz und Landingpage-Erfahrung. Page Speed ist Teil der dritten.
Sinkt der Qualitätsfaktor von 8 auf 5, steigt der Klickpreis bei identischem Maximalgebot um 60 bis 100 Prozent. Bei einem Monatsbudget von 5.000 Euro Werbeausgaben sind das 3.000 bis 5.000 Euro pro Monat, die der Algorithmus zusätzlich abgreift — ohne dass eine einzige zusätzliche Conversion entsteht.
Die Mechanik wirkt doppelt:
- Höherer CPC durch sinkenden Qualitätsfaktor — der Werbeeuro liefert weniger Klicks.
- Niedrigere Conversion-Rate durch lange Ladezeit — von den Klicks kommt weniger an.
Beides multipliziert sich. Wer den TTFB von 900 auf 200 Millisekunden senkt, sieht oft 20 bis 40 Prozent niedrigere Cost per Lead bei identischem Werbebudget. Bei Solar- und Wärmepumpen-Anbietern mit eigenem Vertrieb ist das der Unterschied zwischen rentabler und unrentabler Kampagne.
3. Die echten Hebel — und die teuren Ablenkungen
Es gibt eine kurze Liste wirksamer Hebel und eine lange Liste populärer, aber wirkungsarmer Eingriffe.
Was wirklich TTFB senkt:
- Server-Standort in Deutschland. Jeder Kilometer Glasfaser zwischen Nutzer und Server kostet Millisekunden. Für eine deutsche Zielgruppe ist Frankfurt oder Berlin schneller als Amsterdam, und Amsterdam ist schneller als Dublin.
- Server-level Page Caching. Nginx FastCGI Cache oder LiteSpeed LSCache liefern fertige HTML-Seiten direkt aus dem RAM, ohne dass PHP oder MySQL überhaupt anlaufen. Cache-Hit-TTFB liegt typisch unter 50 Millisekunden.
- NVMe-Storage statt klassischer SATA-SSD. Bei jedem Cache-Miss zählt jede Microsekunde Festplattenzugriff. NVMe ist zwei bis fünf Mal schneller.
- Redis Object Cache. Speichert wiederkehrende Datenbank-Queries dauerhaft im RAM ab. Entlastet MySQL und beschleunigt dynamische Seiten ohne Full-Page-Cache.
- Anycast DNS. Cloudflare DNS oder Route 53 routen DNS-Anfragen auf den geografisch nächsten Server. Spart 20 bis 80 Millisekunden vor dem ersten Byte.
- System-Cron statt wp-cron. Der Standard-WordPress-Cron läuft bei jedem Seitenaufruf mit. Bei viel Traffic blockiert er PHP-Prozesse. Ein systemseitiger Cronjob ersetzt ihn sauber.
Was meistens wenig bringt:
- Minify-Plugins für CSS und JS — wirkt nicht auf TTFB, sondern auf spätere Render-Phasen.
- Lazy Loading für Below-the-Fold-Bilder — gut für LCP, aber TTFB ist davor.
- Cloudflare-Free-Plan ohne Origin-Optimierung — versteckt das Problem hinter einem CDN, löst es nicht.
- „WordPress-Optimierungs"-Plugins mit 30 Schaltern — selten messbar wirksam, oft sogar kontraproduktiv.
4. Stack-Entscheidung: Managed Hosting oder eigener Root-Server
Für die TTFB-Frage gibt es zwei seriöse Wege. Welcher passt, hängt nicht vom Anspruch ab, sondern von der Betriebsform.
Track A — Managed Hosting für Anbieter ohne eigenes Dev-Team
Für Solar-, Wärmepumpen- und SHK-Betriebe, die eine produktive Anfrage-Site brauchen und keinen eigenen DevOps-Aufwand fahren wollen, ist Managed WordPress Hosting aus Deutschland der direkteste Weg.
Werbung · Partnerlink: Ich empfehle in dieser Konstellation HostPress — Managed WordPress Hosting mit Server-Standort Deutschland, NVMe-Storage, Redis-Cache, CDN, täglichen Backups und WordPress-spezifischer Optimierung. Wenn Sie über diesen Link abschließen, entsteht eine Vergütung — der Preis für Sie bleibt identisch. Den vollständigen Architektur-Kontext finden Sie auf der Stack-Solar-Seite.
Der Vorteil: 2 bis 4 Wochen bis zur produktiven Site, kein Server-Administrations-Overhead, integrierte Sicherheits- und Update-Routinen. Der Trade-off: weniger Kontrolle über System-Tuning, was für die meisten Solar-/SHK-Anbieter aber kein Engpass ist.
Track B — Eigener Root-Server für High-Custom-Setups
Für Agenturen, die Multi-Site-Hosting für Care-Plan-Kunden brauchen, oder für High-Traffic-WooCommerce-Setups mit eigenen System-Optimierungen ist Managed Hosting prinzipbedingt zu eng. Hier passt ein eigener Root-Server bei Hetzner oder einem vergleichbaren Anbieter — mit voller Kontrolle über Nginx, PHP-OPcache, MySQL-Tuning und Deployment-Pipeline.
Der Aufwand: höher. Die Skalierbarkeit: deutlich besser. Die TTFB-Werte: identisch oder besser, wenn richtig konfiguriert. Auf der Stack-Agentur-Seite ist dieser Track im Detail dokumentiert; den Performance-Track für Solar-/SHK-Anbieter finden Sie auf der Stack-Solar-Seite.
5. Was TTFB im CPL und CPO konkret bewegt
Im E3-Case hat eine vollständige Anfrage-System-Migration den Cost per Lead von 150 Euro auf 22 Euro gesenkt. Page Speed war einer von mehreren Faktoren — neben Vorqualifizierung, Server-Side Tracking und CRM-Übergabe.
Aber Page Speed wirkt an drei Stellen gleichzeitig:
- Top of Funnel: Mehr Besucher erreichen die Money Page überhaupt, statt vorher abzubrechen.
- Mid Funnel: Mehr Besucher starten die Vorqualifizierung, weil das Formular sofort reagiert.
- Algorithmus: Google senkt den CPC, weil der Qualitätsfaktor steigt — derselbe Euro bringt mehr Klicks.
In Summe: 20 bis 40 Prozent niedrigere Cost per Lead bei identischem Werbebudget sind realistisch, sobald TTFB-Werte unter 200 Millisekunden liegen und die restliche Funnel-Architektur sauber gebaut ist. Wie sich daraus ein belastbarer Cost per Lead und Cost per Auftrag ableiten lässt, ist im CPL-Szenarienvergleich für Photovoltaik aufgeschlüsselt.
Wenn Ihre Money Page heute TTFB-Werte über 600 Millisekunden liefert, zahlen Sie beim Werbeeuro doppelt: höherer CPC und niedrigere Conversion-Rate.
Der Marktcheck prüft, ob Ihr aktueller Stack die TTFB-Ziele trägt oder ob ein Wechsel der Hosting-Basis und der Tracking-Architektur wirtschaftlich rationaler ist.
6. Server-Side Tracking braucht den richtigen Hoster
TTFB ist eine Seite der Performance-Gleichung. Die andere ist saubere Attribution. Wenn der Algorithmus nicht weiß, welche Klicks zu Anfragen geführt haben, optimiert er auf die falschen Signale — und alle Page-Speed-Gewinne fließen in unwirksame Kanäle.
Server-Side Tracking verlagert die Tracking-Logik vom Browser auf den Server. Voraussetzung: ein Hoster, der einen GTM-Server-Container neben WordPress betreiben kann, ohne dass die WordPress-TTFB darunter leidet. Bei Managed-Plattformen geht das über externe Server-Side-Anbieter wie Stape; bei eigenem Root-Server läuft beides auf derselben Maschine.
Die rechtliche Komponente: Server in Deutschland, Consent Mode v2, IP-Maskierung vor dem Weiterleiten an Google oder Meta. Das ist DSGVO-konform und gleichzeitig schneller als jeder US-Cloud-Setup.
7. Was Sie als Nächstes prüfen sollten
Drei Schritte, in dieser Reihenfolge:
- TTFB messen. WebPageTest, PageSpeed Insights oder das Network-Tab der Chrome DevTools. Wenn der Wert über 400 Millisekunden liegt, ist der Hoster oder die Server-Konfiguration der erste Hebel.
- Hosting-Standort prüfen. Wenn der Server nicht in Deutschland steht, kostet jeder Klick aus dem DACH-Raum Latenz, die kein Cache zurückholt.
- Cache-Hit-Rate prüfen. Server-level Page Cache aktiv? Redis als Object Cache eingerichtet? Wenn nein, sind das die nächsten zwei Hebel.
Wenn Sie diese drei Punkte beantwortet haben und unsicher sind, ob ein eigenes Anfrage-System die nächste sinnvolle Stufe ist, ist der Marktcheck der direkteste Weg zur Einordnung. Händische Analyse, Befund per E-Mail innerhalb von 48 Stunden, kein automatisches Software-Score.
—