Core Web Vitals
preload, prefetch, preconnect - wann was?
Drei <link>-Attribute, eine gemeinsame Idee und trotzdem verwechselt sie fast jeder. Alle drei optimieren, wie der Browser externe Ressourcen und Verbindungen behandelt, aber auf grundlegend verschiedene Weise.
Das Grundprinzip
Browser laden Ressourcen nicht einfach stur der Reihenfolge nach. Typ, Fundstelle, Render-Relevanz und Priorität fließen in die Bewertung ein, zusammen mit Preload-Scanner, Spekulationslogik und Render-Blocking-Regeln. Resource Hints greifen in diese Priorisierung ein. Genau deshalb sollte man sie sparsam und gezielt einsetzen: Wer wahllos Hints setzt, riskiert das Gegenteil des Gewünschten; Ressourcen konkurrieren um Bandbreite, kritische Assets werden ausgebremst.
Alle vier Hints sind in allen modernen Browsern gut unterstützt. dns-prefetch läuft seit den frühen Browserversionen, preconnect und preload seit Chrome 46/50, Firefox 39/85 und Safari 11. Polyfills oder Feature-Detection sind nicht nötig.
preload – kritische Assets der aktuellen Seite
preload ist ein starkes Signal an den Browser: Diese Ressource wird sehr bald gebraucht, lade sie früh und mit hoher Priorität, auch wenn sie im Parsing-Fluss erst später auftauchen würde. Der Browser behält sich eigene Optimierungen vor, folgt dem Hint aber in aller Regel.
Am häufigsten eingesetzt wird preload für das Hero-Bild, Custom Fonts im Webfont-Format und kritisches JavaScript, das früh ausgeführt werden muss.
<!-- Hero-Bild vorladen: direkte LCP-Wirkung -->
<link rel="preload" as="image" href="/images/hero.webp">
<!-- Responsives Hero-Bild: imagesrcset + imagesizes sind Pflicht,
sonst lädt man eine Datei vor, die der Browser später gar nicht nutzt -->
<link
rel="preload"
as="image"
href="/images/hero-1280.webp"
imagesrcset="/images/hero-640.webp 640w, /images/hero-1280.webp 1280w, /images/hero-1920.webp 1920w"
imagesizes="100vw"
fetchpriority="high"
>
<!-- Webfont vorladen: crossorigin ist bei Fonts immer Pflicht -->
<link rel="preload" as="font" href="/fonts/Inter-Regular.woff2" type="font/woff2" crossorigin>
<!-- Kritisches Script vorladen -->
<link rel="preload" as="script" href="/js/app.js">
Das as-Attribut teilt dem Browser mit,welcher Ressourcentyp geladen wird, und beeinflusst damit Priorität, CSP-Checks und den Accept-Header der Anfrage. Fehlt es, lädt der Browser die Ressource mit niedriger Default-Priorität und ignoriert sie unter Umständen komplett. Wer fünf Ressourcen mit preload markiert, hat keine davon wirklich priorisiert, weil sie untereinander konkurrieren. Zwei bis drei Hints pro Seite sind die realistische Obergrenze.
prefetch: Ressourcen für den nächsten Schritt
prefetch ist ein Vorschlag. Der Browser lädt die Ressource im Hintergrund, wenn er Kapazität hat, also nach dem kritischen Rendering-Pfad, während der Nutzer liest oder scrollt. Kommt die nächste Navigation, liegt die Ressource bereits im Cache.
Sinnvoll bei vorhersehbaren Nutzeraktionen: ein mehrstufiges Formular, eine Detailseite aus einer Listenansicht, der nächste Artikel einer Serie.
<!-- Nächste Seite vorabladen -->
<link rel="prefetch" href="/kontakt/">
<!-- Kritisches Script der Folgeseite -->
<link rel="prefetch" as="script" href="/js/checkout.js">
prefetch lädt Ressourcen für eine andere Seite. Wer das Attribut auf der aktuellen Seite für die aktuelle Seite einsetzt, hat das Modell falsch verstanden; dafür gibt es preload.
preconnect: Verbindung aufbauen, bevor sie gebraucht wird
Jede Anfrage an eine externe Domain hat Overhead: DNS-Auflösung, TCP-Handshake, TLS-Aushandlung. Das kostet gemeinsam 100–300 ms. preconnect erledigt diesen Aufbau, bevor der Browser die erste echte Anfrage stellt.
Typische Kandidaten sind Google Fonts, CDNs, externe Analytics-Endpunkte und API-Hosts, also alle Domains, die früh und regelmäßig angesprochen werden.
<!-- Google Fonts: zwei preconnects nötig (fonts.googleapis.com + fonts.gstatic.com) -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Eigenes CDN -->
<link rel="preconnect" href="https://cdn.example.com">
Fonts werden mit einer anonymen CORS-Anfrage geladen. Fehlt crossorigin, baut der Browser eine zweite Verbindung auf und macht den Vorteil des preconnect damit wieder zunichte. Mehr als vier bis sechs Hints lohnen sich selten; unbegründete Verbindungen schließt der Browser ohnehin nach kurzer Zeit wieder.
dns-prefetch: der leichtgewichtige Fallback
dns-prefetch löst nur den DNS-Namen auf, ohne Verbindungsaufbau. Es ist der schwächere Bruder von preconnect, sinnvoll für Domains, bei denen unklar ist, ob sie tatsächlich genutzt werden, oder als Rückfalloption für ältere Browser.
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
In der Praxis empfiehlt sich die Kombination beider Hints, wenn ein Font-Host oder CDN kritisch ist:
<!-- Moderner Browser: preconnect. Älterer Browser: dns-prefetch als Fallback. -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://fonts.gstatic.com">
In WordPress einbinden
WordPress bringt eigene Core-Filter mit, über die Resource Hints sauber registriert werden. wp_resource_hints verwaltet preconnect und dns-prefetch, wp_preload_resources (seit WordPress 6.1) übernimmt Preloads, inklusive as, crossorigin, media, imagesrcset, imagesizes und seit 6.6 auch fetchpriority.
// preconnect und dns-prefetch über WordPress-Core-Filter
add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
if ( 'preconnect' === $relation_type ) {
$urls[] = [
'href' => 'https://fonts.gstatic.com',
'crossorigin' => 'anonymous',
];
}
if ( 'dns-prefetch' === $relation_type ) {
$urls[] = 'https://fonts.gstatic.com';
}
return $urls;
}, 10, 2 );
// Webfont vorladen über wp_preload_resources (ab WP 6.1)
add_filter( 'wp_preload_resources', function( $resources ) {
$resources[] = [
'href' => get_template_directory_uri() . '/fonts/Inter-Regular.woff2',
'as' => 'font',
'type' => 'font/woff2',
'crossorigin' => 'anonymous',
];
return $resources;
} );
Der manuelle wp_head-Hook mit Priorität 1 funktioniert ebenfalls und ist schneller eingebaut. Die Core-Filter sind die verlässlichere Wahl, sobald Theme-Vererbung und Plugin-Kompatibilität eine Rolle spielen.
Kurz gefasst
| Hint | Was passiert | Für welchen Zeitpunkt | Priorität |
|---|---|---|---|
| preload | Ressource wird früh geladen | Aktuelle Seite | Hoch |
| prefetch | Ressource wird bei Leerlauf geladen | Nächste Seite / nächster Schritt | Niedrig |
| preconnect | Verbindung aufbauen (DNS + TCP + TLS) | Externe Domain, bald genutzt | Mittel |
| dns-prefetch | DNS-Auflösung anstoßen | Externe Domain, vielleicht genutzt | Sehr niedrig |
Die häufigste Verwechslung: preload lädt eine Datei früher, preconnect stellt eine Verbindung früher her. Bei externen Fonts braucht man oft beides, aber aus unterschiedlichen Gründen. preconnect wärmt die Verbindung zur Font-Domain vor, preload priorisiert eine konkrete Font-Datei. Wer beides verwechselt, optimiert nicht, sondern erzeugt nur zusätzlichen Verkehr im <head>.
Jetzt weiterlesen...
