Was ist das Laden von Ressourcen?

Was ist das Laden von Ressourcen?

Das Laden von Ressourcen (Resource Loading) beschreibt, wie ein Browser die Dateien findet, anfordert, priorisiert und verarbeitet, die eine Seite braucht: HTML, CSS, JavaScript, Schriften, Bilder, Videos und API-Aufrufe. Reihenfolge und Timing dieser Anfragen entscheiden, wann Inhalte erscheinen und wann die Seite reagiert. Eine Seite ist oft nicht langsam, weil ihre Dateien riesig sind, sondern weil eine wichtige Datei zu spät zu laden beginnt.

Wie der Browser Ressourcen lädt

Der Browser lädt zuerst das HTML und findet beim Lesen weitere Dateien: einen Stylesheet-Link, ein Script-Tag, ein Bild. Manche Dateien entdeckt er noch später, etwa eine Schrift, die im Stylesheet steht, oder ein Bild, das per CSS als Hintergrund gesetzt ist. Jede Datei auf einem neuen Origin kostet außerdem DNS-Auflösung, Verbindungsaufbau und TLS, bevor das erste Byte fließt. Dabei vergibt der Browser für jede Anfrage eine Priorität. Bilder starten standardmäßig mit niedriger Priorität und werden erst angehoben, wenn das Layout sie im sichtbaren Bereich findet (web.dev, „Optimize resource loading with the Fetch Priority API“). Stylesheets und klassische Skripte im Head können das erste Zeichnen aufhalten, das ist der kritische Rendering-Pfad.

Vier Wege zur Verbesserung

• Wichtige Dateien früher entdecken. Nutzen Sie Resource Hints: preload für ein Hero-Bild oder eine zentrale Schrift, preconnect für einen Drittanbieter-Origin, den Sie sicher brauchen.
• Unkritische Dateien später laden. Setzen Sie defer oder async bei Skripten (siehe asynchrones Laden) und Lazy Loading für Bilder und iframes unterhalb des sichtbaren Bereichs.
• Priorität anheben oder senken. Das Attribut fetchpriority (high, low, auto) funktioniert bei img, script und link. Es ist ein Hinweis, kein Befehl, und der Browser findet die Datei dadurch nicht früher. Laut web.dev wird es von Chrome und Edge 102, Firefox 132 und Safari 17.2 unterstützt.
• Weniger laden, von näher. Ungenutzten Code entfernen, Dateien komprimieren und über ein CDN ausliefern, damit jeder Round Trip kürzer wird. Gute Cache-Header ersparen wiederkehrenden Besuchern den Download ganz.

Beispiel

Eine Produktseite hat ein großes Hero-Bild, darunter sechs Galeriebilder, ein Analytics-Skript und ein Chat-Widget. Ungeschickt geladen, startet der Browser alles gleichzeitig, und das Hero-Bild konkurriert mit dem Chat-Widget um Bandbreite. Besser: das Hero-Bild mit fetchpriority="high" markieren, die Galerie mit loading="lazy" versehen, dem Analytics-Skript defer geben und das Chat-Widget erst laden, wenn die Seite bedienbar ist.

<img src="/hero.webp" fetchpriority="high" alt="Produkt">
<img src="/gallery-1.webp" loading="lazy" alt="Detail">
<script src="/analytics.js" defer></script>

web.dev berichtet von einem Test bei Google Flights, bei dem fetchpriority="high" am LCP-Bild den LCP von 2,6 s auf 1,9 s verbesserte. Das ist eine Seite mit einem Setup, messen Sie also Ihre eigene Seite.

Häufige Fehler

• Das Hero-Bild per Lazy Loading laden. Der Browser soll damit auf etwas warten, das der Besucher sofort sieht, und der Largest Contentful Paint verzögert sich.
• Alles vorladen. Hints konkurrieren miteinander und helfen ab wenigen nicht mehr. Reservieren Sie sie für Dateien, die das erste Rendern bestimmen.
• Viele Drittanbieter-Origins. Jeder braucht eine eigene Verbindung und kann die Seite ausbremsen, wenn er langsam ist.
• Async bei Skripten, die voneinander abhängen. Mit async ist die Reihenfolge nicht garantiert; nehmen Sie defer.
• Wiederkehrende Besuche ignorieren. Ohne Cache-Header laden Rückkehrer alles erneut herunter.

Bezug zu Tests und Monitoring

Das wichtigste Werkzeug ist das Netzwerk-Wasserfalldiagramm: Es zeigt, was wann startete, was worauf wartete und welche Anfragen blockiert waren. Prüfen Sie es mit gedrosselter Verbindung und von mehr als einem Standort, denn die Entfernung verändert die Verbindungskosten. LoadFocus Page Speed Monitoring führt Google-Lighthouse-Audits nach Zeitplan aus 25 Cloud-Regionen aus, sodass Sie sehen, ob eine Änderung beim Laden überall half oder nur in der Nähe Ihres Servers. Der kostenlose Core Web Vitals Checker zeigt LCP, INP und CLS echter Nutzer aus den CrUX-Daten von Google. Eine breitere Liste von Maßnahmen steht in der 10-Schritte-Anleitung für schnellere Websites.

Häufige Fragen: Laden von Ressourcen

Was ist der Unterschied zwischen Resource Loading und Lazy Loading?

Resource Loading ist der gesamte Vorgang, die Dateien einer Seite zu laden. Lazy Loading ist eine Technik darin: Sie verzögert Dateien, meist Bilder und iframes, bis sie gleich sichtbar werden.

In welcher Reihenfolge lädt ein Browser Ressourcen?

Er beginnt mit dem HTML und fordert dann die Dateien an, die er beim Parsen findet, jeweils mit einer Priorität. Dateien, die im CSS stehen, etwa Schriften und Hintergrundbilder, entdeckt er später. Deshalb gibt es Hints wie preload.

Was macht fetchpriority?

Es bittet den Browser, eine Ressource mit höherer oder niedrigerer Priorität als üblich zu laden. Der Browser darf den Hinweis übergehen, und die Datei wird dadurch nicht früher entdeckt.

Blockiert das Laden von JavaScript das Rendering?

Ein klassisches Skript ohne async, defer oder type module blockiert das Parsen des HTML, solange es geladen und ausgeführt wird. Mit defer oder async entfällt das.

Wie sehe ich, wie meine Ressourcen laden?

Öffnen Sie das Netzwerk-Panel der Browser-DevTools oder führen Sie ein Lighthouse-Audit aus und lesen Sie Wasserfall und Liste der renderblockierenden Anfragen.