Hoppa till innehåll 
DNS prefetching och preloading förkortar aktivt tiden till första synliga innehåll genom att utlösa DNS, TCP och TLS tidigt och tillhandahålla kritiska filer i förväg. Jag kommer att visa dig hur du använder DNS-förhämtning, Förkoppling och förladdning av Webbplatsens hastighet märkbart - inklusive kod, WordPress-installation och beprövade prioriteringar.
Centrala punkter
- DNS-förhämtningTidig namnlösning minskar latenstiden.
- FörkopplaÖppna DNS, TCP och TLS i förväg.
- Förspänning: Aktivt prioritera kritiska filer.
- PrioriteringFå, men avgörande domäner.
- ÖvervakningKontrollera effekterna i vattenfallet.
DNS prefetching: kortfattad förklaring
Med DNS-förhämtning webbläsaren löser IP-adressen för en domän i förväg innan en fil laddas, vilket sparar 20-250 ms per domän - särskilt på mobila anslutningar med hög trafik. Fördröjning. Jag ställer in tipset för externa värdar som jag behöver i området ovanför fliken, till exempel för teckensnitt, analys eller ett CDN. Webbläsaren utför DNS-uppslagningen i bakgrunden och förkortar därmed den kritiska vägen till den första renderingen. Moderna webbläsare använder ibland prefetching automatiskt, men jag säkerställer effekten med en tydlig ledtråd i huvudet. Detta minskar antalet rundresor, stabiliserar den tidiga renderingsstarten och snabbar upp renderingsprocessen. Core Web Vitals.
Skillnad: DNS prefetching vs. preconnect
Prefetch utlöser endast DNS-namn, medan Preconnect också öppnar TCP- och TLS-handskakningen och håller anslutningen varm. För kritiska värdar, t.ex. ett CDN för rendering av CSS eller webbteckensnitt, föredrar jag Preconnect framför bara Prefetch. Jag använder det sparsamt, eftersom varje öppet uttag upptar webbläsarplatser. Attributet Crossorigin tillhör alla värdar med CORS så att senare förfrågningar inte saktas ner. Du kan hitta en tydlig översikt över urvalet och sekvensen i den kompakta Guide till Prefetch.
Förhandsladdning: Förhandsladdning av specifika filer
Förbelastning belastar specifikt Filer aktivt i cacheminnet innan parsern vanligtvis begär dem, vilket påskyndar FCP och LCP. Jag använder det bara för resurser som definitivt behövs, t.ex. kritisk CSS, hjältebilder eller WOFF2-teckensnitt. Attributet hämtningsprioritet styr viktningen uppåt utan att helt tränga undan andra viktiga överföringar. Jag kontrollerar att MIME-typen, as-attributet och den faktiska användningen matchar, annars förlorar jag bandbredd. HTTP/3 är ett bra komplement, som beskrivs i artikeln om HTTP/3 och förladdning beskriven.
Prestandaförbättring i hosting-installationen
En snabb Hosting ökar effekten av tipsen eftersom låga RTT:er, HTTP/3 och ett närliggande CDN minskar väntetiderna per steg. Jag ser regelbundet att TTFB sjunker med upp till en sekund när DNS, TCP och TLS börjar förvärmas och Origin svarar snabbt. På mobila enheter med hög latens lönar det sig dubbelt eftersom varje sparad tur- och returresa går direkt till LCP. Jag är uppmärksam på stabil TLS-hantering, OCSP-häftning och en slimmad TLS-konfiguration. På så sätt utnyttjar webbläsaren sina få samtidiga anslutningar optimalt och snabbar upp Webbplatsens hastighet.
Snabb jämförelse: vilken teknik för vad?
Följande tabell sammanfattar taggarna för effekt, användning och exempel och hjälper mig att välja rätt åtgärd för varje host. Jag kombinerar prefetch för bredd, preconnect för kritiska värdar och preload för viktiga filer. Jag håller antalet samtidigt öppna anslutningar lågt. Detta lämnar tillräckligt med utrymme för parserupptäckter och sent kritiska tillgångar. Den här översikten fattar beslut om Prioritering lättare.
| Teknik | Vad händer? | Typisk användning | Exempel på tagg | Påverkan på FCP/LCP |
|---|---|---|---|---|
| DNS-förhämtning | Tidig Namnupplösning | Externa värdar med senare förfrågningar | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Måttligt positiv, beroende på latenstid |
| Förkoppla | DNS + TCP + DNS + TCP TLS förvärma | CDN, teckensnitt, kritiska API:er | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Klart positivt, sparar rundresor |
| Förspänning | Fil aktiv förladdning | Kritisk CSS, WOFF2, Hero-Image | <link rel="preload" as="style" href="/critical.css"> | Mycket positivt, om det väljs rätt |
WordPress-integration: ren och underhållsbar
I WordPress sätter jag ledtrådarna mycket tidigt i Head, så att webbläsaren ser dem före flaskhalsen i parsern. Jag deduplicerar värdar, kontrollerar förekomsten av https och lägger till Crossorigin endast om det behövs. Följande kod placerar posterna högst upp, vilket maximerar effekten. Jag kontrollerar också efter driftsättningar om nya externa värdar har lagts till. Detta håller hint-listan smal, uppdaterad och effektiv.
funktion 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])) { fortsätt; }
$printed[$key] = true;
echo '' . "\n";
if (strpos($domain, 'https://') === 0) {
echo '' . "\n";
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1);
Bästa praxis: kortfattad men effektiv
Jag begränsar Preconnect till tre till fem Värdar, annars kommer webbläsaren att blockera för många uttag i förtid. Jag placerar alltid hintar i början av huvudet, följt av förladdningar, sedan stilar och skript. För typsnitt kombinerar jag Preconnect med teckensnittsvisning: swap, så att texten visas omedelbart och CLS förblir låg. Jag ser till att förladdade filer garanterat används, annars slösar jag med bandbredd och prioriterar inte det som behövs. För skript från tredje part kontrollerar jag kritiskt om varje Domän är nödvändigt.
Mätning och övervakning: att synliggöra framgång
På fliken Network i DevTools tittar jag på ordningen för DNS, TCP och TLS och kontrollera om de startar tidigare än tidigare. En före- och efterjämförelse i vattenfallet visar tydligt om tipsen fungerar. Jag använder Lighthouse eller PageSpeed Insights för att observera FCP, LCP och CLS samt TTFB-trenden. WebPageTest ger också en anslutningsvy och filmremsor som dokumenterar renderingsstarten. Efter större förändringar upprepar jag mätningen och tar bort föråldrade Värdar från listan med tips.
HTTP/3, QUIC och sammanslagning av anslutningar
Med HTTP/3 via QUIC sparar jag ytterligare Rundresor, eftersom anslutningsinställning, förlusthantering och multiplexering fungerar mer effektivt. Jag kontrollerar om mitt CDN och min Origin erbjuder HTTP/3 och fortsätter att använda Preconnect selektivt. Connection coalescing minskar antalet separata anslutningar om certifikat och IP-adresser matchar. Detta gör att värdar med samma certifikat kan betjäna flera underdomäner via en gemensam Anslutning. Sammantaget ger den tidiga renderingsvägen betydande fördelar, särskilt med många små filer.
Kombinera CDN-uppvärmning och prefetch
Jag värmer upp mitt CDN när jag förväntar mig trafiktoppar och kombinerar detta med Förhämtning och Preconnect för Edge-värdar. Detta innebär att viktiga objekt lagras i edge-cachen och att handskakningarna redan är förberedda. Detta minskar latenserna, särskilt vid inledande samtal och under mobila förhållanden. Praktiska instruktioner finns i artikeln om CDN-uppvärmning, som jag gillar att använda som en checklista. Före utrullningen testar jag träfffrekvensen i cacheminnet och observerar TTFB-utveckling.
Styrning: Håll hint-listan uppdaterad
Jag leder en kort Inventarieförteckning av alla externa värdar och kontrollerar kvartalsvis om nya skript, teckensnitt eller bilder har lagts till. Jag tar bort borttagna integrationer tillsammans med tipset för att hålla listan smal. För varje host noterar jag syfte, kritikalitet och vilken teknik som används (prefetch, preconnect eller preload). Jag anger ändringar i CDN eller fonts omedelbart så att inga föräldralösa poster lämnas kvar. Detta gör att jag kan behålla kontrollen, minska omkostnaderna och säkerställa en konsekvent Prestanda.
Stöd för webbläsare, heuristik och begränsningar
Jag beräknar att webbläsaren tipsar som Signaler inte som ett kommando. Med låg bandbredd, en aktiv datasparare eller i bakgrundsfliken kan webbläsaren justera prioriteringar eller strypa tips. Safari är mer konservativ med föranslutningar, Firefox har olika heuristik för DNS-cacher i vissa fall och mobilvarianter minskar parallella uttag. Det är därför jag formulerar tips precis och undvika översignalering: ett litet antal värdar, tydliga som-värden, korrekt typ-information. För teckensnitt är jag uppmärksam på Crossorigin, annars finns det risk för dubbla hämtningar eller sen CORS-blockering. Om jag vill kontrollera prefetch helt kan jag använda <meta http-equiv="x-dns-prefetch-control" content="on"> eller . av påverka den automatiska heuristiken.
HTTP-rubrik och 103 tidiga ledtrådar
Förutom HTML-taggar använder jag Länkhuvud, så att ledtrådarna kommer med det första serversvaret - perfekt för rendering på serversidan. 103 Early Hints skickar även dessa headers före av det slutliga 200-svaret och vinner därmed dussintals millisekunder på långa linjer.
# NGINX: Föranslutning och förladdning via länkhuvud
add_header Länk '; rel=preconnect; crossorigin' alltid;
add_header Länk '; rel=preload; as=style; fetchpriority=high' alltid;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' alltid;
# Apache (htaccess)
Huvudsida lägg till länk '; rel=preconnect; crossorigin'
Huvuden lägg till länk '; rel=preload; as=image'
Har servern stöd för 103 Tidiga antydningar, Jag skickar också länkrubrikerna tidigt. Viktigt: Jag behåller listan kort, eftersom varje post genererar analysarbete och potentiella anslutningsmöjligheter.
SPA och Service Worker: prefetch av rutt och data
För appar med en sida flyttar jag hintar tillståndsbaseradSå snart hjälten är synlig startar jag en riktad förladdning för nästa rutt (JS-chunk, kritisk bild, API-schema). I Service Worker kan jag cachelagra förladdningsresultat och använda dem efter navigeringshändelser. Jag definierar tydliga avbrytandekriterier (dold flik, överbelastad CPU, svagt nätverk) så att prefetch inte blir en kostnadsdrivare. För ES-moduler ställer jag in tidig modulförladdning, så att beroendekedjan inte saktar ner.
.
// Försiktig SPA-förladdning
if (navigator.connection?.saveData !.== true) {
const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 300));
idle(() => {
const l = document.createElement('link');
l.rel = 'förladdning';
l.as = 'skript';
l.href = '/assets/js/route-checkout.js';
document.head.appendChild(l);
});
}
Säkerhet, dataskydd och riktlinjer
Jag överväger policyramverk: ett strikt CSP kan blockera förladdningar om typsnitt-src, stil-src eller . img-src tillåt inte målen. Crossorigin är obligatoriskt för teckensnitt, annars fungerar inte cachen från alla ursprung. Med känsliga tredje parter sprider jag inte några föranslutningar om jag kan ta bort domänen i framtiden - varje ledtråd är en signal till webbläsaren och kan påskynda spårningsskript. Jag kontrollerar också Spara data och DatasparareI de här lägena minskar jag aggressiviteten i förladdningarna och låter bara DNS prefetch vara aktiv för centrala värdar.
Fördjupa mätmetoderna: API och loggar för tidsinställning
Förutom vattenfall använder jag mig av API för tidsinställning av resurser och Prestationsobservatörtill i fält för att mäta om ledtrådar hamnar framför parsern och hur domänLookupStart, AnslutStart och säkerAnslutningStart flytta. På så sätt kan jag se om en Preconnect verkligen har använts eller om den har avvisats av webbläsaren.
.
Jag jämför dessa data med serverloggar och CDN-statistik (TLS återupptagningsfrekvens, HTTP/3-andel, cacheträffar). Om jag ser att TLS nästan alltid återupptas kan jag minska antalet aktiva föranslutningar och frigöra platser för parserdetektering.
WordPress på djupet: ren användning av kärnfilter
WordPress har redan en infrastruktur för resurstips. Jag ansluter mig själv till wp_resource_hints, istället för att skriva ut rå HTML själv, och bara skicka deduplicerade mål. För förladdning ställer jag in wp_enqueue_style/wp_enqueue_script och lägg till rätt som-attribut via wp_style_lägg_till_data.
// Förhandskoppling och DNS-förhandshämtning via kärnfilter
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);
// Förhandsladdning av Enqueue korrekt
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 '' . "\n";
}, 2);
}, 1);
Jag ser också till att optimeringsplugins (skjuta upp, kombinera) Låt inte ledtrådar slinka bakom parsern. Efter aktivering testar jag om ordningen i huvudet bibehålls och om det inte finns några duplicerade förladdningar.
Felsökning och anti-patterns
- För många förhandsanslutningar: Mer än 3-5 värdar slösar bort uttag. Jag förkortar till första kritiska Mål (teckensnitt/CDN/API).
- Felaktig som/typ: A
as="font"utantyp="font/woff2"kan leda till felaktig prioritering eller dubbla förfrågningar. - Oanvända förbelastningarVarje oanvänd resurs blockerar linjen. Jag tar bort förladdningar som inte används på ett säkert sätt i above-the-fold.
- Crossorigin bortglömd: Med teckensnitt eller externa CDN:er leder detta till CORS-problem och cacheförlust.
- HTML-orderHints måste placeras i början av huvudet. Förladdar före stilar, renderar sedan CSS, sedan kritisk JS.
- Imagesrcset utan storlekarJag lägger till
bildstorlekar, så att webbläsaren väljer rätt och nedladdningarna förblir smidiga.
<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">
Gör välgrundade prioriteringar
Jag fattar beslut på grundval av några frågor: 1) Är värden/tillgångarna garanterade tidigt behövs? 2) Hur hög är latensen (mobil, global, kall CDN)? 3) Finns det alternativ (inline CSS-subset, self-hosting av teckensnitt)? 4) Är anslutningen återanvändbar (sammansmältning, H3, återupptagande)? 5) Nedskrivna upptäcker mätparsern? Det är följande: Prefetch för breda, gynnsamma vinster; preconnect selektivt för uppvärmningar; preload endast för garanterad nödvändiga filer med rent skrivande och korrekt prioritering.
Sammanfattning i korthet
Jag använder DNS Prefetching för breda, gynnsamma latensvinster, preconnect för ett fåtal men centrala värdar och preload för filer som garanterat kommer att behövas. Sekvensen i huvudet och ett sparsamt urval ger de största effekterna. Jag mäter varje förändring, kontrollerar vattenfall och justerar hint-listan regelbundet. I kombination med HTTP/3, ett närliggande CDN och smart resursprioritering ökar jag FCP och LCP på ett synligt sätt. Så här använder jag webbläsaroptimering dns effektivt och hållbart för att öka Webbplatsens hastighet.
