Time to First Byte
Ihr WordPress denkt nach, bevor es antwortet. Eine statische Kopie ist schon fertig.
Die Time to First Byte (TTFB) ist die Zeit vom Abrufen einer Seite, bis ihr erstes Byte ankommt. web.dev von Google wertet 0,8 Sekunden oder weniger als gut und mehr als 1,8 Sekunden als schlecht. Bei WordPress besteht der größte Teil dieser Wartezeit darin, dass die Seite zusammengesetzt wird – PHP, Plugins und Datenbankabfragen, für jeden Besucher aufs Neue. Eine statische Kopie hat die Seite fertig, bevor jemand fragt, also geht das erste Byte sofort hinaus.
Eine Kopie, die funktioniert wie Ihre Website
Ein HTML-Export schreibt jede Seite heraus, mit den Dateien, die darin stehen. Was eine Seite erst lädt, wenn sie offen ist – ein Bild, das beim Scrollen erscheint, ein Menü, das sich füllt, Inhalte, die ein Skript nachholt, ein Link, der auf eine andere Adresse weiterleitet –, fehlt dann oft. Und Sie erfahren es von einem Besucher.
Eine Kopie von MakeStatic funktioniert wie Ihre Website – sie sieht nicht nur so aus. Sie probieren sie selbst aus, neben Ihrer Website, bevor Sie irgendetwas entscheiden. Und funktioniert eine Seite der Kopie einmal anders als bei Ihnen, schreiben Sie an [email protected] – wir beheben das.
- Bilder, die beim Scrollen laden – in jeder Größe, die Ihre Website für Handy und großen Bildschirm hat.
- Schriften, Icons und alles, was Ihr Theme oder Ihr Page-Builder mitbringt.
- Inhalte, die ein Skript nachlädt, sobald die Seite offen ist, und Menüs, die sich füllen, wenn man mit der Maus darüberfährt.
- Links auf Ihren Seiten, die auf eine andere Adresse weiterleiten, tun das auch in der Kopie.
- Videos, die abspielen und sich vorspulen lassen.
- Kontaktformulare, die ankommen, und eine Suche, die antwortet.
Was die Time to First Byte misst
Sie beginnt, wenn der Browser sich auf den Weg zur Seite macht, und endet, wenn das erste Byte der Antwort ankommt: eine etwaige Weiterleitung, das Nachschlagen der Adresse, der Verbindungsaufbau samt Verschlüsselung und dann die Zeit, die der Server zum Antworten braucht. Im letzten Teil verliert eine WordPress-Website ihre Zeit.
Sie gehört nicht zu Googles Core Web Vitals, aber alles andere wartet auf sie. Largest Contentful Paint, einer der Core Web Vitals, schließt sie ein: Eine Seite kann nicht zeigen, was noch nicht angekommen ist.
Warum WordPress spät antwortet
- Jeder Besuch startet PHP und lädt WordPress mit allen Plugins.
- Die Seite wird aus Datenbankabfragen zusammengesetzt, und jede ist eine Wartezeit.
- In einem belebten Moment wartet jeder Besucher auf die anderen.
- Das Hosting setzt die Untergrenze für all das; web.dev nennt es das Erste, worauf man schauen sollte.
Was die üblichen Lösungen tun
Ein Caching-Plugin hebt die fertigen Seiten auf und gibt sie erneut aus – die größte einzelne Verbesserung, die die meisten WordPress-Websites machen können. Es arbeitet aber innerhalb von WordPress: Ein Plugin wie WP Rocket cached standardmäßig keine Seiten für angemeldete Besucher, keine Adressen mit Query-Strings und nicht Warenkorb, Kasse und Kundenkonto eines Shops. Diese werden jedes Mal frisch zusammengesetzt.
Besseres Hosting und ein Content Delivery Network verkürzen den Rest des Weges. Beides ändert nichts daran, dass hinter der Seite ein WordPress steht, bereit, gefragt zu werden.
Was eine statische Kopie ändert
Jede Seite der Kopie ist fertig, bevor jemand sie abruft, und sie wird ohne WordPress ausgeliefert: Kein PHP startet, kein Plugin lädt, keine Datenbank wird gefragt. Der Anteil des Servers an der Wartezeit verschwindet fast ganz, und er hängt nicht davon ab, dass ein Cache zuerst gefüllt wurde.
Ein Teil jedes Unterschieds liegt an unserem Hosting und nicht daran, dass die Seite statisch ist, und der Vergleich sagt das neben seinen Zahlen.
Messen Sie Ihre eigene Website
Geben Sie Ihre Adresse in das Feld auf dieser Seite ein. Wir kopieren diese eine Seite und messen Original und Kopie im selben Browser, nacheinander: die Zeit bis zum ersten Byte und die Zeit, bis die Seite zum ersten Mal zu sehen ist. Sie sehen beide Zahlen unter jeder, mit den zwei Seiten nebeneinander.
Und die Core Web Vitals?
Largest Contentful Paint, der Core Web Vital für das Laden, sollte bei 2,5 Sekunden oder weniger liegen, und das erste Byte ist ein Teil davon. Eine Kopie, die früher antwortet, lässt dem Rest der Seite mehr von dieser Zeit. Was nach dem ersten Byte kommt – Bilder, Schriften, Skripte –, gehört Ihrer Website und ist in der Kopie dasselbe.
Quellen
web.dev: Time to First Byte, Optimize Time to First Byte und Largest Contentful Paint; die Dokumentation von WP Rocket zu den Seiten, die es nicht cached. Geprüft am 28. September 2026.
Häufige Fragen
- Was ist eine gute Time to First Byte?
- 0,8 Sekunden oder weniger, nach dem Maßstab von web.dev; mehr als 1,8 Sekunden gilt als schlecht. Messen Sie sie auf den Seiten, auf denen Ihre Besucher ankommen, nicht nur auf der Startseite.
- Gehört die Time to First Byte zu den Core Web Vitals?
- Nein. web.dev nennt sie eine grundlegende Messgröße statt eines Core Web Vitals, aber Largest Contentful Paint, einer davon, schließt sie ein.
- Laden meine Bilder mit einer statischen Kopie schneller?
- Nein, es sind dieselben Dateien. Was die Kopie verkürzt, ist die Wartezeit, bevor die Seite ankommt; ein schweres Bild bleibt schwer.
- Brauche ich noch ein Caching-Plugin?
- Nicht für Ihre Besucher: Die Kopie besteht schon aus fertigen Seiten. Im WordPress, in dem Sie bearbeiten, macht es für sie so oder so keinen Unterschied.
Probieren Sie es mit Ihrer eigenen Website
Etwa zwanzig Sekunden, und Sie müssen sich nirgends anmelden. Sie haben Ihre Website und die Kopie nebeneinander offen und probieren die Kopie selbst aus, bevor Sie irgendetwas entscheiden.