Zwischen dem Moment, in dem der Browser die HTML-Seite erhält, und dem Moment, in dem das wichtigste Bild erscheint, vergeht oft mehr Zeit als nötig. Der Browser entdeckt viele Ressourcen erst, wenn er das HTML weit genug gelesen hat -- und beginnt dann erst mit dem Verbindungsaufbau zu fremden Servern, der DNS-Auflösung, dem TCP-Handschlag und der TLS-Verhandlung kostet. Resource Hints sind kleine, deklarative Hinweise an den Browser, diese Arbeit vorzuziehen. Sie sind weit verbreitet: 33 Prozent (Web Almanac, 2024) der Seiten nutzen dns-prefetch, 28 Prozent (Web Almanac, 2024) preconnect und 19 Prozent (Web Almanac, 2024) preload. Eine frühzeitige Verbindung spart laut web.dev rund 100 bis 500 Millisekunden (web.dev) Verbindungsaufbau. Dieser Beitrag erklärt preload, prefetch, preconnect, dns-prefetch, modulepreload und die neueren Priority Hints -- und zeigt, wo Überladung mehr schadet als nützt. Eine durchdachte Frontend-Optimierung setzt sie gezielt ein, nicht pauschal.
Das Wichtigste in Kürze
- Resource Hints ziehen Arbeit vor, die der Browser sonst spät entdeckt -- vom Verbindungsaufbau bis zum Download der kritischen Ressource.
- preconnect bereitet die volle Verbindung zu wenigen fremden Servern vor, preload lädt das LCP-Bild und kritische Schriften frühzeitig herunter.
- fetchpriority hebt das LCP-Bild an, das sonst standardmäßig niedrig priorisiert bleibt -- erst die Kombination mit preload entfaltet die volle Wirkung.
- Der häufigste Fehler ist das Überladen: Wer alles vorzieht, bevorzugt am Ende nichts und bremst gerade auf langsamen Netzen das wirklich Wichtige aus.
- Hints wirken nur belegbar, wenn man vorher misst, welche Ressource den ersten Eindruck bestimmt, und die Wirkung danach in den Felddaten prüft.
Was Resource Hints sind und warum sie wirken
Der Browser ist beim Laden einer Seite kein passiver Empfänger, sondern ein Planer, der ständig entscheidet, welche Ressource er als nächstes anfordert und wie wichtig sie ist. Diese Planung beginnt jedoch erst, sobald er die jeweilige Ressource im HTML entdeckt hat. Liegt ein wichtiges Bild tief im Markup oder wird eine Schrift erst per CSS referenziert, startet der Browser den Ladevorgang spät -- und der erste sichtbare Eindruck verzögert sich. Resource Hints durchbrechen diese Reihenfolge: Sie teilen dem Browser bereits im Kopf des Dokuments mit, welche Arbeit er vorziehen darf.
Der entscheidende Hebel liegt im Verbindungsaufbau. Bevor eine einzige Ressource von einem fremden Server geladen werden kann, muss der Browser dessen Adresse auflösen (DNS), eine Verbindung herstellen (TCP) und sie verschlüsseln (TLS). Jeder dieser Schritte ist ein Round-Trip, der je nach Netz Zeit kostet -- mobil mehr als im Festnetz, wie unser Beitrag zur mobilen Performance-Optimierung zeigt. Resource Hints erlauben es, diese Round-Trips parallel zur ersten HTML-Verarbeitung zu erledigen, sodass die spätere Anforderung der eigentlichen Ressource auf eine bereits vorbereitete Verbindung trifft.
Die fünf Hints im Überblick
preconnect und dns-prefetch: den Verbindungsaufbau vorziehen
preconnect ist der wirksamste Hint für fremde Server. Er weist den Browser an, die volle Verbindung -- DNS-Auflösung, TCP-Handschlag und TLS-Verhandlung -- bereits im Voraus aufzubauen, lange bevor die eigentliche Ressource angefordert wird. Trifft die Anforderung dann ein, ist die Verbindung bereits warm, und der Download startet ohne Verzögerung. Laut web.dev lassen sich so rund 100 bis 500 Millisekunden (web.dev) einsparen -- genug, um den Largest Contentful Paint spürbar nach vorne zu ziehen, wenn das LCP-Element von einem fremden Server stammt.
<!-- Volle Verbindung zum Schrift-Server vorab aufbauen -->
<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<!-- Fallback fuer aeltere Browser: nur DNS aufloesen -->
<link rel="dns-prefetch" href="https://fonts.example.com">dns-prefetch ist die leichtgewichtige Variante: Sie löst nur die DNS-Adresse vorab auf, ohne TCP und TLS. Das spart weniger Zeit, kostet aber auch fast nichts und wird von praktisch allen Browsern unterstützt. In der Praxis kombiniert man beide gerne -- preconnect für die ein, zwei wichtigsten fremden Server, dns-prefetch als günstigen Fallback. Die Verbreitung spiegelt das wider: dns-prefetch liegt mit 33 Prozent (Web Almanac, 2024) vorn, preconnect folgt mit 28 Prozent (Web Almanac, 2024). Wichtig beim Schrift-Server: das crossorigin-Attribut, da Schriften per CORS geladen werden -- fehlt es, baut der Browser eine zweite, ungenutzte Verbindung auf.
preconnect sparsam einsetzen
preload: das kritische LCP-Bild und Schriften beschleunigen
Während preconnect nur die Verbindung vorbereitet, lädt preload eine konkrete Ressource tatsächlich früh herunter. Der typische Anwendungsfall ist das LCP-Bild, das spät im Markup steht oder per CSS-Hintergrund geladen wird und das der Browser daher erst verzögert entdeckt. Mit einem preload-Hinweis im Kopf des Dokuments beginnt der Download sofort. Genauso wirksam ist preload für eine kritische Schrift, die sonst erst geladen wird, nachdem das CSS verarbeitet ist -- was zu einem späten Schriftwechsel und damit zu Layout-Verschiebungen führen kann.
<!-- Kritische Schrift vorab laden (CORS, daher crossorigin) -->
<link rel="preload" href="/fonts/inter.woff2" as="font"
type="font/woff2" crossorigin>
<!-- LCP-Hintergrundbild vorab laden und hoch priorisieren -->
<link rel="preload" href="/img/hero.avif" as="image"
fetchpriority="high">Zwei Attribute sind hier entscheidend. Das as-Attribut teilt dem Browser den Ressourcentyp mit, damit er die richtige Priorität und die korrekten CORS-Regeln anwendet -- ohne as wird die Ressource häufig doppelt geladen. Und crossorigin ist bei Schriften Pflicht, da sie im anonymen CORS-Modus angefordert werden: Stimmt der Modus zwischen preload und der späteren Anforderung nicht überein, kann der Browser die vorgeladene Datei nicht wiederverwenden. Wer Schriften ohnehin optimiert, findet vertiefende Hinweise in unserem Beitrag zur Web-Font-Performance.
LCP-Bild vorladen
Steht das größte Bild tief im Markup oder als CSS-Hintergrund, entdeckt es der Browser spät. Ein preload mit as='image' und fetchpriority='high' zieht den Download nach vorne und verkürzt den Largest Contentful Paint.
Schrift vorladen
Eine kritische woff2-Schrift wird sonst erst nach dem CSS geladen. Mit preload, as='font', type und crossorigin startet sie früh -- das verhindert späten Schriftwechsel und damit Layout-Verschiebungen.
Module vorladen
modulepreload lädt ein JavaScript-Modul samt seiner Importkette vorab. So muss der Browser die Abhängigkeiten nicht erst Schritt für Schritt entdecken -- nützlich bei modular gebündeltem Frontend-Code.
Priority Hints: fetchpriority gezielt einsetzen
Der Browser vergibt jeder Ressource automatisch eine Priorität -- Bilder etwa starten standardmäßig mit niedriger Priorität, weil viele Bilder erst weiter unten auf der Seite gebraucht werden. Genau das ist beim LCP-Bild ein Problem: Es ist das wichtigste Bild, wird aber wie ein nebensächliches behandelt. Das fetchpriority-Attribut korrigiert das, indem es dem Browser die relative Wichtigkeit einer Ressource mitteilt -- high zieht sie vor, low schiebt sie nach hinten. Wichtig: Es ist ein Hinweis, kein Befehl; der Browser darf ihn mit seinen eigenen Heuristiken abwägen (web.dev).
Die Wirkung ist gut belegt. Die Nutzung von fetchpriority für das LCP-Bild stieg von 0,03 Prozent (Web Almanac, 2024) der Mobilseiten im Jahr 2022 auf 15 Prozent (Web Almanac, 2024) im Jahr 2024 -- ein steiler Anstieg, der zeigt, wie verbreitet diese Optimierung inzwischen ist. Besonders wirksam ist die Kombination mit preload: Ein vorgeladenes Bild behält sonst seine niedrige Standardpriorität, erst fetchpriority='high' hebt sie an. Umgekehrt lässt sich mit fetchpriority='low' ein unkritisches Skript bewusst zurücknehmen, damit es dem LCP-Pfad keine Bandbreite stiehlt.
fetchpriority und preload gehören zusammen
prefetch und modulepreload: vorausschauend laden
prefetch verfolgt ein anderes Ziel als die übrigen Hints: Es bereitet nicht die aktuelle Seite vor, sondern die wahrscheinliche nächste Navigation. Der Browser lädt eine Ressource mit der niedrigsten Priorität im Hintergrund, während die aktuelle Seite bereits steht -- etwa das wichtigste Skript der Folgeseite eines Funnels oder das nächste Produktbild in einer Galerie. Wird die erwartete Navigation tatsächlich ausgelöst, ist die Ressource schon im Cache. Mit nur 6 Prozent (Web Almanac, 2024) ist prefetch deutlich weniger verbreitet als preconnect oder preload, weil es eine verlässliche Vorhersage des nächsten Schritts voraussetzt.
modulepreload ist die auf JavaScript-Module zugeschnittene Variante von preload. Bei modernem, in Module aufgeteiltem Code muss der Browser die Importkette sonst Schritt für Schritt entdecken: Er lädt ein Modul, liest dessen Importe, lädt das nächste -- ein Wasserfall, der Zeit kostet. modulepreload lädt das Modul samt seiner Abhängigkeiten vorab und parst es bereits. Mit rund 1 Prozent (Web Almanac, 2024) ist die Verbreitung noch gering, doch für modular gebündelte Anwendungen ist der Hint ein wirksames Mittel, den Modul-Wasserfall zu verkürzen. Wie sich JavaScript darüber hinaus aufteilen lässt, zeigt unser Beitrag zu Lazy Loading und Code-Splitting.
| Hint | Was er vorzieht | Typischer Einsatz | Kosten bei Fehleinsatz |
|---|---|---|---|
| dns-prefetch | nur DNS-Auflösung | fremde Server als günstiger Fallback | sehr gering |
| preconnect | DNS + TCP + TLS | 1-2 kritische fremde Server | belegt Verbindungen unnötig |
| preload | konkrete Ressource laden | LCP-Bild, kritische Schrift | verdrängt wichtigere Ressourcen |
| prefetch | Ressource für nächste Seite | wahrscheinliche Folge-Navigation | vergeudete Bandbreite |
| modulepreload | JS-Modul + Abhängigkeiten | modular gebündelter Code | geladen, aber nicht genutzt |
Die häufigsten Fehler: zu viel des Guten
Resource Hints sind mächtig, und genau darin liegt ihre Gefahr. Der häufigste Fehler ist das Überladen: Wird alles vorgeladen, wird nichts mehr bevorzugt. web.dev formuliert es deutlich -- werden zu viele Ressourcen priorisiert, ist faktisch keine mehr priorisiert. Auf langsamen Netzen wirkt sich das besonders aus, weil die ohnehin knappe Bandbreite zwischen vielen gleichrangigen Downloads aufgeteilt wird und das wirklich kritische Element ausgebremst wird. Mehr preload-Tags bedeuten also nicht automatisch eine schnellere Seite -- oft ist das Gegenteil der Fall.
Der zweite klassische Fehler ist der ungenutzte preload. Lädt der Browser eine Ressource vor, die dann gar nicht oder nicht im erwarteten Modus verwendet wird, gibt er nach dem Laden eine Warnung in der Konsole aus -- typischerweise rund 3 Sekunden (DebugBear) nach dem Load-Ereignis. Ein häufiger Auslöser ist eine vorgeladene Schrift ohne crossorigin: Der Browser lädt sie einmal vor und ein zweites Mal für die tatsächliche Nutzung, weil die Anforderungsmodi nicht übereinstimmen. Statt Zeit zu sparen, wird Bandbreite verschwendet.
- preconnect auf ein bis zwei wirklich kritische fremde Server beschränken
- Bei Schriften und anderen CORS-Ressourcen stets crossorigin setzen
- Das as-Attribut bei preload korrekt angeben, sonst droht doppeltes Laden
- Nur das LCP-Element vorladen, nicht jedes Bild der Seite
- fetchpriority='high' mit preload kombinieren, da Bilder sonst niedrig priorisiert bleiben
- Die Konsole nach Warnungen zu ungenutzten preloads durchsuchen
- Jede Änderung mit Felddaten und Labortest gegenprüfen statt blind Hints zu setzen
Der dritte Fehler ist, Hints zu setzen, ohne die Wirkung zu messen. Welche Ressource den ersten Eindruck bestimmt, lässt sich nicht erraten, sondern nur an konkreten Daten ablesen -- am LCP-Element, am kritischen Pfad, an der tatsächlichen Prioritätenverteilung im Wasserfall. Wir gehen in der Praxis genau umgekehrt vor: erst messen, welche Ressource den Largest Contentful Paint bestimmt, dann gezielt einen Hint setzen und anschließend in den Core Web Vitals prüfen, ob er wirklich wirkt. So bleibt der Ladepfad schlank, statt mit gut gemeinten, aber kontraproduktiven Hinweisen überfrachtet zu werden.
Resource Hints sind kein Streuwerkzeug. Wer jede denkbare Domain preconnectet und jedes Bild vorladet, verschiebt das Problem nur -- er bevorzugt alles und damit nichts. Der Nutzen entsteht erst, wenn man genau die ein, zwei Ressourcen vorzieht, die den ersten sichtbaren Eindruck bestimmen.
Resource Hints wirken zudem nicht isoliert, sondern im Zusammenspiel mit der Serverseite. Eine vorab aufgebaute Verbindung nützt wenig, wenn der Server die Antwort langsam erzeugt -- etwa weil eine Datenbankabfrage bremst, wie unser Beitrag zur Datenbank-Query-Optimierung für Shop-Performance zeigt. Umgekehrt verpufft eine schnelle Serverantwort, wenn der Browser das kritische Bild zu spät entdeckt. Erst die Abstimmung von Verbindungsaufbau, Serverantwort und Ladepriorisierung ergibt einen durchgehend schnellen Ladepfad.
Der Kern in einem Satz
Der Aufwand lohnt sich, weil er direkt am wahrgenommenen Tempo ansetzt. Eine eingesparte Verbindung von 100 bis 500 Millisekunden (web.dev) verschiebt den Largest Contentful Paint sichtbar nach vorne, und ein früh geladenes LCP-Bild ist exakt das, was Nutzer als schnellen Seitenaufbau erleben. Da diese Hinweise rein deklarativ im Markup stehen und keine zusätzliche Logik erfordern, gehören sie zu den effizientesten Maßnahmen einer gezielten Frontend-Optimierung -- vorausgesetzt, sie werden mit Augenmaß und auf Basis echter Messwerte gesetzt.