Google PageSpeed Insights – czy warto walczyć o 100/100? Jak naprawdę przyspieszyć stronę WordPress

Szybkość strony internetowej od lat jest jednym z najczęściej poruszanych tematów przy tworzeniu i optymalizacji stron WordPress. Klient uruchamia Google PageSpeed Insights, widzi wynik 55/100 na urządzeniach mobilnych i pojawia się pytanie:

Czy moja strona jest wolna?

Chwilę później pojawia się kolejne:

Czy da się zrobić 100/100 w PageSpeed Insights i czy taki wynik rzeczywiście jest potrzebny?

Odpowiedź nie jest tak oczywista, jak mogłoby się wydawać.

PageSpeed Insights jest bardzo dobrym narzędziem diagnostycznym, ale wynik punktowy nie powinien być jedynym wyznacznikiem jakości strony. Witryna osiągająca 98/100 może być mniej skuteczna sprzedażowo niż strona z wynikiem 80/100. Z kolei rozbudowany sklep WooCommerce z analityką, remarketingiem, systemem płatności, mapami, formularzami i integracjami praktycznie zawsze będzie trudniejszy do zoptymalizowania niż prosta strona składająca się z kilku nagłówków i zdjęcia.

W tym artykule wyjaśnimy, jak działa Google PageSpeed Insights, co oznaczają jego wyniki, czy warto walczyć o 100/100 oraz co faktycznie wpływa na szybkość WordPressa.

Czym jest Google PageSpeed Insights?

Google PageSpeed Insights, często skracany do PSI, to bezpłatne narzędzie Google analizujące wydajność strony internetowej na urządzeniach mobilnych i komputerach.

Po wpisaniu adresu URL otrzymujemy między innymi ocenę wydajności oraz informacje dotyczące:

• czasu wyświetlenia głównej zawartości,
• szybkości reakcji strony,
• stabilności wizualnej,
• czasu odpowiedzi serwera,
• JavaScriptu blokującego główny wątek,
• nieużywanego CSS i JS,
• rozmiaru obrazów,
• sposobu ładowania fontów,
• cache,
• zasobów blokujących renderowanie,
• skryptów firm zewnętrznych.

PageSpeed Insights korzysta przy tym z dwóch rodzajów danych.

Dane laboratoryjne – Lighthouse

Pierwsza część to test wykonywany w kontrolowanych warunkach przez Lighthouse.

Google symuluje określone urządzenie i połączenie internetowe, a następnie mierzy zachowanie strony.

Jest to bardzo przydatne podczas optymalizacji, ponieważ pozwala znaleźć konkretne problemy techniczne.

Właśnie z tego testu pochodzi popularny wynik:

Performance: 0–100

Google klasyfikuje go następująco:

• 90–100 – wynik dobry,
• 50–89 – wymaga poprawy,
• 0–49 – wynik słaby.

Co ważne, nawet Google zaznacza, że idealne 100/100 jest bardzo trudne do uzyskania i nie jest wynikiem oczekiwanym.

Dane rzeczywistych użytkowników – CrUX

Drugi element jest moim zdaniem jeszcze ważniejszy.

Jeżeli strona posiada wystarczająco dużo ruchu, PageSpeed Insights może pokazywać dane pochodzące od rzeczywistych użytkowników Chrome.

Są to dane CrUX – Chrome User Experience Report.

Obejmują doświadczenia użytkowników z ostatnich około 28 dni, a nie pojedynczy test wykonany kilka sekund temu.

Dlatego może wystąpić sytuacja:

PageSpeed Performance: 68/100

ale jednocześnie:

Core Web Vitals: zaliczone

I odwrotnie.

Możemy otrzymać laboratoryjne 95/100, ale prawdziwi użytkownicy korzystający ze słabszych smartfonów i wolniejszego internetu nadal mogą mieć problemy.

Dlatego podczas profesjonalnej optymalizacji nie patrzymy wyłącznie na duże kolorowe kółko z wynikiem.

Core Web Vitals – ważniejsze niż samo 100/100

Obecnie najważniejsze wskaźniki wydajności Google to tzw. Core Web Vitals.

Są to:

LCP – Largest Contentful Paint

LCP określa, jak szybko pojawia się największy istotny element widoczny na ekranie.

Może to być:

• zdjęcie hero,
• banner,
• duży nagłówek,
• obraz produktu,
• duży blok treści.

Dobry wynik:

LCP do 2,5 sekundy.

Jeżeli użytkownik otwiera stronę i przez kilka sekund patrzy na pusty ekran lub loader, nawet świetny wynik innych parametrów niewiele pomoże.

INP – Interaction to Next Paint

INP mierzy szybkość reakcji strony na działania użytkownika.

Przykładowo użytkownik:

• klika menu,
• rozwija filtr produktów,
• dodaje produkt do koszyka,
• otwiera popup,
• wybiera wariant produktu,
• używa wyszukiwarki.

Strona powinna szybko odpowiedzieć.

Dobry wynik:

INP do 200 ms.

INP jest szczególnie istotny na stronach posiadających dużo JavaScriptu.

Rozbudowane menu, slidery, animacje, popupy, filtry AJAX, skrypty marketingowe czy rozbudowane page buildery mogą powodować przeciążenie głównego wątku przeglądarki.

CLS – Cumulative Layout Shift

CLS mierzy stabilność układu.

Klasyczny przykład:

Chcesz kliknąć przycisk „Kup teraz”, ale chwilę przed kliknięciem wczytuje się banner lub zdjęcie i cały layout przesuwa się o 100 pikseli.

Klikasz w zupełnie inne miejsce.

To właśnie problem CLS.

Dobry wynik:

CLS do 0,1.

Google ocenia Core Web Vitals na podstawie 75. percentyla doświadczeń użytkowników, a za prawidłowe uznaje wartości LCP do 2,5 s, INP do 200 ms i CLS do 0,1.

Czy PageSpeed Insights wpływa na SEO?

Tak, ale należy dobrze rozumieć ten temat.

Sama liczba:

Performance 92/100

nie jest bezpośrednio magicznym współczynnikiem rankingowym.

Google nie działa według zasady:

strona A ma 95 punktów, strona B ma 80 punktów, więc strona A automatycznie będzie wyżej.

Core Web Vitals są jednym z elementów wykorzystywanych przez systemy rankingowe Google, ale Google jednocześnie podkreśla, że nie istnieje pojedynczy „page experience signal”, który sam decydowałby o pozycji strony.

Znacznie większe znaczenie może mieć:

• jakość treści,
• dopasowanie treści do zapytania,
• autorytet domeny,
• linkowanie,
• struktura serwisu,
• indeksowanie,
• intencja użytkownika,
• jakość i unikalność oferty.

Szybkość jest jednym z elementów całej układanki.

Dlatego usuwanie połowy funkcjonalności strony wyłącznie po to, aby zmienić wynik z 94 na 100, często nie ma żadnego biznesowego uzasadnienia.

Czy warto mieć 100/100 w Google PageSpeed Insights?

Jeżeli można osiągnąć taki wynik bez kompromisów – oczywiście.

Nie powinien być to jednak główny cel projektu.

Znacznie rozsądniejszym celem jest:

• bardzo szybkie pierwsze wyświetlenie strony,
• dobre Core Web Vitals,
• szybka reakcja interfejsu,
• brak przesuwania layoutu,
• sprawne działanie na telefonie,
• odpowiednio szybki hosting,
• brak niepotrzebnych skryptów.

W praktyce wynik mobilny w granicach 90+ jest już według Google wynikiem dobrym.

Nawet 70–89 nie oznacza automatycznie, że strona jest fatalna.

Trzeba sprawdzić, dlaczego wynik wynosi 75.

Jeżeli największym problemem jest na przykład skrypt Google Maps albo system rezerwacji wymagany przez firmę, wyłączenie go tylko po to, aby PageSpeed pokazał zielony kolor, nie zawsze ma sens.

Dlaczego PageSpeed pokazuje raz 55, a chwilę później 68?

To pytanie pojawia się bardzo często.

Test Lighthouse nie jest całkowicie identyczny przy każdym uruchomieniu.

Wynik może się zmieniać nawet wtedy, kiedy administrator strony nie wykonał żadnej zmiany.

Wpływ mogą mieć między innymi:

• warunki sieciowe,
• obciążenie infrastruktury,
• odpowiedź serwera,
• zewnętrzne API,
• fonty,
• skrypty reklamowe,
• systemy analityczne,
• cache,
• zasoby ładowane z zewnętrznych domen.

Google samo informuje, że wyniki kolejnych testów mogą się różnić.

Dlatego nie należy analizować strony na podstawie jednego pomiaru.

Dobrym rozwiązaniem jest wykonanie kilku testów i szukanie powtarzających się problemów.

Co najbardziej spowalnia WordPressa?

WordPress sam w sobie nie musi być wolny.

Problemy zazwyczaj zaczynają się wtedy, gdy na stronie pojawia się:

• ciężki motyw,
• kilkadziesiąt wtyczek,
• page builder,
• kilka bibliotek JavaScript,
• ogromne zdjęcia,
• fonty z kilku źródeł,
• skrypty analityczne,
• Facebook Pixel,
• Google Ads,
• Google Maps,
• reCAPTCHA,
• popupy,
• widgety czatu,
• zewnętrzne systemy opinii,
• tracking marketingowy.

Każdy kolejny element może oznaczać dodatkowe zapytania HTTP, kolejne pliki JS i CSS oraz pracę wykonywaną przez przeglądarkę.

Dlatego optymalizacja WordPressa powinna być wykonywana całościowo, a nie przez instalację jednej wtyczki „Speed Booster”.

Cache WordPress – jedna z najważniejszych optymalizacji

Jedną z podstaw szybkiej strony WordPress jest cache.

WordPress jest systemem dynamicznym.

Bez cache przy wejściu użytkownika serwer może wykonać szereg operacji:

1. uruchomić PHP,
2. odczytać konfigurację WordPressa,
3. uruchomić motyw,
4. załadować wtyczki,
5. wykonać zapytania do MySQL,
6. wygenerować HTML,
7. przesłać wynik do przeglądarki.

Jeżeli mamy tysiąc wejść, wiele z tych operacji wykonywanych jest ponownie.

Cache pozwala część pracy wykonać wcześniej.

Page cache

Najważniejszy dla klasycznego WordPressa.

Gotowy HTML strony jest zapisywany w cache i kolejny użytkownik może otrzymać go bez ponownego wykonywania wszystkich operacji WordPressa.

Efekt może być ogromny.

Browser cache

Przeglądarka użytkownika może lokalnie przechowywać:

• CSS,
• JavaScript,
• zdjęcia,
• fonty,
• ikony.

Przy wejściu na kolejną podstronę nie trzeba pobierać wszystkiego jeszcze raz.

Object cache

W bardziej rozbudowanych systemach można wykorzystać między innymi Redis lub Memcached.

Pozwala to ograniczyć wielokrotne wykonywanie podobnych zapytań do bazy danych.

Szczególnie duże znaczenie może mieć w WooCommerce i większych portalach.

CDN

Content Delivery Network przechowuje statyczne zasoby na serwerach znajdujących się w różnych lokalizacjach.

Użytkownik może dzięki temu otrzymywać pliki z infrastruktury położonej bliżej niego.

Popularnym przykładem jest Cloudflare.

Minifikacja CSS i JavaScript – czy nadal warto?

Tak, ale nie należy traktować jej jako cudownego rozwiązania wszystkich problemów.

Minifikacja usuwa z kodu elementy niepotrzebne przeglądarce:

• spacje,
• komentarze,
• łamanie linii,
• część dodatkowego formatowania.

Przykładowy CSS:

.header {
    display: flex;
    justify-content: center;
}

po minifikacji może wyglądać tak:

.header{display:flex;justify-content:center}

Plik staje się mniejszy.

Przy dużych arkuszach CSS i bibliotekach JavaScript różnica może być zauważalna.

Jednocześnie współczesne serwery wykorzystują kompresję Brotli lub GZIP, a HTTP/2 i HTTP/3 znacznie zmieniły sposób przesyłania wielu plików.

Dlatego dziś większym problemem niż sama liczba kilobajtów kodu często jest:

ile JavaScriptu przeglądarka musi rzeczywiście wykonać.

Łączenie CSS i JS – nie zawsze daje lepszy wynik

Jeszcze kilka lat temu popularną praktyką było połączenie:

10 plików CSS → 1 plik CSS

20 plików JavaScript → 1 plik JavaScript.

Przy HTTP/1.1 często miało to duży sens.

Przy HTTP/2 i HTTP/3 sytuacja wygląda inaczej, ponieważ wiele zasobów może być pobieranych równolegle.

Ogromny połączony plik JS może być wręcz problemem.

Przykładowo użytkownik wchodzi na prostą podstronę „Kontakt”, ale musi pobrać kod slidera, galerii, WooCommerce, animacji i karuzeli wykorzystywanych wyłącznie na stronie głównej.

Znacznie lepszym rozwiązaniem może być:

ładowanie zasobów tylko tam, gdzie są potrzebne.

Usuń nieużywany CSS

Popularne motywy WordPress i page buildery potrafią generować ogromne arkusze CSS.

Problem polega na tym, że dana podstrona może wykorzystywać jedynie niewielką część tych stylów.

Przykładowo motyw posiada CSS dla:

• sklepu,
• portfolio,
• slidera,
• galerii,
• mega menu,
• tabeli cenowej,
• formularzy,
• animacji,
• popupów.

A podstrona zawiera tylko tekst, zdjęcie i formularz kontaktowy.

Mimo tego przeglądarka może otrzymać cały arkusz.

PageSpeed Insights często pokazuje wtedy komunikat:

Reduce unused CSS

czyli ogranicz nieużywany CSS.

JavaScript – częsty zabójca wydajności mobilnej

W praktyce podczas optymalizacji nowoczesnych stron to właśnie JavaScript bardzo często stanowi większy problem niż HTML czy CSS.

Telefon musi:

• pobrać plik,
• przetworzyć go,
• skompilować,
• wykonać kod,
• obsłużyć eventy,
• zaktualizować DOM.

Na komputerze z szybkim procesorem 500 KB JavaScriptu może być niezauważalne.

Na kilkuletnim telefonie sytuacja może wyglądać zupełnie inaczej.

Dlatego warto sprawdzić, czy naprawdę potrzebujemy wszystkich:

• sliderów,
• animacji,
• popupów,
• trackerów,
• widgetów,
• integracji.

Defer i async dla JavaScriptu

Nie każdy JavaScript musi zostać wykonany przed wyświetleniem strony.

W takich sytuacjach możemy wykorzystać między innymi defer oraz async.

Dzięki temu przeglądarka może szybciej rozpocząć wyświetlanie właściwej zawartości.

W WordPressie funkcję tę oferuje wiele narzędzi optymalizacyjnych, ale trzeba zachować ostrożność.

Automatyczne opóźnienie wszystkich skryptów może spowodować:

• niedziałające menu,
• problemy z formularzem,
• błędy slidera,
• problemy z checkoutem WooCommerce,
• niewczytujące się animacje.

Dlatego po każdej większej zmianie cache lub JavaScriptu należy przetestować stronę ręcznie.

Obrazy – bardzo często największy zasób strony

Nadal spotykamy strony, gdzie jedno zdjęcie hero waży:

3–5 MB.

To zdecydowanie za dużo.

Dla użytkownika znaczenie ma przede wszystkim to, ile danych musi pobrać przed zobaczeniem pierwszego ekranu.

Warto wykorzystywać nowoczesne formaty:

• WebP,
• AVIF.

Należy również odpowiednio skalować zdjęcia.

Jeżeli obraz jest wyświetlany w rozmiarze 600 × 400 px, nie ma sensu wysyłać do telefonu zdjęcia 5000 × 3500 px.

Lazy loading

Lazy loading powoduje, że część obrazów zostaje pobrana dopiero wtedy, kiedy użytkownik zbliża się do nich podczas przewijania.

To bardzo dobra metoda optymalizacji długich stron.

Istnieje jednak jeden ważny wyjątek:

głównego zdjęcia znajdującego się od razu na pierwszym ekranie nie powinniśmy bezmyślnie opóźniać.

Jeżeli obraz jest elementem LCP, zbyt agresywny lazy loading może pogorszyć wynik zamiast go poprawić.

Hosting i TTFB

Możemy zoptymalizować CSS, zmniejszyć obrazy i usunąć JavaScript, ale jeżeli serwer potrzebuje dwóch sekund, żeby rozpocząć odpowiedź, strona nadal będzie sprawiała wrażenie wolnej.

Dlatego bardzo ważny jest TTFB – Time to First Byte.

Na TTFB wpływa między innymi:

• wydajność hostingu,
• konfiguracja PHP,
• wersja PHP,
• baza danych,
• liczba zapytań,
• cache,
• obciążenie serwera,
• lokalizacja serwera.

Według progów wykorzystywanych obecnie przez PageSpeed Insights wynik TTFB do około 800 ms jest uznawany za dobry.

W dobrze skonfigurowanej stronie WordPress można jednak często osiągnąć wartości znacznie niższe.

Fonty również mogą spowalniać stronę

Popularnym problemem są fonty Google Fonts.

Strona może używać przykładowo:

• Roboto 300,
• Roboto 400,
• Roboto 500,
• Roboto 700,
• Poppins 300,
• Poppins 400,
• Poppins 600,
• Poppins 700.

Do tego dochodzą kursywy.

Nagle mamy kilkanaście plików fontów.

Warto zastanowić się, czy wszystkie odmiany rzeczywiście są potrzebne.

Dobrym rozwiązaniem może być także lokalne przechowywanie fontów na własnym serwerze.

Google Maps, reCAPTCHA i skrypty firm trzecich

Bardzo często klient pyta:

„Dlaczego strona ma słabszy wynik, skoro obrazki są małe i hosting jest szybki?”

Powodem mogą być skrypty zewnętrzne.

Przykładowo:

• Google Maps,
• YouTube,
• Facebook Pixel,
• Google Analytics,
• Google Ads,
• reCAPTCHA,
• systemy czatu,
• systemy opinii,
• narzędzia heatmap,
• bannery cookie.

Administrator strony ma ograniczony wpływ na ich kod.

Dlatego warto ładować je tylko tam, gdzie są potrzebne.

Przykład:

Jeżeli reCAPTCHA jest wykorzystywana tylko na podstronie Kontakt, nie zawsze istnieje sens ładowania jej JavaScriptu na wszystkich 500 podstronach serwisu.

To samo dotyczy sliderów czy bibliotek WooCommerce.

Czy każda wtyczka WordPress spowalnia stronę?

Nie.

To bardzo popularny mit.

Możemy posiadać 30 dobrze napisanych, lekkich wtyczek i stronę działającą szybko.

Możemy również posiadać jedną źle przygotowaną wtyczkę, która:

• wykonuje setki zapytań SQL,
• ładuje ogromny JavaScript,
• korzysta z zewnętrznego API,
• uruchamia się na każdej podstronie.

I ta jedna wtyczka może być większym problemem niż pozostałe 30 razem.

Nie liczy się wyłącznie liczba wtyczek, ale ich jakość i sposób działania.

Jak szybko powinna ładować się dobra strona?

Nie istnieje jedna magiczna wartość opisująca cały proces ładowania strony.

Znacznie lepiej analizować poszczególne etapy.

W praktyce użytkownik powinien bardzo szybko zobaczyć pierwszą treść, a najważniejsza zawartość pierwszego ekranu powinna pojawić się w okolicy 1–2,5 sekundy.

Google uznaje LCP do 2,5 sekundy za dobry wynik.

Warto przy tym pamiętać o zachowaniu użytkownika.

Starsze badania Google dotyczące ruchu mobilnego wykazały, że prawdopodobieństwo opuszczenia witryny gwałtownie rośnie wraz z wydłużaniem czasu ładowania, a przekroczenie około 3 sekund było związane ze znacznym wzrostem liczby użytkowników rezygnujących z wizyty.

Dlatego z biznesowego punktu widzenia każda sekunda ma znaczenie.

Nie chodzi wyłącznie o Google.

Chodzi o klienta, który może po prostu nacisnąć „Wstecz” i wejść do konkurencji.

Mobile jest ważniejszy niż desktop

Częsty scenariusz:

Desktop:

96/100

Mobile:

57/100

Dlaczego różnica jest tak duża?

Test mobilny zakłada znacznie słabsze warunki sprzętowe i sieciowe.

I właśnie dlatego jest tak wartościowy.

Nowoczesny komputer z szybkim światłowodem potrafi zamaskować wiele błędów optymalizacji.

Telefon robi to znacznie gorzej.

Jeżeli strona ma:

• 2 MB JavaScriptu,
• ogromne zdjęcie,
• ciężki slider,
• kilka trackerów,

na komputerze możemy tego praktycznie nie zauważyć.

Na telefonie użytkownika będzie to znacznie bardziej odczuwalne.

Jakie wtyczki cache do WordPressa warto rozważyć?

Do popularnych rozwiązań należą między innymi:

• LiteSpeed Cache,
• WP Rocket,
• WP-Optimize,
• WP Super Cache,
• WP Fastest Cache,
• Autoptimize.

Nie oznacza to jednak, że należy zainstalować wszystkie jednocześnie.

Wręcz przeciwnie.

Kilka wtyczek próbujących jednocześnie:

• minifikować CSS,
• opóźniać JavaScript,
• tworzyć cache,
• optymalizować bazę,

może powodować konflikty.

Najlepiej wybrać jedno główne rozwiązanie i poprawnie je skonfigurować.

Czy PageSpeed da się „oszukać”?

Technicznie możemy stworzyć stronę osiągającą prawie idealny wynik poprzez usunięcie:

• animacji,
• video,
• sliderów,
• analityki,
• reklam,
• map,
• fontów,
• integracji.

Możemy zrobić biały ekran z tekstem i wynikiem 100/100.

Tylko co z tego?

Strona internetowa jest narzędziem biznesowym.

Ma:

• sprzedawać,
• pozyskiwać leady,
• prezentować markę,
• odpowiadać na pytania użytkowników,
• prowadzić do kontaktu.

Dlatego optymalizacja powinna szukać kompromisu pomiędzy:

wydajnością, UX, wyglądem i funkcjonalnością.

Jak wygląda dobra optymalizacja WordPressa?

W praktyce proces można podzielić na kilka etapów.

1. Pomiar przed optymalizacją

Sprawdzamy:

• PageSpeed Insights,
• Core Web Vitals,
• TTFB,
• rozmiar strony,
• liczbę zapytań,
• waterfall,
• JavaScript,
• CSS,
• obrazy.

2. Hosting i backend

Sprawdzamy:

• PHP,
• bazę danych,
• cache,
• Redis,
• konfigurację serwera,
• cron WordPressa.

3. Frontend

Analizujemy:

• CSS,
• JavaScript,
• obrazy,
• fonty,
• DOM,
• zasoby blokujące renderowanie.

4. Skrypty zewnętrzne

Sprawdzamy:

• Analytics,
• Ads,
• Facebook,
• reCAPTCHA,
• mapy,
• chaty,
• widgety.

5. Test funkcjonalności

Po optymalizacji należy sprawdzić:

• formularze,
• menu,
• koszyk,
• checkout,
• filtry,
• płatności,
• popupy,
• wersję mobilną.

6. Ponowny pomiar

Dopiero wtedy możemy porównać wyniki.

Czy warto optymalizować stronę z 85 do 95 punktów?

Najczęściej tak, jeżeli możemy osiągnąć poprawę relatywnie niewielkim nakładem pracy.

Jeżeli wystarczy:

• zmniejszyć obrazy,
• usunąć zbędny JS,
• poprawić cache,
• lokalnie załadować fonty,

jest to zdecydowanie warte wykonania.

Jeżeli natomiast zdobycie kolejnych 3 punktów wymaga przebudowania połowy strony i usunięcia istotnych funkcji biznesowych, trzeba zastanowić się nad opłacalnością.

Optymalizacja powinna przynosić realny efekt, a nie wyłącznie ładniejszy screenshot z PageSpeed Insights.

Co jest ważniejsze od wyniku PageSpeed?

Najważniejsze jest realne doświadczenie użytkownika.

Warto więc zadać sobie kilka prostych pytań:

• Czy strona pojawia się szybko po kliknięciu?
• Czy użytkownik od razu widzi treść?
• Czy menu działa natychmiast?
• Czy podczas ładowania elementy nie skaczą?
• Czy formularze działają szybko?
• Czy sklep nie zacina się podczas wyboru produktów?
• Czy strona działa dobrze na przeciętnym telefonie?
• Czy użytkownik może łatwo znaleźć informacje?

Jeżeli odpowiedź brzmi „tak”, jesteśmy znacznie bliżej celu niż strona zoptymalizowana wyłącznie pod laboratoryjne 100 punktów.

FAQ – Google PageSpeed Insights

Czy wynik 100/100 jest możliwy?

Tak. Szczególnie w przypadku prostych stron wynik 100/100 jest jak najbardziej możliwy. Nie powinien jednak być głównym celem optymalizacji.

Jaki wynik PageSpeed jest dobry?

Google klasyfikuje wynik 90–100 jako dobry, 50–89 jako wymagający poprawy, natomiast poniżej 50 jako słaby.

Czy PageSpeed wpływa na pozycjonowanie?

Core Web Vitals są wykorzystywane przez systemy rankingowe Google, ale szybkość jest tylko jednym z wielu elementów SEO. Doskonały PageSpeed nie zastąpi dobrej treści i właściwego dopasowania strony do zapytania.

Czy cache przyspiesza WordPressa?

Tak. Odpowiednio skonfigurowany page cache może znacząco zmniejszyć czas generowania strony przez PHP i bazę danych.

Czy minifikacja CSS i JS nadal ma sens?

Tak, ale jej znaczenie jest mniejsze niż kiedyś. Często większy efekt daje usunięcie niepotrzebnego JavaScriptu i ładowanie skryptów tylko tam, gdzie są rzeczywiście wykorzystywane.

Czy dużo wtyczek zawsze oznacza wolnego WordPressa?

Nie. Znacznie ważniejsza jest jakość wtyczek i sposób, w jaki wykorzystują bazę danych, CSS i JavaScript.

Czy WooCommerce może mieć dobry PageSpeed?

Tak, ale optymalizacja WooCommerce jest trudniejsza niż prostej strony firmowej. Nie wszystkie podstrony można agresywnie cache’ować, a sklep wykorzystuje dodatkowe skrypty, AJAX, koszyk i integracje.

Dlaczego wynik mobilny jest niższy od desktopowego?

Test mobilny przeprowadzany jest w trudniejszych warunkach i symuluje słabsze urządzenie. Dlatego znacznie szybciej ujawnia ciężki JavaScript, duże zdjęcia i problemy z renderowaniem.

Podsumowanie – PageSpeed jest narzędziem, a nie celem

Google PageSpeed Insights jest bardzo wartościowym narzędziem pozwalającym znaleźć problemy techniczne strony.

Nie należy jednak traktować wyniku 100/100 jak celu nadrzędnego.

Dobrze zoptymalizowana strona powinna przede wszystkim:

• szybko wyświetlać najważniejszą zawartość,
• posiadać dobre Core Web Vitals,
• być stabilna wizualnie,
• szybko reagować na działania użytkownika,
• wykorzystywać cache,
• posiadać zoptymalizowane obrazy,
• ograniczać niepotrzebny CSS i JavaScript,
• działać sprawnie na urządzeniach mobilnych.

Lepiej posiadać funkcjonalną, dobrze sprzedającą stronę z wynikiem 90/100 niż laboratoryjne 100/100 osiągnięte kosztem UX, analityki i funkcjonalności.

PageSpeed powinien wskazywać kierunek optymalizacji.

Nie powinien być wyrocznią.