Resource Hints sind Browser-Direktiven, die du im <head> deiner Website als <link>-Tags angibst. Sie signalisieren dem Browser, welche Ressourcen — Schriftarten, Skripte, Bilder, Verbindungen zu Drittanbietern — frühzeitig angefordert werden sollen, noch bevor der Render-Tree sie eigentlich braucht.
Für SEO sind Resource Hints relevant, weil sie direkt die Core Web Vitals beeinflussen: ein schnellerer LCP verbessert die Nutzererfahrung und ist ein Google-Ranking-Faktor. Dieser Artikel erklärt alle vier Typen mit konkreten Anwendungsfällen und häufigen Fehlern.
Die vier Resource-Hint-Typen im Überblick
Es gibt vier Resource-Hint-Direktiven, jede mit einem unterschiedlichen Anwendungsbereich:
| Direktive | Was sie macht | Priorität | Für |
|---|---|---|---|
preload |
Lädt Ressource sofort, mit hoher Priorität | Hoch | Aktuelle Seite |
preconnect |
Baut Verbindung zu Domain auf (DNS + TCP + TLS) | Mittel | Aktuelle Seite |
dns-prefetch |
Löst DNS-Namen auf (nur DNS, kein TCP) | Niedrig | Aktuelle & zukünftige Seite |
prefetch |
Lädt Ressource im Hintergrund für spätere Nutzung | Sehr niedrig | Nächste Seite |
1. preload: Kritische Ressourcen der aktuellen Seite
Was preload macht
preload weist den Browser an, eine Ressource sofort mit hoher Priorität zu laden — noch bevor der Parser auf den ursprünglichen Tag trifft. Es eignet sich für Ressourcen, die für den ersten Seitenaufbau kritisch sind.
Typische preload-Anwendungsfälle
LCP-Bild vorladen — der häufigste und wirkungsvollste Anwendungsfall. Wenn das LCP-Element ein Bild ist, das erst spät im HTML erscheint oder als CSS-Hintergrundbild definiert ist:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">Schriftarten vorladen — Browser laden Web Fonts erst, wenn das CSS geparst wurde. Mit preload startet der Download früher und verhindert FOIT (Flash of Invisible Text):
<link rel="preload" as="font" href="/fonts/inter-var.woff2" type="font/woff2" crossorigin>Das crossorigin-Attribut ist bei Fonts Pflicht — auch bei Same-Origin-Fonts. Ohne es wird die Font zweimal geladen.
Kritisches CSS vorladen — wenn du Critical CSS ausgelagert hast:
<link rel="preload" as="style" href="/css/critical.css" onload="this.rel='stylesheet'">JavaScript-Module vorladen — bei modernen ES-Modulen, die für die initiale Interaktivität benötigt werden:
<link rel="modulepreload" href="/js/main.js">Das as-Attribut: Pflichtfeld bei preload
Das as-Attribut teilt dem Browser mit, um welchen Ressourcentyp es sich handelt, damit er die korrekte Priorität und Content-Security-Policy anwenden kann. Ohne as wird die Ressource zwar heruntergeladen, aber mit falscher Priorität — und oft doppelt, weil der Browser sie nicht im Cache findet.
| Ressourcentyp | as-Wert |
|---|---|
| Bild | image |
| Schriftart | font |
| CSS-Datei | style |
| JavaScript | script |
| Video | video |
| Fetch/XHR | fetch |
Häufige preload-Fehler
Zu viele Preloads: Jedes preload konkurriert um Bandbreite mit dem HTML-Parsing. Drei bis vier Preloads sind normal, mehr als sechs verlangsamen den initialen Ladevorgang. Prüfe mit den Core Web Vitals, ob deine Preloads wirken.
Preload ohne Verwendung: Wenn eine pregeloadete Ressource nicht innerhalb von 3 Sekunden genutzt wird, warnt Chrome in den DevTools: "The resource was preloaded using link preload but not used within a few seconds." Das ist verschwendete Bandbreite.
Responsive Bilder: Für <picture> oder srcset-Bilder funktioniert einfaches preload nicht korrekt — du musst imagesrcset und imagesizes setzen:
<link rel="preload" as="image"
imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
imagesizes="100vw"
fetchpriority="high">2. preconnect: Verbindungen frühzeitig aufbauen
Was preconnect macht
preconnect baut die komplette Verbindung zu einer Domain auf — DNS-Auflösung, TCP-Handshake und TLS-Aushandlung — ohne eine konkrete Ressource zu laden. Das spart 100–300 ms bei der ersten Anfrage an diese Domain.
Wann preconnect einsetzen
preconnect ist ideal für Drittanbieter-Domains, von denen du auf der aktuellen Seite Ressourcen lädst und deren genaue URL du noch nicht kennst (oder die dynamisch bestimmt wird):
<!-- Google Fonts -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- CDN für externe Bibliotheken -->
<link rel="preconnect" href="https://cdn.jsdelivr.net">
<!-- Analytics -->
<link rel="preconnect" href="https://www.googletagmanager.com">Das crossorigin-Attribut bei fonts.gstatic.com ist notwendig, weil Schriftarten mit CORS-Anfragen geladen werden. Fehlt es, baut der Browser eine zweite Verbindung auf.
Nicht zu viele preconnects
Jede preconnect-Verbindung belegt Ressourcen auf dem Server und im Browser. Mehr als vier bis fünf preconnects sind selten sinnvoll und können die Netzwerkaktivität am Seitenstart übersättigen. Faustregel: Nur Domains, von denen du tatsächlich Ressourcen on the critical path lädst.
3. dns-prefetch: Der sparsamere Bruder von preconnect
Was dns-prefetch macht
dns-prefetch löst nur den DNS-Namen auf — kein TCP, kein TLS. Das spart weniger Zeit als preconnect (typisch 20–120 ms statt 100–300 ms), verbraucht aber auch deutlich weniger Ressourcen.
Wann dns-prefetch statt preconnect
Nutze dns-prefetch für:
- Domains auf zukünftigen Seiten (Links in der Navigation, auf die der Nutzer wahrscheinlich klickt)
- Domains, von denen du nur wenige, nicht kritische Ressourcen lädst
- Browser, die preconnect nicht unterstützen (als Fallback)
- Mehr als fünf Drittanbieter-Domains: lieber dns-prefetch als zu viele preconnects
<!-- Für Drittanbieter-Domains mit niedrigerem Impact -->
<link rel="dns-prefetch" href="https://www.facebook.com">
<link rel="dns-prefetch" href="https://connect.facebook.net">
<link rel="dns-prefetch" href="https://platform.twitter.com">Kombinationsregel: Wenn du preconnect und dns-prefetch für dieselbe Domain angibst, ignoriert der Browser das dns-prefetch (preconnect ist ein Superset). Schreibe nie beides für dieselbe Domain.
4. prefetch: Ressourcen für die nächste Seite
Was prefetch macht
prefetch lädt eine Ressource im Hintergrund mit niedriger Priorität — für Seiten, die der Nutzer als nächstes wahrscheinlich besucht. Der Browser startet den Download erst nach dem Load-Event und nutzt freie Bandbreite.
Wann prefetch sinnvoll ist
prefetch ist der einzige Resource Hint, der für die nächste Seite gedacht ist (alle anderen wirken auf die aktuelle):
<!-- Nächste Seite vorhergesagt (z.B. Schritt 2 eines Checkouts) -->
<link rel="prefetch" href="/checkout/step-2.html">
<!-- Große JS-Datei für spätere Interaktion vorbereiten -->
<link rel="prefetch" href="/js/video-player.bundle.js" as="script">Besonders wertvoll ist prefetch bei linearen Nutzerflüssen: Startseite → Produktseite → Warenkorb → Checkout. Wenn du vorhersagen kannst, wohin der Nutzer als nächstes navigiert, kann prefetch die Ladezeit der Folgeseite deutlich reduzieren.
prefetch vs. preload: Die wichtigste Unterscheidung
| Eigenschaft | preload | prefetch |
|---|---|---|
| Für welche Seite | Aktuelle Seite | Nächste Seite |
| Priorität | Hoch (sofort) | Sehr niedrig (Hintergrund) |
| Browser-Verhalten | Erzwingt Download | Nutzt freie Kapazität |
| Auswirkung auf LCP | Direkt positiv (wenn richtig) | Keiner auf aktuelle Seite |
| Risiko | Bandbreitenkonkurrenz | Verschwendete Anfragen wenn Navigation ausbleibt |
Resource Hints und SEO: Was Google tatsächlich bewertet
Google bewertet Resource Hints indirekt über ihre Auswirkung auf die Core Web Vitals. Die wichtigsten Zusammenhänge:
preload → LCP-Verbesserung: Wenn das LCP-Element ein Bild oder eine Schriftart ist, die erst spät entdeckt wird, kann ein korrekt gesetzter preload den LCP um 200–600 ms verbessern. Das hat messbare Auswirkungen auf das Google-Ranking. Unsere Critical-CSS-Analyse zeigt, wie eng LCP und frühzeitiges Ressourcen-Loading zusammenhängen.
preconnect → TTFB und FCP: Wenn eine kritische Ressource von einer Drittanbieter-Domain kommt (z.B. eine Web Font), reduziert preconnect die Verbindungslatenz. Das verbessert den TTFB dieser Ressource und damit den FCP.
prefetch → Navigation UX: Obwohl prefetch die Core Web Vitals der aktuellen Seite nicht beeinflusst, verbessert es die gefühlte Navigation — und damit das Bounce-Rate-Signal, das Google indirekt bewertet.
Audit: Resource Hints deiner Website prüfen
So prüfst du, ob Resource Hints auf deiner Website korrekt gesetzt sind:
1. Chrome DevTools
Öffne DevTools → Network → filtere nach "preload". Du siehst alle vorgeladenen Ressourcen, ihre tatsächliche Priorität und ob sie im Cache genutzt wurden. Grüne Ressourcen wurden verwendet, gelbe wurden pregeloadet aber nicht genutzt (verschwendete Anfragen).
2. Lighthouse / PageSpeed Insights
Lighthouse prüft unter "Opportunities" auf fehlende preconnects für bekannte Drittanbieter. Die Core Web Vitals zeigen dir, ob dein LCP vom Bild-Vorladen profitiert hat.
3. HTML-Quelltext manuell prüfen
Schau im <head> deiner Seite nach existierenden Link-Tags:
<!-- Suche nach diesen Mustern -->
<link rel="preload" ...>
<link rel="preconnect" ...>
<link rel="dns-prefetch" ...>
<link rel="prefetch" ...>Checkliste: Resource Hints richtig einsetzen
- ✅ LCP-Bild preloaden — wenn das Bild im HTML nicht im oberen Bereich steht oder als CSS-Background definiert ist
- ✅ Web Fonts preloaden — immer mit
crossorigin, immer mitas="font" - ✅ Google Fonts preconnect —
fonts.googleapis.com+fonts.gstatic.com(mit crossorigin) - ✅ Analytics preconnect — Google Tag Manager, wenn du es auf jeder Seite nutzt
- ✅ CDN dns-prefetch — für nicht-kritische Drittanbieter-Domains
- ✅ Checkout-Seite prefetch — bei Shop-Seiten mit vorhersagbarem Nutzerfluss
- ❌ Nie: Mehr als 4 preloads auf einer Seite
- ❌ Nie: preload ohne
as-Attribut - ❌ Nie: Font-preload ohne
crossorigin - ❌ Nie: preconnect + dns-prefetch für dieselbe Domain
- ❌ Nie: Mehr als 5 preconnects gleichzeitig
Resource Hints und Lazy Loading: Das richtige Gleichgewicht
Resource Hints und Lazy Loading arbeiten zusammen — aber in entgegengesetzte Richtungen. preload lädt Ressourcen früher, Lazy Loading verschiebt das Laden auf später. Die Kunst liegt darin, beides an der richtigen Stelle einzusetzen:
- Das Hero-Bild:
preload+loading="eager"+fetchpriority="high" - Alle anderen Bilder:
loading="lazy"(kein preload) - Schriftarten:
preload+font-display: swap - Video-Player:
prefetchfür das Bundle, Facade-Pattern für das Video selbst
Mit dem Lazy-Load-Checker kannst du prüfen, ob dein Hero-Bild korrekt konfiguriert ist und welche Bilder noch Lazy Loading benötigen.
WordPress, Shopify und andere CMS
Die meisten CMS erlauben das Hinzufügen von Resource Hints:
WordPress: Das Plugin "Perfmatters" oder manuell via wp_head-Hook:
add_action('wp_head', function() {
echo '<link rel="preconnect" href="https://fonts.googleapis.com">';
echo '<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>';
});Shopify: Im Theme-Editor unter "theme.liquid" im <head>-Bereich direkt einfügen.
Statische Sites (Next.js, Gatsby, Hugo): In der jeweiligen Head-Komponente als statische Link-Tags. Bei Next.js bietet sich next/head an, Gatsby nutzt gatsby-plugin-prefetch-google-fonts.
Fazit: Drei Minuten Setup, messbare Verbesserung
Resource Hints gehören zu den wenigen Optimierungen, die mit minimalem Aufwand direkte Wirkung auf die Core Web Vitals haben. Die wichtigsten Schritte:
- Identifiziere deinen LCP-Kandidaten (Hero-Bild oder Hauptschriftart)
- Füge einen
preload-Tag im<head>hinzu — mitas, bei Fonts mitcrossorigin - Setze
preconnectfür Google Fonts und andere kritische Drittanbieter - Messe den LCP vorher und nachher mit PageSpeed Insights
Kombiniert mit Render-Blocking-Optimierung, Lazy Loading und Critical CSS bilden Resource Hints das Fundament einer performanten, SEO-optimierten Website.