WordPress napędza ponad 40% internetu, a mimo to co druga strona na nim nie przechodzi progów szybkości Google. Zamiast opinii, dane: wyniki Core Web Vitals z HTTP Archive, wpływ Elementora, statystyki bezpieczeństwa wtyczek i uczciwa odpowiedź, kiedy WordPress wciąż jest dobrym wyborem.
Zacznijmy uczciwie: WordPress nie jest złym narzędziem
Według W3Techs WordPress napędza dziś 41,2% wszystkich stron internetowych i prawie 60% stron o rozpoznanym CMS-ie (stan: lipiec 2026). Tak dużej popularności nie osiąga się przypadkiem: WordPress jest darmowy, ma ogromny katalog wtyczek i motywów, a redakcja może publikować treści bez udziału programisty.
Od razu też zaznaczmy nasz interes: SKWEB buduje strony w Next.js, więc mamy w tym porównaniu swoją preferencję. Właśnie dlatego wszystkie liczby w tym tekście pochodzą z publicznych, pierwotnych źródeł (głównie z HTTP Archive, które mierzy realne wizyty użytkowników Chrome) i podajemy je również tam, gdzie są dla nas niewygodne.
Core Web Vitals: co mierzy Google i jak wypada WordPress
Google ocenia doświadczenie użytkownika trzema metrykami Core Web Vitals: LCP (szybkość wczytania głównej treści, próg 2,5 s), INP (reakcja na interakcję, 200 ms) i CLS (stabilność układu, 0,1), liczonymi na 75. percentylu realnych wizyt. Strona „przechodzi”, gdy wszystkie trzy są w normie.
Według raportu technologicznego HTTP Archive (czerwiec 2026, ruch mobilny) progi przechodzi 48,8% stron na WordPressie, wobec 53,1% średniej dla całego internetu. Ciekawiej robi się po rozbiciu na sposób budowania: strony składane Elementorem przechodzą w 36,8%, a strony na czystym edytorze Gutenberg w 60,1%, wyraźnie powyżej średniej. To nie WordPress jest wolny; wolne są ciężkie page buildery, którymi się go obudowuje.
Jest i druga strona medalu: WordPress w segmencie 10 tysięcy najpopularniejszych serwisów przechodzi Core Web Vitals w 59,3% przypadków, a jego zbiorczy wynik poprawił się rok do roku o ponad 5 punktów procentowych. Dobrze zrobiony WordPress po prostu działa.
A Next.js? Uczciwie: średnia rynkowa też nie błyszczy
W tym samym raporcie zbiorczy wynik stron na Next.js na urządzeniach mobilnych to 32,5%, gorzej niż WordPress. Nie ukrywamy tej liczby, bo dobrze pokazuje ważną prawdę: żadna technologia nie daje szybkości „z pudełka”. Profil próby jest inny (na Next.js powstają głównie duże, ciężkie aplikacje komercyjne), ale wniosek zostaje: o wyniku decyduje wykonanie, nie logo frameworka.
Argument za Next.js leży gdzie indziej: w architekturze renderowania. Framework domyślnie generuje strony na serwerze lub w czasie budowania, więc przeglądarka dostaje gotowy HTML zamiast pustej strony i paczki skryptów. Jak wiele to znaczy, pokazał opisany przez Google przypadek Vodafone: test A/B, w którym poprawa LCP o 31% (głównie dzięki przeniesieniu renderowania na serwer) podniosła sprzedaż o 8%. Nasze strony firmowe to w praktyce statyczny HTML z minimalną ilością skryptów, dlatego możemy gwarantować wynik Lighthouse 90+.
Dlaczego page buildery spowalniają strony
Mechanizm jest dobrze udokumentowany. Narzędzia typu „przeciągnij i upuść” opakowują każdy element strony w dodatkowe warstwy kodu, przez co dokument puchnie. Google w dokumentacji Lighthouse ostrzega przy ok. 800 elementach DOM, a powyżej ok. 1 400 zgłasza błąd. Tymczasem strony składane builderami regularnie te progi przekraczają. Duży DOM to wolniejsze przeliczanie stylów, większe zużycie pamięci i gorsza reakcja na kliknięcia (INP).
Co znamienne, przyznaje to sam Elementor: na firmowym blogu zaleca przejście ze starego układu sekcji na kontenery, bo generuje on o połowę mniej elementów. Kierunek słuszny, ale to leczenie objawów architektury, w której strona wizytówka potrafi ważyć tyle, co średni sklep internetowy.
Bezpieczeństwo: 9 na 10 podatności siedzi we wtyczkach
Drugi koszt ekosystemu wtyczek to bezpieczeństwo. Według raportu Patchstack „State of WordPress Security in 2026” w 2025 roku w ekosystemie WordPressa ujawniono 11 334 nowe podatności (o 42% więcej niż rok wcześniej), z czego 91% dotyczyło wtyczek, a zaledwie 6 samego rdzenia. Niemal połowa (46%) nie miała łatki w chwili ujawnienia.
Z kolei Sucuri podaje, że 95,5% zainfekowanych stron opartych o CMS, które analizowali, działało na WordPressie, przy czym sami zastrzegają, że to pochodna popularności platformy, nie jej jakości. Istotniejszy jest inny ich wynik: w momencie infekcji 39% stron miało nieaktualne oprogramowanie, a wśród najczęściej spotykanych podatnych komponentów wymieniają m.in. Elementor Pro. Praktyczny wniosek: strona na WordPressie to zobowiązanie do regularnych aktualizacji. I ten koszt trzeba doliczyć do ceny strony. Strona statyczna nie ma panelu logowania, bazy danych ani wtyczek do łatania, więc powierzchnia ataku jest nieporównywalnie mniejsza.
Kiedy WordPress, a kiedy Next.js? Prosta decyzja
Nasza szczera rekomendacja wygląda tak:
- Wybierz WordPress, jeśli publikujesz codziennie (blog, portal), potrzebujesz dziesiątek gotowych integracji z dnia na dzień i masz kogoś, kto zadba o aktualizacje, albo budżet na opiekę techniczną.
- Wybierz Next.js, jeśli strona ma przede wszystkim sprzedawać: liczy się szybkość, wynik w Google, bezpieczeństwo bez comiesięcznego łatania i pełna własność kodu. Czysty, semantyczny kod ułatwia przy tym dostępność zgodną z WCAG 2.1 i EAA, która od 2025 r. jest wymogiem prawnym.
- Edycję treści rozwiązuje headless CMS: system CMS podpinamy do strony w Next.js, więc samodzielna edycja treści nie wymaga rezygnacji z szybkości.
- Masz już stronę na WordPressie, która działa? Zostaw ją. Migrację warto planować, gdy strona realnie hamuje sprzedaż albo koszty opieki rosną szybciej niż ruch.