Prefetching i preloading: kiedy przyspieszają stronę, a kiedy marnują transfer

Prefetching i preloading nie są magicznym dopalaczem dla każdej strony. To instrukcje dla przeglądarki, które mówią, co pobrać wcześniej. Źle użyte potrafią zająć pasmo zasobami, których użytkownik wcale nie potrzebuje.

Największy sens mają przy krytycznych fontach, głównym obrazie LCP, ważnym skrypcie albo bardzo prawdopodobnym następnym kroku użytkownika. Resztę lepiej mierzyć, zamiast zgadywać.

Różnica w praktyce

• preload: pobierz zasób potrzebny na tej stronie bardzo wcześnie
• prefetch: przygotuj zasób, który może przydać się na kolejnej stronie
• preconnect: wcześniej zestaw połączenie z zewnętrzną domeną
• dns-prefetch: rozwiąż DNS przed właściwym requestem
• modulepreload: przyspiesz ładowanie modułów JavaScript

Najczęstszy błąd to preloading wszystkiego. Przeglądarka ma ograniczone zasoby, więc priorytety trzeba ustawiać ostrożnie.

Jak wdrażać bez ryzyka

1. Zidentyfikuj zasób wpływający na LCP lub pierwszy render.
2. Dodaj preload tylko dla tego zasobu i właściwego typu.
3. Sprawdź ostrzeżenia w DevTools oraz Lighthouse.
4. Zmierz wpływ na mobile oraz desktop.
5. Usuń reguły, które nie zmieniają metryk albo powodują ostrzeżenia.

Dla wielu stron największy efekt daje preload głównego obrazu hero i dobre ładowanie fontów. Dla aplikacji warto analizować bundle i ścieżki użytkownika.

Czego pilnować

• preloadowany zasób musi być użyty szybko po starcie
• typ `as` musi pasować do zasobu
• fonty wymagają poprawnego crossorigin
• prefetch nie może wyciągać ciężkich plików na słabym łączu
• zmiana musi być sprawdzona w Core Web Vitals

Najlepsza optymalizacja jest konkretna. Jeśli nie wiesz, który zasób blokuje renderowanie, zacznij od pomiaru, a dopiero potem dodawaj preload lub prefetch.

Źródła pomocnicze: web.dev: resource hints, MDN: rel=preload.