Jak ustawić preload, preconnect i dns-prefetch

Resource Hints to prosty sposób na podpowiadanie przeglądarce, które zasoby są ważne i kiedy należy je pobrać. Dzięki nim skracamy czas oczekiwania użytkownika, a kluczowe elementy strony pojawiają się szybciej. W tym poradniku krok po kroku nauczysz się, jak bezpiecznie i skutecznie skonfigurować preload, preconnect i dns-prefetch, jak je testować oraz jak unikać typowych błędów, które potrafią pogorszyć wydajność zamiast ją poprawić.

Zasady działania i kiedy używać

Preload – co i po co

Preload instruuje przeglądarka, aby zaczęła pobierać konkretny zasób wcześniej, niż zrobiłaby to normalnie podczas parsowania DOM/CSSOM. To szczególnie przydatne dla kluczowych arkuszy CSS, krytycznych skryptów, najważniejszych obrazów nad linią załadowania (above the fold) oraz fonty w formacie WOFF2. Kluczowe jest poprawne określenie typu (atrybut as) i – w razie potrzeby – dołączenie crossorigin, aby uniknąć podwójnych pobrań i problemów z CORS. Preload nie zmienia logiki wykonywania skryptów, ale może poprawić ich gotowość wcześniej.

Preconnect – skracanie czasu nawiązywania połączenia

Preconnect uruchamia rozwiązywanie DNS, ustanawia połączenie TCP i – jeśli to możliwe – negocjację TLS do wskazanego hosta, skracając czas potrzebny do pierwszego żądania. Daje najlepsze efekty dla zewnętrznych usług, np. CDN, serwerów z fontami, analityką czy API używanym przy starcie. W dobie HTTP/2 i HTTP/3 warto przejrzeć liczbę domen – mniej domen to mniej narzutów. Preconnect jest cięższy niż dns-prefetch, dlatego używaj go selektywnie: tylko tam, gdzie masz pewność, że żądania na ten origin na pewno wystąpią.

DNS-prefetch – najtańsza forma podgrzania DNS

Dns-prefetch zleca wyłącznie wcześniejsze rozwiązywanie DNS. Nie otwiera gniazd TCP, nie negocjuje TLS. Jest tani i bezpieczny przy niepewności, czy origin będzie potrzebny, lub gdy docelowe żądania pojawią się później. Pamiętaj, że jeśli na tę samą domenę użyjesz zarówno dns-prefetch, jak i preconnect, ten drugi de facto zawiera w sobie pierwszy – nie dubluj pracy.

Kiedy który hint wybrać

• Masz zasób absolutnie krytyczny dla pierwszego renderu (CSS, hero image, czcionka do tekstu nad foldem) – użyj preload.
• Wiesz, że strona na starcie wyśle żądania do zewnętrznego hosta (CDN, grafika, API) – wybierz preconnect.
• Przewidujesz możliwe żądania, ale nie masz pewności co do ich wystąpienia/terminu – postaw na dns-prefetch.

Ograniczenia i kompatybilność

• Preload wymaga prawidłowego as (style, script, font, image, fetch, track). Błędny typ obniża skuteczność i priorytet.
• Dla fontów preloading bez poprawnego crossorigin skutkuje podwójnym pobraniem lub błędami CORS.
• Resource Hints to sugestie – przeglądarka może je zignorować w wyjątkowych sytuacjach (np. z powodu priorytetów lub oszczędzania energii).
• HTTP/2 i HTTP/3 optymalizują wiele opóźnień, ale nie zastępują wskazówek – dobrze dobrane hinty wciąż pomagają obniżać opóźnienia i poprawić LCP.

Instrukcje wdrożenia w HTML

Preload w praktyce (as, crossorigin, type, media, imagesrcset)

Najprostszy preload w dokumencie HTML (używaj go w sekcji head strony):

• <link rel=”preload” href=”/css/critical.css” as=”style”>
• <link rel=”preload” href=”/js/app-init.js” as=”script”>
• <link rel=”preload” href=”/img/hero.webp” as=”image” imagesrcset=”/img/hero-800.webp 800w, /img/hero-1200.webp 1200w” imagesizes=”100vw”>

Jeśli plik jest z innego originu i wymaga CORS (szczególnie czcionki):

• <link rel=”preload” href=”https://cdn.example.com/fonts/inter.woff2″ as=”font” type=”font/woff2″ crossorigin>

Upewnij się, że atrybuty type i as odpowiadają rzeczywistości. Dla obrazów z responsywnymi wariantami używaj imagesrcset i imagesizes, aby przeglądarka pobrała właściwy rozmiar.

Preconnect i dns-prefetch w praktyce

Gdy wiemy, że strona natychmiast korzysta z zewnętrznego hosta:

• <link rel=”preconnect” href=”https://cdn.example.com” crossorigin>

Jeżeli nie masz pewności lub łącze jest sporadycznie wykorzystywane:

• <link rel=”dns-prefetch” href=”//cdn.example.com”>

W przypadku zasobów wymagających uwierzytelnienia lub wysyłających ciasteczka, do preconnect dodaj crossorigin – pozwala na przygotowanie kanału z odpowiednim kontekstem.

Przykłady dla fontów, CSS, JS, obrazów

• Font (WOFF2): <link rel=”preload” href=”/fonts/inter.woff2″ as=”font” type=”font/woff2″ crossorigin>
• CSS krytyczny: <link rel=”preload” href=”/css/critical.css” as=”style”>
• Skrypt inicjalizacyjny: <link rel=”preload” href=”/js/init.js” as=”script”>
• Obraz hero: <link rel=”preload” href=”/img/hero@2x.avif” as=”image” imagesrcset=”/img/hero.avif 1x, /img/hero@2x.avif 2x” imagesizes=”(min-width: 900px) 900px, 100vw”>

Dodatkowa uwaga dla czcionek: właściwość CSS font-display: swap/fallback minimalizuje odczuwalne opóźnienie wyświetlania tekstu, ale preload przyspiesza samo pobranie pliku.

Unikanie kolizji priorytetów i duplikatów

• Nie preloaduj wszystkiego. Zbyt wiele preloadów może przeciążyć kolejkę i spowolnić naprawdę krytyczne elementy.
• Jeżeli stosujesz fetchpriority=”high” na obrazie LCP, nie dubluj go preloadem bez powodu – testuj, co daje lepszy efekt.
• Nie łącz jednocześnie dns-prefetch i preconnect do tego samego hosta (preconnect już zawiera DNS).
• Unikaj preloadu dla modułów ładowanych warunkowo w dalszych krokach SPA – zwiększasz transfer bez korzyści.

Konfiguracja po stronie serwera

Nagłówek Link i 103 Early Hints

Możesz wysyłać Resource Hints w nagłówku Link, aby klient otrzymał je jeszcze przed HTML-em. To zwykle najszybsza metoda dla zasobów krytycznych. Przykłady:

• Link: </css/critical.css>; rel=preload; as=style
• Link: </fonts/inter.woff2>; rel=preload; as=font; type=”font/woff2″; crossorigin
• Link: <https://cdn.example.com>; rel=preconnect; crossorigin
• Link: <//cdn.example.com>; rel=dns-prefetch

Gdy serwer lub CDN wspiera Early Hints (HTTP 103), możesz wysłać nagłówki Link jeszcze szybciej – zanim zaczniesz generować odpowiedź 200. Efekt to „wcześniejszy start” pobierania kluczowych zasobów.

Nginx – przykładowe dyrektywy

Dodawanie nagłówków Link w Nginx (umieść w bloku serwera lub lokalizacji, pamiętaj o poprawnym formacie i cytatach):

• add_header Link „</css/critical.css>; rel=preload; as=style” always;
• add_header Link „</fonts/inter.woff2>; rel=preload; as=font; type=font/woff2; crossorigin” always;
• add_header Link „<https://cdn.example.com>; rel=preconnect; crossorigin” always;
• add_header Link „<//cdn.example.com>; rel=dns-prefetch” always;

Użyj always, aby nagłówki były dołączane także przy odpowiedziach w cache’u lub przekierowaniach, jeśli to pożądane. Testuj, bo nie zawsze chcesz hinty na każdej ścieżce.

Apache – przykładowe dyrektywy

W Apache (httpd.conf lub .htaccess):

• Header add Link „</css/critical.css>; rel=preload; as=style
• Header add Link „</fonts/inter.woff2>; rel=preload; as=font; type=font/woff2; crossorigin”
• Header add Link „<https://cdn.example.com>; rel=preconnect; crossorigin”
• Header add Link „<//cdn.example.com>; rel=dns-prefetch”

Zadbaj o unikanie duplikatów Link, szczególnie gdy aplikacja generuje je w HTML, a serwer w nagłówkach. Dwa takie same wpisy nie przyspieszą niczego, a mogą zamieszać w priorytetach.

CDN i reverse proxy – uwagi praktyczne

• Większość CDN pozwala na wstrzykiwanie nagłówków Link lub korzystanie z reguł. Włączaj to per-ścieżka (np. tylko dla stron wejściowych).
• Sprawdź, czy CDN wspiera 103 Early Hints oraz modyfikację priorytetów HTTP/2/3 (niekiedy można wzmocnić preloadowane zasoby).
• Pamiętaj o cache-control i vary – jeśli serwujesz różne warianty (np. krytyczne CSS per język), odzwierciedl to w hintach.

Diagnoza i testy skuteczności

Lighthouse i Core Web Vitals

Lighthouse w Chrome podpowie, które zasoby należałoby preloadować (np. czcionki użyte na starcie). Mierz metryki Core Web Vitals: LCP, FID (INP) i CLS. Dobrze ustawione preloady potrafią zredukować czas renderu głównego elementu, co przekłada się na lepszy LCP i mniejsze porzucenia. Pamiętaj jednak, że preloady mogą zwiększyć transfer – bilansuj zyski i koszty.

Chrome DevTools i trace sieciowy

• Zakładka Network: sprawdź, czy zasób jest pobierany wcześniej (kolumna Priority, Waterfall). Zobacz, czy pojawia się żółta ikona „Preloaded”.
• Performance: nagraj profil i porównaj układ zdarzeń, TTI/INP oraz moment pojawienia się stylów/obrazów.
• Timing-Allow-Origin: dla zasobów z innych originów ustaw ten nagłówek, aby mieć pełny wgląd w szczegóły czasów w DevTools.

WebPageTest i testy porównawcze

WebPageTest pozwala uruchomić testy z różnych lokalizacji, z ograniczeniami przepustowości i na realnych urządzeniach. Porównuj A/B: bez hintów, z dns-prefetch, z preconnect, z preload. Interesuje Cię zwłaszcza First Byte, Start Render, Speed Index i LCP. Zwróć uwagę, czy preconnect skraca widocznie TTFB dla pierwszych żądań do zewnętrznych hostów.

RUM i monitorowanie produkcyjne

• Włącz Real User Monitoring (np. przez własny skrypt lub narzędzia SaaS) i śledź LCP per przeglądarka/urządzenie/region.
• Sprawdzaj stabilność efektu – jeśli hinty są warunkowe, czy w każdych warunkach faktycznie pomagają?
• Regularnie weryfikuj listę hostów objętych preconnect/dns-prefetch – usługi się zmieniają, a martwe wpisy to marnowanie zasobów.

Wzorce, pułapki i dobre praktyki

Preload tylko dla krytycznych zasobów

• Preload jest „głośną” sugestią – ustawia wysoki priorytet. Nadużywany obniża efektywność całej kolejki.
• Preloaduj tylko to, co wpływa na pierwszy render: kluczowe CSS, największy obraz nad foldem, krytyczny JS inicjalizujący interfejs, podstawowe czcionki dla tekstu w viewport.
• Unikaj preloadu dla zasobów używanych daleko w dół strony lub warunkowo – najpierw spróbuj leniwego ładowania (lazy-loading).

CORS i fonty

• Dla fontów zawsze dodaj crossorigin zarówno w link rel=preload, jak i dopilnuj poprawnej konfiguracji serwera (Access-Control-Allow-Origin), aby uniknąć podwójnych żądań.
• W CSS stosuj font-display: swap/fallback/optional – połączone z preloadem minimalizuje migotanie niewidocznego tekstu (FOIT).
• Dbaj o format WOFF2 i kompresję – preload nie naprawi zbyt dużych plików.

HTTP/2, HTTP/3, priorytety i fetchpriority

• W środowiskach HTTP/2 i HTTP/3 pojedyncze połączenie obsłuży wiele zasobów; preconnect ma sens, gdy łączysz się z innymi originami.
• Przeglądarki mają własne algorytmy priorytetyzacji. Preload może je nadpisać, ale rób to oszczędnie.
• Dla obrazów kluczowych testuj też atrybut fetchpriority=”high” na tagu img. Nie zawsze potrzebny jest jednoczesny preload.
• Server Push (HTTP/2) jest obecnie odradzany – w praktyce bywał mało przewidywalny i trudny w utrzymaniu.

SPA, Service Worker i dynamiczne trasy

• W SPA główny LCP często zależy od krytycznego CSS/JS i hero image. Preload może pomóc, ale unikaj ślepego preloadu chunków, których użytkownik nie zobaczy.
• Jeśli masz Service Workera, sprawdź, czy nie koliduje z hintami. Pamiętaj, że SW może szybko serwować z cache, ale pierwszy hit nadal korzysta z hintów.
• W aplikacjach wielojęzycznych lub z routingiem dynamicznym generuj hinty per-szablon. Nie utrzymuj jednej, przerośniętej listy.

Strategia usuwania i utrzymania

• Automatyzuj: generuj preloady podczas builda na podstawie manifestów (np. pliki krytyczne, hashowane nazwy).
• Regularnie audytuj: czy wszystkie wpisy są wciąż potrzebne, czy dany host odpowiada, czy nie nastąpiła zmiana ścieżek/formatów.
• Weryfikuj wpływ na metryki sezonowo i po większych deployach – to, co działało pół roku temu, dziś może być zbędne.

Checklist wdrożeniowy (skrót)

• Określ zasób LCP i krytyczne zależności (CSS, hero image, kluczowe fonty).
• Dobierz właściwy hint: preload dla krytyków, preconnect dla pewnych zewnętrznych originów, dns-prefetch dla niepewnych.
• Ustaw poprawne atrybuty: as, type, crossorigin, imagesrcset, imagesizes.
• Rozważ nagłówki Link i 103 Early Hints na serwerze/CDN.
• Przetestuj w Lighthouse, DevTools i WebPageTest; sprawdź wpływ na LCP i czas pierwszego renderu.
• Usuń duplikaty i wpisy, które nie wnoszą korzyści; nie nadużywaj preloadu.
• Monitoruj RUM i aktualizuj listę hintów po zmianach w buildzie.