Spis treści
- Wprowadzenie – znaczenie preloadingu dla szybkości strony
- Identyfikacja krytycznych zasobów do preloadingu
- Preload CSS i czcionek
- Preloading obrazów wpływających na LCP
- Prefetch dla zasobów przyszłych stron
- Preconnect do zewnętrznych domen i API
- Optymalizacja kolejności ładowania zasobów
- Testowanie wpływu preloadingu na Core Web Vitals
- Dostosowanie preloadingu do urządzeń
- Podsumowanie
- Najczęstsze pytania
Wprowadzenie – znaczenie preloadingu dla szybkości strony
Preload zasobów podpowiada przeglądarce, że plik potrzebny na bieżącej stronie warto pobrać wcześniej. Jest przydatny, gdy ważny zasób pojawia się dopiero w arkuszu CSS albo jest dodawany przez JavaScript. Sam preload nie wyświetla obrazu, nie stosuje CSS i nie uruchamia skryptu – właściwe odwołanie do zasobu nadal musi istnieć.
Nie jest to przycisk „przyspiesz stronę”. Dodatkowe żądania konkurują o łącze z innymi plikami, więc niepotrzebny preload może opóźnić renderowanie. Zacznij od pomiaru, nie od dodawania wskazówek do wszystkich zasobów.
Identyfikacja krytycznych zasobów do preloadingu
- Uruchom PageSpeed Insights dla konkretnego adresu i sprawdź, jaki element jest kandydatem do LCP na telefonie i komputerze. Może to być obraz albo tekst.
- W Chrome DevTools otwórz Network, zaznacz wyłączenie cache, odśwież stronę i obejrzyj waterfall. Sprawdź, kiedy rozpoczyna się pobieranie zasobu LCP i który plik go odkrywa.
- Jeśli istotny obraz tła lub czcionka są odkrywane dopiero po pobraniu CSS, sprawdź preload tego konkretnego pliku. Gdy zasób jest już wcześnie widoczny w HTML, dodatkowa wskazówka często nie pomaga.
Sprawdź osobno szablony stron: obraz na stronie głównej nie musi występować w artykule. Preload nieużywanego pliku to zmarnowany transfer.
Implementacja preload dla kluczowych CSS
Główny arkusz najlepiej wskazać zwykłym rel="stylesheet" w head. Przeglądarka odkrywa go wtedy wcześnie; dodanie preloadu tego samego arkusza nie musi nic poprawić. Jeśli CSS jest odkrywany późno, na przykład przez @import, najpierw rozważ bezpośrednie dołączenie arkusza.
Jeśli pomiar uzasadnia preload arkusza, zachowaj również zwykły link do stylów – sam preload ich nie zastosuje:
<link rel="preload" href="/css/wazny.css" as="style">
<link rel="stylesheet" href="/css/wazny.css">
Adres jest przykładowy. Nie zastępuj bez testów głównego arkusza sztuczką z onload: opóźnione style mogą spowodować błysk niesformatowanej treści, a polityka CSP może blokować kod inline.
Preload czcionki
Plik wskazany w @font-face może być odkrywany późno. Jeżeli rzeczywiście jest używany od razu, przetestuj:
<link rel="preload" href="/fonts/tekst-regular.woff2" as="font" type="font/woff2" crossorigin>
Użyj dokładnie tego samego adresu i wariantu, co w CSS. crossorigin jest potrzebny także dla czcionki z własnej domeny; dla zewnętrznego hosta odpowiedź musi dodatkowo zezwalać na CORS. Preload każdej grubości lub zestawu znaków zwiększa transfer. Przetestuj też font-display i przesunięcia układu po podmianie czcionki.
Preloading obrazów wpływających na LCP
Najpierw umieść ważny obraz w początkowym HTML, nie ustawiaj mu loading="lazy" i rozważ fetchpriority="high". Preload bywa bardziej użyteczny dla obrazu tła z CSS lub obrazu wstawianego później przez JavaScript:
<link rel="preload" href="/images/hero.webp" as="image" fetchpriority="high">
Przykładowy adres zastąp rzeczywistym adresem obrazu. Dla responsywnego img wartości preloadu muszą odpowiadać srcset i sizes obrazu:
<link rel="preload" as="image" fetchpriority="high"
imagesrcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
imagesizes="100vw">
<img src="/images/hero-800.webp"
srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
sizes="100vw" width="1600" height="900" fetchpriority="high" alt="Opis obrazu">
Wymiary, opis i sizes dopasuj do rzeczywistego obrazu i układu. Pominięcie href we wskazówce zapobiega pobraniu niewłaściwego wariantu przez przeglądarkę bez obsługi responsywnego preloadu; obraz nadal załaduje się przez img. Nie preloaduj równocześnie AVIF i WebP tego samego obrazu – przeglądarka obsługująca oba formaty może pobrać oba. Sprawdź w Network, czy nie ma podwójnych pobrań.
Konfiguracja prefetch dla zasobów przyszłych stron
prefetch dotyczy zasobu, który może przydać się podczas późniejszej nawigacji; przeglądarka może zignorować tę wskazówkę. Stosuj ją oszczędnie, np. do publicznego arkusza używanego na prawdopodobnej kolejnej stronie:
<link rel="prefetch" href="/css/oferta.css" as="style">
To nie jest zamiennik preloadu dla bieżącej strony. Nie pobieraj spekulacyjnie stron zawierających dane użytkownika ani adresów wykonujących operacje, np. wylogowanie czy dodanie produktu do koszyka. Uwzględnij koszt transferu, cache, prywatność i ustawienia zgody dla usług zewnętrznych.
Preconnect do zewnętrznych domen i API
preconnect może rozpocząć nawiązywanie połączenia z zewnętrznym źródłem, zanim przeglądarka zażąda pliku. Ma sens dla domeny, z której zasób jest potrzebny wcześnie; wiele nieużytych połączeń to dodatkowy koszt. Przykład dla zewnętrznego serwera czcionek:
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Adres zastąp domeną faktycznego dostawcy. Tryb crossorigin powinien odpowiadać późniejszemu żądaniu; czcionki wymagają go również przy preconnect. Wskazówka może spowodować kontakt z dostawcą przed pobraniem pliku, dlatego nie stosuj jej do usług wymagających zgody, zanim będzie to dozwolone. dns-prefetch rozwiązuje tylko nazwę domeny, a nie nawiązuje pełnego połączenia.
Optymalizacja kolejności ładowania zasobów
Uprość łańcuch zależności: umieszczaj potrzebny CSS w HTML, ogranicz @import i nie ukrywaj ważnego obrazu za skryptem, jeśli może znaleźć się od razu w dokumencie. Dla skryptów niezależnych rozważ async, a dla klasycznych skryptów wymagających zachowania kolejności – defer. Po zmianie sprawdź zależności i działanie strony.
Preload przyspiesza odkrycie zasobu, natomiast fetchpriority jest osobną wskazówką dotyczącą priorytetu. Przeglądarka podejmuje ostateczną decyzję. Nadanie wysokiego priorytetu wielu plikom odbiera korzyść z wyróżnienia najważniejszego.
Testowanie wpływu preloadingu na Core Web Vitals
- Zapisz wynik bazowy dla reprezentatywnego adresu, osobno dla telefonu i komputera. Powtórz test laboratoryjny kilka razy w tych samych warunkach.
- Wprowadź jedną zmianę i porównaj LCP, waterfall, liczbę żądań oraz transfer. Sprawdź konsolę pod kątem ostrzeżeń o nieużytym preloadzie.
- W PageSpeed Insights i raporcie Core Web Vitals w Search Console sprawdź dane rzeczywistych użytkowników, jeśli są dostępne. Dane terenowe obejmują inny okres i warunki niż pojedynczy test laboratoryjny.
- Obserwuj także CLS i INP: preload sam ich nie naprawia, a zmiana kolejności pobierania lub czcionki może wpłynąć na inne elementy strony. Jeśli wynik się pogorszył lub zasób pobierany jest podwójnie, wycofaj wskazówkę.
Core Web Vitals to obecnie LCP, INP i CLS; FCP jest dodatkową metryką diagnostyczną. Preload nie skraca czasu odpowiedzi serwera TTFB. Różnice między testami mogą wynikać z sieci, cache lub urządzenia, dlatego pojedynczy wynik nie dowodzi poprawy.
Dynamiczne dostosowywanie preloadingu dla urządzeń
Nie musisz budować systemu wykrywającego urządzenie. Dla obrazów o różnych rozmiarach zacznij od srcset i sizes; jeśli preload jest uzasadniony, użyj odpowiadających im imagesrcset i imagesizes. Dla różnych obrazów w różnych przedziałach ekranu można rozważyć wzajemnie wykluczające się warunki media, zgodne z faktycznym wyborem obrazu.
Testuj osobno wąski i szeroki ekran oraz wolniejsze połączenie. API informacji o sieci i wskazówki dotyczące oszczędzania danych nie są dostępne jednakowo we wszystkich przeglądarkach; ich brak nie może blokować podstawowego działania strony.
Podsumowanie – poprawa szybkości ładowania strony
- Znajdź faktyczny element LCP i opóźnienie w waterfall.
- Najpierw ułatw przeglądarce wczesne odkrycie zasobu; preload dodaj tylko tam, gdzie pomiar wskazuje potrzebę.
- Dopasuj adres,
as, wariant obrazu i tryb CORS do rzeczywistego użycia. - Porównaj wyniki i usuń wskazówki, które nie pomagają lub powodują dodatkowy transfer.
Dokumentacja: web.dev – resource hints, web.dev – responsywne obrazy oraz MDN – rel="preload".
Najczęstsze pytania
Jakie są najczęstsze błędy przy implementacji preloadingu zasobów?
To przede wszystkim preload zbyt wielu plików, niezgodny adres lub tryb CORS oraz wstępne pobieranie obrazu, który nie jest używany na danej stronie. Sprawdź żądania w panelu Network i usuń niepotrzebne wskazówki.
Czy preloading zasobów wpływa na SEO strony?
Preload może poprawić szybkość strony i LCP, ale nie gwarantuje wyższej pozycji w wyszukiwarce. Zbyt wiele preloadów może także pogorszyć wydajność, dlatego efekt trzeba zmierzyć.
Jak preloading zasobów działa w połączeniu z CDN?
Preload może wskazywać plik na CDN, jeśli adres i sposób pobierania odpowiadają późniejszemu użyciu. Cache i nagłówki CDN trzeba skonfigurować osobno; sam preload ich nie ustawia.
Czy preloading jest kompatybilny ze starszymi przeglądarkami?
Przeglądarka, która nie obsługuje danej wskazówki, może ją zignorować. Zasób nadal musi być poprawnie dołączony w HTML lub CSS; do samego preloadu nie jest potrzebny polyfill.
Jak monitorować skuteczność strategii preloadingu?
Porównaj testy przed zmianą i po niej w podobnych warunkach. W DevTools sprawdź kolejność i liczbę żądań, a w PageSpeed Insights dane laboratoryjne i, jeśli są dostępne, dane rzeczywistych użytkowników.
Czym jest preloading zasobów i dlaczego jest ważny dla wydajności strony?
Preload to wskazówka, która pozwala przeglądarce wcześniej pobrać zasób potrzebny na bieżącej stronie. Przydaje się zwłaszcza wtedy, gdy ważny obraz lub czcionka są odkrywane dopiero po pobraniu CSS.
Jak działa link rel="preload" i kiedy należy go używać?
Link z rel="preload" rozpoczyna wcześniejsze pobieranie wskazanego zasobu, ale sam nie stosuje stylów ani nie uruchamia skryptu. Używaj go dla istotnych, późno odkrywanych plików i dobierz właściwy atrybut as.
Które zasoby warto preloadować, aby poprawić Core Web Vitals?
Kandydatami są późno odkrywany obraz LCP lub plik czcionki używanej od razu w widocznej treści. Wybór zależy od wyniku pomiaru; nie ma uniwersalnej listy zasobów ani liczby preloadów.
Jaka jest różnica między preload, prefetch a preconnect?
Preload pobiera zasób potrzebny na bieżącej stronie, prefetch może przygotować zasób na przyszłą nawigację, a preconnect wcześniej nawiązuje połączenie z inną domeną. Są to wskazówki, a nie gwarancja działania w każdej przeglądarce.
Jak wdrożyć preloading obrazów, które wpływają na LCP?
Najpierw ustal, czy obraz LCP jest odkrywany z opóźnieniem. Jeśli tak, rozważ preload z as="image"; dla wariantów responsywnych dopasuj imagesrcset i imagesizes do srcset i sizes obrazu, a następnie sprawdź, czy pobierany jest właściwy plik tylko raz.
Potrzebujesz pomocy w optymalizacji wydajności strony? Pomożemy znaleźć zasoby opóźniające renderowanie i sprawdzić efekty zmian.