Przejdź do treści 
Wstępne pobieranie DNS i wstępne ładowanie aktywnie skracają czas do pierwszej widocznej treści poprzez wczesne uruchamianie DNS, TCP i TLS oraz dostarczanie krytycznych plików z wyprzedzeniem. Pokażę ci, jak używać Pobieranie DNS z wyprzedzeniem, Wstępne połączenie i wstępne ładowanie Szybkość witryny zauważalnie - w tym kod, konfigurację WordPress i wypróbowane i przetestowane priorytety.
Punkty centralne
- Pobieranie DNSWczesne rozpoznawanie nazw zmniejsza opóźnienia.
- Połączenie wstępneOtwórz DNS, TCP i TLS z wyprzedzeniem.
- Obciążenie wstępneAktywne nadawanie priorytetów krytycznym plikom.
- Ustalanie priorytetówNieliczne, ale decydujące domeny.
- MonitoringSprawdź efekty w wodospadzie.
Prefetching DNS: krótkie wyjaśnienie
Z Pobieranie DNS z wyprzedzeniem Przeglądarka rozwiązuje adres IP domeny z wyprzedzeniem przed załadowaniem pliku, oszczędzając w ten sposób 20-250 ms na domenę - szczególnie w przypadku połączeń mobilnych o dużym natężeniu ruchu. Opóźnienie. Ustawiam podpowiedź dla zewnętrznych hostów, których potrzebuję w obszarze above-the-fold, na przykład dla czcionek, analityki lub CDN. Przeglądarka wykonuje wyszukiwanie DNS w tle, a tym samym skraca krytyczną ścieżkę do pierwszego renderowania. Nowoczesne przeglądarki czasami używają prefetchingu automatycznie, ale ja zapewniam efekt z wyraźną podpowiedzią w głowie. Zmniejsza to liczbę podróży w obie strony, stabilizuje wczesne rozpoczęcie renderowania i przyspiesza proces renderowania. Core Web Vitals.
Różnica: prefetching DNS vs. preconnect
Prefetch uruchamia tylko DNS-names, podczas gdy Preconnect otwiera również TCP i TLS handshake i utrzymuje połączenie w stanie ciepłym. W przypadku krytycznych hostów, takich jak CDN do renderowania CSS lub czcionek internetowych, wolę Preconnect niż tylko Prefetch. Używam go oszczędnie, ponieważ każde otwarte gniazdo zajmuje sloty przeglądarki. Atrybut crossorigin należy do wszystkich hostów z CORS, aby późniejsze żądania nie były spowalniane. Przejrzysty przegląd wyboru i kolejności można znaleźć w kompaktowym dokumencie Przewodnik po Prefetch.
Wstępne ładowanie: wstępne ładowanie określonych plików
Obciążenia wstępne specyficzne Pliki aktywnie do pamięci podręcznej, zanim parser zwykle ich zażąda, przyspieszając w ten sposób FCP i LCP. Używam go tylko do zasobów, które są zdecydowanie potrzebne, takich jak krytyczne CSS, obrazy bohaterów lub czcionki WOFF2. Atrybut priorytet pobierania kieruje wagę w górę bez całkowitego wypierania innych ważnych transferów. Sprawdzam, czy typ MIME, atrybut as i rzeczywiste użycie są zgodne, w przeciwnym razie tracę przepustowość. HTTP/3 jest dobrym dodatkiem, jak opisano w artykule na stronie HTTP/3 i preload opisane.
Wzrost wydajności w konfiguracji hostingu
Szybko Hosting zwiększa efekt podpowiedzi, ponieważ niskie RTT, HTTP/3 i pobliski CDN skracają czas oczekiwania na etap. Regularnie widzę, jak TTFB spada nawet o sekundę, gdy DNS, TCP i TLS zaczynają się wstępnie rozgrzewać, a Origin szybko reaguje. Na urządzeniach mobilnych z dużymi opóźnieniami opłaca się to podwójnie, ponieważ każda zaoszczędzona podróż w obie strony trafia bezpośrednio do LCP. Zwracam uwagę na stabilną obsługę TLS, zszywanie OCSP i uproszczoną konfigurację TLS. W ten sposób przeglądarka optymalnie wykorzystuje kilka jednoczesnych połączeń i przyspiesza działanie. Szybkość witryny.
Szybkie porównanie: która technologia do czego?
Poniższa tabela podsumowuje efekt, użycie i przykładowe tagi oraz pomaga mi wybrać odpowiednią miarę dla każdego hosta. Łączę prefetch dla szerokości, preconnect dla krytycznych hostów i preload dla istotnych plików. Utrzymuję niską liczbę jednocześnie otwartych połączeń. Pozostawia to wystarczająco dużo miejsca na odkrycia parsera i późne krytyczne zasoby. Ten przegląd podejmuje decyzje dotyczące Ustalanie priorytetów łatwiejsze.
| Technologia | Co się dzieje | Typowe zastosowanie | Przykładowy znacznik | Wpływ na FCP/LCP |
|---|---|---|---|---|
| Pobieranie DNS | Wczesne Rozdzielczość nazwy | Hosty zewnętrzne z późniejszymi żądaniami | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | Umiarkowanie pozytywne, w zależności od opóźnienia |
| Połączenie wstępne | DNS + TCP + TLS podgrzać | CDN, czcionki, krytyczne interfejsy API | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | Wyraźnie pozytywne, oszczędza podróże w obie strony |
| Obciążenie wstępne | Plik aktywny obciążenie wstępne | Krytyczny CSS, WOFF2, Hero-Image | <link rel="preload" as="style" href="/critical.css"> | Bardzo pozytywny, jeśli zostanie wybrany prawidłowo |
Integracja z WordPress: czysta i łatwa w utrzymaniu
W WordPressie ustawiam podpowiedzi bardzo wcześnie w aplikacji Głowa, aby przeglądarka widziała je przed wąskim gardłem parsera. Deduplikuję hosty, sprawdzam obecność https i dodaję crossorigin tylko wtedy, gdy jest to wymagane. Poniższy kod umieszcza wpisy na górze, co maksymalizuje efekt. Po wdrożeniu sprawdzam również, czy dodano nowe hosty zewnętrzne. Dzięki temu lista podpowiedzi jest szczupła, aktualna i skuteczny.
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);
Najlepsze praktyki: zwięzłe, ale skuteczne
Ograniczam Preconnect do trzech do pięciu Gospodarze, W przeciwnym razie przeglądarka przedwcześnie zablokuje zbyt wiele gniazd. Zawsze umieszczam podpowiedzi na początku nagłówka, a następnie wstępne ładowanie, potem style i skrypty. W przypadku czcionek łączę Preconnect z font-display: swap, dzięki czemu tekst pojawia się natychmiast, a CLS pozostaje na niskim poziomie. Upewniam się, że pliki preload mają zagwarantowane użycie, w przeciwnym razie marnuję przepustowość i nie nadaję priorytetu temu, co jest potrzebne. W przypadku skryptów innych firm krytycznie sprawdzam, czy każdy Domena jest konieczne.
Pomiary i monitorowanie: uwidocznienie sukcesu
W zakładce Network narzędzia DevTools, patrzę na kolejność DNS, TCP i TLS i sprawdzić, czy uruchamiają się wcześniej niż wcześniej. Porównanie przed i po w wodospadzie wyraźnie pokazuje, czy wskazówki działają. Używam Lighthouse lub PageSpeed Insights do obserwacji FCP, LCP i CLS, a także trendu TTFB. WebPageTest zapewnia również widoki połączeń i paski filmowe, które dokumentują rozpoczęcie renderowania. Po większych zmianach powtarzam pomiar i usuwam nieaktualne dane Gospodarze z listy podpowiedzi.
HTTP/3, QUIC i koalescencja połączeń
Z HTTP/3 przez QUIC oszczędzam dodatkowe Podróże w obie strony, ponieważ konfiguracja połączenia, obsługa strat i multipleksowanie działają wydajniej. Sprawdzam, czy mój CDN i mój Origin oferują HTTP/3 i nadal selektywnie korzystam z Preconnect. Koalescencja połączeń zmniejsza liczbę oddzielnych połączeń, jeśli certyfikaty i adresy IP są zgodne. Dzięki temu hosty z tym samym certyfikatem mogą obsługiwać wiele subdomen za pośrednictwem współdzielonej domeny. Połączenie. Ogólnie rzecz biorąc, wczesna ścieżka renderowania przynosi znaczne korzyści, zwłaszcza w przypadku wielu małych plików.
Połączenie CDN warmup i prefetch
Podgrzewam mój CDN, gdy spodziewam się szczytów ruchu i łączę to z Prefetch i Preconnect dla hostów Edge. Oznacza to, że ważne obiekty są przechowywane w pamięci podręcznej krawędzi, a uściski dłoni są już przygotowane. Zmniejsza to opóźnienia, zwłaszcza przy początkowych połączeniach i w warunkach mobilnych. Praktyczne instrukcje można znaleźć w artykule na temat Rozgrzewka CDN, którego lubię używać jako listy kontrolnej. Przed wdrożeniem testuję wskaźniki trafień w pamięci podręcznej i obserwuję TTFB-rozwój.
Zarządzanie: Aktualizuj listę podpowiedzi
Prowadzę krótki Inwentaryzacja wszystkich zewnętrznych hostów i co kwartał sprawdzam, czy dodano nowe skrypty, czcionki lub obrazy. Usuwam usunięte integracje wraz z podpowiedzią, aby utrzymać listę w porządku. Dla każdego hosta odnotowuję cel, krytyczność i zastosowaną technologię (prefetch, preconnect lub preload). Natychmiast wprowadzam zmiany w CDN lub czcionkach, aby nie pozostawiać osieroconych wpisów. Pozwala mi to zachować kontrolę, zmniejszyć koszty ogólne i zapewnić spójność. Wydajność.
Obsługa przeglądarek, heurystyka i ograniczenia
Obliczam, że podpowiedzi przeglądarki to Sygnały nie jako polecenie. W przypadku niskiej przepustowości, aktywnego oszczędzania danych lub karty w tle przeglądarka może dostosować priorytety lub ograniczyć podpowiedzi. Safari jest bardziej konserwatywne w przypadku połączeń wstępnych, Firefox ma inną heurystykę dla pamięci podręcznych DNS w niektórych przypadkach, a warianty mobilne ograniczają równoległe gniazda. Właśnie dlatego sformułowałem podpowiedzi dokładnie i uniknąć nadmiernej sygnalizacji: niewielka liczba hostów, wyraźne jak-wartości, poprawne typ-informacje. W przypadku czcionek zwracam uwagę na crossorigin, W przeciwnym razie istnieje ryzyko podwójnego pobierania lub późnego blokowania CORS. Jeśli chcę całkowicie kontrolować prefetch, mogę użyć . lub wyłączony wpływają na automatyczną heurystykę.
Nagłówek HTTP i 103 wczesne podpowiedzi
Oprócz znaczników HTML używam Nagłówek łącza, dzięki czemu podpowiedzi są wysyłane wraz z pierwszą odpowiedzią serwera - idealne do renderowania po stronie serwera. 103 Early Hints wysyła nawet te nagłówki przed ostatecznej odpowiedzi 200, a tym samym zyskać dziesiątki milisekund na długich liniach.
# NGINX: Wstępne połączenie i wstępne ładowanie przez nagłówek łącza
add_header Link '; rel=preconnect; crossorigin' always;
add_header Link '; rel=preload; as=style; fetchpriority=high' always;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' zawsze;
# Apache (htaccess)
Nagłówek dodaj link '; rel=preconnect; crossorigin'
Nagłówek dodaj link '; rel=preload; as=image'
Czy serwer obsługuje 103 Wczesne wskazówki, Wcześnie wysyłam również nagłówki linków. Ważne: zachowuję listę krótki, ponieważ każdy wpis generuje wysiłek związany z parsowaniem i potencjalnymi otwarciami połączeń.
SPA i Service Worker: wstępne pobieranie tras i danych
W przypadku aplikacji jednostronicowych przenoszę podpowiedzi oparty na stanieGdy tylko bohater jest widoczny, rozpoczynam ukierunkowane ładowanie wstępne dla następnej trasy (fragment JS, obraz krytyczny, schemat API). W Service Worker mogę buforować wyniki wstępnego ładowania i używać ich po zdarzeniach nawigacyjnych. Definiuję jasne kryteria anulowania (ukryta karta, przeciążony procesor, słaba sieć), aby wstępne pobieranie nie stało się czynnikiem kosztotwórczym. Dla modułów ES ustawiam wczesne modulepreload, aby łańcuch zależności nie zwalniał.
.
.
Bezpieczeństwo, ochrona danych i wytyczne
Rozważam ramy polityki: ścisłe CSP może zablokować wstępne ładowanie, jeśli font-src, style-src lub img-src nie zezwalają na cele. crossorigin jest obowiązkowe dla czcionek, w przeciwnym razie pamięć podręczna nie będzie działać we wszystkich źródłach. W przypadku wrażliwych stron trzecich nie rozpowszechniam żadnych wstępnych połączeń, jeśli mogę usunąć domenę w przyszłości - każda wskazówka jest sygnałem dla przeglądarki i może przyspieszyć skrypty śledzące. Sprawdzam również Save-Data oraz Oszczędzanie danychW tych trybach zmniejszam agresywność preloadu i pozostawiam aktywny prefetch DNS tylko dla hostów centralnych.
Pogłębiona praktyka pomiarowa: interfejs API synchronizacji i dzienniki
Oprócz wodospadów używam również Interfejs API synchronizacji zasobów oraz PerformanceObserverw celu w terenie aby zmierzyć, czy podpowiedzi trafiają przed parser i w jaki sposób domainLookupStart, connectStart oraz secureConnectionStart move. Pozwala mi to rozpoznać, czy połączenie wstępne zostało rzeczywiście użyte, czy też zostało odrzucone przez przeglądarkę.
.
Porównuję te dane z logami serwera i statystykami CDN (wskaźnik wznawiania TLS, udział HTTP/3, trafienia w pamięci podręcznej). Jeśli widzę, że TLS prawie zawsze jest wznawiany, mogę zmniejszyć liczbę aktywnych połączeń wstępnych i zwolnić miejsca na wykrywanie parserów.
WordPress dogłębnie: czyste korzystanie z podstawowych filtrów
WordPress jest już wyposażony w infrastrukturę podpowiedzi zasobów. Dołączam się do wp_resource_hints, zamiast samemu drukować surowy HTML i przekazywać tylko zdeduplikowane cele. Dla wstępnego ładowania ustawiłem wp_enqueue_style/wp_enqueue_script i dodać poprawne jak-atrybuty poprzez wp_style_add_data.
// Preconnect i DNS prefetch przez filtr rdzenia
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 poprawnie
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);
Upewniam się również, że wtyczki optymalizacyjne (odroczenie, połączenie) Nie pozwól, aby podpowiedzi prześlizgnęły się za parserem. Po aktywacji sprawdzam, czy kolejność w head jest zachowana i czy nie ma zduplikowanych preloadów.
Rozwiązywanie problemów i przeciwdziałanie wzorcom
- Zbyt wiele połączeń wstępnychWięcej niż 3-5 hostów marnuje gniazda. Skracam do pierwszy krytyczny Cele (czcionki/CDN/API).
- Nieprawidłowy jako/typ: A
as="font"beztype="font/woff2"może prowadzić do nieprawidłowego priorytetu lub zduplikowanych żądań. - Nieużywane obciążenia wstępneKażdy nieużywany zasób zapycha linię. Usuwam preloads, które nie są bezpiecznie używane w above-the-fold.
- Zapomniany CrossoriginW przypadku czcionek lub zewnętrznych sieci CDN prowadzi to do problemów z CORS i utraty pamięci podręcznej.
- Kolejność HTMLPodpowiedzi muszą być umieszczone na początku nagłówka. Wstępne ładowanie przed stylami, następnie renderowanie CSS, a następnie krytyczny JS.
- Imagesrcset bez rozmiarówDodaję
rozmiary obrazów, aby przeglądarka wybierała poprawnie, a pobieranie pozostało bez zakłóceń.
.
Dobrze uzasadnione ustalanie priorytetów
Decyzję podejmuję na podstawie kilku pytań: 1) Czy host/aktyw jest gwarantowany wcześnie? potrzebne? 2) Jak wysoki jest opóźnienie (mobilne, globalne, zimny CDN)? 3) Czy istnieją alternatywy? (inline CSS subset, self-hosting czcionek)? 4) Czy połączenie jest wielokrotnego użytku? (koalescencja, H3, wznowienie)? 5) Upośledzony odkrycia parsera miar? Wygląda to następująco: Prefetch dla szerokich, korzystnych zysków; preconnect selektywnie dla rozgrzewek; preload tylko dla gwarantowany wymagane pliki z czystym maszynopisem i prawidłową priorytetyzacją.
Podsumowanie w skrócie
Używam DNS Prefetching dla szerokiego, korzystnego wzrostu opóźnień, preconnect dla kilku, ale centralnych hostów i preload dla plików, które na pewno będą potrzebne. Sekwencja w głowie i oszczędna selekcja zapewniają największe efekty. Mierzę każdą zmianę, sprawdzam wodospady i regularnie dostosowuję listę podpowiedzi. W połączeniu z HTTP/3, pobliskim CDN i inteligentną priorytetyzacją zasobów, wyraźnie zwiększam FCP i LCP. W ten sposób efektywnie wykorzystuję optymalizację przeglądarek dns i trwale zwiększam FCP i LCP. Szybkość witryny.
