TTFB: Wie eine gute Zeit zum ersten Byte aussieht und wie man dorthin kommt
Time to First Byte ist die Wartezeit, bevor Ihr Server überhaupt etwas sagt, und es setzt die Decke für alles danach. Wie gut aussieht und wie man findet, welcher Teil von dir langsam ist.
TTFB ist die Zeit zwischen dem Browser, der eine Anfrage sendet und das erste Byte der Antwort erhält. Unter 200ms ist gut, 200–600ms ist praktikabel, über 600ms ist ein Problem. Es besteht aus vier trennbaren Teilen — DNS, Verbindungsaufbau, Netzwerkreise und Serververarbeitung — und es zu verbessern beginnt mit dem Ausarbeiten, welches der vier Ihr Budget isst.
Time to First Byte ist die leiseste Performance Metrik und eine der konsequentesten, denn nichts anderes kann beginnen, bis es endet. Der Browser kann HTML nicht parsen, es hat nicht, kann nicht entdecken, das Stylesheet in ihm referenziert, kann nicht beginnen, das Heldenbild zu holen. Eine langsame TTFB macht die ganze Seite zu spät, egal wie gut alles stromabwärts optimiert wird.
Es wird auch häufig falsch diagnostiziert, denn "TTFB ist 900ms" ist ein Symptom mit mindestens vier verschiedenen Krankheiten.
Die vier Dinge, die sich in einer Zahl verstecken
Klicken Sie auf eine beliebige Anfrage und öffnen Sie das Timing-Panel in Ihrem Browser. Sie werden sehen, wie sich die einzelne TTFB-Nummer ausblendet:
- DNS-Suchen. Wenn es konstant hoch ist, ist Ihr DNS-Provider langsam oder Ihr TTL zu kurz.
- Erste Verbindung und TLS — die Handshakes. Zwei bis drei Rundfahrten über TCP, eine über QUIC. Skalen direkt mit Abstand, und dies ist der Teil, der TLS an einem nahe gelegenen Rand beendet eliminiert.
- Fordern Sie Reiseanfrage an den Server, der sie beantworten wird.
- Warten (TTFB) — der Server macht die Arbeit. Dies ist der Teil Chrome Labels "Warte auf Server-Antwort", und auf einer langsamen dynamischen Website ist es die ganze Geschichte.
Die Diagnose ist eine Frage der Betrachtung, welche Bar am längsten ist. Wenn "Warten" 700ms ist und alles andere 40ms ist, wird keine CDN-Konfiguration Sie speichern — Ihre Anwendung ist langsam und dort ist die Arbeit. Wenn "Warten" 40ms ist und die Verbindungsphasen 600ms sind, ist Ihre Anwendung in Ordnung und Sie haben ein geographisches Problem.
Was als gut zählt
Ein wichtiger Vorbehalt über diese Schwellen: Sie sind nur neben dem Ort, an dem sie gemessen wurden, sinnvoll. Ein 150ms TTFB von Ihrem Büro in der gleichen Stadt wie Ihr Server kann 800ms für einen Kunden in Sao Paulo, und die Sao Paulo-Nummer ist die, die Ihren Umsatz beeinflusst. Testen Sie immer aus mindestens drei Regionen, in denen Sie tatsächlich Besucher haben.
TTFB ist kein Core Web Vital
Es lohnt sich, klar zu sagen, weil es Verwirrung verursacht. Google rangiert nicht direkt auf TTFB — es rangiert auf Größte Contentful Paint, und TTFB ist ein Bestandteil davon. Das macht TTFB nicht unwichtig; es macht es zu einem Leitindikator. Jede Millisekunde von TTFB ist eine Millisekunde LCP kann nicht erholen, so dass eine Website mit einem 900ms TTFB hat mehr als ein Drittel seiner 2,5-Sekunde LCP-Budget ausgegeben, bevor der Browser ein einziges Tag gesehen hat.
Jede Ursache beheben
| Symptome im Timing-Panel | Ursache | Fixieren |
|---|---|---|
| Langes Warten, alles andere kurz | Langsames Renderen auf Server-Seite | Die fertige Seite einschließen; die langsame Abfrage profilieren |
| Lange Verbindung/TLS, kurzes "Warten" | Herkunft fernab des Besuchers | Beenden Sie TLS und dienen von einem nahe gelegenen Rand |
| Schnell vor Ort, langsam aus dem Ausland | Ursprung der einzelnen Regionen | Cache an den Rändern in der Nähe Ihres tatsächlichen Publikums |
| Schnell bei zweiter Last, langsam beim ersten | Cache verpasst | Cache-Hit-Verhältnis erhöhen; Vorwärmen nach Säubern |
| Konsequent hohe DNS | Langsamer Resolver oder kurzer TTL | Anycast DNS; erhöhen Sie TTL auf stabilen Datensätzen |
| Erratic, Spikes unter Last | Ursprungskapazität | In Cache ausladen, so dass der Ursprung weniger sieht |
Beachten Sie das Muster über die meisten dieser Zeilen: der Fix ist "Stopp die langsame Sache auf jeder Anfrage". Eine zwischengespeicherte Seite, die von einem nahe gelegenen Rand aus bedient wird, überspringt den Fernhandshake, die Applikation Render und die Datenbank vollständig – weshalb Caching mehr für TTFB tut als alles andere, was Ihnen zur Verfügung steht.
Eine Falle, die es wert ist, zu benennen: ein CDN vor einer unerreichbaren Seite macht TTFB leicht Schlimmer, nicht besser, weil Sie einen Hopfen hinzugefügt haben. Wenn eine Seite trägt Cache-Control: no-store der Rand muss jede Anfrage an Ihren Ursprung weiterleiten und die Antwort weiterleiten. Wenn jemand berichtet, dass ein CDN seine Website langsamer gemacht hat, ist dies fast immer passiert — und die Lösung ist, die Seite zwischengespeichert zu machen, nicht das CDN zu entfernen.
Eine fünfminütige Diagnose
Maßnahme aus drei Regionen
Ihr eigener Standort und zwei Orte, an denen Sie echte Besucher haben. Beachten Sie die Verbreitung, nicht nur die beste Zahl.
Öffnen Sie das Timing-Panel auf der HTML-Anfrage
Nicht auf einem Vermögenswert — auf dem Dokument selbst. Identifizieren Sie den längsten Balken.
Die gleiche Seite zweimal laden
Wenn die zweite Last dramatisch schneller ist, haben Sie einen Cache Miss gemessen und Ihr Problem ist Trefferverhältnis, nicht Rohgeschwindigkeit.
Kante und Herkunft direkt vergleichen
Fordern Sie die Seite durch das CDN und dann direkt von Ihrem Herkunfts-Hostname. Der Unterschied sagt dir, wie viel der Rand dazu beiträgt — und ob er überhaupt dazu beiträgt.
Häufig gestellte Fragen
Was ist ein guter TTFB?
Unter 200 Millisekunden ist gut und fühlt sich sofort, 200 bis 600 Millisekunden ist akzeptabel mit Raum zu verbessern, und über 600 Millisekunden ist langsam genug, dass Besucher bemerken. Diese Zahlen bedeuten nur etwas in Kombination mit dem Ort, an dem die Messung vorgenommen wurde – ein guter TTFB aus der eigenen Stadt kann für Besucher auf einem anderen Kontinent schlecht sein, also Test aus den Regionen, in denen sich Ihr Publikum befindet.
Was verursacht einen langsamen TTFB?
Vier Dinge, und der Browser Timing Panel wird Ihnen sagen, welche. Die langsame serverseitige Verarbeitung zeigt als lange "Warte"-Phase; die physische Distanz zum Ursprung zeigt als lange Verbindung und TLS-Phasen; Cache verpasst zeigt als langsame erste Last und eine schnelle zweite; und DNS-Probleme zeigen als eine durchweg hohe Lookup-Zeit. Jeder hat einen anderen Fix, so dass die Identifizierung, welche man dominiert kommt vor jeder Änderung.
Ist TTFB ein Kernnetz Vital?
Nein. Googles Core Web Vitals sind die größte zufriedene Farbe, Interaktion zum nächsten Mal und kumulative Layout-Shift. TTFB ist nicht direkt rangiert, aber es ist ein Bestandteil von LCP - jede Millisekunde, die auf das erste Byte wartet, ist ein Millisekunde LCP kann nicht zurück, so eine hohe TTFB-Kappen, wie gut Ihr LCP sein kann.
Verbessert ein CDN TTFB?
Deutlich, für zwischenspeicherbare Inhalte. Eine zwischengespeicherte Seite wird von einem Rand in der Nähe des Besuchers bedient, der den Fern-Handshake entfernt, die Applikation rendern und die Datenbank in einem Zug arbeitet. Für nicht speicherbare Seiten erhöht ein CDN durch Hinzufügen eines Hops die TTFB leicht, so dass, wenn eine Seite keinen Store sendet, das Fix darin besteht, es zwischenspeicherbar zu machen, anstatt das CDN zu entfernen.
Wie kann ich TTFB messen?
In Chrome DevTools, öffnen Sie die Registerkarte Netzwerk, klicken Sie auf das Dokument anfordern, und lesen Sie das Timing-Panel, die DNS getrennt, Verbindung, TLS, Anfrage und Wartezeit. Für eine schnelle Kommandozeilenüberprüfung verwenden Sie Curl mit einem Ausschreibformat Druckzeit_starttransfer. Um zu sehen, was wirkliche Besucher erleben und nicht was Sie erleben, verwenden Sie einen synthetischen Testdienst, der aus mehreren Regionen oder aus der Überwachung der realen Nutzer kommt.
TTFB caps Ihre ganze Seite Geschwindigkeit, so Ziel für unter 200ms - aber messen Sie es von wo Ihre Besucher sind, und teilen Sie es in seine Teile, bevor etwas zu ändern. Wenn "Warten" dominiert, fixieren Sie Ihre Anwendung oder Cache der Seite. Wenn die Verbindungszeit dominiert, verschieben Sie die Antwort näher. Die falsche Lösung ist die häufigste Art, eine Woche zu verbringen und nichts zu gewinnen.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
