Im Bereich „Netzwerk“ in den Entwicklertools Ihres Browsers sehen Sie, welche Ressourcen wann geladen werden. Jede Zeile im Bereich „Netzwerk“ entspricht einer bestimmten URL, die Ihre Web-App geladen hat.
Wissen, was geladen wird
Um die richtigen Caching-Strategien für Ihre Webanwendung zu entwickeln, müssen Sie wissen, was genau geladen wird. Bei der Erstellung einer zuverlässigen Webanwendung kann das Netzwerk allen möglichen dunklen Kräften ausgesetzt sein. Sie müssen die Sicherheitslücken des Netzwerks verstehen, wenn Sie in Ihrer Anwendung damit umgehen möchten.
Vielleicht denken Sie, dass Sie bereits eine gute Vorstellung davon haben, was Ihre Webanwendung lädt. Wenn Sie nur eine kleine Anzahl von statischen HTML-, JavaScript-, CSS- und Bilddateien verwenden, könnte das zutreffen. Sobald Sie jedoch Ressourcen von Drittanbietern, die in Content Delivery Networks gehostet werden, mithilfe dynamischer API-Anfragen und servergenerierter Antworten hinzufügen, wird das Bild schnell düster.
Eine Caching-Strategie, die für einige kleine CSS-Dateien sinnvoll ist, reicht beispielsweise bei Hunderten großer Bilder nicht aus.
Informationen zum Laden
Ein weiterer Teil des gesamten Ladebilds ist, wann alles geladen wird.
Einige Anfragen an das Netzwerk, z. B. die Navigationsanfrage für den ursprünglichen HTML-Code, werden unbedingt ausgeführt, sobald ein Nutzer eine bestimmte URL aufruft. Dieser HTML-Code kann hartcodierte Verweise auf wichtige CSS- oder JavaScript-Dateien enthalten, die ebenfalls geladen werden müssen, um Ihre interaktive Seite anzuzeigen. Alle diese Anfragen befinden sich in Ihrem kritischen Ladepfad. Sie müssen diese aggressiv im Cache speichern, um zuverlässig schnell zu sein.
Andere Ressourcen wie API-Anfragen oder Lazy-Loading-Assets werden möglicherweise erst lange nach dem ersten Laden geladen. Wenn diese Anfragen nur nach einer bestimmten Abfolge von Nutzerinteraktionen erfolgen, kann es passieren, dass bei mehreren Besuchen derselben Seite ein völlig anderer Satz von Ressourcen angefordert wird. Eine weniger aggressive Caching-Strategie eignet sich häufig für Inhalte, die sich außerhalb des kritischen Ladepfads befinden.
Die Spalten Name und Typ geben an,
Die Spalten Name und Typ geben ein aussagekräftiges Bild davon, was geladen wird. Die Antwort auf was wird geladen? im Beispiel oben besteht aus insgesamt vier URLs, die jeweils einen eindeutigen Inhaltstyp darstellen.
Der Name steht für die URL, die Ihr Browser angefordert hat. Allerdings wird nur der letzte Teil des URL-Pfads aufgeführt. Wenn beispielsweise https://example.com/main.css geladen ist, wird unter Name nur main.css angezeigt.
Die letzten Zeichen des URL-Pfads nach dem Punkt (z.B. „css“) werden als URL-Erweiterung bezeichnet.
Die Erweiterung der URL gibt im Allgemeinen an, welcher Ressourcentyp angefordert wird, und verweist direkt auf die Informationen, die in der Spalte „Typ“ angezeigt werden. Beispielsweise ist v2.html ein Dokument und main.css ein Stylesheet.
Die Spalte „Wasserfall“ hilft dabei,
Sehen Sie sich die Spalte „Wasserfall“ an. Beginnen Sie oben und arbeiten Sie sich nach unten vor. Die Länge jedes Balkens stellt die Gesamtzeit dar, die für das Laden der einzelnen Ressourcen aufgewendet wurde. Woran erkennen Sie den Unterschied zwischen einer Anfrage, die als Teil des kritischen Ladepfads gestellt wird, und einer Anfrage, die dynamisch ausgelöst wird, nachdem der anfängliche Ladevorgang der Seite abgeschlossen ist?
Die erste Anfrage in der Vermittlungsabfolge richtet sich immer an das HTML-Dokument, z. B. v2.html. Alle nachfolgenden Anfragen gehen (wie ein Wasserfall-Ansatz) aus dieser ersten Navigationsanfrage, basierend auf den Bildern, Skripts und Stilen, auf die das HTML-Dokument verweist.
Die Vermittlungsabfolge zeigt, dass, sobald v2.html den Ladevorgang abgeschlossen hat, die Anfragen für die Assets, auf die es verweist (auch als Unterressourcen bezeichnet), beginnen. Der Browser kann mehrere Unterressourcen gleichzeitig anfordern. Dies wird durch die sich überschneidenden Balken in der Spalte „Wasserfall“ für main.css und logo.svg dargestellt. Schließlich können Sie im Screenshot sehen, dass der Ladevorgang von main.js zuletzt beginnt und nachdem auch die anderen drei URLs abgeschlossen sind.