Prefetching e precaricamento DNS: ottimizzare la velocità del sito web

Il DNS prefetching e il preloading accorciano attivamente il tempo necessario per ottenere i primi contenuti visibili, attivando in anticipo DNS, TCP e TLS e fornendo in anticipo i file critici. Vi mostrerò come utilizzare Prefetching DNS, Precollegamento e precaricamento del Velocità del sito web in modo evidente, compresi il codice, l'impostazione di WordPress e le priorità collaudate.

Punti centrali

• Prefetch DNSLa risoluzione precoce dei nomi riduce la latenza.
• PrecollegamentoAprire DNS, TCP e TLS in anticipo.
• PrecaricoDare attivamente la priorità ai file critici.
• Definizione delle prioritàPochi, ma decisivi domini.
• MonitoraggioControllare gli effetti nella cascata.

Prefetching DNS: spiegazione in breve

Con Prefetching DNS il browser risolve l'IP di un dominio in anticipo prima di caricare un file, risparmiando così 20-250 ms per dominio, soprattutto sulle connessioni mobili ad alto traffico. Latenza. Imposto il suggerimento per gli host esterni di cui ho bisogno nell'area above-the-fold, ad esempio per i font, gli analytics o un CDN. Il browser esegue la ricerca DNS in background, accorciando così il percorso critico verso il primo rendering. I browser moderni a volte utilizzano il prefetching automaticamente, ma io garantisco l'effetto con un chiaro suggerimento nella testa. Questo riduce i viaggi di andata e ritorno, stabilizza l'inizio del rendering e accelera il processo di rendering. Vitali Web principali.

Differenza: prefetching DNS vs. preconnessione

Il prefetch attiva solo la funzione DNS-mentre Preconnect apre anche l'handshake TCP e TLS e mantiene calda la connessione. Per gli host critici, come un CDN per il rendering di CSS o font web, preferisco Preconnect al semplice Prefetch. Lo uso con parsimonia, perché ogni socket aperto occupa gli slot del browser. L'attributo crossorigine appartiene a tutti gli host con CORS, in modo che le richieste successive non vengano rallentate. Una chiara panoramica della selezione e della sequenza è contenuta nel documento compatto Guida al prefetch.

Precaricamento: precaricamento di file specifici

Carichi di precarico specifici File nella cache prima che il parser le richieda, velocizzando così FCP e LCP. Lo uso solo per risorse assolutamente necessarie, come CSS critici, immagini di eroi o font WOFF2. L'attributo fetchpriority dirige la ponderazione verso l'alto, senza spostare completamente altri trasferimenti importanti. Verifico che il tipo MIME, l'attributo as e l'utilizzo effettivo corrispondano, altrimenti perdo larghezza di banda. HTTP/3 è una buona aggiunta, come descritto nell'articolo su HTTP/3 e precaricamento descritto.

.

Aumento delle prestazioni nella configurazione di hosting

Un rapido Ospitare aumenta l'effetto dei suggerimenti perché RTT bassi, HTTP/3 e un CDN vicino riducono i tempi di attesa per ogni fase. Vedo regolarmente il TTFB ridursi fino a un secondo quando DNS, TCP e TLS vengono preriscaldati e l'origine risponde rapidamente. Sui dispositivi mobili con latenza elevata, questo si ripaga due volte, perché ogni viaggio di andata e ritorno risparmiato va direttamente all'LCP. Presto attenzione alla gestione stabile di TLS, alla pinzatura OCSP e a una configurazione TLS snella. In questo modo, il browser sfrutta in modo ottimale le poche connessioni simultanee e accelera la Velocità del sito web.

Confronto rapido: quale tecnologia per cosa?

La tabella seguente riassume l'effetto, l'uso e gli esempi di tag e mi aiuta a scegliere la misura giusta per ogni host. Combino il prefetch per la larghezza, la preconnessione per gli host critici e il preload per i file essenziali. Mantengo basso il numero di connessioni aperte simultaneamente. Questo lascia spazio sufficiente per le scoperte del parser e per le risorse critiche in ritardo. Questa panoramica prende decisioni su Definizione delle priorità più facile.

Tecnologia	Cosa succede	Utilizzo tipico	Esempio di tag	Impatto su FCP/LCP
Prefetch DNS	Precoce Risoluzione del nome	Host esterni con richieste successive	<link rel="dns-prefetch" href="//fonts.googleapis.com">	Moderatamente positivo, a seconda della latenza
Precollegamento	DNS + TCP + TLS preriscaldare	CDN, font, API critiche	<link rel="preconnect" href="https://cdn.example.com" crossorigin>	Chiaramente positivo, risparmia viaggi di andata e ritorno
Precarico	File attivo precarico	CSS critico, WOFF2, Immagine eroica	<link rel="preload" as="style" href="/critical.css">	Molto positivo, se scelto correttamente

Integrazione con WordPress: pulita e manutenibile

In WordPress, ho impostato i suggerimenti molto presto nel Capo, in modo che il browser li veda prima del collo di bottiglia del parser. Deduplico gli host, verifico la presenza di https e aggiungo crossorigine solo se necessario. Il codice seguente posiziona le voci in alto, massimizzando l'effetto. Inoltre, dopo le distribuzioni, controllo se sono stati aggiunti nuovi host esterni. In questo modo l'elenco dei suggerimenti rimane snello e aggiornato e efficiente.

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])) { continua; }
        $printed[$key] = true;
        echo '" . '\n";
        if (strpos($domain, "https://') === 0) {
            echo '" . '\n";
        }
    }
}
add_action("wp_head', 'add_dns_prefetch', 1);

Migliori pratiche: concise ma efficaci

Limito Preconnect a tre-cinque Ospiti, altrimenti il browser bloccherà prematuramente troppi socket. Colloco sempre i suggerimenti all'inizio della testata, seguiti dai precarichi, quindi dagli stili e dagli script. Per i font, combino Preconnect con visualizzazione dei caratteri: swap, in modo che il testo venga visualizzato immediatamente e il CLS rimanga basso. Mi assicuro che i file di precaricamento siano garantiti per l'uso, altrimenti spreco larghezza di banda e non do priorità a ciò che è necessario. Per gli script di terze parti, verifico criticamente se ogni file di Dominio necessario.

Misurazione e monitoraggio: rendere visibile il successo

Nella scheda Rete di DevTools, osservo l'ordine di DNS, TCP e TLS e verificare se si avviano prima di prima. Un confronto tra prima e dopo nella cascata mostra chiaramente se i suggerimenti stanno funzionando. Uso Lighthouse o PageSpeed Insights per osservare FCP, LCP e CLS e l'andamento di TTFB. WebPageTest fornisce anche una vista delle connessioni e strisce di film che documentano l'avvio del rendering. Dopo le modifiche più importanti, ripeto la misurazione e rimuovo i dati obsoleti. Ospiti dall'elenco dei suggerimenti.

HTTP/3, QUIC e coalescenza delle connessioni

Con HTTP/3 via QUIC risparmio ulteriori Viaggi di andata e ritorno, perché l'impostazione della connessione, la gestione delle perdite e il multiplexing funzionano in modo più efficiente. Verifico se il mio CDN e la mia origine offrono HTTP/3 e continuo a usare Preconnect in modo selettivo. Il coalescing delle connessioni riduce il numero di connessioni separate se i certificati e gli IP corrispondono. Questo permette agli host con lo stesso certificato di servire più sottodomini attraverso un comune Connessione. In generale, il percorso di rendering precoce ne trae un vantaggio significativo, soprattutto con molti file di piccole dimensioni.

Combinare il warmup e il prefetch della CDN

Riscaldo il mio CDN quando prevedo picchi di traffico e combino questo con Prefetch e Preconnect per gli host Edge. Ciò significa che gli oggetti importanti sono memorizzati nella cache dell'edge e gli handshake sono già preparati. Questo riduce le latenze, soprattutto nelle chiamate iniziali e in condizioni di mobilità. Le istruzioni pratiche sono riportate nell'articolo su Riscaldamento CDN, che mi piace usare come lista di controllo. Prima del rollout, verifico le percentuali di hit della cache e osservo i risultati di TTFB-Sviluppo.

Governance: mantenere aggiornata la lista dei suggerimenti

Sto conducendo un breve Inventario di tutti gli host esterni e controllo trimestralmente se sono stati aggiunti nuovi script, font o immagini. Elimino le integrazioni rimosse insieme al suggerimento per mantenere l'elenco snello. Per ogni host, annoto lo scopo, la criticità e la tecnologia utilizzata (prefetch, preconnect o preload). Inserisco immediatamente le modifiche al CDN o ai font, in modo da non lasciare voci orfane. In questo modo mantengo il controllo, riduco le spese generali e garantisco un'immagine coerente. Prestazioni.

Supporto del browser, euristica e limiti

Ho calcolato che i suggerimenti del browser sono Segnali non come comando. In caso di larghezza di banda ridotta, di un risparmio di dati attivo o di una scheda in background, il browser può regolare le priorità o limitare i suggerimenti. Safari è più conservativo con le preconnessioni, Firefox ha un'euristica diversa per le cache DNS in alcuni casi e le varianti mobili riducono i socket paralleli. Ecco perché ho formulato dei suggerimenti preciso ed evitare l'over-signalling: un numero ridotto di host, chiare come-valori, corretti tipo-Informazioni. Per i font faccio attenzione a crossorigine, altrimenti c'è il rischio di doppi fetches o di blocchi CORS tardivi. Se si vuole controllare completamente il prefetch, si può usare . oppure spento influenzare l'euristica automatica.

Intestazione HTTP e 103 suggerimenti precoci

Oltre ai tag HTML, utilizzo Intestazione del link, in modo che i suggerimenti arrivino con la prima risposta del server, ideale per il rendering lato server. 103 Early Hints invia anche queste intestazioni prima di della risposta finale 200, guadagnando così decine di millisecondi su linee lunghe.

# NGINX: Preconnessione e precaricamento tramite intestazione del link
add_header Link '; rel=preconnect; crossorigin' sempre;
add_header Link '; rel=preload; as=style; fetchpriority=high' sempre;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' sempre;

# Apache (htaccess)
Intestazione aggiungere il collegamento '; rel=preconnect; crossorigin'.
Aggiungere il link '; rel=preload; as=image'.'

Il server supporta 103 I primi accenni, Invio anche le intestazioni dei link in anticipo. Importante: conservo l'elenco breve, perché ogni voce genera uno sforzo di analisi e potenziali aperture di connessioni.

SPA e Service Worker: prefetch di percorsi e dati

Per le app a pagina singola, sposto i suggerimenti basato sullo statoAppena l'eroe è visibile, avvio un precaricamento mirato per il percorso successivo (chunk JS, immagine critica, schema API). Nel Service Worker, posso memorizzare nella cache i risultati del precaricamento e utilizzarli dopo gli eventi di navigazione. Definisco criteri di cancellazione chiari (scheda nascosta, CPU sovraccarica, rete debole) in modo che il prefetch non diventi un fattore di costo. Per i moduli ES ho impostato il precoce modulepreload, in modo che la catena delle dipendenze non rallenti.

<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>

Sicurezza, protezione dei dati e linee guida

Considero i quadri di riferimento delle politiche: un rigoroso CSP può bloccare i precarichi se font-src, stile-src oppure img-src non consentire gli obiettivi. crossorigine è obbligatorio per i font, altrimenti la cache non funzionerà in tutte le origini. Con le terze parti sensibili, non diffondo alcun pre-collegamento se posso rimuovere il dominio in futuro: ogni suggerimento è un segnale per il browser e può accelerare gli script di tracciamento. Verifico anche Salva dati e Salvataggio datiIn queste modalità, riduco l'aggressività dei precarichi e lascio attivo il prefetch DNS solo per gli host centrali.

Approfondire la pratica di misurazione: API e log di temporizzazione

Oltre alle cascate, utilizzo il API di temporizzazione delle risorse e Osservatore delle prestazionial fine di sul campo per misurare se i suggerimenti arrivano di fronte al parser e come domainLookupStart, connectStart e secureConnectionStart mossa. Questo mi consente di riconoscere se un Preconnect è stato effettivamente utilizzato o se è stato rifiutato dal 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>

Confronto questi dati con i log del server e le statistiche del CDN (tasso di ripresa di TLS, quota HTTP/3, visite alla cache). Se vedo che TLS riprende quasi sempre, posso ridurre il numero di preconnessioni attive e liberare slot per i rilevamenti del parser.

Approfondimento su WordPress: usare i filtri del nucleo in modo pulito

WordPress è già dotato di un'infrastruttura per i suggerimenti delle risorse. Mi collego a wp_resource_hints, invece di stampare io stesso l'HTML grezzo e passare solo obiettivi deduplicati. Per il precaricamento ho impostato wp_enqueue_style/wp_enqueue_script e aggiungere il corretto come-Attributi via wp_style_add_data.

// Preconnessione e prefetch DNS tramite il filtro centrale
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);

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

Mi assicuro anche che i plugin di ottimizzazione (rinviare, combinare) Non lasciare che i suggerimenti sfuggano al parser. Dopo l'attivazione, verifico se l'ordine nella testata viene mantenuto e se non ci sono precarichi duplicati.

Risoluzione dei problemi e anti-pattern

• Troppe preconnessioniPiù di 3-5 host sprecano le prese. Accorcio al prima critica Obiettivi (caratteri/CDN/API).
• Sbagliato come/tipo: A as="font" senza tipo="font/woff2" può portare a priorità errate o a richieste duplicate.
• Precarichi non utilizzatiOgni risorsa inutilizzata intasa la linea. Rimuovo i precarichi che non sono utilizzati in modo sicuro nell'above-the-fold.
• Crossorigine dimenticataCon i font o i CDN esterni, ciò comporta problemi CORS e perdita di cache.
• Ordine HTMLI suggerimenti devono essere collocati all'inizio della testata. Precaricare prima gli stili, poi rendere il CSS, quindi il JS critico.
• Set di immagini senza dimensioniAggiungo dimensioni immagini, in modo che il browser selezioni correttamente e i download rimangano snelli.

<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">

Stabilire priorità fondate

Decido in base ad alcune domande: 1) L'ospite/asset è garantito in anticipo necessario? 2) Quanto è alto è la latenza (mobile, globale, CDN fredda)? 3) Esistono alternative (sottoinsieme CSS inline, auto-ospedizione dei font)? 4) Il collegamento è riutilizzabile (coalescenza, H3, ripresa)? 5) Deteriorata le scoperte del parser di misura? Segue: Prefetch per guadagni ampi e favorevoli; preconnect selettivamente per i warmup; preload solo per garantito i file richiesti con una digitazione pulita e una corretta definizione delle priorità.

Riassunto in breve

Uso DNS Il prefetching per ottenere ampi e favorevoli guadagni di latenza, la preconnessione per pochi host ma centrali e il preload per i file di cui è garantita la necessità. La sequenza nella testa e una selezione parsimoniosa producono i maggiori effetti. Misuro ogni modifica, controllo le cascate e aggiusto regolarmente l'elenco dei suggerimenti. In combinazione con HTTP/3, un CDN vicino e una prioritizzazione intelligente delle risorse, aumento visibilmente FCP e LCP. Ecco come utilizzo i dns per l'ottimizzazione del browser in modo efficace e sostenibile per aumentare la FCP e la LCP. Velocità del sito web.