Wydajność mobile-first: strategie optymalizacji pod indeks mobilny 2026

Google indeksuje i ocenia w rankingu mobilną wersję strony, pobraną przez swojego robota dla smartfonów. Strona na WordPressie, która jedynie zmniejsza układ desktopowy do szerokości telefonu, może dobrze wyglądać przy pobieżnym sprawdzeniu, a mimo to wysyłać ciężką, wolną stronę na urządzenie, od którego zależy jej indeksowanie. Wydajność mobile-first oznacza budowanie każdej strony najpierw pod telefon na ograniczonym łączu, a dopiero potem dokładanie wagi dla większych ekranów, i tylko tam, gdzie to się opłaca.

Więcej o przyspieszaniu WordPressa przeczytasz w WPPoland.

Ten przewodnik omawia wymagania indeksowania mobile-first w Google, progi Core Web Vitals dla urządzeń mobilnych, sposób mierzenia szybkości mobilnej w laboratorium i w terenie oraz funkcje WordPressa i wzorce kodu, które poprawiają LCP, INP, CLS i nawigację wstecz na telefonach.

#Historia indeksowania mobile-first od 2016 do 2024 roku

Dobre praktyki indeksowania mobile-first Google definiują pojęcie jednym zdaniem: Google używa mobilnej wersji treści witryny, pobranej przez agenta smartfonowego, do indeksowania i rankingu. Dojście do tego punktu dla całej sieci zajęło osiem lat.

We wpisie z października 2023 r. John Mueller i Nir Kalush opisali niewielką grupę witryn, które wciąż zostały na robocie desktopowym. Błędy to strony pokazujące błąd każdemu użytkownikowi mobilnemu, wersja mobilna zablokowana w robots.txt przy dostępnej dla robota wersji desktopowej oraz strony mobilne, które w całości przekierowują na stronę główną. W czerwcu 2024 r. Mueller napisał, że po 5 lipca 2024 r. witryna, której treści w ogóle nie da się otworzyć na urządzeniu mobilnym, przestanie być indeksowana. Googlebot Desktop nadal pojawia się w logach serwera przy niektórych funkcjach, takich jak listingi produktów i Google for Jobs, więc desktopowy user agent w logu dostępu nie oznacza, że witryna została pominięta.

„Indeks mobilny 2026” nie jest więc nowym indeksem. Zmiana nastąpiła w latach 2023 i 2024. Zmienia się natomiast treść Twoich stron mobilnych i to, jak szybko działają dla prawdziwych odwiedzających.

#Co dokumentacja mobile-first Google każe sprawdzić na stronach WordPress

Strona z dobrymi praktykami to lista kontrolna zgodności. Wersja mobilna strony powinna odpowiadać desktopowej pod względem:

• głównej treści, w tym tekstu, obrazów i wideo
• danych strukturalnych
• elementu title i meta description
• tekstu alternatywnego obrazów
• metatagów robots
• nagłówków

Ta sama strona przestrzega przed leniwym ładowaniem głównej treści, która pojawia się dopiero po interakcji użytkownika, na przykład po dotknięciu lub przesunięciu, bo robot takich interakcji nie wykonuje. W WordPressie typowi winowajcy to zakładki lub akordeony, które pobierają treść przez AJAX po kliknięciu, oraz osobne szablony mobilne ze starszych wtyczek mobilnych, które gubią sekcje, schema lub tekst alternatywny. Responsywny motyw, który wysyła ten sam HTML na każde urządzenie, z założenia przechodzi kontrolę zgodności. To jeden z powodów, by ostrożnie podchodzić do HTML zależnego od urządzenia, o czym więcej w sekcji o Client Hints poniżej.

#Progi Core Web Vitals dla urządzeń mobilnych w 2026 roku

Obecne progi wyglądają tak:

Od marca 2024 r. wskaźnikiem responsywności jest Interaction to Next Paint. Wpis Ricka Viscomiego na web.dev ogłosił INP stabilnym wskaźnikiem Core Web Vitals w miejsce First Input Delay i dał deweloperom czas do 9 września 2024 r. na odejście od FID. Poradnik, który nadal wymienia FID jako wskaźnik Core Web Vitals, powstał przed tą zmianą.

Każdy próg oceniany jest na 75. percentylu wczytań strony, osobno dla urządzeń mobilnych i desktopu (web.dev, Web Vitals). Mobile i desktop to odrębne populacje, więc szybki wynik na desktopie nic nie mówi o wyniku na telefonie.

Wiele zespołów ustala wewnętrzne cele poniżej granicy „dobry”, żeby zostawić zapas, bo dane terenowe zmieniają się wraz ze strukturą ruchu, kampaniami i skryptami zewnętrznymi. Dokumentacja Google o page experience dodaje zastrzeżenie: pogoń za idealnym wynikiem wyłącznie z powodów SEO może nie być najlepszym wykorzystaniem czasu.

#Jak Google wykorzystuje sygnały page experience w rankingu

Dokumentacja Google o page experience odpowiada na pytanie o ranking wprost:

• Nie istnieje jeden sygnał page experience. Główne systemy rankingowe biorą pod uwagę wiele sygnałów.
• Core Web Vitals są używane przez systemy rankingowe Google.
• Poza Core Web Vitals pozostałe aspekty page experience nie pomagają bezpośrednio w osiągnięciu wyższej pozycji, choć sprawiają, że korzystanie z witryny jest przyjemniejsze.
• Page experience ocenia się zasadniczo dla pojedynczych stron, z pewnymi ocenami dla całej witryny.
• Google nadal pokazuje najtrafniejszą treść, nawet gdy page experience jest słabe. Dobre doświadczenie pomaga tam, gdzie wiele stron jest podobnie przydatnych.

Dla pracy nad wersją mobilną wyznacza to priorytety. Rozmiar elementów dotykowych, przejrzyste menu mobilne i zgodność z bfcache warto wdrożyć ze względu na odwiedzających i na wskaźniki Core Web Vitals, na które wpływają, ale Google nie opisuje ich jako osobnych sygnałów rankingowych. Ta sama strona nie wymienia żadnego wymogu AMP: jej samoocena obejmuje Core Web Vitals, HTTPS, wyświetlanie na urządzeniach mobilnych, reklamy, natrętne reklamy pełnoekranowe i czytelny obszar głównej treści.

#Jak testować szybkość mobilną w laboratorium i w terenie

#Ustawienia emulacji mobilnej w Lighthouse

Domyślny test mobilny w Lighthouse emuluje Moto G Power (2022) z widokiem 412 na 823 piksele, co ustawiają stałe konfiguracyjne Lighthouse. Dokumentacja ograniczania przepustowości podaje ustawienia sieci: 150 ms opóźnienia, 1,6 Mb/s pobierania i 750 Kb/s wysyłania, z etykietą „Slow 4G” i opisem odpowiadającym mniej więcej najwolniejszej ćwiartce połączeń 4G. Ograniczenie CPU używa stałego mnożnika 4x, który ma przenieść wydajny komputer stacjonarny do przedziału telefonów ze średniej półki. Na wolniejszym laptopie ten mnożnik przesadza, więc przed porównaniem wyników z różnych maszyn sprawdź wartość „CPU/Memory Power” na dole raportu.

• Lighthouse (Chrome DevTools): emulacja mobilna z ograniczeniem CPU i sieci
• PageSpeed Insights: dane od prawdziwych użytkowników (CrUX) plus laboratoryjny test Lighthouse
• WebPageTest: testy na prawdziwych urządzeniach z różnych lokalizacji

#Dane terenowe z CrUX i Search Console

Ocena Core Web Vitals opiera się na danych terenowych. Zgodnie z metodologią CrUX dane zbierane są wyłącznie od użytkowników Chrome, którzy włączyli raportowanie statystyk użytkowania i synchronizują historię przeglądania, a Chrome na iOS jest wykluczony. Safari to nie Chrome, więc również nic nie wnosi. Witryna, której mobilni odwiedzający korzystają głównie z iPhone’ów, dostaje mobilny wynik terenowy od użytkowników Androida.

• Chrome User Experience Report (CrUX): dane od prawdziwych użytkowników Chrome
• Google Search Console (raport Core Web Vitals): grupy mobilne i desktopowe dla Twoich adresów URL
• RUM (Real User Monitoring): narzędzia takie jak SpeedCurve, Calibre czy New Relic do ciągłego monitorowania we wszystkich przeglądarkach

#Na jakich telefonach testować

Żaden emulator nie odtwarza w pełni prawdziwego urządzenia. Do testów warto mieć co najmniej:

• smartfon ze średniej półki (Moto G lub Samsung Galaxy A)
• aktualny smartfon z wyższej półki (iPhone lub Pixel)
• tablet (iPad lub Samsung Tab)

#Ładowanie adaptacyjne w zależności od urządzenia w WordPressie

Ładowanie adaptacyjne serwuje tę samą stronę w różnej wadze, zależnie od tego, z czym poradzi sobie urządzenie odwiedzającego.

#Jak wykryć możliwości urządzenia w JavaScripcie

// Wykrywanie możliwości urządzenia, z wartościami domyślnymi, gdy brakuje API
const getDeviceCapabilities = () => {
  return {
    // Rdzenie CPU
    cores: navigator.hardwareConcurrency || 4,
    // Przybliżona pamięć urządzenia w GB (nie w każdej przeglądarce)
    memory: navigator.deviceMemory || 4,
    // Efektywny typ połączenia
    connection: navigator.connection?.effectiveType || '4g',
    // Preferencja ograniczonego zużycia danych
    saveData: navigator.connection?.saveData || false,
  };
};

MDN oznacza navigator.deviceMemory jako funkcję o ograniczonej dostępności, spoza Baseline, działającą tylko przez HTTPS i celowo nieprecyzyjną: wartość jest zaokrąglana do potęgi dwójki, żeby utrudnić fingerprinting. Traktuj ją jako wskazówkę z bezpieczną wartością domyślną. Wybór formatu obrazu w ogóle nie wymaga wykrywania, bo pokazany niżej element picture pozwala przeglądarce samodzielnie wybrać AVIF lub WebP.

#Co serwować telefonom z wyższej, średniej i niższej półki

Na podstawie wykrytych możliwości:

Urządzenia z wyższej półki (8+ rdzeni, 8+ GB RAM, szybkie połączenie):

• obrazy AVIF w pełnej jakości
• pełny JavaScript z animacjami
• szersze speculative loading prawdopodobnych kolejnych stron
• tła wideo tam, gdzie służą treści

Urządzenia ze średniej półki (4 do 6 rdzeni, 4 do 6 GB RAM, 4G):

• obrazy średniej jakości
• ograniczony JavaScript, proste animacje CSS
• speculative loading tylko dla głównych linków
• statyczne obrazy zamiast teł wideo

Urządzenia z niższej półki (2 do 4 rdzeni, poniżej 4 GB RAM, wolne połączenie lub Save-Data):

• mocno skompresowane obrazy
• tylko niezbędny JavaScript
• bez speculative loading, żeby oszczędzać transfer
• uproszczony układ bez efektów wizualnych

#Client Hints, Accept-CH i cache stron w WordPressie

Client Hints pozwalają serwerowi podjąć tę samą decyzję, zanim wyśle HTML. Przeglądarka nie wysyła ich bez prośby. Zgodnie z przewodnikiem MDN po Client Hints serwer ogłasza, których wskazówek potrzebuje, w nagłówku odpowiedzi Accept-CH, a przeglądarka dołącza je do kolejnych żądań. Pierwsze wyświetlenie strony przez nowego odwiedzającego przychodzi więc bez nich. Domyślnie mogą być wysyłane tylko wskazówki o niskiej entropii (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile i Sec-CH-UA-Platform). Pamięć urządzenia przesyłana jest jako Sec-CH-Device-Memory, a jakość sieci jako ECT, RTT i Downlink.

// 1. Poproś przeglądarkę o wskazówki o urządzeniu i sieci w kolejnych żądaniach
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Odczytaj wskazówki i wybierz poziom wydajności
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

Adaptacja po stronie serwera zwykle psuje się na cache. Wtyczka do cache całych stron albo CDN przechowuje jedną kopię HTML na adres URL, chyba że klucz cache uwzględnia wskazówkę. Bez tego poziom wybrany dla pierwszego odwiedzającego trafia do wszystkich kolejnych. MDN zaleca wymienianie w nagłówku Vary wskazówek, które zmieniają odpowiedź, i ostrzega, że wskazówki o wielu możliwych wartościach, takie jak Downlink i RTT, sprawiają, że odpowiedzi praktycznie nie da się cache’ować. Dla większości stron na WordPressie bezpieczniejszy podział to identyczny HTML dla każdego urządzenia, wybór plików obrazów przez srcset i sizes oraz adaptacja JavaScriptu po stronie klienta. Zachowuje to też zgodność treści, której wymaga dokumentacja mobile-first Google.

#Jak poprawić mobilne LCP

Largest Contentful Paint to zwykle najtrudniejszy do poprawienia wskaźnik na telefonach, bo zależy jednocześnie od sieci, procesora i rozmiaru treści.

#Który element jest LCP na telefonie

Na większości stron WordPress mobilnym elementem LCP jest jeden z tych:

• obraz główny lub obrazek wyróżniający wpisu
• baner w sliderze
• pierwszy długi blok tekstu, na stronach bez obrazów

#Składowe LCP i to, gdzie ucieka czas

Przewodnik web.dev o optymalizacji LCP dzieli wskaźnik na cztery składowe: czas do pierwszego bajtu, opóźnienie wczytania zasobu (od TTFB do chwili, gdy przeglądarka zaczyna pobierać zasób LCP), czas pobierania zasobu oraz opóźnienie renderowania elementu (od końca pobierania do pełnego wyrenderowania elementu). Według przewodnika większość czasu powinna przypadać na pobranie dokumentu HTML i zasobu LCP, po około 40 procent na każde, a każde z dwóch opóźnień powinno zostać poniżej 10 procent. Długie opóźnienie wczytania zasobu prawie zawsze oznacza, że przeglądarka znalazła obraz za późno. Ten sam przewodnik wymienia obraz LCP ustawiony jako tło CSS jako przypadek, którego skaner wstępnego ładowania nie wykryje w HTML, i zaleca, by nigdy nie ładować leniwie obrazu LCP.

#Jak przyspieszyć LCP przez preload, format i rozmiar obrazu

Wstępne ładowanie zasobu LCP:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Usunięcie łańcuchów odkrywania: Przeglądarka powinna znaleźć zasób LCP jak najwcześniej:

1. Pobiera się HTML (TTFB)
2. Zasób LCP zostaje wykryty w HTML
3. Zaczyna się pobieranie zasobu

Jeśli obraz główny jest wskazany w zewnętrznym arkuszu stylów jako background-image, przeglądarka nie odkryje go, dopóki nie pobierze i nie przetworzy CSS. Umieść <img> bezpośrednio w HTML z fetchpriority="high".

Optymalny format obrazu:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Trafny opis"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Rozmiary obrazów dla telefonów: Nie wysyłaj tego samego pliku na telefony i komputery. Ekran telefonu o szerokości 400 pikseli nie potrzebuje obrazu o szerokości 1920 pikseli (więcej w naszym poradniku o optymalizacji obrazów i critical CSS):

// Dodaj rozmiary obrazów dla układów mobilnych
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#Funkcje rdzenia WordPressa dla responsywnych obrazów i leniwego ładowania

Duża część opisanej wyżej pracy z obrazami jest już w rdzeniu WordPressa, a wtyczka, która ją powtarza, może przeszkadzać.

• WordPress 4.4 (2015): srcset i sizes. Notka deweloperska Joe McGilla wyjaśnia, że WordPress dodaje srcset i sizes do generowanego kodu obrazów, dzięki czemu przeglądarka może pobrać najodpowiedniejszy rozmiar. Domyślna wartość sizes zakłada, że obraz jest wyświetlany w swojej szerokości, maksymalnie do pełnej szerokości widoku, a notka zaleca motywom dostosowanie jej filtrem wp_calculate_image_sizes (wp_calculate_image_srcset zmienia listę kandydatów). Filtr max_srcset_image_width ogranicza uwzględniane szerokości, domyślnie do 1600 pikseli. To samo wydanie dodało rozmiar medium_large o szerokości 768 pikseli bez limitu wysokości, generowany tylko dla nowych plików albo po ponownym wygenerowaniu rozmiarów.
• WordPress 5.5: natywne leniwe ładowanie. Atrybutem loading steruje wp_lazy_loading_enabled, wprowadzone w 5.5 i domyślnie włączone dla iframe’ów od 5.7.
• WordPress 6.3: atrybuty optymalizacji ładowania. wp_get_loading_optimization_attributes decyduje, czy obraz dostanie loading="lazy", fetchpriority="high" lub decoding="async". Nie rusza atrybutów, które już są, i ostrzega, gdy element miałby dostać jednocześnie leniwe ładowanie i wysoki priorytet. Od wersji 7.0 akceptuje też fetchpriority="low" i fetchpriority="auto", tak by leniwe ładowanie nie zostało dodane.

Praktyczne sprawdzenie odbywa się w wyrenderowanym HTML prawdziwej strony w widoku telefonu: obraz główny powinien mieć fetchpriority="high" i nie mieć loading="lazy", a jego wartość sizes powinna odpowiadać miejscu, które obraz faktycznie zajmuje w układzie mobilnym. Motyw, który wyświetla obraz główny jako tło CSS, omija to wszystko.

#Speculative loading w WordPressie 6.8

WordPress 6.8 włączył speculative loading przez przeglądarkowe Speculation Rules API. Notka deweloperska Felixa Arntza opisuje ustawienia domyślne:

• Funkcja działa we frontendzie wszystkich witryn, z wyjątkiem zalogowanych użytkowników i witryn z wyłączonymi przyjaznymi bezpośrednimi odnośnikami.
• Adresy URL są pobierane z wyprzedzeniem w trybie conservative, który uruchamia się, gdy użytkownik zaczyna klikać link.
• Adresy URL z parametrami zapytania są automatycznie wykluczane, co obejmuje większość „adresów akcji”, które zmieniają stan przy żądaniu GET.
• API obsługują Chrome, Edge i Opera; pozostałe przeglądarki je ignorują, więc nic się nie psuje.

Notka podaje, że przed scaleniem wtyczka z tą funkcją działała na ponad 50 000 witryn, a witryny, które jej używały, poprawiły odsetek zaliczonego LCP o około 1,9 procent w medianie, według danych HTTP Archive i CrUX. Na telefonie, gdzie cała nawigacja to dotknięcia linków oraz przycisków wstecz i dalej, ma to większe znaczenie niż na desktopie. Wtyczki z własnymi ścieżkami akcji, na przykład koszykiem, powinny je wykluczyć:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#Jak poprawić mobilne INP

INP mierzy, jak szybko strona reaguje na działania użytkownika. Artykuł web.dev o INP uwzględnia trzy typy interakcji: kliknięcia myszą, dotknięcia ekranu dotykowego i naciśnięcia klawiszy na fizycznej lub ekranowej klawiaturze. Najechanie kursorem, powiększanie i przewijanie nie są brane pod uwagę. Opóźnienie każdej interakcji ma trzy części: opóźnienie wejścia, zanim uruchomi się jakikolwiek handler, czas przetwarzania handlerów i opóźnienie prezentacji do namalowania kolejnej klatki. Na telefonie każda interakcja to dotknięcie, a procesor jest wolniejszy, więc rosną wszystkie trzy części.

#Główne przyczyny słabego mobilnego INP

1. Ciężki JavaScript w wątku głównym: skrypty zewnętrzne (analityka, czat, reklamy), które blokują interakcję.
2. Hydratacja frameworka: React, Vue lub Angular hydratujące komponenty po początkowym wczytaniu.
3. Kosztowne handlery zdarzeń: listenery, które przy dotknięciu wykonują ciężkie obliczenia.
4. Długie zadania: przewodnik web.dev o optymalizacji długich zadań definiuje długie zadanie jako każde zadanie trwające dłużej niż 50 ms.

#Jak obniżyć INP przez odroczenie JavaScriptu

Odrocz niekrytyczny JavaScript:

<!-- Wczytaj analitykę po pierwszej interakcji użytkownika -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Wczytaj przy pierwszym dotknięciu, przewinięciu lub naciśnięciu klawisza albo po 5 sekundach
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

Używaj requestIdleCallback do pracy, która nie jest pilna:

// Wykonuj niekrytyczną pracę, gdy przeglądarka jest bezczynna
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

Oddawaj sterowanie wewnątrz handlerów zdarzeń:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // widoczna reakcja w następnej klatce
  await yieldToMain();  // pozwól przeglądarce najpierw namalować
  heavyCalculation();   // wolna część wykonuje się w późniejszym zadaniu
});

Opakowanie ciężkiej pracy w requestAnimationFrame nie pomaga, bo ten callback uruchamia się tuż przed kolejnym malowaniem i nadal wstrzymuje klatkę. Oddanie sterowania dzieli pracę tak, że przeglądarka może najpierw namalować reakcję na dotknięcie. Przewodnik o długich zadaniach odnotowuje, że scheduler.yield() jest obsługiwane w Chrome i Edge 129 oraz Firefoksie 142, ale nie w Safari, i dlatego w kodzie jest zapasowy setTimeout.

#Jak zapobiegać mobilnemu CLS w WordPressie

Cumulative Layout Shift (CLS) najbardziej szkodzi na telefonie, gdzie ekran jest mały i każdy ruch jest widoczny. Na telefonie przesunięcie o 10 pikseli przeszkadza znacznie bardziej niż na monitorze 27-calowym.

#Co powoduje CLS na telefonach

• obrazy bez jawnie podanych wymiarów
• fonty webowe powodujące FOUT lub FOIT
• reklamy i treść wstrzykiwana dynamicznie
• paski nawigacji zmieniające rozmiar przy przewijaniu
• wirtualna klawiatura wypychająca treść

#Jak zarezerwować miejsce na obrazy, fonty i reklamy

Rezerwuj miejsce na obrazy:

/* Kontenery o stałych proporcjach dla obrazów */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Wstępnie ładuj krytyczne fonty:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap z fontem zastępczym o dopasowanych metrykach */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Rezerwuj miejsce na reklamy:

.ad-slot {
  min-height: 250px; /* Oczekiwana wysokość reklamy */
  background: #f5f5f5;
  contain: layout;
}

#Jak sprawić, by strony WordPress mogły trafić do bfcache

Pamięć podręczna wstecz/dalej (bfcache) przechowuje w pamięci pełny stan strony, łącznie ze stertą JavaScriptu, więc powrót przywraca ją niemal natychmiast, bez sięgania do sieci. Przewodnik po bfcache na web.dev autorstwa Philipa Waltona i Barry’ego Pollarda przytacza dane o użyciu Chrome, według których na telefonach 1 na 5 nawigacji to nawigacja wstecz lub dalej, wobec 1 na 10 na desktopie. Wszystkie główne przeglądarki mają bfcache, Chrome od wersji 96.

#Co blokuje bfcache

• Listenery unload. Na desktopie Chrome i Firefox wykluczają stronę z listenerem unload. Na telefonach Chrome i Safari nadal próbują takie strony zapisać, ale handler staje się zawodny. Zamiast niego używaj pagehide; Lighthouse ma audyt no-unload-listeners, który wyłapuje też kod zewnętrzny.
• Cache-Control: no-store w HTML. Przeglądarki tradycyjnie odmawiały umieszczania takich stron w bfcache. Dla treści, która musi być aktualna, ale nie jest wrażliwa, przewodnik zaleca no-cache lub max-age=0, które nie wpływają na kwalifikację.
• Odwołania window.opener. Strony otwartej przez window.open() i sterowanej z okna, które ją otworzyło, nie da się zapisać. rel="noopener" tego unika i jest teraz domyślnym zachowaniem przeglądarek dla target="_blank".
• Otwarte połączenia. Niektóre przeglądarki pomijają strony z otwartym połączeniem IndexedDB, trwającym fetch() lub XMLHttpRequest albo otwartym połączeniem WebSocket lub WebRTC. Przewodnik odnotowuje, że Chrome (od wersji 149) i Safari nie blokują już strony przy otwartych WebSocketach. Zamykaj połączenia w pagehide i otwieraj je ponownie w pageshow.

Użytkownicy mobilni stale korzystają z przycisku „Wstecz”. Gdy strona wraca z bfcache, pojawia się bez nowego żądania.

#Jak sprawdzić, czy strona została przywrócona z bfcache

// Sprawdź, czy strona została przywrócona z bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // W razie potrzeby odśwież dynamiczną treść, np. liczbę produktów w koszyku
    refreshDynamicContent();
  }
});

Przewodnik zaleca też odświeżanie nieaktualnych lub wrażliwych danych w pageshow, gdy persisted ma wartość true, na przykład sumy koszyka, którą użytkownik zmienił na innej stronie.

#Ustawienia WordPressa dla bfcache

// Wyślij nagłówki cache i polityk przed jakimkolwiek wyjściem
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Odrzuć handlery unload, także te dodane przez skrypty zewnętrzne
        header('Permissions-Policy: unload=()');
    }
});

// Usuń skrypt wtyczki, o którym wiadomo, że rejestruje handler unload
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Nagłówki należą do send_headers, bo wp_enqueue_scripts działa wewnątrz wp_head, gdy wyjście już się zaczęło. Linia z Permissions Policy realizuje zalecenie przewodnika po bfcache dla witryn, które w ogóle nie używają unload. Chrome DevTools ma w panelu Application test pamięci wstecz/dalej, który podaje dokładną przyczynę blokady dla danej strony.

#Elementy dotykowe i menu mobilne, które łatwo trafić palcem

Elementy dotykowe mają znaczenie dla użyteczności i dostępności. Google nie opisuje ich jako sygnału rankingowego.

#Minimalny rozmiar elementu dotykowego

• WCAG 2.2, kryterium sukcesu 2.5.8 (poziom AA): dokument Understanding wymaga celów dla wskaźnika o wymiarach co najmniej 24 na 24 piksele CSS, z wyjątkami dotyczącymi odstępów, równoważnej kontrolki, celów w tekście, kontrolek przeglądarki i przypadków niezbędnych. Dla ważnych kontrolek odsyła do surowszego kryterium 2.5.5 Target Size (Enhanced).
• Wytyczne Lighthouse dotyczące elementów dotykowych: dokumentacja audytu mówi, że elementy 48 na 48 pikseli nigdy nie oblewają testu, a 8 pikseli odstępu między nimi to dobry punkt wyjścia.

Wyjątek dla celów w tekście ma znaczenie dla CSS. Linki w akapitach nie potrzebują minimalnej wysokości, więc wymiary nadawaj tylko nawigacji, przyciskom i polom formularzy:

/* Minimalne elementy dotykowe dla kontrolek, nie dla linków w tekście */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#Jak zrobić menu mobilne, które łatwo obsłużyć palcem

Mobilne menu nawigacyjne wymaga szczególnej uwagi przy elementach dotykowych:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Czytelne bez powiększania */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Optymalizacja mobilnych Core Web Vitals w WPPoland

W WPPoland budujemy pod urządzenie w dłoni użytkownika, a nie pod monitor na naszym biurku.

1. Ładowanie adaptacyjne: utrzymujemy identyczny HTML na wszystkich urządzeniach i dostosowujemy obrazy oraz skrypty tam, gdzie pomiary pokazują zysk.
2. Audyt pod kątem telefonów: testujemy na prawdziwych urządzeniach mobilnych, nie tylko w emulacji przeglądarki.
3. Najpierw dane terenowe: pracujemy na mobilnym raporcie CrUX, przenosząc grupy adresów URL ze stanu „Słaby” lub „Wymaga poprawy” do „Dobry”.

#Najczęstsze pytania o wydajność mobilną

1. Czy aplikacja mobilna oznacza, że nie potrzebuję szybkiej strony mobilnej? Nie. Większość ruchu nadal pochodzi z wyszukiwarek i linków w mediach społecznościowych. Jeśli strona mobilna jest wolna, odwiedzający wychodzą, zanim w ogóle zobaczą link do aplikacji.
2. Czy Dynamic Serving jest lepsze od Responsive Design? W praktyce odpowiedzią jest często rozwiązanie hybrydowe. HTML i CSS pozostają responsywne i identyczne dla każdego urządzenia, a pliki obrazów, JavaScript i funkcje niekrytyczne dopasowuje się do urządzenia i połączenia.
3. Jaki jest cel LCP na telefonach w 2026 roku? Próg „dobry” to 2,5 s na 75. percentylu mobilnych wczytań strony. Celuj poniżej z takim zapasem, żeby cięższy tydzień kampanii nie wypchnął strony ponad próg.

#Podsumowanie

Google pobiera i indeksuje sieć jako smartfon od zakończenia migracji w latach 2023 i 2024. Praca nad wydajnością mobilną WordPressa sprowadza się teraz do kilku mierzalnych rzeczy: tej samej treści na każdym urządzeniu, obrazu LCP, który przeglądarka znajdzie w HTML, krótkich zadań wokół każdego dotknięcia, zarezerwowanego miejsca na wszystko, co wczytuje się później, oraz stron, które bfcache może przechować. Mierz je w CrUX dla mobilnych odwiedzających, sprawdzaj w Lighthouse na profilu z ograniczeniem przepustowości i poprawiaj kolejne wskaźniki Core Web Vitals w tej kolejności. Szczegóły dotyczące samego INP znajdziesz w przewodniku po optymalizacji INP.

Jeśli mobilne Core Web Vitals hamują pozycje Twojej strony, skontaktuj się z WPPoland w sprawie audytu mobilnego.