Websites werden immer noch zu langsam geladen. Im kritischsten Moment des Download-Prozesses ist der Kanal oft fast vollständig inaktiv. Die neue Technologie von Fastly, die von Ingenieur Kazuho Oku vorgeschlagen wurde, wird dazu beitragen, diese kritischen ersten Sekunden besser zu nutzen.

Haben Sie jemals eine Website auf Ihr Telefon heruntergeladen und 10 Sekunden lang auf einer Seite ohne Text gesucht? Niemand sitzt gerne und schaut auf einen leeren Bildschirm, während eine ungewöhnliche Schriftart geladen wird. Daher ist es sinnvoll, das Laden so wichtiger Dinge zum frühestmöglichen Zeitpunkt zu übertragen. Die Vorspannung Link rel = Vorspannung sollte das Problem teilweise lösen. Zunächst analysiert der Browser die HTTP-Header. Dies ist also der perfekte Ort, um auf das Vorladen einer Ressource hinzuweisen, die Sie später definitiv benötigen werden.

Standardmäßig ist das Internet langsam

Mal sehen, was passiert, wenn Sie keine Vorlast verwenden. Der Browser kann Ressourcen erst laden, nachdem er festgestellt hat, dass er sie benötigt. Dies ist am wahrscheinlichsten bei Ressourcen der Fall, die sich beim ersten Parsen des Dokuments in HTML befinden (z. B. <script> , <link rel=stylesheet> und <img> ).

Die Ressourcen, die nach dem Erstellen des Renderbaums erkannt werden, werden langsamer heruntergeladen (dies ist der Ort, an dem die Seite aufgrund des Ladens der Schriftart langsamer wird. Um dies zu verstehen, müssen Sie zuerst das Stylesheet laden, es analysieren, das CSS-Objektmodell und dann den Renderbaum erstellen).

Noch langsamer werden Ressourcen DOMContentLoaded , die dem Dokument mithilfe von JavaScript- DOMContentLoaded hinzugefügt werden, die durch Ereignisse wie DOMContentLoaded ausgelöst werden. Wenn Sie alles zusammenfügen, erhalten wir einen nicht optimierten und ziemlich bedeutungslosen Wasserfall. Meistens ist der Kanal inaktiv und Ressourcen werden entweder früher als nötig oder zu spät geladen:

Link rel = Preload hilft sehr

In den letzten Jahren hat sich die Situation dank Link rel = Vorspannung verbessert. Zum Beispiel:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Dank dieser Anweisungen kann der Browser sofort nach Erhalt der Header und vor Beginn der Analyse des HTML-Körpers mit dem Laden von Ressourcen beginnen:



Dies ist eine erhebliche Verbesserung, insbesondere bei großen Seiten und kritischen Ressourcen, die sonst zu spät entdeckt würden. Insbesondere für Schriftarten kann jedoch alles zu einer kritischen Ressource werden, z. B. die zum Laden einer JavaScript-Anwendung erforderliche Datendatei.

Wir können jedoch noch mehr tun. Schließlich unternimmt der Browser zwischen dem Zeitpunkt des Abschlusses des Sendens der Anforderung und dem Empfang der ersten Bytes der Antwort nichts (das große grüne Fragment bei der ersten Anforderung ist höher).

Wir nutzen die Zeit des „Server-Denkens“ mit Hilfe von „frühen Tipps“.

Auf der anderen Seite ist der Server sehr beschäftigt. Es generiert eine Antwort und bestimmt, ob es erfolgreich ist oder nicht. Nach dem Zugriff auf die Datenbank, API-Aufrufe, Authentifizierung usw. Der Server kann entscheiden, dass der 404-Fehler die richtige Antwort ist.

Manchmal ist die Server-Meditationszeit kürzer als die Netzwerklatenz. Manchmal wesentlich mehr. Es ist jedoch wichtig zu verstehen, dass sie sich nicht überschneiden. Während der Server nachdenkt, senden wir keine Daten an den Client.

Es ist jedoch interessant, dass Sie bereits vor dem Generieren der Antwort einige Stile und Schriftarten kennen, die Sie herunterladen müssen, um die Seite anzuzeigen. Schließlich verwenden Fehlerseiten normalerweise dieselbe Corporate Identity und dasselbe Design wie normale Seiten. Es wäre großartig, diese Link: rel=preload zu senden, bevor der Server überhaupt funktioniert . Aus diesem Grund wurde der von der HTTP-Arbeitsgruppe in RFC8297 konzipierte Early Hints- Standard von Fastly, meinem Kollegen Kazuho Oku, geprägt. Bewerten Sie die Magie mehrerer Statusleisten in einer Antwort :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

Der Server kann den ersten sogenannten "informativen" Antwortcode aufzeichnen, sobald er eine Anfrage erhält, und ihn an das Netzwerk senden. Dann wird er sich mit der Definition einer realen Reaktion und ihrer Erzeugung befassen. In der Zwischenzeit können Sie im Browser viel früher mit dem Vorladen beginnen:



Dies erfordert natürlich bestimmte Änderungen im Betrieb von Browsern, Servern und CDNs, und die Entwickler einiger Browser haben Vorbehalte gegen die Schwierigkeiten bei der Implementierung geäußert. Daher ist noch unklar, wann diese Header in Betrieb genommen werden können. Sie können den Fortschritt in öffentlichen Trackern für Chrome und Firefox verfolgen.

Wir gehen davon aus, dass Sie am Ende Early Hints-Header direkt von Fastly aus ausgeben können und weiterhin Anfragen auf standardmäßige Weise senden können. Wir haben noch nicht entschieden, wie die Schnittstelle über VCL eingestellt werden soll. Lassen Sie mich wissen, wenn Sie diesbezüglich Wünsche haben!

Aber was ist mit HTTP / 2 Server Push?

Mit HTTP / 2 gibt es eine neue Technologie namens Server Push, die das gleiche Problem zu lösen scheint wie Link rel = Preload in Early Hints Answer. Obwohl es wirklich funktioniert (und Sie in Fastly sogar schnell benutzerdefinierte Pushs von Edgeservern generieren können), gibt es in mehreren Punkten erhebliche Unterschiede:

• Der Server weiß nichts über die Verfügbarkeit einer Ressource auf dem Client und pusht sie daher häufig unnötig. Aufgrund der Netzwerkpufferung und Latenz kann der Client das Senden normalerweise nicht abbrechen, bevor alle Inhalte empfangen wurden. (Obwohl es eine mögliche Lösung für dieses Problem gibt, in Form der vorgeschlagenen Cache Digest- Überschrift, an der Kazuho mit Joam Weiss von Akamai arbeitet).
• Die gestreamten Ressourcen sind an die Verbindung gebunden, sodass es einfach ist, eine Ressource zu starten, die der Client nicht verwendet, da er versucht, sie über eine andere Verbindung abzurufen. Clients müssen möglicherweise eine andere Verbindung verwenden, da sich die Ressource in einer anderen Quelle mit einem anderen TLS-Zertifikat befindet oder weil sie in einem anderen Anmeldeinformationsmodus abgerufen wird.
• H2 Push ist in verschiedenen Browsern nicht sehr konsequent implementiert . Daher ist es schwierig vorherzusagen, ob es in Ihrem speziellen Fall funktioniert oder nicht.

Auf die eine oder andere Weise bieten Early Hints und Server Push unterschiedliche Kompromisse. Frühe Hinweise ermöglichen eine effizientere Nutzung des Netzwerks im Austausch für zusätzlichen Paketaustausch. Wenn Sie eine geringe Netzwerklatenz und lange Überlegungen zum Server erwarten, ist Early Hints die richtige Lösung.

Dies ist jedoch nicht immer der Fall. Seien wir optimistisch und stellen wir uns vor, dass sich die Menschen bald auf dem Mars niederlassen werden. Sie surfen mit einer Verzögerung von 20 bis 45 Minuten für jeden Paketaustausch im Internet, sodass der zusätzliche Austausch äußerst schmerzhaft ist und die Serverzeit im Vergleich dazu vernachlässigbar ist. Server Push gewinnt hier leicht. Wenn wir uns jedoch jemals Webseiten von Mars ansehen, ist es wahrscheinlicher, dass wir eine Art Datenpaket herunterladen, etwa Webpakete, die jetzt angeboten werden, und signierte Börsen .

Zusätzlicher Bonus: Schnellerer Zusammenbruch von Anfragen

Obwohl Early Hints hauptsächlich im Browser verwendet werden soll, gibt es für CDN einen interessanten potenziellen Vorteil. Wenn Fastly viele Anfragen für dieselbe Ressource erhält, senden wir normalerweise nur eine davon an die Quelle und stellen den Rest in die Warteschlange. Dieser Vorgang wird als Anforderungskollabieren bezeichnet . Wenn die Antwort von der Quelle Cache-Control: private , sollten Sie alle Anforderungen aus der Warteschlange entfernen und separat an die Quelle senden, da wir nicht eine Antwort verwenden können, um mehrere Anforderungen zu erfüllen.

Wir können keine Entscheidung treffen, bis eine Antwort auf die erste Anforderung eingegangen ist. Wenn der Server jedoch bei der Unterstützung von Early Hints eine Antwort von Early Hints mit der Überschrift Cache-Control zurückgibt, wissen wir viel früher, dass die Warteschlange nicht zu einer einzigen Anforderung zusammengefasst werden kann, sondern stattdessen Leiten Sie alle Anforderungen aus der Warteschlange sofort an die Quelle weiter.

Bestellen Sie weniger kritische Inhalte mit Prioritäts-Tipps

Frühe Tipps sind eine gute Möglichkeit, auf einige der wertvollsten Objekte in der Warteschlange (Wasserfall) zuzugreifen: Wenn das Netzwerk inaktiv ist, wartet der Benutzer, es ist nur eine Anforderung unterwegs und es wird nichts auf dem Bildschirm angezeigt. Sobald jedoch der HTML-Code geladen und die Seite analysiert wird, steigt die Anzahl der Ressourcen, die geladen werden müssen, dramatisch an. Jetzt ist es wichtig, Ressourcen nicht so schnell wie möglich zu laden, sondern in der richtigen Reihenfolge. Browser verwenden eine überraschend komplexe Reihe von Heuristiken , um die Priorität des Downloads unabhängig zu bestimmen. Wenn Sie sie jedoch neu definieren möchten, können Sie dies in Zukunft mithilfe von Prioritätshinweisen tun:

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

Mit diesem neuen wichtigen Attribut können Entwickler die Ladereihenfolge von Ressourcen im Falle eines Wettbewerbs um das Netzwerk steuern. Möglicherweise können Ressourcen mit niedriger Priorität verzögert werden, bis der Prozessor und das Netzwerk frei sind, oder je nach Gerätetyp.

Kann das verwendet werden?

Weder frühe noch vorrangige Hinweise sind zum Standard geworden. Vor kurzem hat H2O, der von Fastly verwendete und unterstützte HTTP / 2-Server, begonnen, Early Hints zu verwenden (siehe PR 1727 und 1767 ). Es ist beabsichtigt, Priority Hints in Chrome zu implementieren und 1xx-Antworten aktiv zu verfolgen. Gleichzeitig schadet es nicht, sofort mit dem Senden von Early Hints zu beginnen - und wenn Sie dem Trend einen Schritt voraus sein möchten, dann gehen Sie!