Passer au contenu 
Le DNS prefetching et le preloading réduisent activement le temps jusqu'au premier contenu visible en déclenchant le DNS, le TCP et le TLS à un stade précoce et en mettant à disposition les fichiers critiques à l'avance. Je vais te montrer comment utiliser Préchargement DNS, Preconnect et Preloading les Vitesse du site web y compris le code, la configuration WordPress et les priorités testées sur le terrain.
Points centraux
- Préchargement DNS: La résolution de nom précoce réduit la latence.
- Préconnexion: Ouvrir DNS, TCP et TLS au préalable.
- Preload: Privilégier activement les fichiers critiques.
- Définition des priorités: peu de domaines, mais des domaines décisifs.
- Suivi: vérifier les effets dans la chute d'eau.
DNS Prefetching : expliqué brièvement
Avec Préchargement DNS le navigateur pré-résout l'IP d'un domaine avant de charger un fichier, ce qui permet d'économiser 20-250 ms par domaine - en particulier sur les connexions mobiles à haut débit. Latence. Je place le Hint pour les hôtes externes dont j'ai besoin dans le domaine Above-the-Fold, par exemple pour les polices, les analytics ou un CDN. Le navigateur effectue la recherche DNS en arrière-plan et raccourcit ainsi le chemin critique vers le premier rendu. Les navigateurs modernes utilisent le prefetching en partie automatiquement, mais je sécurise l'effet avec un hint clair dans le head. Je réduis ainsi les roundtrips, stabilise le démarrage précoce du rendu et accélère le Core Web Vitals.
Différence : DNS prefetching vs. preconnect
Prefetch ne résout que le DNS-Preconnect ouvre en outre le handshake TCP et TLS et maintient la connexion au chaud. Pour les hôtes critiques, par exemple un CDN pour le rendu CSS ou les polices web, je préfère Preconnect au simple Prefetch. Je l'utilise avec parcimonie, car chaque socket ouvert occupe des slots de navigateur. L'attribut crossorigin appartient à tous les hôtes avec CORS, afin que les requêtes ultérieures ne soient pas ralenties. Tu trouveras un aperçu clair du choix et de l'ordre dans le document compact Guide sur Prefetch.
Preloading : Précharger des fichiers de manière ciblée
Preload charge spécifique Fichiers dans le cache avant que l'analyseur ne les demande, ce qui accélère FCP et LCP. Je ne l'utilise que pour les ressources dont je suis sûr qu'elles seront utilisées, comme le CSS critique, les images Hero ou les polices WOFF2. L'attribut fetchpriority oriente la pondération vers le haut, sans évincer complètement d'autres transferts importants. Je contrôle que le type MIME, l'attribut as et l'utilisation réelle correspondent, sinon je perds de la bande passante. HTTP/3 est un bon complément, comme le montre l'article sur les HTTP/3 et préchargement décrites.
Gain de performance dans la configuration d'hébergement
Un rapide Hébergement renforce l'effet des hints, car les RTT bas, HTTP/3 et un CDN proche font baisser les temps d'attente par niveau. Je constate régulièrement que le TTFB baisse jusqu'à une seconde lorsque DNS, TCP et TLS démarrent préchauffés et que l'Origin répond de manière fixe. Sur les appareils mobiles à forte latence, cela s'avère doublement payant, car chaque roundtrip économisé est directement intégré dans le LCP. Je veille à la stabilité des traitements TLS, à l'étalement OCSP et à une configuration TLS légère. Ainsi, le navigateur utilise de manière optimale ses quelques connexions simultanées et accélère le Vitesse du site.
Comparaison rapide : quelle technique pour quoi faire ?
Le tableau suivant résume l'effet, l'utilisation et les exemples de balises et m'aide à choisir la bonne mesure par hôte. Je combine Prefetch pour la largeur, Preconnect pour les hôtes critiques et Preload pour les fichiers indispensables. Ce faisant, je maintiens le nombre de connexions ouvertes simultanément à un niveau faible. Cela laisse suffisamment de marge de manœuvre pour les découvertes de l'analyseur et les actifs critiques de dernière minute. Cette vue d'ensemble permet de prendre des décisions concernant Définition des priorités plus facile.
| Technique | Ce qui se passe | Utilisation typique | Exemple de balise | Impact sur le FCP/LCP |
|---|---|---|---|---|
| Préchargement DNS | Précoces Résolution de noms | Hôtes externes avec des requêtes ultérieures | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Modérément positif, selon la latence |
| Préconnexion | DNS + TCP + TLS préchauffer | CDN, polices de caractères, API critiques | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Nettement positif, économise les roundtrips |
| Preload | Fichier actif précharger | Critical CSS, WOFF2, Hero-Image | <link rel="preload" as="style" href="/critical.css"> | Très positif, si correctement choisi |
Intégration WordPress : propre et maintenable
Dans WordPress, je place les hints très tôt dans le Tête, pour que le navigateur les voie avant le bottleneck de l'analyseur. Je déduplique les hôtes, je vérifie la présence de https et j'ajoute crossorigin uniquement si nécessaire. Le code suivant place les entrées tout en haut, ce qui maximise l'effet. En outre, je contrôle après les déploiements si de nouveaux hôtes externes ont été ajoutés. Ainsi, la liste "hint" reste légère, à jour et efficace.
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 '' . "\n" ;
if (strpos($domain, 'https://') === 0) {
echo '' . "\n" ;
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1) ;
Meilleures pratiques : succinctes mais efficaces
Je limite Preconnect à trois à cinq Hôtes, Sinon, le navigateur bloque trop de sockets prématurément. Je place toujours les hints au début du head, puis les preloads, les styles et les scripts. Pour les polices, je combine Preconnect avec affichage des polices : swap, pour que le texte apparaisse immédiatement et que CLS reste bas. Je veille à ce que les fichiers de préchargement soient utilisés de manière garantie, sinon je gaspille de la bande passante et je ne donne pas la priorité aux besoins. Pour les scripts de tiers, je vérifie de manière critique si chaque Domaine est nécessaire.
Mesure et suivi : rendre les succès visibles
Dans l'onglet Network de DevTools, je regarde l'ordre de DNS, TCP et TLS et vérifie s'ils démarrent plus tôt qu'avant. Une comparaison avant/après dans la cascade montre clairement si les conseils sont efficaces. Avec Lighthouse ou PageSpeed Insights, je tiens compte de FCP, LCP et CLS ainsi que de la tendance TTFB. WebPageTest fournit en outre Connection-View et Filmstrips, qui attestent du démarrage du rendu. Après des modifications importantes, je répète la mesure et je supprime les données obsolètes. Hôtes de la liste Hint.
HTTP/3, QUIC et coalescence de connexions
Avec HTTP/3 via QUIC, je fais des économies supplémentaires. Allers-retours, Je ne veux pas que les connexions soient interrompues, car l'établissement des connexions, le traitement des pertes et le multiplexage sont plus efficaces. Je vérifie si mon CDN et mon Origin proposent HTTP/3 et je continue à utiliser la préconnexion de manière ciblée. Le Connection Coalescing réduit le nombre de connexions séparées lorsque les certificats et les IP correspondent. Ainsi, les hôtes utilisant le même certificat desservent plusieurs sous-domaines via une connexion commune. Connexion. En somme, le chemin de rendu précoce en profite nettement, surtout s'il y a beaucoup de petits fichiers.
Combiner CDN-Warmup et Prefetch
Je chauffe mon CDN lorsque je prévois des pics de trafic et je combine cela avec Prélecture et préconnexion pour les hôtes Edge. Ainsi, les objets importants se trouvent dans le cache Edge et les handshake sont déjà préparés. Cela permet de réduire les temps de latence, surtout lors des premiers appels et dans des conditions de mobilité. Un guide pratique est fourni dans l'article sur Préchauffage du CDN, que j'utilise volontiers comme liste de contrôle. Avant les déploiements, je teste les taux de réussite du cache et j'observe les TTFB-développement.
Gouvernance : tenir à jour la liste des hints
J'effectue une brève Inventaire de tous les hôtes externes et vérifie tous les trimestres si de nouveaux scripts, polices ou images ont été ajoutés. Je biffe les intégrations supprimées avec leur mention afin que la liste reste légère. Pour chaque hôte, je note le but, la criticité et la technique utilisée (prefetch, preconnect ou preload). J'intègre immédiatement les modifications apportées au CDN ou aux polices de caractères afin d'éviter les entrées orphelines. Cela me permet de garder le contrôle, de réduire les frais généraux et d'assurer la cohérence des données. Performance.
Support du navigateur, heuristiques et limites
Je prévois que les browser hints seront utilisés comme Signaux et non comme une commande. En cas de faible bande passante, d'économiseur de données actif ou d'onglet d'arrière-plan, le navigateur peut adapter les priorités ou réduire les allers-retours. Safari est plus conservateur pour les préconnexions, Firefox a parfois d'autres heuristiques pour les caches DNS, et les variantes mobiles réduisent les sockets parallèles. C'est pourquoi je formule des hints précis et évite la sursignalisation : peu d'hôtes, des as-valeurs correctes type-Les indications de la police. Pour les polices de caractères, je fais attention à crossorigin, Sinon, il y a un risque de double fetch ou de blocage tardif du CORS. Si je veux contrôler complètement le prefetch, je peux le faire avec <meta http-equiv="x-dns-prefetch-control" content="on"> ou off influencer l'heuristique automatique.
En-têtes HTTP et 103 Early Hints
Outre les balises HTML, j'utilise En-tête de lien, pour que les hints arrivent dès la première réponse du serveur - idéal pour le rendu côté serveur. 103 Early Hints envoient même ces en-têtes avant de la réponse finale de 200 et gagnent ainsi des dizaines de millisecondes supplémentaires sur les longues lignes.
# NGINX : préconnexion et préchargement via l'en-tête de lien
add_header lien ' ; rel=preconnect ; crossorigin' toujours ;
add_header lien ' ; rel=preload ; as=style ; fetchpriority=high' always ;
add_header lien ' ; rel=preload ; as=font ; type=font/woff2 ; crossorigin' always ;
# Apache (htaccess)
Header add lien ' ; rel=preconnect ; crossorigin'.
En-tête add lien ' ; rel=preload ; as=image'
Le serveur prend-il en charge 103 Early Hints, j'envoie également les en-têtes de liens très tôt. Important : je conserve la liste en bref, La plupart du temps, les entrées ne sont pas très nombreuses, car chaque entrée génère des efforts d'analyse syntaxique et des ouvertures de connexion potentielles.
SPA et Service Worker : Préfetch d'itinéraire et de données
Pour les applications à page unique, je déplace les hints basé sur l'étatDès que le héros est visible, je lance un Preload ciblé pour l'itinéraire suivant (JS-Chunk, image critique, schéma API). Dans le Service Worker, je peux mettre en cache les résultats du Preload et les utiliser en fonction des événements de navigation. Je définis des critères d'interruption clairs (onglet caché, CPU surchargée, réseau faible) afin que Prefetch ne devienne pas un générateur de coûts. Pour les modules ES, je définis très tôt modulepreload, pour que la chaîne de dépendance ne soit pas freinée.
<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>
Sécurité, protection des données et politiques
Je pense à des cadres de politique : un strict CSP peut bloquer les Preloads si font-src, style-src ou img-src ne permettent pas les objectifs. crossorigin est obligatoire pour les polices, sinon le cache ne s'applique pas à l'ensemble de l'origine. Pour les tierces parties sensibles, je ne diffuse pas de préconnexions lorsque je pourrais supprimer le domaine à l'avenir - chaque hint est un signal pour le navigateur et peut accélérer les scripts de suivi. Je vérifie également Save-Data et Économiseur de donnéesDans ces modes, je réduis l'agressivité des preloads et je laisse uniquement le DNS prefetch actif pour les hôtes centraux.
Approfondir la pratique de la mesure : Timing API et Logs
Outre les cascades, j'utilise les API de gestion des ressources et PerformanceObserverafin de dans le champ de mesurer si les hints arrivent avant l'analyseur syntaxique et comment les domainLookupStart, connectStart et secureConnectionStart déplacer. Cela me permet de savoir si un préconnect a vraiment été utilisé ou s'il a été rejeté par le navigateur.
<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>
Je compare ces données avec les journaux de serveur et les statistiques CDN (taux de résomption TLS, proportion de HTTP/3, hits de cache). Si je vois que TLS résume presque toujours, je peux réduire le nombre de préconnexions actives et libérer des slots pour les détections de l'analyseur.
Approfondissement de WordPress : utiliser proprement les filtres Core
WordPress est déjà doté d'une infrastructure pour les notes de ressources. Je m'y accroche wp_resource_hints, Au lieu d'imprimer moi-même le HTML brut, je ne transfère que les cibles dédupliquées. Pour le Preload, j'utilise wp_enqueue_style/wp_enqueue_script et ajoute les bons as-attributs via wp_style_add_data.
// Preconnect et DNS Prefetch via le 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) ;
// Enqueuer correctement le Preload
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) ;
De plus, je veille à ce que les plugins d'optimisation (defer, combine) Ne pas laisser les hints se glisser derrière l'analyseur. Après l'activation, je teste si l'ordre dans le head est conservé et s'il n'y a pas de double preload.
Dépannage et anti-patterns
- Trop de préconnexionsPlus de 3-5 hôtes gaspillent des sockets. Je raccourcis à la première critique Cibles (Fonts/CDN/API).
- Mauvais as/type: Un
as="font"sanstype="font/woff2"peut conduire à une priorité manquée ou à une double requête. - Preloads inutilisésChaque ressource non utilisée encombre la ligne. Je supprime les préchargements qui ne sont pas utilisés de manière sûre dans l'Above-the-Fold.
- Oublier Crossorigin: Pour les polices ou les CDN étrangers, cela entraîne des problèmes CORS et une perte de cache.
- Ordre HTMLLes hints doivent être placés au début du head. Preloads avant les styles, puis Render-CSS, puis JS critique.
- Imagesrcset sans sizes: Je complète
tailles d'images, Pour que le navigateur sélectionne correctement et que les téléchargements restent légers.
<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">
Définir des priorités en toute connaissance de cause
Je décide sur la base de quelques questions : 1) L'hôte/l'actif est-il garanti tôt utilisé ? 2) Quelle est la hauteur est la latence (mobile, globale, CDN froid) ? 3) Existe-t-il des alternatives (sous-ensemble CSS en ligne, auto-hébergement des polices) ? 4) La connexion est-elle réutilisable (Coalescence, H3, Résomption) ? 5) Affecte la mesure Découvertes de l'analyseur syntaxique ? Il en résulte que : Prefetch pour des gains larges et avantageux ; Preconnect sélectif pour les warmups ; Preload uniquement pour les garanti les fichiers nécessaires avec un typage propre et une priorisation correcte.
Résumé en bref
J'utilise DNS Prefetching pour des gains de latence larges et avantageux, Preconnect pour des hôtes peu nombreux mais centraux et Preload pour des fichiers dont la nécessité est garantie. L'ordre dans la tête et une sélection parcimonieuse fournissent les plus grands effets. Je mesure chaque changement, je vérifie les cascades et j'adapte régulièrement la liste "hint". En combinaison avec HTTP/3, un CDN proche et une priorisation intelligente des ressources, j'améliore visiblement FCP et LCP. C'est ainsi que j'utilise efficacement browser optimization dns et que j'augmente durablement les Vitesse du site.
