Zum Inhalt springen 
DNS Prefetching und Preloading verkürzen aktiv die Zeit bis zum ersten sichtbaren Inhalt, indem sie DNS, TCP und TLS früh anstoßen und kritische Dateien vorab bereitstellen. Ich zeige, wie du mit DNS Prefetching, Preconnect und Preloading die Website-Geschwindigkeit spürbar steigerst – inklusive Code, WordPress-Setup und praxiserprobten Prioritäten.
Zentrale Punkte
- DNS Prefetch: Frühzeitige Namensauflösung reduziert Latenz.
- Preconnect: DNS, TCP und TLS vorab öffnen.
- Preload: Kritische Dateien aktiv vorziehen.
- Priorisierung: Wenige, aber entscheidende Domains.
- Monitoring: Effekte im Wasserfall prüfen.
DNS Prefetching: kurz erklärt
Mit DNS Prefetching löst der Browser die IP einer Domain vorab, bevor er eine Datei lädt, und spart damit 20–250 ms pro Domain – besonders auf mobilen Verbindungen mit hoher Latenz. Ich setze den Hint für externe Hosts, die ich im Above-the-Fold-Bereich brauche, etwa für Fonts, Analytics oder ein CDN. Der Browser führt den DNS-Lookup im Hintergrund aus und verkürzt so den kritischen Pfad zum ersten Rendern. Moderne Browser nutzen Prefetching teilweise automatisch, doch ich sichere den Effekt mit einem klaren Hint im Head ab. So reduziere ich Roundtrips, stabilisiere den frühen Renderstart und beschleunige die Core Web Vitals.
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.googletagmanager.com">
<link rel="dns-prefetch" href="//cdn.example.com">
Unterschied: DNS Prefetching vs. Preconnect
Prefetch löst nur den DNS-Namen, während Preconnect zusätzlich den TCP- und TLS-Handshake öffnet und die Verbindung warm hält. Für kritische Hosts, etwa ein CDN für Render-CSS oder Webfonts, ziehe ich Preconnect dem bloßen Prefetch vor. Ich setze es sparsam ein, da jeder offene Socket Browser-Slots belegt. Das Attribut crossorigin gehört an alle Hosts mit CORS, damit spätere Requests nicht gebremst werden. Einen klaren Überblick zu Auswahl und Reihenfolge findest du im kompakten Leitfaden zu Prefetch.
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Preloading: Dateien gezielt vorziehen
Preload lädt spezifische Dateien aktiv in den Cache, bevor der Parser sie üblicherweise anfordert, und beschleunigt so FCP und LCP. Ich nutze es nur für Ressourcen, die sicher gebraucht werden, etwa critical CSS, Hero-Bilder oder WOFF2-Fonts. Das Attribut fetchpriority lenkt die Gewichtung nach oben, ohne andere wichtige Transfers komplett zu verdrängen. Ich kontrolliere, dass der MIME-Typ, das as-Attribut und die tatsächliche Nutzung übereinstimmen, sonst verliere ich Bandbreite. Eine gute Ergänzung bildet HTTP/3, wie im Beitrag zu HTTP/3 und Preload beschrieben.
<link rel="preload" as="style" href="/assets/css/critical.css" fetchpriority="high">
<link rel="preload" as="font" href="/assets/fonts/inter-regular.woff2" type="font/woff2" crossorigin>
<link rel="preload" as="image" href="/assets/img/hero.webp" imagesrcset="/assets/img/hero.webp 1x, /assets/img/[email protected] 2x">
Performance-Gewinn im Hosting-Setup
Ein schnelles Hosting verstärkt die Wirkung der Hints, weil niedrige RTTs, HTTP/3 und ein nahes CDN die Wartezeiten pro Stufe drücken. Ich sehe regelmäßig, dass TTFB um bis zu eine Sekunde fällt, wenn DNS, TCP und TLS vorgewärmt starten und der Origin fix antwortet. Auf Mobilgeräten mit hoher Latenz zahlt sich das doppelt aus, weil jeder gesparte Roundtrip direkt ins LCP eingeht. Ich achte auf stabile TLS-Aushandlungen, OCSP-Stapling und eine schlanke TLS-Konfiguration. So nutzt der Browser seine wenigen gleichzeitigen Verbindungen optimal aus und beschleunigt die Website Speed.
Schnellvergleich: welche Technik wofür?
Die folgende Tabelle fasst Wirkung, Einsatz und Beispiel-Tags zusammen und hilft mir, pro Host die richtige Maßnahme zu wählen. Ich kombiniere Prefetch für Breite, Preconnect für kritische Hosts und Preload für unverzichtbare Dateien. Dabei halte ich die Anzahl gleichzeitig geöffneter Verbindungen gering. So bleibt genug Spielraum für Parser-Entdeckungen und late-critical Assets. Dieser Überblick macht Entscheidungen zur Priorisierung leichter.
| Technik | Was passiert | Typischer Einsatz | Beispiel-Tag | Auswirkung auf FCP/LCP |
|---|---|---|---|---|
| DNS Prefetch | Frühe Namensauflösung | Externe Hosts mit späteren Requests | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Mäßig positiv, je nach Latenz |
| Preconnect | DNS + TCP + TLS vorwärmen | CDN, Fonts, kritische APIs | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Deutlich positiv, spart Roundtrips |
| Preload | Datei aktiv vorladen | Critical CSS, WOFF2, Hero-Image | <link rel="preload" as="style" href="/critical.css"> | Sehr positiv, wenn korrekt gewählt |
WordPress-Integration: sauber und wartbar
In WordPress setze ich die Hints sehr früh im Head, damit der Browser sie vor dem Parser-Bottleneck sieht. Ich dedupliziere Hosts, prüfe das Vorhandensein von https und ergänze crossorigin nur bei Bedarf. Der folgende Code platziert Einträge ganz oben, was den Effekt maximiert. Zusätzlich kontrolliere ich nach Deployments, ob neue externe Hosts dazugekommen sind. So bleibt die Hint-Liste schlank, aktuell und effizient.
function add_dns_prefetch() {
$domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com'];
$printed = [];
foreach ($domains as $domain) {
$key = preg_replace('#^https?:#', '', $domain);
if (isset($printed[$key])) { continue; }
$printed[$key] = true;
echo '<link rel="dns-prefetch" href="' . esc_url($key) . '" />' . "\n";
if (strpos($domain, 'https://') === 0) {
echo '<link rel="preconnect" href="' . esc_url($domain) . '" crossorigin />' . "\n";
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1);
Best Practices: knapp, aber wirkungsvoll
Ich beschränke Preconnect auf drei bis fünf Hosts, sonst blockiert der Browser zu viele Sockets vorzeitig. Ich setze Hints immer an den Anfang des Head, danach folgen Preloads, dann Styles und Scripts. Für Fonts kombiniere ich Preconnect mit font-display: swap, damit Text sofort erscheint und CLS niedrig bleibt. Ich achte darauf, dass Preload-Dateien garantiert genutzt werden, sonst verschenke ich Bandbreite und priorisiere am Bedarf vorbei. Für Third-Party-Skripte prüfe ich kritisch, ob wirklich jede Domain nötig ist.
Messung und Monitoring: Erfolge sichtbar machen
Im Network-Tab der DevTools schaue ich auf die Reihenfolge von DNS, TCP und TLS und prüfe, ob sie früher starten als zuvor. Ein Vorher-Nachher-Vergleich im Wasserfall zeigt klar, ob die Hints greifen. Mit Lighthouse oder PageSpeed Insights beachte ich FCP, LCP und CLS sowie den TTFB-Trend. WebPageTest liefert zusätzlich Connection-View und Filmstrips, die den Renderstart belegen. Nach größeren Änderungen wiederhole ich die Messung und entferne veraltete Hosts aus der Hint-Liste.
HTTP/3, QUIC und Connection Coalescing
Mit HTTP/3 über QUIC spare ich zusätzliche Roundtrips, weil Verbindungsaufbau, Verlustbehandlung und Multiplexing effizienter arbeiten. Ich prüfe, ob mein CDN und mein Origin HTTP/3 anbieten und setze Preconnect weiterhin gezielt ein. Connection Coalescing reduziert die Anzahl separater Verbindungen, wenn Zertifikate und IPs passen. Dadurch bedienen Hosts mit demselben Zertifikat mehrere Subdomains über eine gemeinsame Verbindung. In Summe profitiert der frühe Renderpfad deutlich, besonders bei vielen kleinen Dateien.
CDN-Warmup und Prefetch kombinieren
Ich erwärme mein CDN, wenn ich Traffic-Spitzen erwarte, und kombiniere das mit Prefetch und Preconnect für Edge-Hosts. So liegen wichtige Objekte im Edge-Cache und die Handshakes sind bereits vorbereitet. Das senkt Latenzen vor allem auf Erstaufrufen und unter Mobilbedingungen. Eine praktische Anleitung liefert der Beitrag zu CDN-Warmup, den ich gern als Checkliste nutze. Vor Rollouts teste ich Cache-Hit-Rates und beobachte die TTFB-Entwicklung.
Governance: Hint-Liste aktuell halten
Ich führe eine kurze Inventur aller externen Hosts und prüfe quartalsweise, ob neue Skripte, Fonts oder Bilder dazugekommen sind. Entfernte Integrationen streiche ich samt Hint, damit die Liste schlank bleibt. Für jeden Host vermerke ich Zweck, Kritikalität und die eingesetzte Technik (Prefetch, Preconnect oder Preload). Änderungen am CDN oder an Schriften pflege ich sofort ein, damit keine verwaisten Einträge liegen bleiben. So behalte ich Kontrolle, reduziere Overhead und sichere eine konsistente Performance.
Browserunterstützung, Heuristiken und Grenzen
Ich kalkuliere ein, dass Browser Hints als Signale verstehen – nicht als Befehl. Bei geringer Bandbreite, aktivem Data Saver oder im Hintergrundtab kann der Browser Prioritäten anpassen oder Hints drosseln. Safari ist konservativer bei Preconnects, Firefox hat teils andere Heuristiken für DNS-Caches, und Mobile-Varianten reduzieren parallele Sockets. Deshalb formuliere ich Hints präzise und vermeide Übersignalisierung: wenige Hosts, klare as-Werte, korrekte type-Angaben. Für Fonts achte ich auf crossorigin, sonst drohen doppelte Fetches oder ein spätes CORS-Blocken. Wenn ich Prefetch vollständig steuern möchte, kann ich mit <meta http-equiv="x-dns-prefetch-control" content="on"> oder off die automatische Heuristik beeinflussen.
HTTP-Header und 103 Early Hints
Neben HTML-Tags nutze ich Link-Header, damit Hints schon mit der ersten Serverantwort einfliegen – ideal bei serverseitigem Rendering. 103 Early Hints schicken diese Header sogar vor der finalen 200-Antwort und gewinnen so weitere Dutzend Millisekunden auf langen Leitungen.
# NGINX: Preconnect und Preload via Link-Header
add_header Link '<https://fonts.gstatic.com>; rel=preconnect; crossorigin' always;
add_header Link '</assets/css/critical.css>; rel=preload; as=style; fetchpriority=high' always;
add_header Link '</assets/fonts/inter-regular.woff2>; rel=preload; as=font; type=font/woff2; crossorigin' always;
# Apache (htaccess)
Header add Link '<https://cdn.example.com>; rel=preconnect; crossorigin'
Header add Link '</assets/img/hero.webp>; rel=preload; as=image'
Unterstützt der Server 103 Early Hints, sende ich die Link-Header zusätzlich frühzeitig. Wichtig: Ich halte die Liste kurz, weil jeder Eintrag Parsing-Aufwand und potenzielle Verbindungsöffnungen erzeugt.
SPA und Service Worker: Routen- und Daten-Prefetch
Bei Single-Page-Apps verschiebe ich Hints zustandsbasiert: Sobald der Hero sichtbar ist, starte ich ein gezieltes Preload für die nächste Route (JS-Chunk, kritisches Bild, API-Schema). Im Service Worker kann ich Preload-Ergebnisse cachen und nach Navigationsereignissen verwenden. Ich definiere klare Abbruchkriterien (Tab versteckt, CPU überlastet, schwaches Netz), damit Prefetch nicht zum Kostentreiber wird. Für ES-Module setze ich früh modulepreload, damit die Dependenz-Kette nicht ausbremst.
<link rel="modulepreload" href="/assets/js/app.entry.js">
<script>
// Vorsichtige SPA-Vorladung
if (navigator.connection?.saveData !== true) {
const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 300));
idle(() => {
const l = document.createElement('link');
l.rel = 'preload';
l.as = 'script';
l.href = '/assets/js/route-checkout.js';
document.head.appendChild(l);
});
}
</script>
Sicherheit, Datenschutz und Richtlinien
Ich bedenke Policy-Rahmenwerke: Ein strenges CSP kann Preloads blockieren, wenn font-src, style-src oder img-src die Ziele nicht zulassen. crossorigin ist für Fonts Pflicht, sonst greift der Cache nicht origin-übergreifend. Bei sensiblen Third-Parties streue ich keine Preconnects, wenn ich die Domain künftig entfernen könnte – jeder Hint ist ein Signal an den Browser und kann Tracking-Skripte beschleunigen. Ich prüfe außerdem Save-Data und Data Saver: In diesen Modi reduziere ich die Aggressivität von Preloads und lasse lediglich DNS Prefetch für zentrale Hosts aktiv.
Messpraxis vertiefen: Timing API und Logs
Neben Wasserfällen nutze ich die Resource Timing API und PerformanceObserver, um im Feld zu messen, ob Hints vor dem Parser landen und wie sich domainLookupStart, connectStart und secureConnectionStart verschieben. So erkenne ich, ob ein Preconnect wirklich genutzt oder vom Browser verworfen wurde.
<script>
new PerformanceObserver((list) => {
for (const e of list.getEntriesByType('resource')) {
if (e.name.includes('fonts.gstatic.com')) {
console.log('DNS:', e.domainLookupEnd - e.domainLookupStart,
'TLS:', e.secureConnectionStart > 0 ? e.connectEnd - e.secureConnectionStart : 0,
'Start:', e.startTime.toFixed(1));
}
}
}).observe({ type: 'resource', buffered: true });
</script>
Ich gleiche diese Daten mit Server-Logs und CDN-Statistiken (TLS-Resumption-Rate, HTTP/3-Anteil, Cache-Hits) ab. Wenn ich sehe, dass TLS fast immer resümiert, kann ich die Anzahl aktiver Preconnects reduzieren und Slots für Parser-Entdeckungen freigeben.
WordPress-Vertiefung: Core-Filter sauber nutzen
WordPress bringt bereits eine Infrastruktur für Resource Hints mit. Ich hänge mich an wp_resource_hints, statt selbst Roh-HTML zu drucken, und übergebe nur deduplizierte Ziele. Für Preload setze ich wp_enqueue_style/wp_enqueue_script und ergänze die richtigen as-Attribute über wp_style_add_data.
// Preconnect und DNS Prefetch via Core-Filter
add_filter('wp_resource_hints', function($urls, $relation_type) {
$critical = [
'preconnect' => ['https://fonts.gstatic.com', 'https://cdn.example.com'],
'dns-prefetch' => ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de']
];
if (!empty($critical[$relation_type])) {
foreach ($critical[$relation_type] as $u) {
if (!in_array($u, $urls, true)) { $urls[] = $u; }
}
}
return $urls;
}, 10, 2);
// Preload korrekt enqueuen
add_action('wp_enqueue_scripts', function() {
wp_enqueue_style('critical', get_stylesheet_directory_uri() . '/assets/css/critical.css', [], null);
wp_style_add_data('critical', 'preload', true);
wp_style_add_data('critical', 'as', 'style');
wp_register_style('font-inter', false);
wp_enqueue_style('font-inter');
add_action('wp_head', function() {
echo '<link rel="preload" as="font" href="' . esc_url(get_stylesheet_directory_uri() . '/assets/fonts/inter-regular.woff2') . '" type="font/woff2" crossorigin />' . "\n";
}, 2);
}, 1);
Zusätzlich achte ich darauf, dass Optimization-Plugins (defer, combine) Hints nicht hinter den Parser rutschen lassen. Nach Aktivierung teste ich, ob die Reihenfolge im Head erhalten bleibt und ob keine doppelten Preloads entstehen.
Fehlersuche und Anti-Patterns
- Zu viele Preconnects: Mehr als 3–5 Hosts verschwenden Sockets. Ich kürze auf die erstkritischen Ziele (Fonts/CDN/API).
- Falsches as/type: Ein
as="font"ohnetype="font/woff2"kann zu verfehlter Priorität oder doppeltem Request führen. - Unbenutzte Preloads: Jede nicht genutzte Ressource verstopft die Leitung. Ich entferne Preloads, die im Above-the-Fold nicht sicher gebraucht werden.
- Crossorigin vergessen: Bei Fonts oder fremden CDNs führt das zu CORS-Problemen und Cache-Verlust.
- HTML-Reihenfolge: Hints müssen an den Anfang des Head. Preloads vor Styles, dann Render-CSS, dann kritische JS.
- Imagesrcset ohne sizes: Ich ergänze
imagesizes, damit der Browser richtig wählt und Downloads schlank bleiben.
<link rel="preload" as="image" href="/assets/img/hero.webp"
imagesrcset="/assets/img/hero.webp 1x, /assets/img/[email protected] 2x"
imagesizes="(min-width: 1024px) 1200px, 100vw">
Priorisierung fundiert treffen
Ich entscheide anhand weniger Fragen: 1) Wird der Host/Asset garantiert früh gebraucht? 2) Wie hoch ist die Latenz (mobil, global, kaltes CDN)? 3) Gibt es Alternativen (Inline-CSS-Subset, Self-Hosting der Fonts)? 4) Ist die Verbindung wiederverwendbar (Coalescing, H3, Resumption)? 5) Beeinträchtigt die Maßnahme Parser-Entdeckungen? Daraus folgt: Prefetch für breite, günstige Gewinne; Preconnect selektiv für Warmups; Preload nur für garantiert benötigte Dateien mit sauberem Typing und korrekter Priorisierung.
Zusammenfassung in Kürze
Ich nutze DNS Prefetching für breite, günstige Latenzgewinne, Preconnect für wenige, aber zentrale Hosts und Preload für garantiert benötigte Dateien. Die Reihenfolge im Head und eine sparsame Auswahl liefern die größten Effekte. Ich messe jede Änderung, prüfe Wasserfälle und passe die Hint-Liste regelmäßig an. In Kombination mit HTTP/3, einem nahen CDN und schlauer Ressourcenpriorisierung hebe ich FCP und LCP sichtbar an. So setze ich browser optimization dns effektiv ein und steigere nachhaltig die Website Speed.
