Die Zeit bis zum ersten Byte ist die Spanne vom Fragen bis zum Eintreffen des ersten Antwortbytes. Sie enthält DNS, die Verbindung, den Handshake und das Nachdenken des Servers - und curl druckt jeden Teil einzeln, sodass Sie sehen, welcher es ist.
curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://yourdomain.com/Sie lesen
- dns groß - ein langsamer Resolver, oder eine sehr niedrige TTL, die jedes Mal eine Abfrage erzwingt.
- connect groß - Entfernung. Ein Server auf einem anderen Kontinent lässt sich nicht mit Code reparieren.
- tls minus connect groß - der Handshake. Eine unvollständige Zertifikatskette zwingt den Browser, das fehlende Stück nachzuladen.
- ttfb minus tls groß - der Server baut die Seite. Das ist der Teil, den Sie reparieren können.
Was gut ist
- Unter 200 ms - der Server ist nicht Ihr Problem. Schauen Sie in den Browser.
- 200-500 ms - normal für eine dynamische Seite ohne Cache.
- Über 800 ms - etwas Bestimmtes ist langsam, und es lohnt sich, das zu finden, statt es zuzucachen.
Messen Sie dieselbe URL mehrmals. Die erste Anfrage nach einem Deployment ist aus Gründen langsam, die nie einen Besucher treffen - kalte Caches, leerer opcache -, und eine einzelne Messung davon sagt Ihnen nichts.
Von dort messen, wo Ihre Besucher sind
Ein TTFB vom Server selbst lässt das Netz ganz aus und ist immer hervorragend. Es ist auch nicht das, was irgendjemand erlebt.
Ist die TTFB in Ordnung und die Seite fühlt sich trotzdem langsam an, hören Sie auf, den Server zu optimieren. Die Zeit steckt im Browser, und keine Menge Caching ändert daran etwas.
