Im Bereich „Netzwerk“ in den Entwicklertools Ihres Browsers können Sie sehen, welche Ressourcen geladen werden und wann. Jede Zeile im Bereich „Netzwerk“ entspricht einer bestimmten URL, die von Ihrer Webanwendung geladen wurde.
Wissen, was Sie laden
Um die richtigen Caching-Strategien für Ihre Webanwendung zu entwickeln, müssen Sie wissen, was genau Sie laden. Beim Erstellen einer zuverlässigen Webanwendung kann das Netzwerk allen möglichen schädlichen Einflüssen ausgesetzt sein. Sie müssen die Sicherheitslücken des Netzwerks kennen, um sie in Ihrer App beheben zu können.
Sie denken vielleicht, dass Sie schon eine ziemlich gute Vorstellung davon haben, was Ihre Webanwendung lädt. Wenn Sie nur wenige statische HTML-, JavaScript-, CSS- und Bilddateien verwenden, ist das möglicherweise der Fall. Sobald Sie jedoch Ressourcen von Drittanbietern, die in Content Delivery Networks gehostet werden, mit dynamischen API-Anfragen und servergenerierten Antworten kombinieren, wird das Bild schnell unübersichtlicher.
Eine Caching-Strategie, die für einige kleine CSS-Dateien sinnvoll ist, ist beispielsweise für Hunderte großer Bilder wahrscheinlich nicht sinnvoll.
Laden Sie nur, wenn es nötig ist
Ein weiterer Teil des Gesamtbilds des Ladevorgangs ist wann alles geladen wird.
Einige Anfragen an das Netzwerk, z. B. die Navigationsanfrage für Ihre erste HTML-Seite, werden bedingungslos gesendet, sobald ein Nutzer eine bestimmte URL aufruft. Dieser HTML-Code kann hartcodierte Verweise auf kritische CSS- oder JavaScript-Dateien enthalten, die ebenfalls geladen werden müssen, damit die interaktive Seite angezeigt werden kann. Diese Anfragen befinden sich alle im kritischen Ladepfad. Sie müssen diese Daten aggressiv im Cache speichern, damit sie zuverlässig schnell sind.
Andere Ressourcen wie API-Anfragen oder lazy-loaded-Assets werden möglicherweise erst lange nach Abschluss des ersten Ladevorgangs geladen. Wenn diese Anfragen nur nach einer bestimmten Abfolge von Nutzerinteraktionen erfolgen, werden bei mehreren Besuchen derselben Seite möglicherweise völlig unterschiedliche Ressourcen angefordert. Eine weniger aggressive Caching-Strategie ist oft für Inhalte geeignet, die sich außerhalb des kritischen Ladepfads befinden.
Die Spalten „Name“ und „Typ“ geben Aufschluss darüber,
Die Spalten „Name“ und „Typ“ geben Aufschluss darüber, was geladen wird. Die Antwort auf die Frage „Was wird geladen?“ im Beispiel oben sind insgesamt vier URLs, die jeweils einen bestimmten Inhaltstyp repräsentieren.
Der Name steht für die URL, die von Ihrem Browser angefordert wurde. Sie sehen jedoch nur den letzten Teil des Pfads der URL. 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 Erweiterung der URL bezeichnet.
Die Erweiterung der URL gibt in der Regel an, welche Art von Ressource angefordert wird, und wird direkt den Informationen in der Spalte „Typ“ zugeordnet. Beispiel: v2.html ist ein Dokument und main.css ein Stylesheet.
Die Spalte „Abfolge“ gibt Aufschluss darüber,
Sehen Sie sich die abfolgebasierte Spalte von oben nach unten an. Die Länge der einzelnen Balken entspricht der Gesamtzeit, die für das Laden der jeweiligen Ressource benötigt wurde. Woran erkennen Sie den Unterschied zwischen einer Anfrage, die im Rahmen des kritischen Ladepfads erfolgt, und einer Anfrage, die dynamisch ausgelöst wird, lange nachdem die Seite vollständig geladen wurde?
Die erste Anfrage in der Abfolge bezieht sich immer auf das HTML-Dokument, z. B. v2.html. Alle nachfolgenden Anfragen werden (wie bei einem Wasserfall) aus dieser ersten Navigationsanfrage abgeleitet, je nachdem, auf welche Bilder, Scripts und Stile das HTML-Dokument verweist.
Die Abfolge zeigt, dass sobald v2.html geladen ist, die Anfragen für die Assets gestartet werden, auf die es verweist (auch als untergeordnete Ressourcen bezeichnet). Der Browser kann mehrere untergeordnete Ressourcen gleichzeitig anfordern. Das wird durch die sich überschneidenden Balken in der abfolgebasierten Spalte für main.css und logo.svg dargestellt. Wie Sie auf dem Screenshot sehen, wird main.js als Letztes geladen und das Laden ist erst abgeschlossen, wenn auch die anderen drei URLs geladen wurden.