preload, prefetch und preconnect ohne Bandbreiten-Konkurrenz
Wer preload, prefetch und preconnect wahllos im Head verteilt, verschenkt genau die Bandbreite und Prioritätsklasse, die für die wirklich kritische Ressource gebraucht wird. Dieser Artikel erklärt, wie der Preload Scanner des Browsers arbeitet, wann welcher Resource Hint tatsächlich sinnvoll ist und wie sich Overuse mit Chrome DevTools zuverlässig erkennen, messen und vermeiden lässt.
Inhaltsverzeichnis
- 1. Was Resource Hints sind und wie der Preload Scanner funktioniert
- 2. link rel="preload" für kritische Ressourcen der aktuellen Seite
- 3. link rel="prefetch" für die nächste Navigation
- 4. link rel="preconnect" und dns-prefetch für Drittanbieter-Origins
- 5. Die Overuse-Falle: zu viele Hints konkurrieren um Bandbreite
- 6. fetchpriority als Ergänzung zu Resource Hints
- 7. Praxisbeispiel: Hero-Bild und Font in Hyvä preloaden
- 8. Preconnect im Checkout und Prefetch bei Hover auf der Kategorieseite
- 9. Resource Hints validieren: DevTools, Priority Column, Warnungen
- 10. Zusammenfassung
- 11. FAQ
1. Was Resource Hints sind und wie der Preload Scanner funktioniert
Resource Hints sind deklarative <link rel="...">-Anweisungen im <head>, die dem Browser mitteilen, welche Ressourcen demnächst gebraucht werden, bevor der normale Rendering-Pfad sie überhaupt entdeckt. Anders als ein gewöhnliches <script>- oder <img>-Tag lösen sie keine Verarbeitung aus, sondern reservieren nur Netzwerkpriorität und Verbindungskapazität im Voraus. Vier Hint-Typen decken die Praxis ab: preload für die aktuelle Seite, prefetch für die wahrscheinlich nächste Navigation, preconnect für die frühe Verbindungsaufnahme und dns-prefetch als minimaler, günstigerer Vorläufer davon.
Chrome, Firefox und Safari nutzen einen sogenannten Preload Scanner, der parallel zum eigentlichen HTML-Parser die rohe Markup-Antwort nach referenzierten Ressourcen durchsucht, noch bevor CSS ausgewertet oder JavaScript ausgeführt wird. Er erkennt src-, srcset- und href-Attribute und startet Downloads spekulativ, während der Haupt-Parser noch mit dem Document Object Model beschäftigt ist. Resource Hints wirken deshalb nur zuverlässig, wenn sie im initialen HTML-Dokument stehen. Per JavaScript nach dem ersten Rendering nachgeschobene Hints werden vom Scanner nicht mehr erfasst und kommen faktisch zu spät, um die kritische Ladephase zu beschleunigen.
2. link rel="preload" für kritische Ressourcen der aktuellen Seite
<link rel="preload"> ist für Ressourcen gedacht, die der Browser ohnehin auf dieser Seite laden wird, aber erst spät entdeckt, weil sie in CSS, JavaScript oder erst weit unten im DOM referenziert sind. Typische Kandidaten sind das kritische Web-Font, das LCP-Hero-Bild und ein render-blockierendes CSS- oder JS-Chunk. Das as-Attribut ist dabei Pflicht, nicht optional: Der Browser nutzt es, um die korrekte Prioritätsklasse zu setzen, die passende Content-Security-Policy-Direktive zu prüfen und den Ressourcen-Cache-Key zu bestimmen. Fehlt as oder stimmt es nicht mit dem tatsächlichen Verbrauch überein, lädt der Browser die Datei häufig ein zweites Mal, weil er den Cache-Eintrag nicht wiederverwenden kann.
Ein besonders häufiger Stolperstein betrifft Fonts: preload für Web-Fonts benötigt immer das crossorigin-Attribut, selbst bei Ressourcen aus dem gleichen Origin, weil die Font-Loading-Spezifikation Font-Dateien grundsätzlich per anonymem CORS-Fetch lädt. Fehlt crossorigin, landet die vorgeladene Datei in einem anderen Cache-Eintrag als der später vom CSS ausgelöste Fetch, und die Font wird faktisch zweimal heruntergeladen, ohne dass eine Fehlermeldung darauf hinweist. Ein zusätzliches type-Attribut wie font/woff2 erlaubt dem Browser, das Format ohne Netzwerk-Roundtrip zu prüfen und die Anfrage bei fehlender Unterstützung gar nicht erst zu stellen.
<!-- Critical font: preload with correct "as", "type" and "crossorigin" -->
<link rel="preload" as="font" type="font/woff2"
href="/static/frontend/Mironsoft/default/de_DE/fonts/inter-var.woff2"
crossorigin>
<!-- LCP hero image: preload matches the actual <img> src/srcset exactly -->
<link rel="preload" as="image"
href="/media/wysiwyg/hero/summer-sale.webp"
imagesrcset="/media/wysiwyg/hero/summer-sale-480.webp 480w,
/media/wysiwyg/hero/summer-sale-1200.webp 1200w"
imagesizes="100vw"
fetchpriority="high">
<!-- Critical inline CSS chunk extracted for above-the-fold rendering -->
<link rel="preload" as="style" href="/static/frontend/Mironsoft/default/css/critical.css">
<link rel="stylesheet" href="/static/frontend/Mironsoft/default/css/critical.css">
<!-- WRONG: missing "as" forces a guess and often triggers a duplicate download -->
<!-- <link rel="preload" href="/fonts/inter-var.woff2"> -->
3. link rel="prefetch" für die nächste Navigation
<link rel="prefetch"> unterscheidet sich von preload in einem entscheidenden Punkt: Es lädt nicht für die aktuelle Seite, sondern spekulativ für eine wahrscheinliche zukünftige Navigation, mit der niedrigsten verfügbaren Netzwerkpriorität. Der Browser holt die Ressource erst, wenn die eigentlich kritischen Ressourcen der aktuellen Seite bereits bedient sind, und legt sie anschließend in den HTTP-Cache. Typische Einsatzfälle in einem Magento-Shop: die Produktdetailseite (PDP) von der Kategorieseite aus prefetchen, weil ein Klick auf ein Produkt die naheliegendste nächste Aktion ist, oder die Checkout-Seite vom Warenkorb aus, sobald mindestens ein Artikel im Cart liegt.
Der Effekt ist spürbar, weil beim tatsächlichen Seitenwechsel keine erneute DNS-Auflösung, kein TCP-Handshake und im Idealfall kein erneuter Download mehr nötig sind. Der Nutzer erlebt eine praktisch sofortige Navigation. Wichtig ist, prefetch nur für Ziele einzusetzen, deren Eintrittswahrscheinlichkeit tatsächlich hoch ist. Ein Prefetch für jedes einzelne Produkt einer Kategorieseite mit fünfzig Artikeln verschwendet Bandbreite und Serverkapazität für neunundvierzig Seiten, die der Nutzer nie besucht.
<!-- Category page: prefetch the likely next PDP document during idle time -->
<link rel="prefetch" href="/catalog/product/view/id/1234" as="document">
<!-- Cart page: prefetch checkout shell so the next navigation is warm -->
<link rel="prefetch" href="/checkout" as="document">
<!-- Prefetch a script bundle that checkout will need, low priority -->
<link rel="prefetch" href="/static/frontend/Mironsoft/default/js/checkout-bundle.js" as="script">
4. link rel="preconnect" und dns-prefetch für Drittanbieter-Origins
<link rel="preconnect"> führt DNS-Auflösung, TCP-Handshake und bei HTTPS zusätzlich den TLS-Handshake vorab aus, sodass die eigentliche Anfrage später ohne diese Verzögerung startet. Das lohnt sich ausschließlich für Origins außerhalb der eigenen Domain, die mit hoher Wahrscheinlichkeit tatsächlich gebraucht werden: das CDN für Produktbilder und statische Assets, die Domain des Zahlungsanbieters auf der Checkout-Seite, ein externer Font-Host oder der Analytics-Endpunkt. Für den eigenen Origin bringt preconnect nichts, weil die Verbindung ohnehin sofort aufgebaut wird.
dns-prefetch ist die abgespeckte Variante: Sie löst nur den DNS-Namen auf, ohne TCP- oder TLS-Handshake, kostet dadurch weniger Ressourcen und eignet sich für Origins, deren Nutzung wahrscheinlich, aber nicht sicher ist. Beide Hints haben eine harte Grenze: Der Browser hält eine offene, ungenutzte Verbindung nur wenige Sekunden, meist um die zehn Sekunden, bevor er sie wieder schließt. Ein preconnect, das zu früh gesetzt wird und dessen Ressource erst Minuten später gebraucht wird, verpufft wirkungslos. Als Faustregel gilt, sich auf vier bis sechs wirklich kritische Drittanbieter-Origins pro Seite zu beschränken.
<!-- CDN serving product images and static assets -->
<link rel="preconnect" href="https://cdn.mironsoft.de" crossorigin>
<!-- Payment gateway iframe/API host, only present on checkout pages -->
<link rel="preconnect" href="https://secure.payment-provider.com" crossorigin>
<!-- Web font origin, cheap dns-prefetch as a fallback for older browsers -->
<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<link rel="dns-prefetch" href="https://fonts.example.com">
<!-- Analytics endpoint: dns-prefetch only, connection is not certain to be needed -->
<link rel="dns-prefetch" href="https://analytics.mironsoft.de">
5. Die Overuse-Falle: zu viele Hints konkurrieren um Bandbreite
Resource Hints sind kein kostenloser Bonus, sondern verbrauchen echte Ressourcen: Bandbreite, offene Socket-Verbindungen und Prozessorzeit für DNS- und TLS-Handshakes. Jedes zusätzliche preload konkurriert mit den anderen Anfragen um das begrenzte Congestion Window der TCP-Verbindung, besonders in der ohnehin langsamen Slow-Start-Phase kurz nach dem Verbindungsaufbau. Wer zehn Ressourcen preloadet, verteilt die verfügbare Bandbreite auf zehn Anfragen gleicher hoher Priorität, statt sie auf die eine wirklich kritische Ressource zu konzentrieren. Das Ergebnis ist paradox: Mehr Preloads verlangsamen häufig genau die Ressource, die am dringendsten gebraucht wird.
Chrome DevTools macht das sichtbar über eine Konsolen-Warnung: "The resource ... was preloaded using link preload but not used within a few seconds". Sie erscheint, wenn eine vorgeladene Ressource nicht innerhalb kurzer Zeit tatsächlich für das Rendering verwendet wird, meist wegen eines falschen as-Werts, eines fehlenden crossorigin oder schlicht, weil die Ressource gar nicht auf jeder Seite gebraucht wird. Die praktikable Regel: preload auf ein bis zwei wirklich LCP-relevante Ressourcen pro Seite begrenzen, preconnect auf vier bis sechs Origins, und jeden Hint regelmäßig gegen echte DevTools-Messungen validieren statt ihn einmal zu setzen und zu vergessen.
6. fetchpriority als Ergänzung zu Resource Hints
Das fetchpriority-Attribut mit den Werten high, low und auto ergänzt Resource Hints, ersetzt sie aber nicht. Es erlaubt, die interne Prioritätsheuristik des Browsers gezielt zu korrigieren, ohne eine zusätzliche preload-Anweisung zu benötigen. Ein <img fetchpriority="high"> auf dem LCP-Bild reicht in vielen Fällen bereits aus, um es vor anderen, später im DOM stehenden Bildern zu laden, weil der Browser Bilder standardmäßig mit niedrigerer Priorität als render-blockierendes CSS einstuft. Umgekehrt lässt sich mit fetchpriority="low" ein Bild-Karussell unterhalb des Folds bewusst zurückstufen, damit es nicht mit dem Hero-Bild um Bandbreite konkurriert.
Der praktische Unterschied zu preload: fetchpriority ändert nur die Reihenfolge unter bereits entdeckten Ressourcen, entdeckt aber keine neuen. Ein Bild, das erst nach einem JavaScript-Rendering im DOM erscheint, profitiert nicht von fetchpriority, weil der Preload Scanner es zu diesem Zeitpunkt noch gar nicht sehen kann. Auch die fetch()-API unterstützt seit Kurzem eine priority-Option, die sich analog verhält und sich für dynamisch nachgeladene Daten eignet, etwa bei einer Produktsuche mit Live-Vorschlägen.
7. Praxisbeispiel: Hero-Bild und Font in Hyvä preloaden
In einem Hyvä-Theme lassen sich Resource Hints nicht hart in eine Basis-default_head_blocks.xml schreiben, weil Hero-Bild und kritisches Font je nach Seitentyp unterschiedlich sind. Der saubere Weg ist ein eigener Block, der über das Layout-XML nur dort referenziert wird, wo er gebraucht wird, etwa auf der CMS-Startseite oder auf Kategorieseiten mit Hero-Banner. Der Block liest die tatsächliche Bild-URL und Auflösung aus dem aktuellen Content, statt eine feste URL zu hardcoden, damit der preload-Hint immer exakt zum später gerenderten <img>-Tag passt.
Wichtig ist die Reihenfolge im Head: Resource Hints gehören so weit oben wie möglich, idealerweise noch vor Google Tag Manager oder anderen Drittanbieter-Snippets, damit der Preload Scanner sie beim ersten Durchlauf durch das rohe HTML erfasst. In Hyvä bietet sich dafür der Block head.additional an, der bewusst früh im Dokument gerendert wird und sich gezielt pro Layout-Handle einschränken lässt, sodass die Checkout-Seite andere Hints bekommt als die Kategorieseite.
<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
<body>
<referenceBlock name="head.additional">
<!-- Renders <link rel="preload"> for the hero image and critical font -->
<block class="Mironsoft\Performance\Block\ResourceHints"
name="performance.resource.hints"
template="Mironsoft_Performance::head/resource-hints.phtml"/>
</referenceBlock>
</body>
</page>
8. Preconnect im Checkout und Prefetch bei Hover auf der Kategorieseite
Ein preconnect zur Domain des Zahlungsanbieters gehört ausschließlich auf die Checkout-Seite, gesteuert über das Layout-Handle checkout_index_index, nicht global in ein Basis-Layout. Auf jeder anderen Seite wäre die Verbindung ungenutzte Verschwendung, weil der Browser sie ohnehin nach wenigen Sekunden wieder schließt. Auf der Kategorieseite lohnt sich stattdessen ein hover- oder fokusgetriggerter prefetch: Sobald ein Nutzer mit der Maus über eine Produktkarte fährt oder sie per Tastatur fokussiert, ist die Wahrscheinlichkeit eines Klicks deutlich höher als im Durchschnitt, und ein dynamisch injizierter <link rel="prefetch"> für genau diese PDP zahlt sich aus.
Die Injektion sollte über requestIdleCallback laufen, damit sie niemals mit der eigentlichen Interaktion des Nutzers konkurriert, und pro Link nur einmal ausgelöst werden, um doppelte Hints zu vermeiden. In Hyvä-Themes lässt sich das sauber als kleine Alpine.js-Komponente umsetzen, die an jede Produktkarte gebunden wird und beim ersten mouseenter- oder focus-Event den Hint setzt, ohne zusätzliche Bibliotheken oder synchrones JavaScript im kritischen Pfad zu benötigen.
// Hyvä Alpine.js component: prefetch PDP resources on hover/focus, not on every render
function categoryProductLink() {
return {
prefetched: false,
schedulePrefetch(url) {
if (this.prefetched) return;
this.prefetched = true;
// Idle-time injection so it never competes with the current page's critical path
const inject = () => {
const link = document.createElement('link');
link.rel = 'prefetch';
link.as = 'document';
link.href = url;
document.head.appendChild(link);
};
if ('requestIdleCallback' in window) {
requestIdleCallback(inject, { timeout: 2000 });
} else {
setTimeout(inject, 200);
}
}
};
}
// Register the component with Alpine, bound via x-data on each product card
document.addEventListener('alpine:init', () => {
Alpine.data('categoryProductLink', categoryProductLink);
});
9. Resource Hints validieren: DevTools, Priority Column, Warnungen
Der zuverlässigste Weg, Resource Hints zu prüfen, führt über den Network-Tab der Chrome DevTools. Die Spalte Priority zeigt für jede Anfrage die tatsächlich vergebene Netzwerkpriorität, von Highest bis Lowest. Ein per preload vorgeladenes Bild sollte dort High oder Highest zeigen, während ein per prefetch geladenes Dokument mit Lowest erscheinen sollte. Weicht die angezeigte Priorität von der Erwartung ab, deutet das meist auf ein falsches oder fehlendes as-Attribut hin. Die Spalte Initiator zeigt außerdem, ob eine Ressource tatsächlich vom Preload Scanner oder erst später vom Renderer angefordert wurde.
Die Konsole ergänzt das um Laufzeit-Warnungen: Ungenutzte Preloads werden explizit gemeldet, ebenso Font-Preloads ohne crossorigin. Der Lighthouse-Audit "Preload key requests" listet Ressourcen auf, die spät entdeckt werden und von einem Hint profitieren würden, während "Avoid chaining critical requests" zeigt, wo eine Kette aus abhängigen Anfragen die Zeit bis zur ersten sichtbaren Darstellung unnötig verlängert. Beide Reports gehören in jeden Performance-Review, bevor neue Resource Hints in Produktion gehen, und sollten nach jedem größeren Theme- oder Layout-Update erneut geprüft werden.
Die folgende Übersicht fasst zusammen, wann welcher Resource-Hint-Typ sinnvoll ist und welches Overuse-Risiko er jeweils birgt.
| Hint-Typ | Einsatzzweck | Prioritäts-Auswirkung | Browser-Support | Overuse-Risiko |
|---|---|---|---|---|
| preload | Kritische Ressource der aktuellen Seite (Font, Hero-Bild, CSS) | Hoch, sofort | Alle modernen Browser | Hoch bei falschem "as" oder Überzahl |
| prefetch | Wahrscheinliche nächste Navigation (PDP, Checkout) | Niedrigste, im Leerlauf | Alle modernen Browser | Mittel bei falscher Vorhersage |
| preconnect | Sicher genutzter Drittanbieter-Origin (CDN, Payment) | Nur Verbindungsaufbau, keine Daten | Alle modernen Browser | Hoch bei mehr als 6 Origins |
| dns-prefetch | Wahrscheinlicher, aber unsicherer Drittanbieter-Origin | Nur DNS, minimale Kosten | Auch ältere Browser | Gering, günstiger Fallback |
| fetchpriority | Priorität bereits bekannter Ressourcen fein justieren | Direkt, ohne neue Anfrage | Aktuelle Chromium/Firefox-Versionen | Gering, kein Extra-Download |
In der Praxis ergänzen sich die fünf Mechanismen: preload und fetchpriority beschleunigen, was ohnehin geladen wird, prefetch und preconnect bereiten vor, was wahrscheinlich als Nächstes gebraucht wird. Wer alle fünf undifferenziert auf jede Seite legt, statt sie gezielt pro Seitentyp einzusetzen, produziert genau die Bandbreiten-Konkurrenz, die Resource Hints eigentlich verhindern sollen.
Mironsoft
Netzwerk-Performance, Resource Hints und Hyvä-Optimierung für Magento-Shops
Resource Hints gezielt statt wahllos einsetzen?
Wir analysieren, welche Ressourcen auf euren Magento-Seiten wirklich kritisch sind, setzen preload, prefetch und preconnect präzise pro Seitentyp und validieren jeden Hint mit echten DevTools-Messungen statt Bauchgefühl.
Resource-Hints-Audit
DevTools-Analyse aller preload-, prefetch- und preconnect-Tags pro Seitentyp
Hyvä-Implementierung
Layout-XML-Blöcke für Hero-Bild, Font und checkout-spezifisches Preconnect
Monitoring-Setup
Lighthouse-Audits und Priority-Column-Checks in die CI/CD-Pipeline integrieren
10. Zusammenfassung
Resource Hints lösen ein sehr spezifisches Problem: Der Browser entdeckt manche kritische Ressourcen erst spät im Rendering-Prozess, weil sie in CSS, JavaScript oder tief im DOM versteckt sind. preload holt genau diese eine LCP-relevante Ressource früher, mit korrektem as- und bei Fonts zwingendem crossorigin-Attribut. prefetch bereitet die wahrscheinlich nächste Navigation im Leerlauf vor, ohne die aktuelle Seite zu verlangsamen. preconnect und dns-prefetch nehmen die Verbindungskosten zu Drittanbieter-Origins vorweg, aber nur für Ziele, die auch tatsächlich gebraucht werden. fetchpriority justiert die Reihenfolge bereits bekannter Ressourcen, ohne eine zusätzliche Anfrage zu erzeugen.
Der entscheidende Denkfehler bei Resource Hints ist die Annahme, mehr sei automatisch besser. Jeder Hint kostet Bandbreite, Verbindungsslots oder Prozessorzeit, und diese Kosten konkurrieren direkt mit der einen Ressource, die wirklich zuerst fertig sein muss. Wer preload auf ein bis zwei LCP-kritische Ressourcen und preconnect auf vier bis sechs Origins begrenzt, dabei die Priority-Column in Chrome DevTools regelmäßig kontrolliert und ungenutzte Preload-Warnungen ernst nimmt, holt aus Resource Hints einen messbaren Vorteil heraus, statt sie zur ungeprüften Standardpraxis zu machen.
Resource Hints: preload, prefetch, preconnect - Das Wichtigste auf einen Blick
Preload Scanner
Erkennt nur Hints im initialen HTML. Per JavaScript nachgeschobene preload-Tags kommen zu spät für die kritische Ladephase.
preload vs. prefetch
preload für die aktuelle Seite mit hoher Priorität, prefetch für die nächste Navigation mit niedrigster Priorität im Leerlauf.
Overuse-Grenze
Ein bis zwei preload-Ressourcen pro Seite, vier bis sechs preconnect-Origins. Mehr konkurriert um Bandbreite.
Validierung
Priority Column in Chrome DevTools und Konsolen-Warnung "preloaded but not used" nach jedem Deployment prüfen.