Czym jest Speculative Loading? Tak WordPress ładuje strony przed kliknięciem

Klikasz link, a następna strona po prostu już jest. Żadnego białego ekranu, żadnego czekania. Często nie stoi za tym szybszy serwer, tylko przeglądarka, która pomyślała krok naprzód. Tym właśnie jest Speculative Loading: przeglądarka zgaduje, którą stronę otworzysz jako następną, i ładuje ją zawczasu. Jeśli trafi, przejście na nową stronę wydaje się natychmiastowe. Jeśli się pomyli, po prostu na próżno pobrała kilka kilobajtów. Od wersji 6.8 WordPress ma tę technikę wbudowaną na stałe, a wielu właścicieli witryn nawet nie wie, że ich strona już z niej korzysta. Z tego artykułu dowiesz się, jak to wszystko działa, co WordPress ustawia domyślnie i kiedy warto coś poprawić.

Czym jest Speculative Loading? Proste wyjaśnienie

Speculative Loading, po polsku mniej więcej spekulatywne ładowanie, to ogólne określenie technik, dzięki którym przeglądarka pobiera strony, zanim ktokolwiek je faktycznie otworzy. Spekulatywne dlatego, że nikt nie wie na pewno, czy odwiedzający rzeczywiście kliknie link. Przeglądarka po prostu obstawia.

Wyobraź sobie uważną baristkę w Twojej ulubionej kawiarni. Widzi, jak wchodzisz przez drzwi, i zaczyna przygotowywać cappuccino, zanim cokolwiek zamówisz. Zwykle trafia i dostajesz kawę bez czekania. Jeśli wyjątkowo zamówisz herbatę, cappuccino idzie na marne. Mniej więcej tak samo działa Speculative Loading.

Sam pomysł nie jest nowy. Już lata temu istniały wskazówki <link rel="prefetch"> i <link rel="prerender">, którymi witryny mogły polecać przeglądarce strony do wcześniejszego załadowania, a biblioteki takie jak instant.page czy Quicklink dokładały to samo za pomocą JavaScriptu. Naprawdę niezawodne to jednak nie było. Chrome już dawno zastąpił nawet stare rel="prerender" okrojoną wersją, która w ogóle niczego nie renderuje. Dlatego gdy dziś mowa o Speculative Loading, prawie zawsze chodzi o Speculation Rules API, które Google wprowadził w Chrome.

Po co cały ten wysiłek? Bo czas ładowania wpływa bezpośrednio na Core Web Vitals. Jeśli strona zostanie w całości przygotowana w tle, Largest Contentful Paint (LCP) wynosi dla odwiedzającego praktycznie zero. Szybciej się nie da.

Jak działa Speculation Rules API?

Witryna przekazuje przeglądarce kilka reguł. Są zapisane jako JSON w bloku typu speculationrules. Tak wygląda prosta reguła:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Mówiąc po ludzku: wszystkie linki na tej witrynie mogą zostać wyrenderowane z wyprzedzeniem, gdy tylko odwiedzający okaże zainteresowanie, na przykład gdy na chwilę zatrzyma kursor myszy nad linkiem. Takie reguły, które odnoszą się do linków w dokumencie, nazywają się Document Rules. Oprócz nich istnieją List Rules, w których podajesz przeglądarce stałą listę adresów URL, na przykład następną stronę serii artykułów.

Dwie rzeczy sprawiają, że API jest przyjemnie nieskomplikowane. Po pierwsze, to przeglądarka ostatecznie decyduje, czy zastosuje się do reguły. Gdy bateria jest prawie pusta albo brakuje pamięci operacyjnej, po prostu odpuszcza. Po drugie, przeglądarki, które nie znają API, zwyczajnie ignorują ten blok. Nic więc nie może się zepsuć. Zamiast w kodzie HTML reguły można zresztą dostarczać także przez nagłówek w odpowiedzi serwera (Speculation-Rules), z czego korzystają przede wszystkim sieci CDN.

Prefetch czy Prerender: jaka jest różnica?

Speculation Rules API zna dwa tryby, a różnica między nimi jest większa, niż sugerują nazwy.

W trybie Prefetch przeglądarka pobiera tylko surowy kod HTML strony docelowej i na chwilę odkłada go na bok. Obrazy, arkusze stylów i skrypty zostają pominięte, nic nie jest wykonywane. Gdy odwiedzający potem kliknie, oszczędza sobie czekania na serwer, czyli w gruncie rzeczy Time to First Byte. Resztę przeglądarka ładuje jak zwykle. Prefetch jest tani i nie ma prawie żadnych skutków ubocznych.

W trybie Prerender przeglądarka idzie na całość. Ładuje całą stronę razem z obrazami, CSS i JavaScriptem w niewidocznej karcie i buduje ją do końca. Po kliknięciu po prostu podmienia widoczną stronę. Odwiedzający ma wrażenie, jakby strona była tam od zawsze. Cena: więcej przesłanych danych, więcej mocy obliczeniowej, a JavaScript się wykonuje, choć odwiedzający może nigdy nie zobaczyć tej strony. Ze względów bezpieczeństwa Prerender domyślnie działa tylko dla stron z tej samej domeny.

Można przyjąć prostą zasadę: Prefetch to bezpieczne ustawienie podstawowe, a Prerender to turbo dla stron, które z dużym prawdopodobieństwem zostaną otwarte jako następne.

Nie myl obu trybów z preload i preconnect. Te wskazówki przyspieszają ładowanie plików bieżącej strony, na przykład fontów albo największego obrazu. Jak poprawnie z nich korzystać, opisujemy w artykule o używaniu preload i preconnect dla fontów i zasobów w WordPressie.

Kiedy przeglądarka ładuje z wyprzedzeniem? Cztery poziomy eagerness

Parametrem eagerness (po polsku mniej więcej gorliwość) ustalasz, jak wcześnie przeglądarka może zacząć. Im wcześniej, tym większy zysk czasu, ale tym częściej przeglądarka też chybia.

• immediate: od razu, gdy tylko przeglądarka odczyta regułę. Ma sens tylko dla garstki adresów URL, co do których masz dużą pewność.
• eager: prawie równie wcześnie. Chrome dopracował to zachowanie w ostatnich wersjach, więc ten poziom leży teraz między immediate a moderate.
• moderate: na komputerze spekulacja rusza, gdy kursor myszy zatrzyma się nad linkiem na około 200 milisekund, albo wcześniej, gdy zostanie wciśnięty przycisk myszy. Na smartfonach, gdzie nie ma czegoś takiego jak hover, Chrome korzysta z innych sygnałów, takich jak dotknięcie.
• conservative: dopiero gdy odwiedzający naprawdę klika, a dokładniej w chwili wciśnięcia przycisku myszy lub dotknięcia ekranu palcem. Do zakończenia kliknięcia mija tylko ułamek sekundy. Przewaga jest niewielka, za to prawie żadna spekulacja nie idzie w próżnię.

Chrome sam też pilnuje, żeby nikt nie przesadził. Przy moderate i conservative przeglądarka trzyma w pogotowiu najwyżej dwie spekulacje naraz i wyrzuca najstarszą, gdy tylko pojawi się nowa. Przy immediate i eager dozwolonych jest do 50 spekulacji typu Prefetch i 10 typu Prerender. W trybie oszczędzania energii, przy włączonym oszczędzaniu danych, gdy brakuje pamięci albo gdy użytkownik wyłączył w ustawieniach wstępne wczytywanie stron, Chrome w ogóle nie spekuluje. Szczegóły Google opisuje w dokumentacji dla Chrome.

Speculative Loading w WordPressie: co od wersji 6.8 dzieje się automatycznie

Performance Team WordPressa najpierw przetestował tę funkcję jako osobną wtyczkę o nazwie Speculative Loading. Działała na ponad 50 000 witryn, a według analizy danych z HTTP Archive i Chrome UX Report odsetek pozytywnych wyników Largest Contentful Paint na tych witrynach wzrósł w medianie o około 1,9 procent. Brzmi skromnie, ale jak na funkcję, która nie wymaga żadnej pracy, to porządny zysk. Wraz z WordPressem 6.8 całość trafiła w kwietniu 2025 roku do rdzenia. Ustawienia domyślne są celowo zachowawcze:

• Tryb prefetch, eagerness conservative. Ładowany jest więc tylko kod HTML i to dopiero wtedy, gdy kliknięcie już się zaczęło.
• Tylko dla niezalogowanych odwiedzających. Kto jest zalogowany, widzi pasek narzędzi i często spersonalizowane treści. Takie strony nie trafiają do żadnego cache, więc ich wcześniejsze ładowanie byłoby kosztowne.
• Tylko z Pretty Permalinks. Jeśli w sekcji Ustawienia › Bezpośrednie odnośniki nadal zaznaczona jest opcja Prosty, funkcja pozostaje wyłączona.
• Żadnych adresów URL z parametrami. Wykluczone jest wszystko, co ma w adresie znak zapytania, czyli na przykład wyszukiwanie albo link typu ?add-to-cart=123 w sklepie internetowym. Panel administracyjny, strona logowania i linki z rel="nofollow" również są tabu.
• Wyjątki za pomocą klasy. Linki z klasą no-prefetch albo linki w bloku z tą klasą nigdy nie są ładowane z wyprzedzeniem. Klasa no-prerender wyklucza tylko renderowanie z wyprzedzeniem.

Skąd taka ostrożność? Wtyczka miała jeszcze domyślnie ustawiony Prerender z moderate i dzięki temu wyciskała więcej szybkości. Przy milionach witryn z niezliczonymi kombinacjami motywów i wtyczek zespół uznał jednak za zbyt duże ryzyko, że JavaScript będzie się wykonywał na stronach, których nikt nigdy nie odwiedzi. Tak też zespół uzasadnia to w oficjalnym ogłoszeniu. Jeśli chcesz więcej, nadal możesz zainstalować wtyczkę Speculative Loading. Dodaje ona w sekcji Ustawienia › Czytanie panel, w którym bez kodu zmienisz tryb i eagerness, a w razie potrzeby włączysz funkcję także dla zalogowanych użytkowników.

Jak dostosować lub wyłączyć Speculative Loading w WordPressie?

Bez wtyczki zrobisz to za pomocą filtrów. Poniższe fragmenty kodu umieść w pliku functions.php swojego Child Theme albo, jeszcze lepiej, w małej własnej wtyczce, żeby przetrwały zmianę motywu.

Użyj Prerender zamiast Prefetch:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

Sprawdzenie za pomocą is_array() jest ważne. Dla zalogowanych użytkowników i witryn bez Pretty Permalinks WordPress przekazuje tu null, a dzięki temu sprawdzeniu funkcja pozostaje w takich przypadkach wyłączona.

Wyklucz wybrane sekcje:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
	$paths[] = '/go/*';
	if ( 'prerender' === $mode ) {
		$paths[] = '/koszyk/*';
	}
	return $paths;
}, 10, 2 );

Typowe przypadki to przekierowania linków partnerskich, które przy otwarciu zliczają kliknięcie, koszyk albo strony, których treść ciągle się zmienia. Ścieżki podajesz względem strony głównej, a ewentualny podkatalog WordPress dopisuje sam. Drugi parametr pozwala wykluczyć ścieżki tylko dla jednego trybu, w przykładzie koszyk wyłącznie przy renderowaniu z wyprzedzeniem.

Wyklucz pojedyncze linki: Nadaj linkowi lub otaczającemu go blokowi klasę no-prefetch. W edytorze blokowym zrobisz to w sekcji Zaawansowane, w polu na dodatkowe klasy CSS, zupełnie bez kodu.

Całkowicie wyłącz Speculative Loading:

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

Całkowite wyłączenie ma sens tylko wtedy, gdy masz ku temu konkretny powód. W ustawieniach domyślnych ta funkcja nie kosztuje praktycznie nic.

Jakie wady ma Speculative Loading?

Zysk na szybkości nie jest całkiem darmowy. Te kwestie warto znać:

Większe obciążenie serwera. Każda spekulacja to prawdziwe żądanie. Jeśli Page Cache serwuje gotową stronę, serwer prawie tego nie odczuwa. Bez cache każdy Prefetch uruchamia PHP i zapytania do bazy danych, jakby pojawił się prawdziwy odwiedzający. Na Shared Hostingu z ograniczonymi zasobami agresywne ustawienie, takie jak immediate czy eager, może więc być odczuwalne. W mniejszej skali to samo dotyczy odwiedzających z ograniczonym pakietem danych.

Linki, które coś uruchamiają. W teorii zwykły link nigdy nie powinien niczego zmieniać. W praktyce niektóre i tak to robią: linki wylogowania, liczniki kliknięć linków partnerskich, oceny jednym kliknięciem albo szybkie „Dodaj do koszyka”. Wykluczając wszystkie adresy URL z parametrami, WordPress wyłapuje wiele takich przypadków, ale już nie ładne adresy w rodzaju /go/partner/. Takie adresy warto wykluczyć samodzielnie.

Zafałszowane statystyki. Prefetch nie wykonuje JavaScriptu, więc narzędzia analityczne takie jak Matomo czy Google Analytics niczego nie zauważą. Statystyki tworzone na podstawie logów serwera, na przykład w panelu klienta wielu firm hostingowych, mogą jednak liczyć te żądania jako odsłony. W trybie Prerender JavaScript naprawdę się wykonuje. Google Analytics i Google Publisher Tag same czekają, aż strona zostanie faktycznie wyświetlona. Narzędzia, które tego nie robią, liczą wizyty, do których nigdy nie doszło. Dla własnych skryptów jest proste sprawdzenie:

if (document.prerendering) {
	document.addEventListener('prerenderingchange', startTracking, { once: true });
} else {
	startTracking();
}

Na serwerze spekulatywne żądania rozpoznasz po nagłówku Sec-Purpose, który ma wartość prefetch lub prefetch;prerender.

Treść może być nieco nieaktualna. Chrome przechowuje strony załadowane z wyprzedzeniem przez kilka minut. Przy conservative nie ma to znaczenia, bo kliknięcie następuje od razu. Przy wcześniejszych poziomach strona z szybko zmieniającą się treścią, na przykład relacja na żywo, może w chwili otwarcia mieć już kilka minut.

Które przeglądarki obsługują Speculative Loading?

Chrome w pełni obsługuje Speculation Rules API, podobnie jak Edge, Opera i inne przeglądarki oparte na Chromium. Safari pracuje nad własną implementacją, która w nowszych wersjach jest jednak wciąż ukryta za przełącznikiem dla deweloperów. Firefox na razie nie obsługuje tego API.

Brzmi to jak luka, ale w praktyce nie stanowi problemu. Ponieważ przeglądarki ignorują reguły, których nie rozumieją, korzystają wszyscy użytkownicy Chrome, a dla reszty po prostu nic się nie zmienia. Na większości witryn Chrome i tak jest zdecydowanie największym kawałkiem tortu. Już na początku 2025 roku, czyli jeszcze przed startem w WordPressie, według WordPress Performance Team ponad 8 procent wszystkich odsłon stron w Chrome korzystało ze Speculation Rules.

Jak sprawdzić, czy Speculative Loading działa na mojej witrynie?

Trzy szybkie sposoby:

1. Zajrzyj do kodu źródłowego. Otwórz swoją witrynę w oknie prywatnym, czyli bez logowania, i wyszukaj w kodzie źródłowym speculationrules. WordPress umieszcza reguły w stopce.
2. Użyj Chrome DevTools. W zakładce Application, w sekcji Background services, znajdziesz obszar Speculative loads. Zobaczysz tam aktywne reguły, adresy URL załadowane z wyprzedzeniem i powód, dla którego dana spekulacja się nie udała.
3. Sprawdź nagłówki. Jeśli CDN dodaje własne reguły, na przykład Cloudflare z funkcją Speed Brain, nie znajdziesz ich w kodzie HTML, tylko w nagłówku odpowiedzi Speculation-Rules. Wtedy mogą równolegle działać dwa zestawy reguł. To nie szkodzi, ale warto o tym wiedzieć, zanim zmienisz coś w jednym miejscu i zaczniesz się zastanawiać, dlaczego nic się nie dzieje.

Jak InspectWP pomaga Ci mieć na oku czas ładowania i Resource Hints

Raport InspectWP pokazuje Ci najpierw, jaka wersja WordPressa działa na Twojej witrynie. Od wersji 6.8 wiesz już dzięki temu, że Speculative Loading domyślnie działa dla niezalogowanych odwiedzających, o ile włączone są Pretty Permalinks. W sekcji HTML raport wymienia też klasyczne Resource Hints, czyli Prefetch, DNS Prefetch, Preconnect i Prerender, oraz oznacza wpisy, które pojawiają się w kodzie źródłowym więcej niż raz. Często wskazuje to na wtyczki, które wchodzą sobie w drogę. Jeśli pojawia się tam jeszcze stare rel="prerender", to dobra okazja, żeby przejść na Speculation Rules API. Ponieważ strony ładowane z wyprzedzeniem kosztują dużo mniej, gdy działa cache, warto też przyjrzeć się wykrytym wtyczkom cache i nagłówkom odpowiedzi serwera. Bezpłatny raport w krótkim czasie pokaże Ci, jak wypada Twoja witryna.