Speculation Rules API dla WordPress i WooCommerce

W 2026 roku użytkownicy oczekują nawigacji poniżej 2 sekund. Każda dodatkowa sekunda ładowania kosztuje około 4,42% konwersji (Portent); krążąca w sieci liczba 7% pochodzi od Akamai i dotyczy opóźnienia o 100 milisekund. Google to wie i nagradza szybkie strony wyższymi pozycjami.

Ten przewodnik to nie teoria. To działający kod i lista kontrolna, które możesz wdrożyć dzisiaj na swojej stronie WordPress lub sklepie WooCommerce. Speculation Rules pomagają dopiero wtedy, gdy checkout i cart fragments są już pod kontrolą. Tę kolejność prac opisują case study odzyskania wydajności WooCommerce oraz optymalizacja wydajności WooCommerce w 2026.

#1. Dlaczego wydajność WordPress i WooCommerce nadal ma znaczenie

#Współczynnik odrzuceń a czas ładowania strony

Źródło: Google i SOASTA, benchmarki szybkości stron mobilnych. Liczby to wzrost prawdopodobieństwa odrzucenia wobec jednej sekundy, a nie bezwzględny współczynnik odrzuceń. Think with Google

Google potwierdził: Core Web Vitals to czynnik rankingowy. W 2024 roku FID został zastąpiony przez INP (Interaction to Next Paint), metrykę, która mierzy responsywność strony na interakcje użytkownika.

#Czym jest postrzegana szybkość strony

Możesz mieć wolny serwer (TTFB 800ms), ale jeśli użytkownik widzi treści natychmiast i nawigacja wydaje się natychmiastowa, postrzegana prędkość jest doskonała.

To właśnie robi Speculation Rules API, preładowuje następne strony w tle, zanim użytkownik kliknie.

#2. Jakie optymalizacje zrobić przed Speculation Rules API

Zanim wdrożysz zaawansowane techniki, upewnij się, że fundamenty są solidne.

#Jak dodać defer do JavaScript w functions.php

// functions.php - defer dla niekrytycznego JS
add_filter('script_loader_tag', function($tag, $handle) {
    $defer_scripts = ['jquery', 'wp-embed', 'comment-reply'];
    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

#Obsługa AVIF w WordPress 6.5+

WordPress 6.5+ obsługuje AVIF natywnie. AVIF oferuje 20-30% lepszą kompresję niż WebP.

<img
  src="product.avif"
  srcset="product-400.avif 400w, product-800.avif 800w"
  sizes="(max-width: 600px) 400px, 800px"
  loading="lazy"
  decoding="async"
  alt="Produkt"
>

#Jak zejść z TTFB poniżej 200 ms

#3. Jak JavaScript wpływa na INP i CLS w WordPress

#Jak naprawić INP przez dzielenie długich zadań

INP cierpi, gdy główny wątek jest zablokowany. Typowi winowajcy:

• Ciężkie page buildery (Elementor, Divi)
• Skrypty czatów (Intercom, Zendesk)
• Piksele śledzące (Facebook, Google Ads)

Rozwiązanie: dziel długie zadania

// Dziel długie zadania na mniejsze chunki < 50ms
async function longTask(items) {
    for (const item of items) {
        await processItem(item);
        // Ustąp głównemu wątkowi
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}

#Jak zapobiec CLS przy obrazach i reklamach

/* Rezerwuj miejsce dla obrazów */
img {
    aspect-ratio: 16 / 9;
    width: 100%;
    height: auto;
}

/* Rezerwuj miejsce dla reklam */
.ad-slot {
    min-height: 250px;
}

#4. Jak Speculation Rules API robi prefetch i prerender

To serce tego przewodnika. Speculation Rules API to natywna przeglądarkowa funkcja, która pozwala preładowywać strony w tle.

#Reguła prefetch dla wszystkich linków wewnętrznych

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/wp-admin/*" } },
          { "not": { "href_matches": "*.pdf" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prerender koszyka, zamówienia i stron produktów

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/koszyk/", "/zamowienie/"],
      "eagerness": "immediate"
    },
    {
      "source": "document",
      "where": {
        "or": [
          { "href_matches": "/produkt/*" },
          { "selector_matches": ".important-link" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Różnice: prefetch a prerender

#Co oznaczają poziomy eagerness

• conservative: przy wciśnięciu przycisku wskaźnika lub dotknięciu linku; domyślny poziom dla reguł typu document
• moderate: na desktopie po 200 ms najechania kursorem (albo wcześniej, jeśli użytkownik wciśnie przycisk wskaźnika); na urządzeniach mobilnych 500 ms po zatrzymaniu przewijania, dla dużych linków w pobliżu ostatniego dotknięcia
• eager: od Chrome 143 po 10 ms najechania kursorem na desktopie i 50 ms po wejściu linku w widoczny obszar na urządzeniach mobilnych
• immediate: gdy tylko przeglądarka odczyta reguły; domyślny poziom dla reguł typu list

Czasy pochodzą z przewodnika Chrome po prerenderingu. Przed Chrome 143 poziom eager działał tak samo jak immediate, więc starsze artykuły, które opisują go jako “natychmiast, agresywnie”, mówią o wcześniejszym zachowaniu.

#5. Jak domyślnie działa ładowanie spekulatywne w WordPress 6.8

Od wersji 6.8 Speculation Rules API jest częścią rdzenia WordPressa. Funkcję przeniesiono z wtyczki Speculative Loading, która przed włączeniem do rdzenia działała na ponad 50 000 stron. Notatka deweloperska rdzenia podaje, na podstawie danych HTTP Archive i CrUX, że w witrynach korzystających z tej funkcji odsetek stron z dobrym wynikiem LCP wzrósł w medianie o około 1,9%. Według tej samej notatki ponad 8% nawigacji w Chrome korzysta już z reguł spekulacji.

#Domyślne ustawienia ładowania spekulatywnego w rdzeniu WordPressa

Bez żadnej konfiguracji rdzeń wypisuje na froncie jeden zestaw reguł z trybem prefetch i poziomem eagerness conservative. Oba są zapisane jako auto, więc kolejne wydanie może zmienić to, na co auto się przekłada, bez psucia twojej konfiguracji. Prefetch rusza, gdy użytkownik wciśnie przycisk wskaźnika na linku. Daje to niewielkie wyprzedzenie rzędu kilkuset milisekund i prawie nie generuje zmarnowanych żądań.

Rdzeń wyłącza tę funkcję w trzech sytuacjach:

• dla zalogowanych użytkowników, więc pasek narzędzi, podglądy i linki do kokpitu nigdy nie są spekulowane,
• w witrynach bez przyjaznych bezpośrednich odnośników (pretty permalinks),
• dla adresów URL z parametrami zapytania, które domyślnie są wyłączone z prefetchu i prerenderingu.

Ostatnia reguła ma znaczenie dla WooCommerce. Linki dodające produkt do koszyka używają query stringa, więc domyślna konfiguracja nigdy ich nie pobiera z wyprzedzeniem. Wtyczka, która udostępnia inne adresy akcji (żądania GET zmieniające stan), nadal musi je wykluczyć sama, zwłaszcza jeśli podniesiesz poziom eagerness.

#Jak zmienić ładowanie spekulatywne filtrami WordPressa

Rdzeń udostępnia dwa filtry i jedną akcję. wp_speculation_rules_configuration otrzymuje tablicę z kluczami mode i eagerness albo null, gdy spekulacja jest dla danego żądania wyłączona. Dozwolone tryby to auto, prefetch i prerender, a dozwolone wartości eagerness to auto, conservative, moderate i eager. Wartość immediate jest odrzucana celowo, bo przy regułach na poziomie całego dokumentu zdecydowanie się jej odradza.

// Przełącz regułę rdzenia na prerender po najechaniu kursorem
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

// Wyklucz spersonalizowane ścieżki tylko z prerenderingu
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
    if ( 'prerender' === $mode ) {
        $paths[] = '/my-account/*';
    }
    return $paths;
}, 10, 2 );

// Dodaj własną regułę obok reguły rdzenia
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
    $rules->add_rule( 'prerender', 'shop-cart', array(
        'source'    => 'list',
        'urls'      => array( '/cart/' ),
        'eagerness' => 'moderate',
    ) );
} );

Filtr wykluczanych ścieżek przyjmuje wzorce w składni URL Pattern, względne wobec frontu witryny, oraz opcjonalny argument $mode. Akcja wp_load_speculation_rules przekazuje obiekt WP_Speculation_Rules, a metoda add_rule() przyjmuje zarówno reguły typu list, jak i reguły typu document z warunkiem where. Zwrócenie null z filtra konfiguracji wyłącza spekulację dla danego żądania.

#Jak wykluczyć linki klasami no-prefetch i no-prerender

Redaktorzy mogą wyłączyć pojedyncze linki bez pisania kodu. Klasa no-prefetch wpisana w polu “Dodatkowe klasy CSS” w panelu Zaawansowane bloku całkowicie wyłącza jego linki z ładowania spekulatywnego. Klasa no-prerender pozwala na prefetch, ale blokuje prerender. Prefetch jest częścią prerenderingu, więc no-prefetch obejmuje oba tryby. To najszybsza poprawka, gdy jeden widżet, na przykład kalendarz rezerwacji, zaczyna działać niepoprawnie po prerenderingu.

#Ustawienia wtyczki Speculative Loading a rdzeń WordPressa

Wtyczka Speculative Loading zespołu WordPress Performance Team nadal istnieje i działa agresywniej niż rdzeń. Domyślnie używa prerenderingu z poziomem moderate, więc strona renderuje się w tle, gdy użytkownik najedzie kursorem na link. Tryb i eagerness ustawisz w menu Ustawienia, Czytanie.

Wtyczka ostrzega, gdy włączasz spekulację dla zalogowanych użytkowników bez trwałego cache obiektów, bo wtedy każda spekulowana strona kosztuje pełne żądanie PHP bez cache. Jej filtr wykluczeń nazywa się plsr_speculation_rules_href_exclude_paths. W sklepie WooCommerce z dużym ruchem zalogowanych klientów trzymaj spekulację dla zalogowanych wyłączoną, dopóki nie działa cache obiektów, na przykład Redis.

#6. Jak wdrożyć Speculation Rules API w WordPress

#Metoda 1: reguły we własnej wtyczce

W WordPressie 6.8 i nowszym rdzeń sam wypisuje skrypt speculationrules. Własny skrypt w wp_head dokłada obok niego drugi zestaw reguł, więc tej metody używaj tylko na starszych wersjach albo najpierw wyłącz regułę rdzenia, zwracając null z filtra wp_speculation_rules_configuration. Na aktualnych wersjach czystszą drogą są filtry opisane wyżej.

<?php
/**
 * Plugin Name: Speculation Rules API
 */
add_action('wp_head', function() {
    if (is_admin()) return;
    ?>
    <script type="speculationrules">
    {
      "prefetch": [
        {
          "source": "document",
          "where": {
            "and": [
              { "href_matches": "/*" },
              { "not": { "href_matches": "/wp-*" } }
            ]
          },
          "eagerness": "moderate"
        }
      ]
    }
    </script>
    <?php
});

#Metoda 2: dynamiczne reguły dla koszyka i paginacji

add_action('wp_head', function() {
    $prerender_urls = [];

    // Prerender produkty z koszyka
    if (function_exists('WC') && WC()->cart) {
        foreach (WC()->cart->get_cart() as $item) {
            $prerender_urls[] = get_permalink($item['product_id']);
        }
    }

    // Prerender następną stronę archiwum
    if (is_archive() || is_home()) {
        $next_link = get_next_posts_link();
        if ($next_link) {
            preg_match('/href="([^"]+)"/', $next_link, $matches);
            if (!empty($matches[1])) {
                $prerender_urls[] = $matches[1];
            }
        }
    }

    if (empty($prerender_urls)) return;

    $rules = [
        'prerender' => [[
            'source' => 'list',
            'urls' => array_unique($prerender_urls),
            'eagerness' => 'moderate'
        ]]
    ];

    echo '<script type="speculationrules">' . json_encode($rules) . '</script>';
});

#7. Jakie wyniki dają Speculation Rules API w praktyce

#Case study 1: Sklep WooCommerce (500 produktów)

Problem: Nawigacja z kategorii do produktu trwała kilka sekund

Rozwiązanie:

• Prefetch dla linków w viewport
• Prerender dla “Dodaj do koszyka” i “Kasa”

Wynik:

• Przed: kilka sekund oczekiwania
• Po: postrzegane jako natychmiastowe
• Współczynnik odrzuceń: wyraźnie spadł

#Case study 2: Blog WordPress (1000+ artykułów)

Problem: INP poza zielonym zakresem, użytkownicy odczuwali “lag”

Rozwiązanie:

• Defer wszystkich skryptów
• Prerender dla “Czytaj więcej”
• Object Cache (Redis)

Wynik:

• INP: wszedł w zielony zakres
• LCP: wszedł w zielony zakres
• Ruch organiczny: wzrósł

#8. Jakie pułapki Speculation Rules API omijać

#Których stron nie prerenderować

• Stron z autoryzacją (login, panel użytkownika)
• Stron z efektami ubocznymi (zapisy, płatności)
• Zewnętrznych URL-i

#Data Saver, wsparcie przeglądarek i limit prerenderów

• Data Saver wyłącza spekulację, pełną listę warunków blokujących znajdziesz niżej
• Nieobsługujące przeglądarki (Firefox oraz Safari bez eksperymentalnej flagi) ignorują reguły
• Limit prerenderów: Chrome pozwala na 10 prerenderów dla reguł immediate i tylko na 2 dla eager, moderate i conservative, przy czym jako pierwszy odpada najstarszy

#Limity spekulacji w Chrome dla poziomów eagerness

Chrome ogranicza liczbę spekulacji, które strona może utrzymywać jednocześnie, a limit zależy od poziomu eagerness. Liczby poniżej pochodzą z przewodnika Chrome po prerenderingu.

Przy trzech poziomach opartych na interakcji kolejka działa według zasady FIFO: nowa spekulacja anuluje najstarszą. Anulowany adres można później spekulować ponownie, a jego zasoby, które da się zapisać w cache, zwykle nadal są w cache HTTP. Usunięcie ze strony skryptu z regułą typu list zwalnia miejsce w puli immediate. Przydaje się to, gdy po złożeniu zamówienia reguła koszyka ma ustąpić innej regule.

#Kiedy Chrome ignoruje reguły spekulacji

Reguły spekulacji są tylko wskazówką i Chrome je pomija, gdy:

• użytkownik ma włączony tryb Save-Data,
• włączone jest oszczędzanie energii (Energy Saver), a bateria jest słaba,
• urządzeniu brakuje pamięci,
• wyłączone jest ustawienie wstępnego wczytywania stron (Preload pages), co robią niektóre rozszerzenia, na przykład uBlock Origin,
• strona jest otwarta w karcie w tle.

Prerenderowane strony wstrzymują też ramki iframe z innych originów do momentu aktywacji, więc osadzona mapa albo odtwarzacz wideo ładuje się dopiero, gdy użytkownik faktycznie wejdzie na stronę. Reguły spekulacji wewnątrz prerenderowanej strony są przetwarzane dopiero po jej aktywacji, a reguły w ramkach iframe są ignorowane.

#Fallback prefetch dla przeglądarek bez wsparcia

if (!HTMLScriptElement.supports?.('speculationrules')) {
    // Fallback: klasyczny prefetch
    document.querySelectorAll('a[href^="/"]').forEach(link => {
        link.addEventListener('mouseenter', () => {
            const prefetch = document.createElement('link');
            prefetch.rel = 'prefetch';
            prefetch.href = link.href;
            document.head.appendChild(prefetch);
        }, { once: true });
    });
}

#9. Jak przygotować strony WooCommerce do bezpiecznego prerenderingu

Prerenderowana strona uruchamia swój JavaScript, zanim użytkownik ją zobaczy. Właśnie dlatego wydaje się natychmiastowa i właśnie dlatego może popsuć sklep, jeśli kod zakłada prawdziwą wizytę.

#Których adresów WooCommerce nie pobierać ani nie prerenderować

MDN uznaje adresy URL z efektami ubocznymi po stronie serwera za niebezpieczne zarówno dla prefetchu, jak i dla prerenderingu: wylogowanie, zmianę języka, dodanie do koszyka, wysyłkę jednorazowych kodów SMS, zużywanie limitów oraz śledzenie konwersji reklam. W sklepie WooCommerce chodzi o link wylogowania na stronie Moje konto, przełącznik waluty lub języka zrobiony jako link GET i każdy własny adres typu “kup teraz”. Strony są dodatkowo niebezpieczne dla prerenderingu, gdy ich skrypty zapisują dane po stronie klienta, które czytają inne otwarte karty, albo gdy wysyłają zdarzenia analityczne lub wyświetlenia reklam, zanim użytkownik zobaczy stronę.

Prerenderowane strony mogą też być nieaktualne. Strona prerenderowana, gdy odwiedzający był wylogowany, nadal pokazuje widok dla niezalogowanych, nawet jeśli zaloguje się on w innej karcie. Chrome może trzymać stronę pobraną przez prefetch przez około pięć minut, więc pokazana treść może pochodzić sprzed nawet pięciu minut.

#Jak wyczyścić spekulowane strony po dodaniu do koszyka

Nagłówek odpowiedzi Clear-Site-Data przyjmuje wartości prefetchCache i prerenderCache. Wysłany w odpowiedzi na dowolne żądanie w obrębie tej samej witryny, na przykład na wywołanie AJAX, które dodaje produkt do koszyka, odrzuca spekulacje wykonane przed zmianą koszyka. Następne najechanie kursorem pobiera wtedy świeżą stronę koszyka lub zamówienia zamiast pokazywać starą.

// Odrzuć nieaktualne spekulacje po zmianie koszyka w WooCommerce
add_action( 'woocommerce_add_to_cart', function () {
    if ( ! headers_sent() ) {
        header( 'Clear-Site-Data: "prefetchCache", "prerenderCache"' );
    }
} );

#Jak rozpoznać żądania spekulatywne na serwerze

Chrome oznacza żądania spekulatywne nagłówkiem Sec-Purpose. Prefetch wysyła Sec-Purpose: prefetch, a prerender Sec-Purpose: prefetch;prerender. Każda odpowiedź końcowa (po przekierowaniach) spoza zakresu od 200 do 299 przerywa spekulację, a status 204 lub 205 przerywa prerender, ale nadal pozwala na prefetch. Zwrócenie błędu to najbardziej toporny sposób, żeby zablokować spekulację dla danej ścieżki. MDN zaleca raczej przepuścić żądanie i odłożyć efekty uboczne w JavaScripcie, bo zablokowana spekulacja to stracony zysk szybkości.

#Jak opóźnić analitykę do momentu pokazania prerenderowanej strony

document.prerendering ma wartość true, dopóki strona renderuje się w tle, a zdarzenie prerenderingchange zachodzi w chwili, gdy użytkownik ją aktywuje. Obejmij tym warunkiem analitykę, wyświetlenia reklam i wszystko inne, co powinno liczyć tylko prawdziwe odsłony:

function initTracking() {
    // analityka, wyświetlenia reklam, widżety czatu
}

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

Część API przeglądarki sama czeka na aktywację. Według MDN geolokalizacja, prośby o zgodę na powiadomienia, rejestracja service workera i dostęp do kamery zwracają oczekującą obietnicę (promise), dopóki strona nie zostanie pokazana, natomiast alert() wraca od razu, a confirm() zwraca false. Kod, który podczas ładowania strony polega na tych wynikach, potrzebuje tego samego zabezpieczenia.

#10. Które przeglądarki wspierają Speculation Rules API w 2026

Wersje pochodzą z danych MDN o zgodności przeglądarek, gdzie funkcja nadal ma status eksperymentalnej i nie należy do Baseline. W praktyce reguły przyspieszają nawigację w przeglądarkach opartych na Chromium, a w pozostałych nic nie robią. Dlatego rdzeń WordPressa traktuje je jako progressive enhancement.

#11. Jak używać Speculation Rules z Content Security Policy

#Jak dopuścić reguły spekulacji przy restrykcyjnym CSP

Blok reguł spekulacji to element <script>, więc restrykcyjna polityka script-src blokuje go jak każdy skrypt inline. MDN wymienia trzy sposoby, żeby go dopuścić: nonce, hash albo słowo kluczowe 'inline-speculation-rules'. Przewodnik Chrome dodaje, że to słowo kluczowe obejmuje reguły wstrzykiwane skryptem z hashem lub nonce, dlatego w witrynach z restrykcyjnym CSP reguły zwykle wstawia się JavaScriptem. Jeśli panel Speculative loads nie pokazuje żadnych reguł w witrynie z wtyczką bezpieczeństwa, najpierw sprawdź nagłówek CSP.

#Jak serwować reguły spekulacji nagłówkiem Speculation-Rules

Reguły mogą też trafić do pliku JSON wskazanego w nagłówku odpowiedzi HTTP. Wtedy nie ma ich w HTML i problem z CSP znika. Adres w nagłówku musi być ujęty w cudzysłów, plik musi mieć typ MIME application/speculationrules+json, a plik z innego originu musi przejść kontrolę CORS. Względne adresy w pliku są domyślnie rozwiązywane względem samego pliku JSON, więc jeśli ścieżki w regule odnoszą się do strony, dodaj do niej "relative_to": "document".

Speculation-Rules: "/speculationrules.json"

Reguły z nagłówka i reguły inline są łączone w jeden zestaw. Chrome 136 dodał pole tag, które trafia do nagłówka żądania Sec-Speculation-Tags, więc CDN albo serwer może rozpoznać, który zestaw reguł wywołał żądanie, i obsłużyć je inaczej.

#Na jakie spekulacje między domenami pozwala Chrome

Prerender jest domyślnie ograniczony do tego samego originu. Subdomenę w obrębie tej samej witryny, na przykład sklep na osobnej subdomenie, można prerenderować tylko wtedy, gdy odpowiada nagłówkiem Supports-Loading-Mode: credentialed-prerender, a prerender między różnymi witrynami w ogóle nie jest możliwy. Prefetch między witrynami działa tylko wtedy, gdy użytkownik nie ma ciasteczek dla witryny docelowej, co zapobiega śledzeniu. Odrzucone spekulacje tego typu widać w panelu Speculative loads w DevTools.

#12. Jak mierzyć Speculation Rules API po wdrożeniu

#Narzędzia do sprawdzania speculative loads

• Chrome DevTools: panel Speculative loads na karcie Application
• Lighthouse CI: Automatyzacja testów wydajności
• WebPageTest: Rzeczywiste testy z różnych lokalizacji
• DebugBear: Real User Monitoring (RUM)

#Jak śledzić trafienia spekulatywne w GA4

Resource Timing nie ma typu inicjatora “speculation”, więc ładowania spekulatywnego nie da się zaobserwować na stronie, która je wywołała. Mierz zamiast tego na stronie, na którą użytkownik trafia: activationStart większy od zera oznacza, że strona była prerenderowana, a deliveryType o wartości navigational-prefetch oznacza, że pochodzi z prefetchu. Oba pola opisuje MDN.

// Zgłoś, w jaki sposób dostarczono bieżącą stronę
const nav = performance.getEntriesByType('navigation')[0];
let delivery = 'normal';
if (nav.activationStart > 0) {
    delivery = 'prerender';
} else if (nav.deliveryType === 'navigational-prefetch') {
    delivery = 'prefetch';
}
gtag('event', 'page_delivery', { delivery_type: delivery });

Porównaj liczbę trafień prerender i prefetch z liczbą żądań spekulatywnych widocznych w logach serwera (zobacz nagłówek Sec-Purpose opisany wyżej). Różnica to zmarnowane spekulacje. Chrome mierzy Core Web Vitals prerenderowanej strony od aktywacji, a nie od początku prerenderingu, a biblioteka web-vitals od wersji 3.1.0 raportuje takie nawigacje z navigationType równym prerender, jak podaje przewodnik Chrome po prerenderingu. Dziel dane z rzeczywistych wizyt według tej wartości, bo inaczej niemal zerowe LCP prerenderowanych odsłon zamaskuje wolną zwykłą nawigację.

#13. Lista kontrolna wdrożenia Speculation Rules API

#Przed wdrożeniem

• Zmierz bazowy Lighthouse score
• Sprawdź TTFB < 200ms
• Upewnij się, że Object Cache jest aktywny
• Obrazy są serwowane jako AVIF

#W trakcie wdrożenia

• Dodaj bazowy prefetch (moderate)
• Analizuj heatmapy (Hotjar, Clarity)
• Zidentyfikuj top 3 ścieżki nawigacji
• Dodaj prerender dla linków o wysokim zamiarze
• Przetestuj na 10% ruchu (A/B)
• Monitoruj “zmarnowane” prefetchy

#Po wdrożeniu

• Porównaj LCP, INP, Navigation Time
• Sprawdź Cache Hit Ratio
• Długoterminowo: współczynnik odrzuceń, współczynnik konwersji

#Od czego zacząć wdrożenie Speculation Rules API

Speculation Rules API to przełom dla 2026. Dzięki preładowywaniu stron w tle, nawigacja staje się natychmiastowa, bez żadnych zmian w infrastrukturze.

Najważniejsze:

1. Zacznij od prefetch z moderate eagerness, to bezpieczne
2. Dodaj prerender dla procesu zakupowego w e-commerce
3. Monitoruj metryki, nie zgaduj, mierz

Potrzebujesz profesjonalnej optymalizacji? Jako specjalista WordPress pomagam w przyspieszaniu stron WordPress i WooCommerce. Zobacz też optymalizacja szybkości WordPress.