Być może już podejrzewają Państwo, że witryna WordPress nie działa tak szybko, jak mogłaby. Czy jednak sprawdzono jej działanie na urządzeniu mobilnym?
Wystarczy wyjąć telefon i załadować własną stronę. Proszę policzyć sekundy, obserwować skaczący układ i obrazy ładujące się w nieprawidłowych rozmiarach. Dokładnie to widzi 60% odwiedzających, bo taki właśnie udział ma ruch mobilny w 2026 roku.
Google też to obserwuje.
Mobile-first indexing: dlaczego szybkość na mobile decyduje o pozycji
Od 2021 roku Google stosuje mobile-first indexing dla każdej witryny w sieci. Oznacza to, że pozycja w wynikach wyszukiwania zależy od wydajności na urządzeniu mobilnym, nie na komputerze stacjonarnym.
Wydajność na komputerze nadal ma znaczenie w wielu procesach zakupowych B2B, jednak indeks Google jest oparty na wersji mobilnej i to szybkość mobilna niesie większą wagę SEO. Wynik 45 w mobilnym PageSpeed to liczba, którą analizuje crawler Google, i to ona decyduje, czy strona pojawi się na pierwszej, czy na trzeciej stronie wyników.
Wiele witryn WordPress bez dedykowanych działań optymalizacyjnych uzyskuje 35-55 punktów w mobilnym PageSpeed. To poniżej progu rekomendowanego przez Google i realny problem biznesowy.
Dlaczego WordPress sprawia problemy na urządzeniach mobilnych
Szablony nie były projektowane z myślą o mobile-first
Większość szablonów WordPress jest projektowana z myślą o komputerach stacjonarnych, a następnie dostosowywana do urządzeń mobilnych za pomocą media queries CSS. W efekcie telefon pobiera te same ciężkie zasoby co przeglądarka desktopowa, a następnie ukrywa to, czego nie potrzebuje. Dane są jednak przesyłane, JavaScript jest wykonywany, a użytkownik po prostu tego nie widzi.
Prawdziwa witryna mobile-first przesyła urządzeniu tylko to, czego faktycznie potrzebuje. Większość szablonów WordPress tego nie robi domyślnie, choć jest to możliwe przy starannym doborze i konfiguracji szablonu.
CSS i JavaScript blokujące renderowanie
Przeciętna witryna WordPress ładuje 15-25 oddzielnych plików CSS i JavaScript, zanim cokolwiek pojawi się na ekranie. Każdy plik to osobna komunikacja z serwerem. W sieciach mobilnych, nawet szybkim 4G, może to dodać 2-4 sekundy czystego oczekiwania przed wyświetleniem pierwszego piksela.
Wtyczki do buforowania próbują łączyć i minimalizować te pliki, lecz nie rozwiązują fundamentalnego problemu: WordPress ładuje wszystko z wyprzedzeniem, ponieważ wtyczki nie koordynują ze sobą działań.
Obrazy jako główna przyczyna problemów
WordPress generuje wiele rozmiarów obrazów, rzadko jednak serwuje właściwy dla danego urządzenia. Obraz hero o szerokości 2000px trafia na ekran telefonu o szerokości 390px. Nawet przy wtyczkach do lazy loading WordPress domyślnie nie obsługuje nowoczesnych formatów WebP ani AVIF i nie korzysta z węzłów CDN bliskich odwiedzającemu.
Na urządzeniach mobilnych obrazy stanowią często 60-80% łącznej wagi strony. Błąd w tym obszarze sprawia, że reszta optymalizacji traci znaczenie.
Page buildery generują ogromny narzut
Elementor, Divi, WPBakery to narzędzia ułatwiające projektowanie w WordPress. JavaScript page buildera może dodać 500kb-1.5MB na stronę. Witryny korzystające z wielu page builderów często ładują się 5-8 sekund na urządzeniach mobilnych średniej klasy w sieci 4G. Na komputerze z szybkim łączem różnica jest prawie niezauważalna.
Hosting współdzielony nie radzi sobie ze szczytami ruchu mobilnego
Użytkownicy mobilni są niecierpliwi i oczekują załadowania strony w czasie poniżej 2 sekund. Serwery hostingu współdzielonego, które potrzebują 800ms tylko na odpowiedź na pierwsze zapytanie, zużywają już połowę tego budżetu, zanim załaduje się choć jeden zasób.
Twarde liczby: WordPress kontra Next.js na urządzeniach mobilnych
Po kilkudziesięciu migracjach z WordPress do Next.js wyniki mobilne wyglądają zazwyczaj następująco:
| Metryka | WordPress (bez optymalizacji) | Next.js na Vercel |
|---|---|---|
| Mobile PageSpeed | 35-55 | 90-99 |
| First Contentful Paint | 3.0-5.5s | 0.3-0.8s |
| Largest Contentful Paint | 4.0-8.0s | 0.6-1.2s |
| Cumulative Layout Shift | 0.15-0.35 | 0.01-0.05 |
| Łączna waga strony | 2-5mb | 200-500kb |
Ta sama treść. Ta sama identyfikacja wizualna. Różnica leży w architekturze.
Co oznacza architektura mobile-first w praktyce
Witryny Next.js są zbudowane w fundamentalnie odmienny sposób:
Static generation. Strony są wstępnie kompilowane jako pliki HTML w momencie wdrożenia. Użytkownik mobilny otrzymuje statyczny plik z CDN, bez przetwarzania po stronie serwera, zapytań do bazy danych ani wykonywania PHP. Czas odpowiedzi: ok. 50ms globalnie.
Responsywne obrazy domyślnie. Wbudowany komponent Image w Next.js automatycznie serwuje właściwy rozmiar w formacie WebP lub AVIF, z lazy loading, z węzła brzegowego. Użytkownik mobilny z ekranem 390px otrzymuje obraz 390px, nie 2000px wciśnięty w wąski viewport.
Wdrożenie na edge CDN. Vercel serwuje witrynę z ponad 100 globalnych lokalizacji brzegowych. Użytkownik mobilny w Warszawie otrzymuje stronę z serwera w pobliskiej lokalizacji, nie ze współdzielonego serwera za oceanem. Sama odległość fizyczna może zaoszczędzić 200-400ms.
Minimalny JavaScript. Brak jQuery, łańcuchów wtyczek i środowiska uruchomieniowego page buildera. Typowa witryna biznesowa Next.js przesyła łącznie 50-100kb JavaScript, znacznie mniej niż typowe projekty WordPress (często 500kb-1.5MB).
Co można z tym zrobić
Najpierw należy sprawdzić wynik mobilny. Bez znajomości aktualnego wyniku mobilnego PageSpeed działanie jest pozbawione podstaw. Bezpłatny WordPress Health Report dostępny jest na webvise.io/wp-health-report. Raport pokazuje rzeczywisty wynik mobilny, zagrożenia bezpieczeństwa oraz prognozowany wynik po przebudowie.
Warto ocenić, czy dalsza optymalizacja WordPress pozwoli osiągnąć cel. Przy wyniku mobilnym poniżej 60 bardzo trudno przekroczyć 90+ wyłącznie za pomocą wtyczek. Można wydać środki na wtyczki do buforowania, optymalizatory obrazów i subskrypcje CDN, a wynik i tak może utknąć w okolicach 60. W pewnym momencie to architektura staje się czynnikiem ograniczającym.
Warto rozważyć przebudowę. Migracja z WordPress do Next.js jest dostosowana do złożoności witryny, wolumenu treści, ryzyka SEO i integracji, oraz usuwa architektoniczne przyczyny problemów z wydajnością mobilną. Prawidłowo zbudowane witryny już w momencie uruchomienia uzyskują zazwyczaj 90+ na mobile. Odpada konieczność utrzymywania pipeline'u wtyczek, a wydajność nie degraduje się przez aktualizacje wtyczek ani szablonów, choć aktualizacje frameworka i zależności pozostają.
Użytkownicy mobilni i crawler Google'a dostrzegają różnicę.
Chcą Państwo sprawdzić wynik swojej witryny na mobile? Bezpłatny WordPress Health Report czeka na webvise.io/wp-health-report. Zajmuje to 60 sekund, bez rejestracji.