...
webhosting-logo

DNS prefetching og preloading: optimering af hjemmesidens hastighed

DNS prefetching og preloading forkorter aktivt tiden til første synlige indhold ved at udløse DNS, TCP og TLS tidligt og levere kritiske filer på forhånd. Jeg vil vise dig, hvordan du bruger DNS-forhåndshentning, Forbind og forudindlæsning af Hjemmesidens hastighed mærkbart - inklusive kode, WordPress-opsætning og afprøvede prioriteter.

Centrale punkter

  • DNS-forhåndshentningTidlig navneopløsning reducerer ventetiden.
  • ForbindelseÅbn DNS, TCP og TLS på forhånd.
  • Forspænding: Prioriterer aktivt kritiske filer.
  • PrioriteringFå, men afgørende domæner.
  • OvervågningTjek effekter i vandfaldet.

DNS prefetching: kort forklaret

Med DNS-forhåndshentning Browseren opløser et domænes IP på forhånd, før den indlæser en fil, hvilket sparer 20-250 ms pr. domæne - især på mobile forbindelser med høj trafik. Forsinkelse. Jeg indstiller hintet til eksterne hosts, som jeg har brug for i above-the-fold-området, f.eks. til skrifttyper, analyser eller et CDN. Browseren udfører DNS-opslaget i baggrunden og forkorter dermed den kritiske vej til den første rendering. Moderne browsere bruger nogle gange prefetching automatisk, men jeg sikrer effekten med et klart hint i hovedet. Det reducerer round trips, stabiliserer den tidlige renderingsstart og fremskynder renderingsprocessen. Core Web Vitals.

.

Forskel: DNS prefetching vs. preconnect

Prefetch udløser kun DNS-navne, mens Preconnect også åbner TCP- og TLS-håndtrykket og holder forbindelsen varm. Til kritiske værter, som f.eks. et CDN til rendering af CSS eller webfonte, foretrækker jeg Preconnect frem for bare Prefetch. Jeg bruger det sparsomt, da hver åben socket optager plads i browseren. Attributten crossorigin tilhører alle værter med CORS, så senere anmodninger ikke bliver bremset. Du kan finde en klar oversigt over udvælgelsen og rækkefølgen i den kompakte Guide til Prefetch.

.
.

Preloading: Preloading af specifikke filer

Forudindlæsning af specifikke belastninger Filer aktivt i cachen, før parseren normalt anmoder om dem, hvilket gør FCP og LCP hurtigere. Jeg bruger det kun til ressourcer, der er absolut nødvendige, som f.eks. kritisk CSS, heltebilleder eller WOFF2-skrifttyper. Attributten hentningsprioritet styrer vægtningen opad uden helt at fortrænge andre vigtige overførsler. Jeg tjekker, at MIME-typen, as-attributten og den faktiske brug stemmer overens, ellers mister jeg båndbredde. HTTP/3 er en god tilføjelse, som beskrevet i artiklen om HTTP/3 og forhåndsindlæsning beskrevet.

.

Øget ydeevne i hosting-opsætningen

En hurtig Hosting øger effekten af hints, fordi lave RTT'er, HTTP/3 og et nærliggende CDN reducerer ventetiden pr. trin. Jeg ser jævnligt TTFB falde med op til et sekund, når DNS, TCP og TLS starter forvarmet, og Origin reagerer hurtigt. På mobile enheder med høj latenstid betaler det sig dobbelt, fordi hver sparet roundtrip går direkte ind i LCP'en. Jeg er opmærksom på stabil TLS-håndtering, OCSP-hæftning og en slank TLS-konfiguration. På den måde udnytter browseren sine få samtidige forbindelser optimalt og gør processen hurtigere. Hjemmesidens hastighed.

Hurtig sammenligning: hvilken teknologi til hvad?

Følgende tabel opsummerer effekten, brugen og eksempler på tags og hjælper mig med at vælge den rigtige foranstaltning til hver enkelt host. Jeg kombinerer prefetch til bredde, preconnect til kritiske værter og preload til vigtige filer. Jeg holder antallet af samtidige åbne forbindelser lavt. Det giver plads nok til parser-opdagelser og sent kritiske aktiver. Denne oversigt træffer beslutninger om Prioritering lettere.

Teknologi Hvad sker der? Typisk brug Eksempel på tag Indvirkning på FCP/LCP
DNS-forhåndshentning Tidlig Opløsning af navn Eksterne værter med senere anmodninger <link rel="dns-prefetch" href="//fonts.googleapis.com"> Moderat positiv, afhængigt af ventetid
Forbindelse DNS + TCP +. TLS forvarme CDN, skrifttyper, kritiske API'er <link rel="preconnect" href="https://cdn.example.com" crossorigin> Klart positivt, sparer rundture
Forspænding Fil aktiv forspænding Kritisk CSS, WOFF2, Hero-Image <link rel="preload" as="style" href="/critical.css"> Meget positivt, hvis man vælger rigtigt

WordPress-integration: ren og vedligeholdelsesvenlig

I WordPress sætter jeg hints meget tidligt i processen. Hoved, så browseren ser dem før parser-flaskehalsen. Jeg deduplikerer hosts, tjekker tilstedeværelsen af https og tilføjer crossorigin kun hvis det er nødvendigt. Den følgende kode placerer poster øverst, hvilket maksimerer effekten. Jeg tjekker også efter implementeringer, om der er tilføjet nye eksterne værter. Dette holder hint-listen slank, opdateret og 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æt; }
        $printed[$key] = true;
        echo '' . "\n";
        if (strpos($domain, 'https://') === 0) {
            echo '' . "\n";
        }
    }
}
add_action('wp_head', 'add_dns_prefetch', 1);

Bedste praksis: kortfattet, men effektivt

Jeg begrænser Preconnect til tre til fem Værter, Ellers vil browseren blokere for mange sockets for tidligt. Jeg placerer altid hints i begyndelsen af hovedet, efterfulgt af preloads, så styles og scripts. Til skrifttyper kombinerer jeg Preconnect med font-display: swap, så teksten vises med det samme, og CLS forbliver lav. Jeg sørger for, at der er garanti for, at preload-filer bliver brugt, ellers spilder jeg båndbredde og prioriterer ikke det, der er brug for. For tredjeparts-scripts tjekker jeg kritisk, om alle Domæne er nødvendigt.

Måling og overvågning: Gør succesen synlig

På fanen Network i DevTools ser jeg på rækkefølgen af DNS, TCP og TLS og tjekke, om de starter tidligere end før. En før- og eftersammenligning i vandfaldet viser tydeligt, om hintsene virker. Jeg bruger Lighthouse eller PageSpeed Insights til at observere FCP, LCP og CLS samt TTFB-tendensen. WebPageTest giver også en forbindelsesvisning og filmstrimler, der dokumenterer renderingsstarten. Efter større ændringer gentager jeg målingen og fjerner forældede Værter fra listen med hints.

HTTP/3, QUIC og sammensmeltning af forbindelser

Med HTTP/3 via QUIC sparer jeg yderligere Rundrejser, fordi forbindelsesopsætning, tabshåndtering og multiplexing fungerer mere effektivt. Jeg tjekker, om mit CDN og min Origin tilbyder HTTP/3 og fortsætter med at bruge Preconnect selektivt. Connection coalescing reducerer antallet af separate forbindelser, hvis certifikater og IP'er matcher. Det gør det muligt for værter med samme certifikat at betjene flere underdomæner via en delt Forbindelse. Alt i alt er der store fordele ved den tidlige renderingsvej, især med mange små filer.

Kombiner CDN-opvarmning og prefetch

Jeg varmer mit CDN op, når jeg forventer trafikspidser, og kombinerer det med Prefetch og Preconnect til Edge-værter. Det betyder, at vigtige objekter gemmes i edge-cachen, og at håndtryk allerede er forberedt. Det reducerer ventetiden, især ved de første opkald og under mobile forhold. Praktiske instruktioner kan findes i artiklen om CDN-opvarmning, som jeg kan lide at bruge som en tjekliste. Før udrulning tester jeg cache-hitrater og observerer TTFB-udvikling.

Styring: Hold hint-listen opdateret

Jeg leder en kort Inventar af alle eksterne hosts og tjekker hvert kvartal, om der er tilføjet nye scripts, skrifttyper eller billeder. Jeg sletter fjernede integrationer sammen med hintet for at holde listen slank. For hver host noterer jeg formålet, kritikaliteten og den anvendte teknologi (prefetch, preconnect eller preload). Jeg indtaster ændringer i CDN eller fonts med det samme, så der ikke efterlades forældreløse poster. Det giver mig mulighed for at bevare kontrollen, reducere overhead og sikre en konsekvent Ydelse.

Browser-understøttelse, heuristik og begrænsninger

Jeg beregner browserens hints som Signaler ikke som en kommando. Med lav båndbredde, en aktiv datasparer eller i baggrundsfanen kan browseren justere prioriteter eller drosle hints. Safari er mere konservativ med preconnects, Firefox har i nogle tilfælde en anden heuristik for DNS-caches, og mobilvarianter reducerer parallelle sockets. Det er derfor, jeg formulerer hints præcis og undgå oversignalering: et lille antal værter, klare som-værdier, korrekt type-...information. For skrifttyper er jeg opmærksom på crossorigin, Ellers er der risiko for dobbelt hentning eller sen CORS-blokering. Hvis jeg vil kontrollere prefetch fuldstændigt, kan jeg bruge . eller af påvirke den automatiske heuristik.

HTTP-header og 103 tidlige hints

Udover HTML-tags bruger jeg Link-overskrift, så hints flyver ind med det første serversvar - ideelt til rendering på serversiden. 103 Early Hints sender endda disse headere før af det endelige 200-svar og dermed vinde dusinvis af millisekunder på lange linjer.

# NGINX: Preconnect og preload via link-header
add_header Link '; rel=preconnect; crossorigin' altid;
add_header Link '; rel=preload; as=style; fetchpriority=high' altid;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' altid;

# Apache (htaccess)
Header add Link '; rel=preconnect; crossorigin'
Header add link '; rel=preload; as=image'

Understøtter serveren 103 Tidlige hints, Jeg sender også linkoverskrifterne tidligt. Vigtigt: Jeg beholder listen kort, fordi hver post genererer analysearbejde og potentielle forbindelsesåbninger.

SPA og Service Worker: prefetch af ruter og data

Til apps med én side flytter jeg hints tilstandsbaseretSå snart helten er synlig, starter jeg en målrettet forudindlæsning af den næste rute (JS-klump, kritisk billede, API-skema). I Service Worker kan jeg cache preload-resultater og bruge dem efter navigationshændelser. Jeg definerer klare aflysningskriterier (skjult fane, overbelastet CPU, svagt netværk), så prefetch ikke bliver en omkostningsdriver. For ES-moduler indstiller jeg tidlig modulforindlæsning, så afhængighedskæden ikke bliver langsommere.

.
.

Sikkerhed, databeskyttelse og retningslinjer

Jeg overvejer politiske rammer: en streng CSP kan blokere forindlæsninger, hvis font-src, style-src eller img-src Tillad ikke målene. crossorigin er obligatorisk for skrifttyper, ellers vil cachen ikke fungere på tværs af alle oprindelser. Med følsomme tredjeparter spreder jeg ikke nogen pre-connects, hvis jeg kan fjerne domænet i fremtiden - ethvert hint er et signal til browseren og kan fremskynde sporingsscripts. Jeg tjekker også Gemme data og DatasparerI disse tilstande reducerer jeg aggressiviteten af preloads og lader kun DNS prefetch være aktiv for centrale værter.

Uddyb målepraksis: Timing af API og logfiler

Ud over vandfald bruger jeg API til ressource-timing og PerformanceObservertil i marken for at måle, om hints lander foran parseren, og hvordan domainLookupStart, connectStart og secureConnectionStart flytte. På den måde kan jeg se, om en Preconnect virkelig er blevet brugt, eller om den er blevet afvist af browseren.

.

Jeg sammenligner disse data med serverlogs og CDN-statistikker (TLS-genoptagelsesrate, HTTP/3-andel, cache-hits). Hvis jeg kan se, at TLS næsten altid genoptages, kan jeg reducere antallet af aktive preconnects og frigive slots til parserdetektioner.

WordPress i dybden: Brug kernefiltre rent

WordPress kommer allerede med en infrastruktur til ressourcehints. Jeg knytter mig til wp_resource_hints, i stedet for selv at udskrive rå HTML og kun sende deduplikerede mål. Til forudindlæsning sætter jeg wp_enqueue_style/wp_enqueue_script og tilføj den korrekte som-attributter via wp_style_add_data.

// Preconnect og DNS prefetch via kernefilter
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);

// Enqueue-preload 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);

Jeg sørger også for, at optimeringsplugins (udsætte, kombinere) Lad ikke hints glide ind bag parseren. Efter aktivering tester jeg, om rækkefølgen i hovedet er bevaret, og om der ikke er nogen dobbelte preloads.

Fejlfinding og anti-mønstre

  • For mange forudgående forbindelser: Mere end 3-5 værter spilder stikkontakter. Jeg forkorter til første kritiske Mål (skrifttyper/CDN/API).
  • Forkert som/type: A as="font" uden type="font/woff2" kan føre til forkert prioritering eller dobbelte anmodninger.
  • Ubrugte forspændingerAlle ubrugte ressourcer tilstopper linjen. Jeg fjerner preloads, der ikke bruges sikkert i above-the-fold.
  • Crossorigin glemt: Med skrifttyper eller eksterne CDN'er fører dette til CORS-problemer og tab af cache.
  • HTML-ordreHints skal placeres i begyndelsen af head. Preloader før styles, derefter render CSS, derefter kritisk JS.
  • Imagesrcset uden størrelserJeg tilføjer billedeformater, så browseren vælger korrekt, og downloads forbliver slanke.
.

Lav en velbegrundet prioritering

Jeg beslutter mig ud fra nogle få spørgsmål: 1) Er værten/aktivet garanteret tidligt brug for? 2) Hvor høj er ventetiden (mobil, global, kold CDN)? 3) Er der alternativer? (inline CSS subset, self-hosting af skrifttyper)? 4) Kan forbindelsen genbruges? (sammensmeltning, H3, genoptagelse)? 5) Forringet opdagelserne i målparseren? Det er som følger: Prefetch til brede, gunstige gevinster; preconnect selektivt til opvarmning; preload kun til garanteret nødvendige filer med renskrivning og korrekt prioritering.

Sammenfatning i korte træk

Jeg bruger DNS Prefetching til brede, gunstige latenstidsgevinster, preconnect til nogle få, men centrale værter og preload til filer, der med garanti er brug for. Sekvensen i hovedet og et sparsomt udvalg giver de største effekter. Jeg måler hver ændring, tjekker vandfald og justerer hint-listen regelmæssigt. I kombination med HTTP/3, et CDN i nærheden og smart ressourceprioritering øger jeg FCP og LCP synligt. Sådan bruger jeg browseroptimering dns effektivt og bæredygtigt til at øge Hjemmesidens hastighed.

Aktuelle artikler