Preload, Prefetch und Preconnect: wann was wirklich hilft
Resource Hints sind nützlich, wenn sie zu echten Browser-Engpässen passen. Blind eingesetzt erzeugen sie Prioritätsrauschen und machen Seiten manchmal langsamer.
Inhaltsverzeichnis
- Resource Hints sind keine Magie
- Was der Browser bereits gut macht
- Preload: für Ressourcen der aktuellen Seite, die zu spät entdeckt werden
- Preload und LCP-Bilder
- Prefetch: für die nächste Seite, nicht für diese
- Preconnect: für teure Verbindungen zu wichtigen Origins
- DNS-prefetch: der leichtere Verwandte
- So entscheiden Sie: ein praktischer Workflow
- 1. Engpass identifizieren
- 2. Einen Hint nach dem anderen hinzufügen
- 3. Nebenwirkungen auf Prioritäten prüfen
- 4. Header und Caching prüfen
- Häufige Fehler
- Zu viel preloaden
- Prefetch für erforderliche Ressourcen verwenden
- Zu jedem Drittanbieter preconnecten
- Mobile Bedingungen vergessen
- Eine einfache Entscheidungstabelle
- Die ruhige Regel
Resource Hints sind keine Magie
preload, prefetch und preconnect werden oft wie eine Performance-Checkliste behandelt. Ein paar Tags in den <head> einfügen, Lighthouse erneut ausführen, sich besser fühlen. So funktionieren sie nicht.
Diese Hints sind Anweisungen an die Lade-Pipeline des Browsers. Sie können helfen, wenn Sie etwas wissen, das der Browser nicht früh genug entdecken kann. Sie können schaden, wenn Sie raten, unkritische Arbeit zu hoch priorisieren oder Verbindungen aufwärmen, die Nutzer nie brauchen.
Die Kurzfassung:
- Verwenden Sie
preloadfür Ressourcen, die für die aktuelle Seite erforderlich sind, aber zu spät entdeckt werden. - Verwenden Sie
prefetchfür wahrscheinliche Ressourcen einer künftigen Navigation, nicht für Essentials der aktuellen Seite. - Verwenden Sie
preconnectfür wichtige Drittanbieter-Origins, bei denen der Verbindungsaufbau tatsächlich verzögert.
Die praktische Frage lautet nicht „welcher Hint ist am schnellsten?“. Sie lautet: „Worauf wartet der Browser, und kann dieser Hint dieses Warten beseitigen?“
Was der Browser bereits gut macht
Moderne Browser sind keine passiven Datei-Downloader. Sie parsen HTML, scannen vorausschauend nach Ressourcen, vergeben Prioritäten, nutzen Verbindungen wieder, verzögern nicht sichtbare Arbeit und passen sich an Netzwerkbedingungen an.
Das bedeutet: Resource Hints sollten selektiv eingesetzt werden. Wenn ein Stylesheet, Script, Bild oder Font bereits früh entdeckt und mit der richtigen Priorität versehen wird, bewirkt ein zusätzlicher Hint möglicherweise nichts. Schlimmer noch: Er kann mit wichtigeren Ressourcen konkurrieren.
Bevor Sie Hints hinzufügen, sehen Sie sich eine Waterfall-Ansicht in DevTools oder einen Lab-Report an. Wenn Sie Lighthouse verwenden, beginnen Sie mit den Diagnosen statt mit dem Score; wir haben einen separaten Leitfaden dazu, wie man einen Lighthouse-Report liest, ohne in Panik zu geraten — beachten Sie aber, dass die korrekte URL zwischen Groß- und Kleinschreibung unterscheidet. Nutzen Sie bei Bedarf den verlinkten Artikel aus der Navigation Ihrer Website.
Die eigentlichen Belege sind meist an drei Stellen sichtbar:
- Eine kritische Ressource startet spät, weil der Browser sie spät entdeckt.
- Eine Verbindung zu einer wichtigen Origin benötigt spürbar Zeit vor der ersten Anfrage.
- Eine Ressource für die nächste Seite ist sehr vorhersehbar und kann in Leerlaufzeit günstig geladen werden.
Wenn nichts davon zutrifft, ist ein Hint wahrscheinlich nur Dekoration.
Preload: für Ressourcen der aktuellen Seite, die zu spät entdeckt werden
preload sagt dem Browser: „Lade diese Ressource jetzt, weil die aktuelle Seite sie brauchen wird.“
Ein typisches Beispiel ist ein Webfont, der innerhalb von CSS referenziert wird. Der Browser muss HTML herunterladen, das CSS entdecken, das CSS herunterladen, es parsen, den Font entdecken und dann den Font anfordern. Wenn dieser Font für Text above the fold wichtig ist, kann die Entdeckung spät genug erfolgen, um Layout Shifts oder verzögertes Textrendering zu verursachen.
Ein Preload kann diese Anfrage nach vorne ziehen:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Das Attribut as ist wichtig. Es sagt dem Browser, um welche Art von Ressource es sich handelt, was Priorität, Caching, Content Security Policy und Request-Header beeinflusst. Fonts benötigen außerdem in der Regel crossorigin, selbst wenn sie von derselben Website ausgeliefert werden, weil Font-Fetching den CORS-Modus verwendet.
Gute Kandidaten für preload sind:
- Der primäre Webfont für sichtbaren Text.
- Ein Hero-Bild, das das Largest Contentful Paint-Element ist und nicht früh entdeckt werden kann.
- Eine kritische CSS-Datei, die indirekt geladen wird.
- Ein Modul oder Script, das sehr früh benötigt wird, aber hinter einem anderen Script verborgen ist.
Schlechte Kandidaten für preload sind:
- Jede Font-Stärke im Designsystem.
- Bilder below the fold.
- Scripts, die für das initiale Rendering nicht benötigt werden.
- Ressourcen, die der Browser bereits im ersten HTML-Chunk entdeckt.
Preload ist wirkungsvoll, weil es die Priorität auf der aktuellen Seite beeinflusst. Genau deshalb lässt es sich auch leicht falsch einsetzen. Wenn Sie fünf große Assets preloaden, helfen Sie dem Browser nicht mehr. Sie streiten mit ihm.
Fonts sind der klassische Fall. Das Preloaden einer primären Font-Datei kann helfen. Sechs Schriftschnitte und Kursiven zu preloaden macht die Lage meist schlechter. Wenn Fonts Ihr Engpass sind, bereinigen Sie zuerst das Font-Set; unser Leitfaden dazu, warum Webfonts auf den meisten Websites immer noch der einfachste Performance-Gewinn sind, behandelt diese Aufräumarbeit ausführlicher.
Preload und LCP-Bilder
Das Preloaden eines LCP-Bildes kann nützlich sein, wenn das Bild im initialen HTML nicht sichtbar ist. Häufige Ursachen sind CSS-Hintergrundbilder, clientseitig gerenderte Komponenten oder Responsive-Image-Logik, die spät erscheint.
Wenn Ihr Hero-Bild jedoch bereits als <img> im HTML steht, mit sinnvollem srcset, sizes, Abmessungen und ohne Lazy Loading, kann der Browser es wahrscheinlich schnell finden. In diesem Fall kann fetchpriority='high' je nach Seite angemessener sein als Preload.
Ein guter Test: Wenn die Bildanfrage im Waterfall spät startet und zum LCP-Element wird, sollten Sie Preload erwägen. Wenn sie früh startet, aber langsam herunterlädt, liegt das Problem bei Größe, Format, CDN-Verhalten oder Serverlatenz — nicht bei der Entdeckung. Zu Entscheidungen über Bildformate siehe wann AVIF WebP schlägt und wann nicht.
Prefetch: für die nächste Seite, nicht für diese
prefetch sagt dem Browser: „Diese Ressource könnte bald benötigt werden, ist aber jetzt nicht erforderlich.“
Diese Unterscheidung ist wichtig. Prefetch hat absichtlich eine niedrige Priorität. Der Browser kann die Ressource in Leerlaufzeit laden und für spätere Nutzung speichern. Er kann sie bei schlechten Verbindungen, Datensparmodi oder Speicherdruck auch überspringen.
Verwenden Sie Prefetch, wenn die Nutzerabsicht stark genug ist, um die nächste Ressource wahrscheinlich zu machen.
Gute Kandidaten für Prefetch sind:
- Der nächste Schritt in einem mehrseitigen Checkout.
- Suchergebnisse, nachdem ein Nutzer mit der Eingabe einer Suchanfrage beginnt, sofern die nächste Route vorhersehbar ist.
- Dokumentationsseiten, die aus einem Inhaltsverzeichnis verlinkt sind, während der Nutzer aktiv Inhalte in der Nähe liest.
- Route-Chunks in einer Single-Page-App, nachdem ein Nutzer ein Navigationselement hovert oder fokussiert.
Schlechte Kandidaten für Prefetch sind:
- Ihr gesamter Navigationsbaum.
- Große Videos oder Bildergalerien.
- Drittanbieter-Scripts „nur für den Fall“.
- Seiten, die Nutzer selten als Nächstes besuchen.
Bei Prefetch zahlt sich Zurückhaltung aus. Eine geladene und nie genutzte Ressource ist nicht kostenlos. Sie verbraucht Bandbreite, Serverkapazität, Energie und möglicherweise Nutzerdaten. In Mobilfunknetzen kann spekulatives Laden aktiv unfreundlich sein.
Für viele Websites ist die beste Prefetch-Strategie absichtsbasiert. Prefetchen Sie die Preisseite nicht sofort beim Laden der Startseite. Prefetchen Sie sie, wenn der Nutzer das Preismenü öffnet, den Preislink hovert oder in die Nähe eines Call-to-Action scrollt, der eine Navigation stark vorhersagt.
Denken Sie außerdem daran, dass sich Browser unterschiedlich verhalten. Manche Browser sind bei Prefetch konservativ; manche Datenschutzeinstellungen reduzieren oder deaktivieren spekulatives Laden. Behandeln Sie Prefetch als opportunistische Verbesserung, nicht als Korrektheitsmechanismus.
Preconnect: für teure Verbindungen zu wichtigen Origins
preconnect sagt dem Browser: „Beginne jetzt mit dem Aufbau einer Verbindung zu dieser Origin.“
Das kann DNS-Lookup, TCP-Verbindung und TLS-Aushandlung umfassen. Bei Drittanbieter-Origins kann dieser Aufbau Hunderte Millisekunden dauern, insbesondere in Netzwerken mit hoher Latenz. Wenn die Seite bald eine kritische Anfrage von dieser Origin benötigt, kann Preconnect die spätere Anfrage beschleunigen.
Beispiel:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Gute Kandidaten für Preconnect sind:
- Eine Font-Origin, die für render-blockierenden Text verwendet wird.
- Eine kritische API-Origin, die während der initialen Interaktion benötigt wird.
- Eine CDN-Origin, die Assets above the fold ausliefert.
- Ein Zahlungs- oder Identitätsanbieter, der unmittelbar nach einer Nutzeraktion benötigt wird.
Schlechte Kandidaten für Preconnect sind:
- Analytics- und Werbe-Endpunkte, die für Nutzer nicht kritisch sind.
- Origins, die nur in manchen Sessions verwendet werden.
- Lange Listen von Drittanbietern.
- Same-Origin-Ressourcen, bei denen der Browser die Verbindung bereits hat oder bald öffnen wird.
Preconnect hat Haltekosten. Offene Sockets verbrauchen Speicher und Netzwerkressourcen. Browser schließen ungenutzte Verbindungen, aber das macht unnötige Preconnects nicht harmlos.
Eine nützliche Regel: Setzen Sie Preconnect auf höchstens ein oder zwei Drittanbieter-Origins mit hoher Sicherheit pro Seite. Wenn Sie versucht sind, mehr hinzuzufügen, braucht Ihre Drittanbieter-Architektur wahrscheinlich eher eine Überprüfung als Ihre Hints eine Erweiterung.
DNS-prefetch: der leichtere Verwandte
Sie sehen möglicherweise auch dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Dies löst nur den Domainnamen auf. Es öffnet keine TCP- oder TLS-Verbindung. Es ist günstiger als Preconnect, aber auch weniger hilfreich.
DNS-prefetch kann für Drittanbieter-Origins mit geringerer Sicherheit sinnvoll sein, bei denen ein vollständiger Preconnect zu aggressiv wirkt. In der Praxis gilt: Wenn eine Origin kritisch ist und sicher bald verwendet wird, bevorzugen Sie Preconnect. Wenn es nur möglich ist, verwenden Sie entweder DNS-prefetch oder tun Sie nichts.
So entscheiden Sie: ein praktischer Workflow
Beginnen Sie mit Messung, nicht mit Tags.
1. Engpass identifizieren
Öffnen Sie einen Performance-Trace und suchen Sie nach später Entdeckung. Startete die Anfrage für Font, Hero-Bild oder Script erst, nachdem eine andere Datei heruntergeladen und geparst wurde? Das ist ein Preload-Kandidat.
Wenn eine Anfrage erst nach einem langen DNS/TCP/TLS-Aufbau zu einer Drittanbieter-Origin startet, ist das ein Preconnect-Kandidat.
Wenn die aktuelle Seite in Ordnung ist, die nächste Navigation aber vorhersehbar langsam, kann Prefetch helfen.
2. Einen Hint nach dem anderen hinzufügen
Resource Hints interagieren miteinander. Fügen Sie einen hinzu, testen Sie ihn und behalten Sie ihn nur, wenn sich der Waterfall verbessert und nutzerseitige Metriken nicht schlechter werden.
Achten Sie bei Preload darauf, ob die gehintete Ressource tatsächlich bald verwendet wird. Chrome warnt möglicherweise, wenn eine vorgeladene Ressource kurz nach dem Laden nicht verwendet wird. Nehmen Sie diese Warnung ernst.
3. Nebenwirkungen auf Prioritäten prüfen
Ein Preload kann Bandbreite von CSS, JavaScript oder Bildern abziehen, die wichtiger sind. Ein Preconnect kann einen Verbindungsslot belegen. Ein Prefetch kann Hintergrundverkehr erzeugen.
Das richtige Ergebnis ist nicht „die gehintete Datei startet früher“. Das richtige Ergebnis ist: „Die Seite wird für Nutzer spürbar besser.“ Betrachten Sie LCP, INP, CLS und, wo möglich, Real-User-Monitoring.
4. Header und Caching prüfen
Hints können in HTML oder HTTP-Link-Headern gesendet werden. Header sind nützlich, wenn der Server früh weiß, was die Seite brauchen wird, sind aber beiläufig schwerer zu inspizieren. Wenn Sie debuggen, ob ein Hint in Produktion tatsächlich vorhanden ist, zählen rohe Header; genau solche Situationen behandelt unser Leitfaden zum Debuggen von Redirects und HTTP-Headern.
Auch Caching ist wichtig. Das Preloaden einer Ressource mit nicht passenden Credentials, falschem as oder abweichenden URL-Parametern kann doppelte Downloads verursachen. Das ist eine der häufigsten Arten, wie ein gut gemeinter Preload zu einem Performance-Bug wird.
Häufige Fehler
Zu viel preloaden
Wenn alles kritisch ist, ist nichts kritisch. Beschränken Sie Preload auf Ressourcen, die für initiales Rendering oder unmittelbare Interaktivität benötigt werden. Eine typische Seite sollte null bis drei Preloads haben, nicht zwanzig.
Prefetch für erforderliche Ressourcen verwenden
Prefetch hat niedrige Priorität und ist optional. Verwenden Sie ihn nicht für Assets, die von der aktuellen Seite benötigt werden. Wenn die Seite sie jetzt braucht, erwägen Sie Preload oder normale HTML-Entdeckung.
Zu jedem Drittanbieter preconnecten
Drittanbieterlastige Seiten haben oft zehn oder mehr externe Origins. Zu allen einen Preconnect zu setzen erzeugt Rauschen. Wählen Sie die ein oder zwei, die sowohl kritisch als auch vorhersehbar genutzt werden.
Mobile Bedingungen vergessen
Resource Hints sind auf langsameren Verbindungen am wertvollsten, aber dort auch am gefährlichsten. Ein verschwendeter Prefetch auf einer schnellen Desktop-Verbindung ist ein Rundungsfehler. Bei einem eingeschränkten Mobilfunktarif ist er ein schlechter Tausch.
Eine einfache Entscheidungstabelle
| Situation | Bester Hint | Warum | |---|---:|---| | Kritischer Font, der über CSS entdeckt wird | preload | Die aktuelle Seite braucht ihn, die Entdeckung ist spät | | Hero-Bild hinter CSS oder clientseitigem Rendering verborgen | preload | Kann LCP verbessern, wenn das Bild spät startet | | Wahrscheinliche nächste Route nach Nutzerabsicht | prefetch | Hilft künftiger Navigation, ohne die aktuelle Seite zu blockieren | | Kritische Drittanbieter-Font/API-Origin | preconnect | Entfernt den Verbindungsaufbau aus dem kritischen Pfad | | Mögliche, aber unsichere Drittanbieter-Origin | dns-prefetch oder nichts | Geringere Kosten, geringere Sicherheit | | Bild below the fold | nichts | Lazy Loading und Browser-Priorisierung arbeiten lassen |
Die ruhige Regel
Resource Hints funktionieren am besten, wenn sie unspektakulär und spezifisch sind. Ein Font. Ein LCP-Bild. Eine wichtige Drittanbieter-Origin. Eine wahrscheinliche nächste Route nach Absicht.
Sie funktionieren schlecht, wenn sie als Optimismus eingesetzt werden: Vielleicht braucht der Nutzer dies, vielleicht sollte der Browser das laden, vielleicht bedeuten mehr Hints mehr Geschwindigkeit.
Browser optimieren bereits aggressiv. Ihre Aufgabe ist nicht, jede Anfrage bis ins Detail zu micromanagen. Ihre Aufgabe ist es, die wenigen Fälle zu korrigieren, in denen dem Browser im richtigen Moment Informationen fehlen.
Häufig gestellte Fragen
Sollte ich alle meine Fonts preloaden?
Ist Prefetch für jeden internen Link sicher?
Was ist der Unterschied zwischen preconnect und dns-prefetch?
Können Resource Hints Core Web Vitals verbessern?
Sollten Resource Hints in HTML oder HTTP-Headern hinzugefügt werden?
Quellen & weiterführende Literatur
