Preload, preconnect i fetchpriority: jak podpowiedzieć przeglądarce, co pobrać najpierw

Czym są podpowiedzi dotyczące zasobów i po co się je stosuje

Podpowiedzi dotyczące zasobów (ang. resource hints) to informacje dla przeglądarki o tym, jak ładować pliki strony i w jakiej kolejności je traktować. Zapisuje się je w kodzie HTML, zwykle na początku sekcji head, albo wysyła w nagłówku odpowiedzi serwera. Tak opisuje je kurs wydajności w serwisie web.dev, w rozdziale Assist the browser with resource hints, który obejmuje znaczniki link o relacjach preconnect, dns-prefetch, preload i prefetch oraz atrybut fetchpriority.

Potrzeba podpowiadania bierze się stąd, że przeglądarka poznaje stronę stopniowo. Najpierw dostaje dokument HTML, w nim znajduje adresy arkuszy stylów, skryptów i obrazów, a dopiero w pobranych arkuszach i skryptach odkrywa kolejne pliki: czcionki, obrazy tła, moduły. Autor strony zna tę układankę z góry, a podpowiedź pozwala przekazać tę wiedzę przeglądarce, zanim sama do niej dojdzie.

Z punktu widzenia właściciela firmy liczy się skutek: szybciej widoczna treść w górnej części strony. Mierzy go wskaźnik LCP (ang. Largest Contentful Paint, czas wyświetlenia największego elementu treści), należący do podstawowych wskaźników internetowych. Według opracowania Optimize Largest Contentful Paint dobry wynik to najwyżej 2,5 sekundy dla co najmniej 75% wizyt, a wartości powyżej 4 sekund są oceniane jako słabe. Szerzej opisujemy ten wskaźnik we wpisie o tym, co opóźnia LCP na stronie i jak to naprawić.

Jak przeglądarka sama ustala kolejność pobierania

Przeglądarka przypisuje każdemu znalezionemu zasobowi priorytet pobierania i na tej podstawie układa kolejkę. Jak podaje web.dev w opracowaniu Optimize resource loading with the Fetch Priority API, priorytet zależy od rodzaju zasobu, jego położenia i kolejności w dokumencie oraz od tego, czy skrypt ma atrybut async lub defer. Zasoby o tym samym priorytecie pobierane są w kolejności, w jakiej zostały odkryte.

Te domyślne zasady zwykle działają dobrze, ale nie zawsze trafiają w potrzeby konkretnej strony. Najlepszym przykładem są obrazy. W Chrome obraz zaczyna z niskim priorytetem i dopiero po obliczeniu układu strony, gdy okaże się, że leży w widocznym obszarze, zostaje podniesiony do wysokiego. Do tego czasu przegrywa w kolejce ze skryptami i arkuszami stylów. Tabela pokazuje wybrane domyślne priorytety w Chrome w brzmieniu widocznym w narzędziach deweloperskich.

Drugim ograniczeniem jest to, co przeglądarka potrafi zauważyć sama. Podczas czytania dokumentu działa w niej skaner wstępnego ładowania (ang. preload scanner), który wyszukuje w kodzie HTML adresy plików i zleca ich pobranie z wyprzedzeniem. Skaner widzi obraz zapisany w atrybucie src lub srcset znacznika img, ale nie widzi obrazu dodawanego przez JavaScript, obrazu ukrytego w atrybutach danych przez skrypt leniwego ładowania ani obrazu tła zdefiniowanego w zewnętrznym arkuszu stylów. Takie zasoby są odkrywane późno i to właśnie dla nich przewidziano podpowiedzi. Zanim pojawi się pierwsza z nich, warto ustalić, co jest elementem LCP na najważniejszych podstronach, osobno na komputerze i na telefonie.

Preconnect i dns-prefetch: wcześniejsze połączenie z obcą domeną

Preconnect nakazuje przeglądarce wcześniej nawiązać połączenie z innym serwerem, a dns-prefetch ogranicza się do ustalenia jego adresu. Obie podpowiedzi mają sens wyłącznie dla domen innych niż domena samej strony. Szczegóły opisuje web.dev w opracowaniu Establish network connections early to improve perceived page speed.

Zanim przeglądarka pobierze plik z nowego serwera, musi wykonać trzy czynności: zamienić nazwę domeny na adres IP (zapytanie DNS), otworzyć połączenie z serwerem i je zaszyfrować. Każda z nich wymaga wymiany danych w obie strony, więc przygotowanie połączenia może oznaczać nawet trzy takie rundy, zanim popłynie pierwszy bajt właściwego pliku. Według web.dev wcześniejsze połączenie z ważnymi zewnętrznymi domenami potrafi skrócić ładowanie o 100-500 ms, a samo zapytanie DNS zajmuje zwykle około 20-120 ms.

Kiedy stosować preconnect

Preconnect sprawdza się dla domen, z których strona na pewno i szybko pobierze coś ważnego, choć dokładny adres pliku nie jest znany z góry. Web.dev wymienia tu biblioteki pobierane z zewnętrznej sieci dostarczania treści, serwery obrazów, w których adres zdjęcia zależy od szerokości ekranu, oraz transmisje wideo. Typowym przykładem są też czcionki z Google Fonts, dla których zalecane jest połączenie z dwiema domenami: tą z arkuszem stylów i tą z plikami czcionek.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<link rel="dns-prefetch" href="https://fonts.gstatic.com">

W drugim wierszu przykładu pojawia się atrybut crossorigin i nie jest to ozdobnik. Czcionki pobierane są w trybie anonimowym, dlatego połączenie przygotowane bez tego atrybutu nie zostanie użyte do ich pobrania. Web.dev podaje, że w takiej sytuacji przeglądarka wykona jedynie zapytanie DNS, a dla samej czcionki otworzy nowe połączenie.

Kiedy wystarczy dns-prefetch

Dns-prefetch jest tańszy, bo nie otwiera połączenia, tylko ustala adres serwera. Nadaje się dla domen mniej ważnych albo takich, których na stronie jest zbyt wiele, by z każdą łączyć się z wyprzedzeniem: narzędzi analitycznych, wtyczek społecznościowych, okna czatu. Web.dev zaleca prostą zasadę: preconnect tylko dla najważniejszych obcych domen, dns-prefetch dla pozostałych.

Obie podpowiedzi można też zapisać dla tej samej domeny, traktując dns-prefetch jako rozwiązanie zapasowe dla przeglądarek, które nie obsługują preconnect. Trzeba to jednak zrobić w dwóch osobnych znacznikach link. Połączenie obu wartości w jednym atrybucie rel wywołuje według web.dev błąd w przeglądarce Safari, w wyniku którego preconnect zostaje anulowany.

Jeśli większość obcych domen pochodzi z dodatków marketingowych, lepszym pierwszym ruchem bywa ograniczenie ich liczby niż dopisywanie podpowiedzi, o czym piszemy we wpisie o tym, jak skrypty zewnętrzne spowalniają stronę. Z kolei czcionka przeniesiona na własny serwer nie wymaga już osobnego połączenia, co omawiamy w tekście Czcionki internetowe a szybkość strony.

Preload: wcześniejsze pobranie zasobu odkrywanego późno

Preload każe przeglądarce pobrać wskazany plik wcześniej, niż odkryłaby go sama, ponieważ bieżąca strona na pewno go potrzebuje. Różni się od pozostałych podpowiedzi tym, że jest poleceniem obowiązkowym: jak wyjaśnia web.dev w opracowaniu Preload critical assets to improve loading speed, preconnect przeglądarka wykonuje według własnej oceny, a preload musi zrealizować. Pobrany plik trafia do pamięci podręcznej i czeka. Skrypt nie zostaje przez to uruchomiony, a arkusz stylów zastosowany, dopóki strona sama o nie nie poprosi.

Preload jest przeznaczony dla zasobów ważnych i zarazem odkrywanych późno. Kurs web.dev wylicza cztery takie grupy: czcionki, arkusze stylów dołączane regułą @import, obrazy tła z arkusza stylów będące kandydatem na element LCP oraz zasoby LCP wczytywane przez JavaScript. Dla pliku, który i tak stoi w kodzie HTML na początku dokumentu, preload nic nie zmienia, bo skaner wstępnego ładowania znajdzie go równie szybko.

Atrybuty as, type i crossorigin

Znacznik preload wymaga atrybutu as, który określa rodzaj zasobu: script, style, font, image i inne. Na jego podstawie przeglądarka ustala priorytet, wysyła właściwe nagłówki i sprawdza, czy pliku nie ma już w pamięci podręcznej. Pominięcie atrybutu as albo wpisanie błędnej wartości sprawia, że przeglądarka nie potrafi nadać żądaniu właściwej ważności, a część zasobów, na przykład skrypty, może zostać pobrana dwukrotnie.

Atrybut type zawiera typ MIME pliku. Przeglądarka pobierze zasób tylko wtedy, gdy obsługuje podany typ, a w przeciwnym razie zignoruje cały znacznik. Trzeci atrybut, crossorigin, jest obowiązkowy dla czcionek, także tych leżących na własnym serwerze. Czcionka pobrana przez preload bez tego atrybutu zostanie pobrana drugi raz, gdy poprosi o nią arkusz stylów.

<link rel="preload" href="/fonts/naglowki.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/tlo-glowne.webp" as="image" type="image/webp" fetchpriority="high">
<link rel="preload" href="/js/krytyczny.js" as="script">

Link: </css/style.css>; rel="preload"; as="style"

Ostatni wiersz przykładu pokazuje zapis w nagłówku HTTP o nazwie Link. Przeglądarka nie musi wtedy analizować dokumentu, by dowiedzieć się o zasobie, co według web.dev w niektórych przypadkach daje niewielką dodatkową poprawę. Dla obrazów podawanych w kilku rozmiarach kurs web.dev zaleca w znaczniku preload atrybut imagesrcset zamiast zwykłego adresu.

Fetchpriority: zmiana ważności pobierania zasobu

Atrybut fetchpriority informuje przeglądarkę, że dany zasób jest ważniejszy albo mniej ważny, niż wynikałoby to z domyślnych zasad. Można go dodać do znaczników img, link i script. Przyjmuje trzy wartości: high (podnieść ważność), low (obniżyć) oraz auto, czyli ustawienie domyślne, w którym decyduje przeglądarka.

W opisie tego atrybutu web.dev podkreśla dwie cechy. Fetchpriority jest wskazówką, a nie poleceniem, więc przeglądarka stara się ją uwzględnić, ale może postąpić inaczej, gdy wymaga tego rozstrzygnięcie konfliktu między zasobami. Ponadto wartość działa względnie: przesuwa zasób w górę lub w dół w stosunku do jego punktu wyjścia. Arkusz stylów z początku dokumentu oznaczony jako low nie spadnie na koniec kolejki, tylko z poziomu Highest na High.

Czym fetchpriority różni się od preload

Preload odpowiada za odkrycie zasobu, fetchpriority za jego miejsce w kolejce. Preload sprawia, że przeglądarka dowiaduje się o pliku wcześnie, ale pobiera go z priorytetem domyślnym dla danego rodzaju zasobu, więc obraz wskazany przez preload nadal może dostać niski priorytet i czekać za innymi plikami. Fetchpriority z kolei nie pomaga w odkryciu: jeśli przeglądarka nie wie o istnieniu obrazu, sam atrybut niczego nie przyspieszy. Dlatego obie podpowiedzi się uzupełniają.

Gdzie fetchpriority pomaga

Najważniejszym zastosowaniem jest obraz główny strony. Oznaczony wartością high od razu startuje z wysokim priorytetem i nie czeka na obliczenie układu. W przykładzie opisanym przez web.dev oznaczenie obrazu głównego w serwisie Google Flights skróciło LCP z 2,6 do 1,9 sekundy.

Druga grupa zastosowań to obniżanie ważności. Dotyczy obrazów, które stoją wysoko w kodzie, ale nie są widoczne od razu, czyli kolejnych slajdów w karuzeli czy miniatur galerii. Przeglądarka może uznać je za leżące blisko widocznego obszaru i podnieść ich priorytet, a według web.dev leniwe ładowanie nie zawsze temu zapobiega. Trzecia grupa to skrypty: te z atrybutem async dostają domyślnie niski priorytet, więc skrypt naprawdę potrzebny do działania strony można podnieść, a skrypt blokujący, lecz mało istotny, obniżyć.

<ul class="karuzela">
  <img src="/img/slajd-1.jpg" fetchpriority="high" alt="...">
  <img src="/img/slajd-2.jpg" fetchpriority="low" alt="...">
  <img src="/img/slajd-3.jpg" fetchpriority="low" alt="...">
</ul>

<script src="/js/wazny.js" async fetchpriority="high"></script>
<script src="/js/malo-wazny.js" fetchpriority="low"></script>

Web.dev zwraca też uwagę, że korzyści z ustawiania priorytetów są największe tam, gdzie zasoby rywalizują o przepustowość, czyli na wolnych łączach i przy starszych wersjach protokołu HTTP.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Obraz główny i czcionki: jak ułożyć kod w typowych sytuacjach

Dla obrazu głównego najlepszy układ to zwykły znacznik img w kodzie HTML z atrybutem fetchpriority o wartości high i bez leniwego ładowania, a preload jest potrzebny dopiero wtedy, gdy obrazu nie da się w ten sposób umieścić. Web.dev formułuje to jako zasadę: zasób LCP powinien dać się odkryć w pierwszej odpowiedzi serwera i zacząć się pobierać równocześnie z pierwszym zasobem strony.

Obraz w znaczniku img

To najprostszy przypadek. Hipotetyczny przykład: strona usługowa hydraulika z Łodzi otwiera się dużym zdjęciem ekipy przy pracy. Zdjęcie stoi w kodzie jako img, więc skaner znajdzie je bez pomocy i preload nie jest tu potrzebny. Wystarczy fetchpriority o wartości high oraz upewnienie się, że motyw lub wtyczka nie dopisały do niego atrybutu loading o wartości lazy. Web.dev ostrzega, że elementu LCP nigdy nie należy ładować leniwie, bo zawsze oznacza to zbędne opóźnienie. Szerzej opisujemy to we wpisie Leniwe ładowanie obrazów i ramek.

<!-- Obraz główny jako znacznik img -->
<img src="/img/ekipa-przy-pracy.webp" width="1200" height="600"
     fetchpriority="high" alt="Hydraulik podczas montażu instalacji">

<!-- Obraz główny jako tło z arkusza stylów -->
<link rel="stylesheet" href="/css/style.css">
<link rel="preload" fetchpriority="high" as="image"
      href="/img/tlo-glowne.webp" type="image/webp">

Obraz jako tło lub wstawiany przez skrypt

Inaczej jest wtedy, gdy zdjęcie zostało ustawione jako tło sekcji w arkuszu stylów albo wstawia je skrypt suwaka. Przeglądarka dowie się o nim dopiero po pobraniu i przetworzeniu arkusza lub skryptu. W takim układzie web.dev zaleca preload obrazu z fetchpriority o wartości high, umieszczony w kodzie HTML, tak aby pobieranie ruszyło razem z arkuszem stylów. Trwalszym rozwiązaniem bywa przebudowa sekcji tak, aby obraz stał się zwykłym znacznikiem img.

Kilka obrazów w górnej części strony

W sklepie internetowym karta produktu ma zwykle duże zdjęcie i rząd miniatur, a strona główna karuzelę banerów. Wysoki priorytet należy się jednemu obrazowi: zdjęciu głównemu albo pierwszemu slajdowi. Web.dev zaznacza, że oznaczenie wartością high więcej niż jednego lub dwóch obrazów odbiera atrybutowi skuteczność. Pozostałym slajdom i miniaturom lepiej nadać wartość low.

Czcionki

Czcionki są odkrywane późno z natury rzeczy, ponieważ ich adresy stoją w regule @font-face wewnątrz arkusza stylów. Jeśli elementem LCP jest tekst, na przykład duży nagłówek na stronie kancelarii z Krakowa, web.dev zaleca preload czcionki użytej w tym nagłówku. Warto ograniczyć się do jednego lub dwóch plików rzeczywiście widocznych w górnej części strony, zawsze z atrybutem crossorigin. Web.dev podpowiada też miejsce w kodzie: preload czcionek najlepiej działa pod koniec sekcji head lub na początku sekcji body. Gdy czcionka pochodzi z obcej domeny i dokładny adres pliku nie jest stały, zamiast preload stosuje się preconnect do tej domeny.

Kiedy nadmiar podpowiedzi spowalnia stronę

Podpowiedzi spowalniają stronę wtedy, gdy jest ich za dużo albo dotyczą zasobów, które nie są potrzebne od razu. Łącze użytkownika ma ograniczoną przepustowość, więc każdy plik pobierany z wyprzedzeniem zabiera jej część innym. Web.dev nazywa preload bardzo silnym narzędziem, które łatwo nadużyć: zbyt wiele takich znaczników powoduje rywalizację o łącze i wydłuża ładowanie, a przy wolnej sieci żaden z nich nie przynosi już korzyści.

Z nadmiarem preconnect jest podobnie. Każde połączenie kosztuje, między innymi przesłanie certyfikatów potrzebnych do szyfrowania, i w nadmiarze również opóźnia ważniejsze zasoby. Z fetchpriority problem ma inną naturę: atrybut nie generuje dodatkowych pobrań, tylko przestaje cokolwiek znaczyć, gdy wartość high dostaje połowa plików na stronie.

W audytach technicznych spotykamy kilka powtarzających się pomyłek. To obserwacje z praktyki agencji, a ich mechanizm wynika z zasad opisanych w web.dev:

• preload wszystkich odmian czcionki, także tych używanych dopiero w stopce lub na innych podstronach,
• preload czcionki bez atrybutu crossorigin albo dowolnego zasobu bez atrybutu as, co kończy się podwójnym pobraniem,
• preload obrazu, który na telefonie nie jest wyświetlany, bo wersja mobilna używa innego pliku,
• znaczniki pozostawione po zmianie szablonu, wskazujące pliki, których strona już nie używa,
• preconnect do kilkunastu domen dodany hurtowo przez wtyczkę optymalizacyjną,
• fetchpriority o wartości high na każdym slajdzie karuzeli albo razem z leniwym ładowaniem na tym samym obrazie.

Na część tych błędów zwraca uwagę sama przeglądarka. Chrome wyświetla w konsoli ostrzeżenie o zasobie pobranym przez preload i niewykorzystanym, mniej więcej 3 sekundy po zdarzeniu load, czyli po zakończeniu ładowania strony. Takie ostrzeżenie oznacza, że znacznik wskazuje niepotrzebny plik, ma błędny adres albo brakuje w nim któregoś z wymaganych atrybutów.

Jak sprawdzić priorytety w panelu Sieć

Priorytety pobierania widać w narzędziach deweloperskich Chrome, w panelu Sieć (Network), po włączeniu dodatkowej kolumny Priorytet (Priority). Web.dev opisuje to w kilku czynnościach, które można wykonać na własnej stronie bez uprawnień administratora.

1. Otwarcie narzędzi deweloperskich

   Na badanej stronie należy otworzyć narzędzia deweloperskie Chrome i przejść do zakładki Sieć. Lista żądań wypełnia się podczas ładowania, dlatego po otwarciu panelu stronę trzeba odświeżyć.

2. Włączenie kolumny z priorytetem

   Kliknięcie prawym przyciskiem myszy w nagłówki tabeli otwiera listę dostępnych kolumn. Po zaznaczeniu pozycji Priorytet przy każdym pliku pojawia się jedna z wartości: Highest, High, Medium, Low lub Lowest.

3. Włączenie dużych wierszy żądań

   W ustawieniach panelu znajduje się opcja dużych wierszy żądań (Big request rows). Pokazuje ona dwa priorytety: początkowy i końcowy. To samo widać w dymku po najechaniu kursorem na wartość w kolumnie.

Odczyt jest prosty. Jeśli obraz główny ma priorytet początkowy Low, a końcowy High, przeglądarka podniosła go dopiero po obliczeniu układu i fetchpriority o wartości high ma tu sens. Jeśli po wdrożeniu atrybutu oba priorytety brzmią High, zmiana zadziałała. Jeśli ta sama czcionka występuje na liście dwa razy, niemal na pewno brakuje atrybutu crossorigin albo as. Kolejność wierszy pokazuje z kolei, czy zasób wskazany przez preload rzeczywiście zaczął się pobierać wcześniej niż przed zmianą.

Po sprawdzeniu priorytetów warto zajrzeć do zakładki Konsola i poczekać kilka sekund na ewentualne ostrzeżenia o niewykorzystanym preload. Pomocny jest też audyt Lighthouse, który według web.dev wskazuje zasoby odkrywane późno, a którego uruchomienie opisujemy we wpisie Lighthouse: jak uruchomić audyt strony w Chrome. Web.dev radzi przy tym, by nie projektować priorytetów z góry, tylko sprawdzić, jakie nadała przeglądarka, i dopisać podpowiedź tam, gdzie kolejność odbiega od oczekiwanej.

Podpowiedzi w WordPressie i kiedy potrzebna jest pomoc

W WordPressie część podpowiedzi powstaje automatycznie, dlatego przed dopisaniem własnych trzeba sprawdzić, co już znajduje się w kodzie strony. System ma wbudowaną funkcję wp_resource_hints(), która wypisuje znaczniki link dla relacji dns-prefetch, preconnect, prefetch i prerender, a filtr o tej samej nazwie pozwala motywom i wtyczkom dodawać do nich kolejne adresy.

Automatycznie dodawany jest też atrybut fetchpriority. Zgodnie z opisem zmian na stronie zespołu WordPressa, Image performance enhancements in WordPress 6.3, system nadaje wartość high obrazowi, który uznaje za najbardziej prawdopodobny element LCP, pod warunkiem że iloczyn jego szerokości i wysokości wynosi domyślnie co najmniej 50 tysięcy pikseli. Dalszym obrazom dopisuje leniwe ładowanie, nie łączy obu atrybutów na jednym obrazie i nie nadpisuje wartości ustawionych ręcznie.

Automat opiera się jednak na przewidywaniu, a nie na pomiarze. Nie obejmie obrazu tła z arkusza stylów ani zdjęcia wstawianego przez skrypt suwaka. Do tego dochodzą wtyczki optymalizacyjne i kreatory stron, które dopisują własne znaczniki preload i preconnect. Z naszej praktyki wynika, że na takich stronach częściej trzeba podpowiedzi porządkować i usuwać niż dodawać nowe.

Samodzielnie można bezpiecznie wykonać diagnozę: ustalić element LCP, obejrzeć priorytety w panelu Sieć i przeczytać ostrzeżenia w konsoli. Pomoc specjalisty przydaje się wtedy, gdy zmiana wymaga ingerencji w szablon, gdy podpowiedzi generuje kilka wtyczek jednocześnie albo gdy mimo poprawek wskaźnik LCP w danych od użytkowników pozostaje słaby. Przyczyna zwykle leży wtedy głębiej, na przykład w czasie odpowiedzi serwera lub wadze obrazów, i same podpowiedzi jej nie usuną. Kolejność pobierania zasobów sprawdzamy w ramach usługi SEO techniczne, a szerszą ocenę serwisu obejmuje audyt SEO. Wszystkie trzy wskaźniki przedstawiamy we wpisie Core Web Vitals: jak poprawić LCP, INP i CLS.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl