Jetzt arbeite ich an einem Projekt für einen Kunden. Dies ist eine E-Commerce-Website, daher interessieren mich einige Aspekte der Leistung sehr. Für den Anfang sind dies verschiedene Indikatoren, die die Ladezeit einer Site charakterisieren. Weiter - Dies ist die Startzeit für das Rendern der Seite. Dies ist wichtig für diejenigen Besucher, die nach dem Aufrufen der Website den Inhalt so schnell wie möglich sehen möchten (natürlich fallen alle Website-Besucher in diese Kategorie). Zu den Leistungsindikatoren, die mich interessieren, gehören diejenigen, die die Besonderheiten der Aktivitäten meines Kunden widerspiegeln. Zum Beispiel: "Wie schnell wird das Hauptbild des Produkts geladen?" Eine Analyse all dieser Indikatoren kann wertvolle Informationen über den Stand des Projekts liefern.
Es gibt jedoch einen Indikator, dem Front-End-Entwickler anscheinend häufig nicht genügend Aufmerksamkeit schenken. Es ist Zeit für das erste Byte (Time to First Byte, TTFB). Sie können dies verstehen, Sie können Entwicklern diese Haltung gegenüber TTFB zumindest teilweise verzeihen, insbesondere angesichts der Tatsache, dass sie diesen Indikator als etwas betrachten, das nur vom Backend der Projekte abhängt. Wenn wir jedoch versuchen, das Problem in Bezug auf diesen Indikator buchstäblich kurz auszudrücken, können wir Folgendes sagen: "Obwohl ein guter TTFB-Wert nicht unbedingt bedeutet, dass die Website, die dies demonstriert, als schnell angesehen werden kann, weist ein schlechter TTFB-Indikator mit ziemlicher Sicherheit auf Probleme mit der Projektleistung hin."
Selbst wenn wir die Tatsache berücksichtigen, dass der Front-End-Entwickler möglicherweise in einer Position ist, in der er das Backend und den TTFB nicht unabhängig beeinflussen kann, ist es wichtig zu berücksichtigen, dass hohe TTFB-Werte die Leistung der Site erheblich beeinträchtigen können. Infolgedessen ähneln die Bemühungen eines Front-End-Entwicklers, der nach Website-Geschwindigkeit strebt, einem Aufholspiel. Dies gilt beispielsweise für die Bildoptimierung, die Minimierung des Materialvolumens, aus dem die wichtigsten Abschnitte des Projekts bestehen, und das asynchrone Herunterladen von Webschriftarten. Dies bedeutet nicht, dass Sie in diesem Wissen die Front-End-Optimierungen aufgeben und aufgeben können. Wenn der TTFB jedoch zu hoch ist, erinnern alle derartigen Optimierungen an den Versuch, ein Problem unter Bedingungen zu beheben, unter denen es bereits Schaden angerichtet hat und zu spät ist, um dieses Problem zu beheben. In der Tat ist es deshalb für diejenigen, die das Front-End entwickeln, sehr wichtig, den TTFB-Indikator genau zu überwachen, und es ist sehr wichtig, wenn seine Werte zu hoch sind, Maßnahmen zu seiner Verbesserung zu ergreifen.
Was ist TTFB?
TTFB sieht nicht sehr informativ aus ( Bild in voller Größe )TTFB ist ein Indikator, der, gelinde gesagt, undurchsichtig aussieht. Er beeinflusst so sehr, dass ich das Gefühl habe, dass wir die ganze Zeit nur seine ernsthafte Analyse abwischen. Viele spekulieren, dass TTFB nur die Zeit ist, die der Server benötigt, um eine Antwort vorzubereiten, aber es ist tatsächlich nur ein kleiner Teil dessen, was TTFB betrifft.
Das erste, worauf ich Sie aufmerksam machen möchte, ist, dass die Leute beim Lernen normalerweise sehr überrascht sind. Wir sprechen über die Tatsache, dass TTFB die Zeit enthält, zu der die Anforderung vom Client über das Netzwerk an den Server gesendet wird, und die Zeit, die der Serverantwortpfad zum Client benötigt. Dies ist die sogenannte "Round Trip Time" (Round Trip Time, RTT). TTFB ist nicht nur eine Zeit, die der Server für die Vorbereitung einer Antwort benötigt. Es ist auch die Zeit, die für die Übertragung von Daten von Client zu Server und von Server zu Client aufgewendet wird (diese Daten enthalten natürlich das für uns interessante „erste Byte“).
Mit diesem Wissen können wir nun leicht verstehen, warum der TTFB-Indikator beim Anzeigen von Websites von Mobilgeräten oft einfach unangemessen groß ist. Es ist durchaus möglich, dass Sie früher in solchen Situationen Folgendes gefragt hätten: "Ich bin sicher, dass der Server nicht weiß, dass ich die Website von einem Mobiltelefon aus ansehe. Wie erhöht es dann den TTFB? “ Der Grund dafür ist, dass Mobilfunknetzverbindungen in der Regel Verbindungen mit hoher Latenz sind. Wenn die RTT-Anzeige, die die Zeit angibt, die die Daten benötigen, um vom Telefon zum Server und zurück zu gelangen, beispielsweise 250 ms beträgt, erhöht sich der TTFB um den entsprechenden Wert.
Wenn ich möchte, dass die Leser dieses Materials nur eine Hauptidee daraus herausnehmen, würde ich diese Idee wie folgt formulieren: "Netzwerkverzögerungen wirken sich auf TTFB aus."
Was betrifft TTFB noch? In der Tat - viel von allem. Hier ist eine alles andere als vollständige Liste dessen, was zu diesem Indikator beiträgt. Die Elemente in dieser Liste sind in zufälliger Reihenfolge.
- Netzwerkverzögerungen. Wie bereits erwähnt, enthält TTFB die Zeit, die erforderlich ist, um eine Anforderung an den Server zu senden und eine Antwort vom Server zurückzugeben. Nehmen Sie zum Beispiel die Zeit, die für eine Datenaustauschsitzung zwischen einem Gerät in London und einem Server in New York erforderlich ist. Idealerweise sind dies bei Verwendung einer Glasfaserverbindung 28 ms. Dies basiert jedoch auf vielen sehr optimistischen Annahmen. In Wirklichkeit sollten Sie ungefähr 75 ms erwarten. Deshalb ist es so wichtig, CDN zu verwenden. Selbst jetzt, im Zeitalter des Internets, ist die geografische Nähe eines bestimmten Unternehmens und seiner Kunden von Vorteil.
- Routing Wenn Sie CDN verwenden (und das sollte auch so sein!), Kann die Anfrage Ihres Kunden, beispielsweise von Leeds, nur an das MAN-Rechenzentrum umgeleitet werden, sodass sich herausstellt, dass sich die vom Client benötigte Ressource nicht im entsprechenden PoP- Cache befindet . Anschließend wird die Anfrage mit Ihren Materialien an den realen Server umgeleitet, um dem Client dennoch zu übermitteln, was er benötigt. Befindet sich dieser Server beispielsweise in Virginia, führt all dies ohne ersichtlichen Grund zu einer ernsthaften Erhöhung des TTFB.
- Mit Dateien arbeiten. Selbst wenn der Server einfach statische Daten aus seinem Dateisystem liest, z. B. Bilder oder Stildateien, dauert es einige Zeit, bis dieser Vorgang abgeschlossen ist. Diese Zeit ist auch Teil von TTFB.
- Priorisierung Das HTTP / 2-Protokoll verfügt über Mechanismen zum Priorisieren der Anforderungsverarbeitung. Infolgedessen kann sich herausstellen, dass Anforderungen mit niedriger Priorität auf dem Server verzögert werden können, was Anforderungen mit hoher Priorität Platz macht. Selbst wenn Sie die HTTP / 2-Priorisierungsmechanismen nicht berücksichtigen und davon ausgehen, dass alles reibungslos funktioniert, können diese erwarteten Verzögerungen zu TTFB beitragen.
- Ausführen von Anwendungen. Dies ist in der Tat ziemlich offensichtlich, aber ich möchte darauf hinweisen, dass die zum Ausführen der Serveranwendungen erforderliche Zeit TTFB ernsthaft beeinflusst.
- Datenbankabfragen. Wenn Sie etwas von der Datenbank anfordern müssen, um die Seite zu erstellen, wird die Zeit zum Abschließen eines solchen Vorgangs auch in TTFB enthalten sein.
- API-Aufrufe Wenn Daten von bestimmten APIs (intern oder extern) zur Vorbereitung der Seite benötigt werden, wirken sich Aufrufe dieser APIs auf TTFB aus.
- Server-Rendering Es ist ziemlich offensichtlich, dass das serverseitige Rendern Zeit braucht. Diese Zeit ist leicht zu bewerten, aber dies negiert nicht den Beitrag dieser Operation zu TTFB.
- Günstiges Hosting. Wenn Sie billiges Hosting verwenden, versuchen, so viel wie möglich zu sparen und die Leistung zu beeinträchtigen, bedeutet dies normalerweise, dass eine Reihe anderer Projekte den Server verwenden, auf dem sich Ihr Projekt befindet. Vielleicht eine beträchtliche Menge. Infolgedessen kann jemand, der billiges Hosting verwendet, mit einem Rückgang der Serverleistung rechnen, was sich auf die Fähigkeit des Projekts auswirken kann, Anforderungen zu verarbeiten. In der Tat sprechen wir über die Tatsache, dass die Leistung der Serverhardware nicht ausreicht, um die Anforderungen der Anwendung zu erfüllen.
- DDoS-Angriffe, hohe Belastung des Projekts. Hier setzen wir das im vorherigen Absatz dieser Liste behandelte Thema fort. Wenn nämlich die Auslastung des Servers zunimmt und das Projekt keine flexible Skalierung der Serverkapazitäten vorsieht, führt dies dazu, dass die Geräte an ihre Grenzen stoßen. Infolgedessen sinkt die Anwendungsleistung.
- WAF, Load Balancer. Dienste wie WAF oder Load Balancer vor der Serveranwendung erhöhen die TTFB.
- Einige Funktionen von CDN. Die Verwendung von CDNs ist ein Faktor, der sich sicherlich positiv auf TTFB auswirkt, aber einige Merkmale von CDNs können dies noch verschlimmern. Dies ist beispielsweise Anforderungsfaltung , ESI usw.
- Verzögerungen bei der „letzten Meile“. Wenn wir über einen Computer aus London sprechen, der auf einen Server in New York zugreift, vereinfachen wir die Situation normalerweise zu stark und reduzieren sie fast auf die Tatsache, dass Computer und Server direkt miteinander verbunden sind. In Wirklichkeit ist alles viel komplizierter. Das Signal zwischen Computer und Server geht über viele Vermittler. Unser Router sendet es an den Anbieter. Über ein drahtloses Netzwerk gelangt er in ein Kabel, das über den Meeresboden verlegt ist. Zu den Verzögerungen auf der "letzten Meile" gehören alle Schwierigkeiten, die der Datenübertragung zwischen Endgeräten im Wege stehen.
Ein 0 ms TTFB ist ein Wunschtraum. Daher ist es wichtig zu beachten, dass die Liste nichts enthält, was den TTFB immer negativ beeinflusst oder diesen Indikator immer verschlechtert. Diese Liste wird am besten als Beschreibung der TTFB-Struktur eines Projekts verstanden. Mein Ziel ist es nicht, bestimmte Technologien zu kritisieren, sondern zu zeigen, wie bestimmte Technologien TTFB beeinflussen können. Und um ehrlich zu sein, ist es angesichts der Tatsache, wie viel passiert, bevor der Client das erste Byte der Antwort vom Server erhält, bereits überraschend, dass die Websites im Allgemeinen geladen werden.
Mit TTFB das Geheimnis aufdecken
Hoffentlich sieht TTFB jetzt nicht mehr so mysteriös aus. Wenn Sie ein wenig Zeit mit der Implementierung von API
Server Timing verbringen, können Sie schwierige Serverzeitindikatoren messen und an Client-Systeme senden. Auf diese Weise können Webentwickler potenzielle Leistungsengpässe erkennen und beseitigen, die zuvor vor ihren Augen verborgen waren.
Mit der Server-Timing-API können Entwickler Abfrageantworten mit dem optionalen
Server-Timing HTTP-Header erweitern. Es enthält Zeitinformationen, die von der Anwendung selbst gemessen werden.
Diesen Mechanismus haben wir letztes Jahr bei der Arbeit am BBC iPlayer verwendet.
Jeder Antwort kann ein neuer Server-Timing-Header hinzugefügt werden ( Bild in voller Größe ).
Beachten Sie, dass das Server-Timing auch das System belastet. Während der Arbeit müssen Sie die relevanten Indikatoren messen und den
Server-Timing Header ausfüllen. Der Browser erlaubt dem Front-End-Entwickler nur, diese Daten mit den entsprechenden Tools anzuzeigen.
Jetzt können Sie direkt im Browser die TTFB-Struktur sehen ( Bild in voller Größe ).Wenn Sie die Server-Timing-API implementieren möchten, sehen Sie sich
dieses Material an .
Zusammenfassung
Es ist sehr wichtig, dass Webentwickler verstehen, inwieweit TTFB die sogenannte "Site-Leistung" beeinflusst. Die Zeit bis zum ersten Byte ist eine bestimmte Grenze, nach der Überquerung können wir über Website-Optimierung sprechen. Je niedriger dieser Indikator, desto besser.
Liebe Leser! Optimieren Sie Ihre Webprojekte mit TTFB?
