Preload, prefetch i preconnect: kiedy każde z nich naprawdę pomaga
Resource hints są przydatne, gdy odpowiadają na rzeczywiste wąskie gardła przeglądarki. Używane na ślepo, dodają szum priorytetów i czasem spowalniają strony.
Spis treści
- Resource hints nie są magią
- Co przeglądarka już robi dobrze
- Preload: dla zasobów bieżącej strony odkrywanych zbyt późno
- Preload i obrazy LCP
- Prefetch: dla następnej strony, nie tej
- Preconnect: dla kosztownych połączeń do ważnych originów
- DNS-prefetch: lżejszy kuzyn
- Jak zdecydować: praktyczny workflow
- 1. Zidentyfikuj wąskie gardło
- 2. Dodawaj po jednej wskazówce naraz
- 3. Sprawdź skutki uboczne priorytetów
- 4. Zweryfikuj nagłówki i cache
- Częste błędy
- Preload zbyt wielu rzeczy
- Używanie prefetch dla wymaganych zasobów
- Preconnect do każdej firmy trzeciej
- Zapominanie o warunkach mobilnych
- Prosta tabela decyzyjna
- Spokojna reguła
Resource hints nie są magią
preload, prefetch i preconnect są często traktowane jak lista kontrolna wydajności. Dodaj kilka tagów do <head>, uruchom ponownie Lighthouse, poczuj się lepiej. To nie tak działa.
Te wskazówki są instrukcjami dla potoku ładowania przeglądarki. Mogą pomóc, gdy wiesz coś, czego przeglądarka nie jest w stanie odkryć wystarczająco wcześnie. Mogą zaszkodzić, gdy zgadujesz, nadajesz zbyt wysoki priorytet pracy niekrytycznej albo rozgrzewasz połączenia, których użytkownicy nigdy nie będą potrzebować.
Krótka wersja:
- Używaj
preloaddla zasobów wymaganych przez bieżącą stronę, ale odkrywanych zbyt późno. - Używaj
prefetchdla prawdopodobnych zasobów przyszłej nawigacji, nie dla elementów niezbędnych na bieżącej stronie. - Używaj
preconnectdla ważnych originów firm trzecich, gdzie zestawienie połączenia jest rzeczywistym opóźnieniem.
Praktyczne pytanie nie brzmi „która wskazówka jest najszybsza?”. Brzmi: „na co czeka przeglądarka i czy ta wskazówka może to oczekiwanie usunąć?”.
Co przeglądarka już robi dobrze
Nowoczesne przeglądarki nie są biernymi programami do pobierania plików. Parsują HTML, skanują z wyprzedzeniem w poszukiwaniu zasobów, przypisują priorytety, ponownie używają połączeń, opóźniają pracę, która nie jest widoczna, i dostosowują się do warunków sieciowych.
To oznacza, że resource hints powinny być selektywne. Jeśli arkusz stylów, skrypt, obraz albo font jest już odkrywany wcześnie i ma właściwy priorytet, dodanie wskazówki może nie zrobić nic. Co gorsza, może konkurować z zasobami, które mają większe znaczenie.
Zanim dodasz wskazówki, obejrzyj wykres waterfall w DevTools albo raport laboratoryjny. Jeśli używasz Lighthouse, zacznij od diagnostyki, a nie od wyniku; mamy osobny przewodnik o czytaniu raportu Lighthouse bez paniki — ale pamiętaj, że poprawny URL rozróżnia wielkość liter, więc w razie potrzeby użyj podlinkowanego artykułu z nawigacji swojej witryny.
Prawdziwe dowody zwykle widać w trzech miejscach:
- Krytyczny zasób startuje późno, ponieważ przeglądarka odkrywa go późno.
- Połączenie z ważnym originem zajmuje zauważalny czas przed pierwszym żądaniem.
- Zasób następnej strony jest bardzo przewidywalny i tani do pobrania w czasie bezczynności.
Jeśli żadna z tych rzeczy nie jest prawdziwa, wskazówka prawdopodobnie jest tylko dekoracją.
Preload: dla zasobów bieżącej strony odkrywanych zbyt późno
preload mówi przeglądarce: „Pobierz ten zasób teraz, ponieważ bieżąca strona będzie go potrzebować”.
Typowym przykładem jest font webowy wskazany wewnątrz CSS. Przeglądarka musi pobrać HTML, odkryć CSS, pobrać CSS, sparsować go, odkryć font, a dopiero potem zażądać fontu. Jeśli ten font jest ważny dla tekstu widocznego above-the-fold, odkrycie może nastąpić na tyle późno, że spowoduje przesunięcia układu albo opóźnione renderowanie tekstu.
Preload może przesunąć to żądanie wcześniej:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Atrybut as ma znaczenie. Mówi przeglądarce, jakiego rodzaju jest to zasób, co wpływa na priorytet, cache, content security policy i nagłówki żądania. Fonty zwykle potrzebują też crossorigin, nawet gdy są serwowane z tej samej witryny, ponieważ pobieranie fontów używa trybu CORS.
Dobre kandydatury do preload to między innymi:
- Główny font webowy używany do widocznego tekstu.
- Obraz hero, który jest elementem Largest Contentful Paint i nie jest odkrywalny wcześnie.
- Krytyczny plik CSS ładowany pośrednio.
- Moduł lub skrypt potrzebny bardzo wcześnie, ale ukryty za innym skryptem.
Złe kandydatury do preload to między innymi:
- Każda grubość fontu w design systemie.
- Obrazy below-the-fold.
- Skrypty, które nie są potrzebne do początkowego renderowania.
- Zasoby, które przeglądarka już odkrywa w pierwszym fragmencie HTML.
Preload jest potężny, ponieważ wpływa na priorytet bieżącej strony. Z tego samego powodu łatwo go nadużyć. Jeśli preloadujesz pięć dużych zasobów, przestajesz pomagać przeglądarce. Zaczynasz się z nią spierać.
Fonty są klasycznym przypadkiem. Preload jednego głównego pliku fontu może pomóc. Preload sześciu grubości i kursyw zwykle pogarsza sytuację. Jeśli fonty są twoim wąskim gardłem, najpierw uporządkuj zestaw fontów; nasz przewodnik o tym, dlaczego fonty webowe nadal są najłatwiejszą wygraną wydajnościową na większości stron, opisuje to porządkowanie bardziej szczegółowo.
Preload i obrazy LCP
Preload obrazu LCP może być przydatny, gdy obraz nie jest widoczny w początkowym HTML. Częste przyczyny to obrazy tła w CSS, komponenty renderowane po stronie klienta albo logika obrazów responsywnych, która pojawia się późno.
Ale jeśli twój obraz hero jest już w HTML jako <img> z sensownym srcset, sizes, wymiarami i bez lazy loadingu, przeglądarka prawdopodobnie znajdzie go szybko. W takim przypadku dodanie fetchpriority='high' może być bardziej odpowiednie niż preload, zależnie od strony.
Dobry test: jeśli żądanie obrazu zaczyna się późno na wykresie waterfall i obraz staje się elementem LCP, rozważ preload. Jeśli zaczyna się wcześnie, ale pobiera wolno, problemem jest rozmiar, format, zachowanie CDN albo opóźnienie serwera — nie odkrywanie. W kwestii decyzji o formatach obrazów zobacz kiedy AVIF pokonuje WebP, a kiedy nie.
Prefetch: dla następnej strony, nie tej
prefetch mówi przeglądarce: „Ten zasób może być wkrótce potrzebny, ale nie jest wymagany teraz”.
To rozróżnienie jest ważne. Prefetch ma celowo niski priorytet. Przeglądarka może pobrać go w czasie bezczynności i zachować do późniejszego użycia. Może też pominąć go przy słabych połączeniach, w trybach oszczędzania danych albo pod presją pamięci.
Używaj prefetch, gdy intencja użytkownika jest wystarczająco silna, by następny zasób był prawdopodobny.
Dobre kandydatury do prefetch to między innymi:
- Następny krok w wielostronicowym checkout.
- Wyniki wyszukiwania po tym, jak użytkownik zacznie wpisywać zapytanie, jeśli następna trasa jest przewidywalna.
- Strony dokumentacji podlinkowane ze spisu treści, gdy użytkownik aktywnie czyta pobliską treść.
- Fragmenty tras w aplikacji single-page po najechaniu lub sfokusowaniu elementu nawigacji przez użytkownika.
Złe kandydatury do prefetch to między innymi:
- Całe drzewo nawigacji.
- Duże filmy albo galerie obrazów.
- Skrypty firm trzecich „na wszelki wypadek”.
- Strony, które użytkownicy rzadko odwiedzają jako następne.
Prefetch to obszar, w którym powściągliwość się opłaca. Zasób pobrany i nigdy nieużyty nie jest darmowy. Zużywa przepustowość, zasoby serwera, energię i potencjalnie dane użytkownika. W sieciach mobilnych pobieranie spekulacyjne może być aktywnie nieprzyjazne.
Dla wielu witryn najlepszą strategią prefetch jest strategia oparta na intencji. Nie pobieraj strony z cennikiem przez prefetch od razu po załadowaniu strony głównej. Zrób to, gdy użytkownik otworzy menu cennika, najedzie na link do cennika albo przewinie w pobliże call-to-action, które mocno przewiduje nawigację.
Pamiętaj też, że zachowanie przeglądarek się różni. Niektóre przeglądarki podchodzą do prefetch zachowawczo; część ustawień prywatności ogranicza albo wyłącza ładowanie spekulacyjne. Traktuj prefetch jako oportunistyczne usprawnienie, nie jako mechanizm poprawności.
Preconnect: dla kosztownych połączeń do ważnych originów
preconnect mówi przeglądarce: „Zacznij teraz zestawiać połączenie z tym originem”.
Może to obejmować wyszukiwanie DNS, połączenie TCP i negocjację TLS. Dla originów firm trzecich takie przygotowanie może zająć setki milisekund, zwłaszcza w sieciach o wysokiej latencji. Jeśli strona wkrótce potrzebuje krytycznego żądania z tego originu, preconnect może przyspieszyć późniejsze żądanie.
Przykład:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Dobre kandydatury do preconnect to między innymi:
- Origin fontów używany dla tekstu blokującego renderowanie.
- Krytyczny origin API potrzebny podczas początkowej interakcji.
- Origin CDN serwujący zasoby above-the-fold.
- Dostawca płatności albo tożsamości potrzebny natychmiast po akcji użytkownika.
Złe kandydatury do preconnect to między innymi:
- Endpointy analityczne i reklamowe, które nie są krytyczne dla użytkownika.
- Originy używane tylko w niektórych sesjach.
- Długie listy firm trzecich.
- Zasoby z tego samego originu, gdzie przeglądarka już ma albo wkrótce otworzy połączenie.
Preconnect ma koszt utrzymania. Otwarte sockety zużywają pamięć i zasoby sieciowe. Przeglądarki zamykają nieużywane połączenia, ale to nie sprawia, że niepotrzebne preconnect są nieszkodliwe.
Przydatna reguła: używaj preconnect najwyżej do jednego lub dwóch originów firm trzecich o wysokiej pewności na stronie. Jeśli kusi cię, by dodać więcej, twoja architektura firm trzecich prawdopodobnie bardziej wymaga przeglądu niż twoje wskazówki wymagają rozbudowy.
DNS-prefetch: lżejszy kuzyn
Możesz też spotkać dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>To tylko rozwiązuje nazwę domeny. Nie otwiera połączenia TCP ani TLS. Jest tańsze niż preconnect, ale też mniej pomocne.
DNS-prefetch może być rozsądny dla originów firm trzecich o niższej pewności, gdzie pełny preconnect wydaje się zbyt agresywny. W praktyce, jeśli origin jest krytyczny i na pewno będzie wkrótce użyty, wybierz preconnect. Jeśli jest jedynie możliwy, użyj DNS-prefetch albo nie rób nic.
Jak zdecydować: praktyczny workflow
Zacznij od pomiaru, nie od tagów.
1. Zidentyfikuj wąskie gardło
Otwórz trace wydajnościowy i poszukaj późnego odkrywania. Czy żądanie fontu, obrazu hero albo skryptu zaczęło się dopiero po pobraniu i sparsowaniu innego pliku? To kandydat do preload.
Jeśli żądanie zaczyna się dopiero po długim zestawianiu DNS/TCP/TLS do originu firmy trzeciej, to kandydat do preconnect.
Jeśli bieżąca strona działa dobrze, ale następna nawigacja jest przewidywalnie wolna, prefetch może pomóc.
2. Dodawaj po jednej wskazówce naraz
Resource hints wchodzą ze sobą w interakcje. Dodaj jedną, przetestuj ją i zostaw tylko wtedy, gdy waterfall się poprawia, a metryki widoczne dla użytkownika się nie pogarszają.
W przypadku preload obserwuj, czy wskazany zasób rzeczywiście jest szybko używany. Chrome może ostrzec, gdy zasób pobrany przez preload nie zostanie użyty krótko po załadowaniu. Traktuj to ostrzeżenie poważnie.
3. Sprawdź skutki uboczne priorytetów
Preload może odciągnąć przepustowość od CSS, JavaScriptu albo obrazów, które mają większe znaczenie. Preconnect może zająć slot połączenia. Prefetch może dodać ruch w tle.
Właściwy rezultat to nie „wskazany plik startuje wcześniej”. Właściwy rezultat to „strona staje się odczuwalnie lepsza dla użytkowników”. Patrz na LCP, INP, CLS i, gdy to możliwe, monitoring rzeczywistych użytkowników.
4. Zweryfikuj nagłówki i cache
Wskazówki mogą być wysyłane w HTML albo w nagłówkach HTTP Link. Nagłówki są przydatne, gdy serwer wcześnie wie, czego strona będzie potrzebować, ale trudniej je pobieżnie sprawdzić. Jeśli debugujesz, czy wskazówka rzeczywiście jest obecna na produkcji, surowe nagłówki mają znaczenie; to dokładnie taki przypadek, jaki opisuje nasz przewodnik po debugowaniu przekierowań i nagłówków HTTP.
Cache również ma znaczenie. Preload zasobu z niedopasowanymi credentials, błędnym as albo innymi parametrami URL może spowodować podwójne pobranie. To jeden z najczęstszych sposobów, w jaki preload dodany w dobrej wierze staje się błędem wydajnościowym.
Częste błędy
Preload zbyt wielu rzeczy
Jeśli wszystko jest krytyczne, nic nie jest. Ogranicz preload do zasobów potrzebnych do początkowego renderowania albo natychmiastowej interaktywności. Typowa strona powinna mieć od zera do trzech preloadów, nie dwadzieścia.
Używanie prefetch dla wymaganych zasobów
Prefetch ma niski priorytet i jest opcjonalny. Nie używaj go dla zasobów wymaganych przez bieżącą stronę. Jeśli strona potrzebuje czegoś teraz, rozważ preload albo normalne odkrywanie w HTML.
Preconnect do każdej firmy trzeciej
Strony obciążone firmami trzecimi często mają dziesięć albo więcej zewnętrznych originów. Preconnect do wszystkich tworzy szum. Wybierz jeden lub dwa, które są jednocześnie krytyczne i przewidywalnie używane.
Zapominanie o warunkach mobilnych
Resource hints są najcenniejsze na wolniejszych połączeniach, ale tam są też najbardziej niebezpieczne. Zmarnowany prefetch na szybkim połączeniu desktopowym to błąd zaokrąglenia. Na ograniczonym planie mobilnym to zły kompromis.
Prosta tabela decyzyjna
| Sytuacja | Najlepsza wskazówka | Dlaczego | |---|---:|---| | Krytyczny font odkrywany przez CSS | preload | Bieżąca strona go potrzebuje, odkrycie jest późne | | Obraz hero ukryty za CSS albo renderowaniem po stronie klienta | preload | Może poprawić LCP, jeśli obraz startuje późno | | Prawdopodobna następna trasa po intencji użytkownika | prefetch | Pomaga przyszłej nawigacji bez blokowania bieżącej strony | | Krytyczny origin fontów/API firmy trzeciej | preconnect | Usuwa zestawianie połączenia ze ścieżki krytycznej | | Możliwy, ale niepewny origin firmy trzeciej | dns-prefetch albo nic | Niższy koszt, niższa pewność | | Obraz below-the-fold | brak | Pozwól działać lazy loadingowi i priorytetom przeglądarki |
Spokojna reguła
Resource hints działają najlepiej, gdy są nudne i konkretne. Jeden font. Jeden obraz LCP. Jeden ważny origin firmy trzeciej. Jedna prawdopodobna następna trasa po intencji.
Działają słabo, gdy są używane jako optymizm: może użytkownik będzie tego potrzebować, może przeglądarka powinna pobrać tamto, może więcej wskazówek oznacza większą szybkość.
Przeglądarki już agresywnie optymalizują. Twoim zadaniem nie jest mikrozarządzanie każdym żądaniem. Twoim zadaniem jest skorygowanie tych kilku przypadków, w których przeglądarce brakuje informacji we właściwym momencie.
Najczęściej zadawane pytania
Czy powinienem preloadować wszystkie fonty?
Czy prefetch jest bezpieczny dla każdego linku wewnętrznego?
Jaka jest różnica między preconnect a dns-prefetch?
Czy resource hints mogą poprawić Core Web Vitals?
Czy resource hints należy dodawać w HTML czy w nagłówkach HTTP?
Źródła i dalsza lektura
