DNS prefetch i preconnect — kiedy to ma sens?
TL;DR: DNS prefetch i preconnect mają sens zawsze wtedy, gdy Twoja strona korzysta z zasobów hostowanych na innych domenach, które nie są krytyczne, ale będą użyte w niedalekiej przyszłości (dns-prefetch), lub są absolutnie kluczowe i potrzebne od razu (preconnect). Mówiąc prościej, jeśli łączysz się z zewnętrznymi serwisami, to prawdopodobnie powinieneś je rozważyć.
Co to w ogóle jest DNS prefetch i preconnect?
Zanim przeglądarka zacznie pobierać jakikolwiek zasób z innej domeny – czy to obrazek, skrypt, czy styl CSS – musi najpierw przetłumaczyć nazwę domeny (np. google-analytics.com) na adres IP. To tak zwana rezolucja DNS. Ten proces, choć zazwyczaj szybki, trwa pewien czas – od kilkudziesięciu do kilkuset milisekund, a w skrajnych przypadkach i więcej.
DNS prefetch (<link rel="dns-prefetch">)
dns-prefetch to instrukcja dla przeglądarki, aby w tle, jeszcze zanim będzie potrzebować danego zasobu, spróbowała rozpoznać nazwę domeny. Działa to jak szybkie sprawdzenie, gdzie jest dany serwer, zanim jeszcze zdecydujemy się do niego zadzwonić. Przeglądarka po prostu pobiera adres IP, nie nawiązując pełnego połączenia.
Preconnect (<link rel="preconnect">)
preconnect idzie o krok dalej. Oprócz rozpoznania nazwy domeny, instruuje przeglądarkę, aby nawiązała wstępne połączenie z serwerem docelowym. Obejmuje to nie tylko rezolucję DNS, ale także trzykrotne uzgadnianie protokołu TCP (tzw. three-way handshake) oraz, jeśli strona korzysta z HTTPS, uzgadnianie połączenia TLS/SSL. To jakby dzwonić do restauracji i od razu poprosić o przygotowanie stolika, zanim jeszcze wyjdziemy z domu. Kiedy już będziemy potrzebować danego zasobu, przeglądarka ma już otwarte „drzwi” i może natychmiast zacząć pobieranie danych.
Dlaczego to jest ważne dla szybkości strony?
Każda milisekunda się liczy. Badania pokazują, że nawet ułamki sekund opóźnienia w ładowaniu strony mogą prowadzić do wzrostu współczynnika odrzuceń i spadku konwersji. Dla klienta Allegro, Pyszne.pl czy mBanku, który chce szybko dokonać płatności lub zamówić jedzenie, sekunda opóźnienia to często powód do frustracji i opuszczenia serwisu.
Opóźnienia wynikające z rezolucji DNS i nawiązywania połączeń to tzw. latencja. Na szybkich łączach światłowodowych w dużych miastach nie zawsze jest to odczuwalne, ale już na smartfonie, w pociągu, na słabszym zasięgu LTE, albo gdy serwer docelowy jest za oceanem, każda dodatkowa faza połączenia wydłuża czas oczekiwania. DNS prefetch i preconnect minimalizują ten czas, pozwalając przeglądarce na wykonanie części pracy w tle, zanim użytkownik faktycznie zobaczy potrzebę tych zasobów. Ma to bezpośredni wpływ na wskaźniki Core Web Vitals, takie jak LCP (Largest Contentful Paint) i TBT (Total Blocking Time).
Kiedy stosować dns-prefetch?
Stosuj dns-prefetch dla domen, które są prawdopodobne do wykorzystania, ale nie są natychmiast krytyczne dla załadowania głównej treści. Jest to bardziej bezpieczna i mniej obciążająca opcja, gdy masz wiele zewnętrznych zasobów.
- Usługi analityczne: Google Analytics, Hotjar, Clarity. Są one ważne, ale nie muszą być aktywne w pierwszej milisekundzie ładowania strony.
- Czcionki z zewnętrznych źródeł: Google Fonts (
fonts.gstatic.com,fonts.googleapis.com). Często kluczowe dla wyglądu strony, ale przeglądarka może zacząć je pobierać nieco później. - Widgety mediów społecznościowych: Facebook Pixel, skrypty Twittera, LinkedIn. Używane do śledzenia lub wyświetlania treści, ale nie niezbędne do pierwszej prezentacji strony.
- Zewnętrzne systemy komentarzy: Disqus.
- Skrypty reklamowe: Google Adsense, inne platformy reklamowe.
- Płatności: Jeśli na stronie masz bramki płatności takie jak Przelewy24, PayU, Stripe, które nie są osadzone bezpośrednio na stronie koszyka, ale pojawią się później (np. na stronie podsumowania zamówienia).
Przykład: Jeśli masz stronę z blogiem, która korzysta z Google Fonts i Google Analytics, a dodatkowo ma osadzony widget Facebooka, możesz dodać:
<link rel="dns-prefetch" href="https://fonts.gstatic.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">
<link rel="dns-prefetch" href="https://connect.facebook.net">Kiedy stosować preconnect?
preconnect rezerwuj dla domen, które są absolutnie krytyczne i na pewno będą użyte bardzo wcześnie w procesie ładowania strony. Pamiętaj, że nawiązanie pełnego połączenia zużywa więcej zasobów systemowych przeglądarki, więc nie przesadzaj z ich liczbą (zazwyczaj 2-4 wystarczą).
- CDN (Content Delivery Network): Jeśli używasz CDN do dostarczania obrazów, skryptów, styli CSS (np. Cloudflare, Netlify CDN, jsDelivr). To są zasoby kluczowe dla szybkiego renderowania strony.
- Kluczowe API: Jeśli Twoja strona jest aplikacją SPA (Single Page Application) i natychmiast po załadowaniu HTML-a odpytuje zewnętrzne API o kluczowe dane, to
preconnectjest idealny. - Krytyczne bramki płatności: Jeśli strona koszyka wymaga natychmiastowego połączenia z Przelewy24 lub ING, aby pobrać skrypt odpowiedzialny za interfejs płatności,
preconnectprzyspieszy jego pojawienie się. - Zewnętrzne biblioteki JavaScript: Jeśli ładujesz np. Reacta, Vue.js, jQuery z zewnętrznego CDN i jest to kluczowe dla funkcjonalności strony.
Przykład: Strona e-commerce, która korzysta z CDN dla obrazów i ma kluczowy skrypt z zewnętrznej domeny:
<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://api.example.com">Praktyczne przykłady użycia w kodzie HTML
Obie dyrektywy umieszcza się w sekcji <head> Twojej strony, najlepiej na początku, aby przeglądarka miała czas na wykonanie tych operacji zanim zacznie parsować resztę dokumentu.
<!DOCTYPE html>
<html lang="pl">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Moja Super Strona</title>
<!-- Optymalizacje wydajności -->
<link rel="dns-prefetch" href="https://fonts.gstatic.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">
<link rel="preconnect" href="https://cdn.moja-firma.pl">
<link rel="preconnect" href="https://payments.przelewy24.pl" crossorigin> <!-- Zwróć uwagę na crossorigin dla zasobów z CORS -->
<!-- Pozostałe style i skrypty -->
<link rel="stylesheet" href="/css/style.css">
<script src="/js/main.js" defer></script>
</head>
<body>
<!-- Treść strony -->
</body>
</html>Ważna uwaga: dla preconnect, jeśli zasób jest pobierany z atrybutem crossorigin (np. czcionki z Google Fonts, niektóre skrypty), należy dodać atrybut crossorigin również do tagu <link rel="preconnect">, aby uniknąć podwójnego nawiązywania połączenia.
Jak zidentyfikować, które zasoby warto optymalizować?
To pytanie za 100 punktów, a odpowiedź jest prosta: narzędzia deweloperskie w przeglądarce i serwisy takie jak Google PageSpeed Insights, GTmetrix czy WebPageTest. W SISL, kiedy nasi klienci, często właściciele małych i średnich firm lub startupów, zgłaszają problemy z wydajnością, zaczynamy od dogłębnej analizy.
- Narzędzia deweloperskie przeglądarki (zakładka Network): Otwórz narzędzia deweloperskie (F12), przejdź do zakładki „Network” i odśwież stronę. Zobaczysz kaskadę ładowania zasobów. Szukaj pozycji, gdzie widać wyraźne bloki związane z „DNS Lookup”, „Initial Connection” lub „SSL Handshake” dla zewnętrznych domen. To są Twoi kandydaci.
- PageSpeed Insights / GTmetrix / WebPageTest: Te narzędzia oferują bardziej zaawansowane wykresy „waterfall” (kaskadowe), które jasno pokazują, ile czasu zajmuje każdy etap ładowania zasobu. Skup się na domenach, które pojawiają się wcześnie na wykresie, a mają długie czasy nawiązywania połączeń.
- Zewnętrzne skrypty i zasoby: Pomyśl o wszystkim, co ładujesz spoza swojej głównej domeny. Czy to Google Analytics, reklamy, czcionki, biblioteki JavaScript, ikony, mapy, czy systemy komentarzy. Każdy z nich to potencjalny kandydat.
Jako butikowe studio SISL, weryfikujemy każde zewnętrzne połączenie, aby upewnić się, że nie spowalnia ono strony. W końcu, co z tego, że strona wygląda pięknie, jeśli użytkownik musi czekać, jak na wizytę w urzędzie skarbowym.
Mity i pułapki — kiedy te optymalizacje szkodzą?
Choć DNS prefetch i preconnect są potężnymi narzędziami, niewłaściwe użycie może przynieść więcej szkody niż pożytku.
- Nadmierne stosowanie
preconnect: Przeglądarka ma ograniczoną liczbę połączeń, które może nawiązać jednocześnie. Jeśli zasypiesz ją dziesiątkamipreconnect, może to spowodować, że te naprawdę krytyczne połączenia będą musiały czekać, lub przeglądarka porzuci mniej ważne, by zrobić miejsce nowym. Zamiast przyspieszyć, spowolnisz stronę. Optymalna liczba to zazwyczaj 2-4 dla najbardziej krytycznych zasobów. - Niepotrzebne prefetch/preconnect: Jeśli „prefisz” domenę, która nigdy nie zostanie użyta (np. dla usługi, z której zrezygnowałeś, ale zapomniałeś usunąć link), marnujesz zasoby klienta i przeglądarki.
- Wpływ HTTP/2 i HTTP/3: W środowisku HTTP/2, gdzie wiele zasobów może być przesyłanych przez jedno połączenie TCP, znaczenie
preconnectdla zasobów z tej samej domeny maleje. Jednak dla zasobów z różnych domen, nadal jest bardzo przydatne. HTTP/3 (QUIC) jeszcze bardziej minimalizuje narzut związany z nawiązywaniem połączeń, ale jego adopcja wciąż rośnie. - DNS prefetch dla własnej domeny: Całkowicie bez sensu. Przeglądarka już zna IP Twojej domeny, gdy ją odwiedza.
crossorigin: Brak tego atrybutu wpreconnectdla zasobów CORS (np. czcionki) może sprawić, że przeglądarka nawiąże dwa połączenia zamiast jednego. Upewnij się, że używasz go poprawnie.
Podsumowanie — czy warto się w to bawić?
Zdecydowanie tak. DNS prefetch i preconnect to jedne z tych „małych rzeczy”, które sumują się do znaczącej poprawy wydajności. W dobie, gdy użytkownicy OLX czy Pyszne.pl oczekują natychmiastowych reakcji, a Google premiuje szybkie strony, ignorowanie takich optymalizacji to strzelanie sobie w stopę.
Niewielki wysiłek włożony w prawidłowe wdrożenie tych dyrektyw może przynieść realne korzyści w postaci szybszego ładowania, lepszego doświadczenia użytkownika i wyższych pozycji w wynikach wyszukiwania. Pamiętaj jednak o umiarze i analizie – kluczem jest selektywne stosowanie dla tych zasobów, które naprawdę na to zasługują. Jeśli czujesz, że optymalizacja wydajności Twojej strony to czarna magia, albo po prostu brakuje Ci czasu, napisz do nas. W SISL podchodzimy do takich tematów z konkretami, bez zbędnych „synergii”.