DNS prefetching en preloading verkorten actief de tijd tot de eerste zichtbare inhoud door DNS, TCP en TLS vroegtijdig te activeren en kritieke bestanden vooraf aan te leveren. Ik zal je laten zien hoe je DNS-prefetching, Vooraf aansluiten en laden van de Snelheid website merkbaar - inclusief code, WordPress-installatie en beproefde prioriteiten.
Centrale punten
- DNS-prefetchVroegtijdige naamresolutie vermindert de latentie.
- VoorverbindingOpen vooraf DNS, TCP en TLS.
- Voorbelasting: Actief prioriteiten stellen bij kritieke bestanden.
- PrioriteringWeinig, maar beslissende domeinen.
- ControleControleer de effecten in de waterval.
DNS prefetching: kort uitgelegd
Met DNS-prefetching de browser lost het IP van een domein van tevoren op voordat een bestand wordt geladen, waardoor 20-250 ms per domein wordt bespaard - vooral op mobiele verbindingen met veel verkeer. Latency. Ik stel de hint in voor externe hosts die ik nodig heb in het gedeelte boven de vouw, bijvoorbeeld voor lettertypen, analytics of een CDN. De browser voert de DNS lookup op de achtergrond uit en verkort zo het kritieke pad naar de eerste rendering. Moderne browsers gebruiken prefetching soms automatisch, maar ik zorg voor het effect met een duidelijke hint in het hoofd. Dit vermindert rondreizen, stabiliseert de vroege renderstart en versnelt het renderproces. Kernwaarden Web Vitals.
Verschil: DNS prefetching vs. preconnect
Prefetch activeert alleen de DNS-namen, terwijl Preconnect ook de TCP- en TLS-handdruk opent en de verbinding warm houdt. Voor kritieke hosts, zoals een CDN voor render CSS of webfonts, geef ik de voorkeur aan Preconnect boven alleen Prefetch. Ik gebruik het spaarzaam, omdat elke open socket browserslots in beslag neemt. Het attribuut crossorigin behoort tot alle hosts met CORS zodat latere verzoeken niet worden vertraagd. Je vindt een duidelijk overzicht van de selectie en volgorde in de compacte Gids voor Prefetch.
Voorladen: Specifieke bestanden voorladen
Specifieke voorbelasting Bestanden actief in de cache voordat de parser ze meestal opvraagt, waardoor FCP en LCP sneller werken. Ik gebruik het alleen voor bronnen die absoluut nodig zijn, zoals kritieke CSS, hero afbeeldingen of WOFF2 lettertypen. Het attribuut haalprioriteit richt de weging naar boven zonder andere belangrijke overdrachten volledig te verdringen. Ik controleer of het MIME type, het as attribuut en het werkelijke gebruik overeenkomen, anders verlies ik bandbreedte. HTTP/3 is een goede toevoeging, zoals beschreven in het artikel op HTTP/3 en preload beschreven.
Prestatiewinst in de hostingopstelling
Een snelle Hosting vergroot het effect van de hints omdat lage RTT's, HTTP/3 en een CDN in de buurt de wachttijden per stap verkleinen. Ik zie TTFB regelmatig tot een seconde dalen als DNS, TCP en TLS voorverwarmd starten en de Origin snel reageert. Op mobiele apparaten met hoge latency betaalt dit zich dubbel en dwars terug, omdat elke bespaarde round trip direct naar de LCP gaat. Ik besteed aandacht aan stabiele TLS afhandeling, OCSP nieten en een slanke TLS configuratie. Op deze manier maakt de browser optimaal gebruik van zijn weinige gelijktijdige verbindingen en versnelt de Snelheid website.
Snelle vergelijking: welke technologie waarvoor?
De volgende tabel vat het effect, het gebruik en voorbeeldtags samen en helpt me om de juiste maatregel voor elke host te kiezen. Ik combineer prefetch voor de breedte, preconnect voor kritieke hosts en preload voor essentiële bestanden. Ik houd het aantal gelijktijdig openstaande verbindingen laag. Hierdoor blijft er genoeg ruimte over voor parserontdekkingen en laat-kritische assets. Dit overzicht maakt beslissingen over Prioritering eenvoudiger.
| Technologie | Wat gebeurt er? | Typisch gebruik | Voorbeeld tag | Invloed op FCP/LCP |
|---|---|---|---|---|
| DNS-prefetch | Vroeg Naam resolutie | Externe hosts met latere verzoeken | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Matig positief, afhankelijk van latentie |
| Voorverbinding | DNS + TCP + TLS voorverwarmen | CDN, lettertypen, cruciale API's | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Duidelijk positief, bespaart rondreizen |
| Voorbelasting | Bestand actief voorbelasting | Kritische CSS, WOFF2, Hero-afbeelding | <link rel="preload" as="style" href="/critical.css"> | Zeer positief, mits juist gekozen |
WordPress-integratie: schoon en onderhoudbaar
In WordPress stel ik de hints heel vroeg in de Hoofd, zodat de browser ze eerder ziet dan het knelpunt van de parser. Ik ontdubbel hosts, controleer de aanwezigheid van https en voeg crossorigin alleen indien nodig. De volgende code plaatst vermeldingen bovenaan, wat het effect maximaliseert. Ik controleer ook na implementaties of er nieuwe externe hosts zijn toegevoegd. Dit houdt de hintlijst slank, up-to-date en efficiënt.
functie add_dns_prefetch() {
$domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com'];
$printed = [];
foreach ($domains als $domain) {
$key = preg_replace('#^https?:#', '', $domain);
if (isset($printed[$key])) { doorgaan; }
$printed[$key] = true;
echo '' . "\n";
if (strpos($domain, 'https://') === 0) {
echo '' . "\n";
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1);
Beste praktijken: beknopt maar effectief
Ik beperk Preconnect tot drie tot vijf Hosts, Anders blokkeert de browser voortijdig te veel sockets. Ik plaats hints altijd aan het begin van de kop, gevolgd door preloads, dan stijlen en scripts. Voor lettertypen combineer ik Preconnect met lettertype-weergave: verwisselen, zodat tekst meteen verschijnt en CLS laag blijft. Ik zorg ervoor dat preloadbestanden gegarandeerd worden gebruikt, anders verspil ik bandbreedte en geef ik geen prioriteit aan wat nodig is. Voor scripts van derden controleer ik kritisch of elke Domein nodig is.
Meten en monitoren: succes zichtbaar maken
Op het tabblad Netwerk van de DevTools kijk ik naar de volgorde van DNS, TCP en TLS en controleer of ze eerder starten dan voorheen. Een voor en na vergelijking in de waterval laat duidelijk zien of de hints werken. Ik gebruik Lighthouse of PageSpeed Insights om FCP, LCP en CLS en de TTFB-trend te observeren. WebPageTest biedt ook een verbindingsweergave en filmstroken die de start van de render documenteren. Na grote veranderingen herhaal ik de meting en verwijder ik verouderde Hosts uit de Hint-lijst.
HTTP/3, QUIC en samenvoegen van verbindingen
Met HTTP/3 via QUIC bespaar ik extra Retourvluchten, omdat het opzetten van verbindingen, het afhandelen van verliezen en multiplexen efficiënter werken. Ik controleer of mijn CDN en mijn Origin HTTP/3 aanbieden en blijf Preconnect selectief gebruiken. Connection coalescing vermindert het aantal aparte verbindingen als certificaten en IP's overeenkomen. Hierdoor kunnen hosts met hetzelfde certificaat meerdere subdomeinen bedienen via een gedeelde Aansluiting. Over het algemeen heeft het vroege renderpad aanzienlijk voordeel, vooral bij veel kleine bestanden.
CDN warmup en prefetch combineren
Ik verwarm mijn CDN wanneer ik pieken in het verkeer verwacht en combineer dit met Prefetch en Preconnect voor Edge hosts. Dit betekent dat belangrijke objecten worden opgeslagen in de edge cache en dat de handshakes al zijn voorbereid. Dit vermindert latencies, vooral bij initiële gesprekken en onder mobiele omstandigheden. Praktische instructies zijn te vinden in het artikel op CDN-opwarming, die ik graag gebruik als checklist. Voor de uitrol test ik de cache-hit rates en observeer ik de TTFB-ontwikkeling.
Bestuur: Hintlijst actueel houden
Ik leid een korte Inventaris van alle externe hosts en controleer elk kwartaal of er nieuwe scripts, lettertypen of afbeeldingen zijn toegevoegd. Ik verwijder verwijderde integraties samen met de hint om de lijst compact te houden. Voor elke host noteer ik het doel, de kriticiteit en de gebruikte technologie (prefetch, preconnect of preload). Ik voer wijzigingen aan het CDN of de fonts onmiddellijk in zodat er geen verweesde vermeldingen achterblijven. Zo behoud ik de controle, verlaag ik de overheadkosten en zorg ik voor een consistente Prestaties.
Browserondersteuning, heuristieken en beperkingen
Ik bereken dat browser hints als Signalen niet als opdracht. Bij lage bandbreedte, een actieve datasaver of een tabblad op de achtergrond kan de browser prioriteiten aanpassen of hints afknijpen. Safari is conservatiever met preconnects, Firefox heeft in sommige gevallen andere heuristieken voor DNS-caches en mobiele varianten verminderen parallelle sockets. Daarom formuleer ik hints nauwkeurig en oversignalering te voorkomen: een klein aantal hosts, duidelijke als-waarden, correct type-informatie. Voor lettertypen let ik op crossorigin, Anders is er een risico op dubbele fetches of late CORS-blokkering. Als ik prefetch volledig wil controleren, kan ik het volgende gebruiken <meta http-equiv="x-dns-prefetch-control" content="on"> of uit de automatische heuristieken beïnvloeden.
HTTP-header en 103 vroege hints
Naast HTML-tags gebruik ik Link koptekst, zodat hints binnenkomen met het eerste serverantwoord - ideaal voor rendering aan de serverkant. 103 Early Hints verzenden zelfs deze headers voor van het uiteindelijke antwoord 200 en winnen zo tientallen milliseconden op lange lijnen.
# NGINX: Preconnect en preload via link header
add_header Link '; rel=preconnect; crossorigin' altijd;
add_header Link '; rel=preload; as=style; fetchpriority=high' altijd;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' altijd;
# Apache (htaccess)
Header toevoegen Link '; rel=preconnect; crossorigin'.
Header toevoegen link '; rel=preload; as=image'
Ondersteunt de server 103 Vroege hints, Ik stuur de linkheaders ook eerder. Belangrijk: ik bewaar de lijst korte, omdat elke invoer parsing inspanning en potentiële verbindingsopeningen genereert.
SPA en Service Worker: route en gegevens prefetchen
Voor apps met één pagina verplaats ik hints op de toestand gebaseerdZodra de held zichtbaar is, start ik een gerichte preload voor de volgende route (JS chunk, kritieke afbeelding, API schema). In de Service Worker kan ik preloadresultaten cachen en gebruiken na navigatiegebeurtenissen. Ik definieer duidelijke annuleringscriteria (tabblad verborgen, CPU overbelast, zwak netwerk) zodat prefetch geen kostendrijver wordt. Voor ES modules stel ik vroegtijdig modulepreload, zodat de afhankelijkheidsketen niet vertraagt.
<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>
Beveiliging, gegevensbescherming en richtlijnen
Ik beschouw beleidskaders: een strikt CSP kan voorbelastingen blokkeren als lettertype-src, stijl-src of afbeeldingsbron de doelen niet toestaan. crossorigin is verplicht voor lettertypen, anders werkt de cache niet bij alle herkomsten. Ik maak geen preconnectie met gevoelige derden als ik het domein in de toekomst zou kunnen verwijderen - elke hint is een signaal naar de browser en kan volgscripts versnellen. Ik controleer ook Gegevens opslaan en GegevensbesparingIn deze modi verminder ik de agressiviteit van preloads en laat ik DNS prefetch alleen actief voor centrale hosts.
Meetpraktijk verdiepen: Timing API en logs
Naast watervallen gebruik ik de Hulpbron Timing API en PrestatieObserverom in het veld om te meten of hints voor de parser terechtkomen en hoe domeinLookupStart, connectStart en secureConnectionStart verplaatsen. Hierdoor kan ik herkennen of een Preconnect echt is gebruikt of is afgewezen door de browser.
<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>
Ik vergelijk deze gegevens met serverlogs en CDN statistieken (TLS hervattingspercentage, HTTP/3 aandeel, cache hits). Als ik zie dat TLS bijna altijd wordt hervat, kan ik het aantal actieve preconnects verminderen en slots vrijmaken voor parser detecties.
WordPress diepgaand: kernfilters schoon gebruiken
WordPress heeft al een infrastructuur voor resource hints. Ik hecht me aan wp_resource_hints, in plaats van zelf ruwe HTML af te drukken en alleen ontdubbelde doelen door te geven. Voor preload stel ik wp_enqueue_stijl/wp_enqueue_script en voeg de juiste als-attributen via wp_stijl_toevoegen_gegevens.
// Preconnect en DNS prefetch via kernfilter
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 correct enqueue
add_action('wp_enqueue_scripts', function() {
wp_enqueue_style('kritisch', get_stylesheet_directory_uri() . '/assets/css/critical.css', [], null);
wp_style_add_data('critical', 'preload', true);
wp_style_add_data('kritisch', 'als', 'stijl');
wp_register_style('font-inter', false);
wp_enqueue_style('font-inter');
add_action('wp_head', function() {
echo '' . "\n";
}, 2);
}, 1);
Ik zorg er ook voor dat optimalisatieplugins (uitstellen, combineren) Laat geen hints wegglippen achter de parser. Na activering test ik of de volgorde in de kop behouden blijft en of er geen dubbele preloads zijn.
Probleemoplossing en antipatronen
- Te veel preconnectsMeer dan 3-5 hosts verspillen sockets. Ik verkort tot de eerste kritiek Doelen (lettertypen/CDN/API).
- Verkeerd als/type: A
as="lettertype"zondertype="font/woff2"kan leiden tot onjuiste prioriteit of dubbele verzoeken. - Ongebruikte voorbelastingElke ongebruikte bron verstopt de lijn. Ik verwijder preloads die niet veilig worden gebruikt in de above-the-fold.
- Crossorigin vergeten: Met lettertypen of externe CDN's leidt dit tot CORS-problemen en cacheverlies.
- HTML-bestellingHints moeten aan het begin van de head worden geplaatst. Preloads voor stijlen, dan CSS renderen, dan kritische JS.
- Imagesrcset zonder afmetingenIk voeg toe
afbeeldingsformaten, zodat de browser correct selecteert en de downloads slank blijven.
<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">
Gefundeerde prioriteiten stellen
Ik beslis op basis van een paar vragen: 1) Is de host/asset gegarandeerd vroeg nodig? 2) Hoe hoog is de latentie (mobiel, wereldwijd, koud CDN)? 3) Zijn er alternatieven? (inline CSS-subset, zelf hosten van lettertypen)? 4) Is de verbinding herbruikbaar (coalescing, H3, hervatting)? 5) Onvoldoende de maatregel parser ontdekkingen? Het volgt: Prefetch voor brede, gunstige winsten; preconnect selectief voor warmups; preload alleen voor gegarandeerd vereiste bestanden met schone typografie en correcte prioritering.
Samenvatting in het kort
Ik gebruik DNS Prefetching voor brede, gunstige latencywinsten, preconnect voor een paar maar centrale hosts en preload voor bestanden die gegarandeerd nodig zijn. De volgorde in het hoofd en een spaarzame selectie leveren de grootste effecten op. Ik meet elke verandering, controleer watervallen en pas de hintlijst regelmatig aan. In combinatie met HTTP/3, een CDN in de buurt en slimme resourceprioritering verhoog ik FCP en LCP zichtbaar. Dit is hoe ik dns met browseroptimalisatie effectief en duurzaam verhoog. Snelheid website.
