Dawno już strony internetowej przestała być wyłącznie technicznym detalem, którym zajmują się administratorzy serwerów i programiści. Dziś bezpośrednio wpływa nie tylko na komfort użytkownika, skuteczność sprzedaży, wykorzystanie budżetu reklamowego, ale też na widoczność strony w Google i innych wyszukiwarkach.

Problem w tym, że optymalizacja WordPressa często sprowadzana jest do prostego schematu: zainstalować plugin cache, uruchomić Google PageSpeed Insights i próbować za wszelką cenę uzyskać wynik 100/100.

W praktyce dobra optymalizacja wygląda inaczej.

Trzeba najpierw ustalić, co faktycznie spowalnia stronę, a dopiero później poprawiać konkretne elementy: serwer, backend WordPressa, CSS, JavaScript, obrazy, fonty, zewnętrzne skrypty czy strukturę DOM.

Czym właściwie jest szybkość strony?

Nie istnieje jedna wartość określająca, że strona „ładuje się w 2 sekundy”.

Ładowanie strony jest procesem. Przeglądarka najpierw łączy się z serwerem, pobiera HTML, analizuje dokument, pobiera kolejne zasoby, buduje DOM i CSSOM, wykonuje JavaScript, renderuje elementy i dopiero później pozwala użytkownikowi swobodnie korzystać z interfejsu.

Dlatego dwie strony mogą pozornie ładować się przez podobny czas, a mimo to jedna będzie odbierana jako znacznie szybsza.

Jeżeli użytkownik natychmiast zobaczy nagłówek, zdjęcie produktu i przycisk „Kup”, strona może sprawiać wrażenie szybkiej nawet wtedy, gdy mniej istotne elementy nadal są pobierane w tle.

Jeśli natomiast przez pierwsze dwie sekundy widoczny jest tylko biały ekran, doświadczenie będzie zdecydowanie gorsze.

To właśnie dlatego Google nie ogranicza pomiaru wydajności do jednego czasu ładowania.

PageSpeed Insights to nie tylko wynik od 0 do 100

Google PageSpeed Insights analizuje stronę przy użyciu Lighthouse i prezentuje zarówno dane laboratoryjne, jak i informacje dotyczące rzeczywistych doświadczeń użytkowników, jeśli odpowiednia ilość takich danych jest dostępna.

Najbardziej widoczny jest wynik Performance:

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

Nie należy jednak traktować tych wartości jak oceny szkolnej.

Strona z wynikiem 92 nie musi być biznesowo lepsza od strony z wynikiem 86. Co więcej, wynik testu Lighthouse może zmieniać się pomiędzy kolejnymi pomiarami.

Znacznie ważniejsze jest zrozumienie, co powoduje słaby wynik oraz jak strona zachowuje się u prawdziwych użytkowników.

Core Web Vitals – ważniejsze niż pogoń za 100 punktami

Obecnie Google skupia się przede wszystkim na trzech podstawowych wskaźnikach Core Web Vitals:

LCP – Largest Contentful Paint

Mierzy moment wyświetlenia największego istotnego elementu znajdującego się w początkowym obszarze strony. Najczęściej będzie to duże zdjęcie, baner albo fragment tekstu.

Dobry wynik to maksymalnie 2,5 sekundy.

INP – Interaction to Next Paint

Pokazuje, jak szybko strona reaguje na działania użytkownika, np. kliknięcie przycisku, wybór wariantu produktu czy rozwinięcie menu.

Dobry wynik to maksymalnie 200 ms.

CLS – Cumulative Layout Shift

Mierzy nieoczekiwane przesunięcia układu.

Jeżeli użytkownik chce kliknąć przycisk, ale w ostatniej chwili nad nim pojawia się reklama albo obraz i przycisk przesuwa się niżej, CLS będzie wysoki.

Dobry wynik to maksymalnie 0,1.

Google ocenia te wskaźniki na podstawie 75. percentyla wizyt, osobno dla urządzeń mobilnych i komputerów.

Czy szybkość strony wpływa na SEO?

Tak, ale warto właściwie rozumieć tę zależność.

Nie działa to według prostego schematu:

strona A ma PageSpeed 95, strona B ma 80, więc strona A automatycznie znajdzie się wyżej w Google.

Google nadal przede wszystkim próbuje pokazać użytkownikowi najbardziej odpowiednią treść. Dobre doświadczenie użytkownika, w tym wydajność strony, jest jednym z elementów mogących pomagać w wynikach wyszukiwania, ale nie zastąpi jakości treści ani jej trafności.

Optymalizacja wydajności ma jednak jeszcze drugi, często ważniejszy efekt.

Szybsza strona oznacza mniej użytkowników rezygnujących przed jej załadowaniem, szybsze przejście do produktu lub formularza i mniejsze tarcie na ścieżce konwersji.

Dlatego optymalizację PageSpeed warto traktować przede wszystkim jako optymalizację doświadczenia użytkownika, a dopiero później jako techniczne SEO.

Jak poprawić szybkość WordPressa?

Nie istnieje jeden uniwersalny plugin rozwiązujący wszystkie problemy.

Wydajność WordPressa jest sumą wielu warstw:

1. infrastruktury serwerowej,
2. konfiguracji PHP i bazy danych,
3. WordPressa i używanych pluginów,
4. motywu,
5. HTML i DOM,
6. CSS,
7. JavaScript,
8. obrazów i fontów,
9. zewnętrznych usług,
10. cache i CDN.

Najlepsze efekty daje optymalizacja tych elementów w odpowiedniej kolejności.

1. Zacznij od TTFB i serwera

Jeżeli serwer potrzebuje dwóch sekund tylko na wygenerowanie HTML, optymalizacja obrazków nie rozwiąże podstawowego problemu.

TTFB, czyli Time to First Byte, określa czas od rozpoczęcia żądania do otrzymania pierwszych danych z serwera.

Na wynik wpływają między innymi:

• wydajność procesora,
• obciążenie serwera,
• wersja i konfiguracja PHP,
• wydajność MySQL/MariaDB,
• liczba wykonywanych zapytań,
• pluginy WordPressa,
• zewnętrzne API,
• cache,
• odległość użytkownika od serwera.

W polskich realiach nadal można spotkać WordPressy działające na tanim współdzielonym hostingu razem z setkami innych serwisów. Sam szybki internet użytkownika niewiele pomoże, jeżeli każde żądanie PHP czeka na zasoby przeciążonego serwera.

Dobrym rozwiązaniem może być odpowiednio skonfigurowany VPS, hosting zoptymalizowany pod WordPressa lub infrastruktura cloud.

Sama nazwa technologii nie gwarantuje jednak wydajności. Źle skonfigurowany VPS może działać znacznie wolniej niż dobre konto współdzielone.

2. Wykorzystuj page cache

WordPress generuje stronę dynamicznie.

Standardowe wejście użytkownika może oznaczać:

1. uruchomienie PHP,
2. załadowanie WordPressa,
3. uruchomienie pluginów,
4. wykonanie zapytań SQL,
5. wygenerowanie HTML,
6. wysłanie wyniku do przeglądarki.

Jeżeli wynik dla większości użytkowników jest identyczny, wykonywanie całej operacji przy każdym wejściu jest marnowaniem zasobów.

Page cache zapisuje gotowy HTML i przy kolejnych żądaniach może zwrócić go bez ponownego uruchamiania całej aplikacji.

W przypadku stron contentowych różnica potrafi być bardzo duża.

Inaczej wygląda sytuacja w systemach zawierających dane użytkownika, koszyk, checkout czy panel klienta. Tam cache musi być skonfigurowany ostrożniej.

3. Object cache pomaga backendowi WordPressa

Page cache i object cache rozwiązują dwa różne problemy.

Object cache, np. wykorzystujący Redis, pozwala zachować wyniki często powtarzanych operacji i zapytań.

Może mieć duże znaczenie w bardziej rozbudowanych instalacjach WordPressa i WooCommerce.

Nie oznacza jednak automatycznie, że samo zainstalowanie Redisa przyspieszy każdą stronę. Najpierw trzeba sprawdzić, gdzie rzeczywiście znajduje się bottleneck.

4. Ogranicz render-blocking CSS i JavaScript

Przeglądarka nie może od razu narysować strony, jeżeli wcześniej musi pobrać i przetworzyć zasoby blokujące renderowanie.

Typowy przykład to duży plik CSS lub synchroniczny JavaScript umieszczony w <head>.

W przypadku CSS warto:

• ograniczyć jego rozmiar,
• usunąć nieużywane reguły,
• wydzielić style krytyczne,
• odłożyć ładowanie CSS niepotrzebnego na początku strony.

Google wskazuje redukcję oraz odroczenie niekrytycznego CSS jako jedne ze sposobów zmniejszenia opóźnienia renderowania elementu LCP.

JavaScript można natomiast ładować za pomocą defer lub async, jeżeli logika aplikacji na to pozwala.

Nie należy jednak automatycznie dodawać defer do wszystkich skryptów. Pluginy często zależą od kolejności wykonywania kodu i agresywna automatyczna optymalizacja może uszkodzić stronę.

5. Usuń nieużywany CSS

Rozbudowany motyw może zawierać style:

• WooCommerce,
• formularzy,
• sliderów,
• galerii,
• popupów,
• tabel,
• elementów blogowych,
• widgetów,

nawet jeżeli konkretna podstrona nie wykorzystuje żadnego z nich.

Przeglądarka nadal musi pobrać i przetworzyć cały plik.

Chrome DevTools Coverage pozwala sprawdzić, jaka część CSS i JavaScript rzeczywiście jest wykorzystywana.

W większych projektach dobrym rozwiązaniem jest budowanie osobnych paczek zasobów dla różnych typów stron zamiast ładowania jednego ogromnego pliku wszędzie.

6. Nie przesadzaj z JavaScriptem

JavaScript jest jednym z najczęstszych powodów sytuacji, w której strona wygląda na załadowaną, ale nadal reaguje wolno.

Przeglądarka musi kod:

• pobrać,
• sparsować,
• skompilować,
• wykonać.

W tym czasie główny wątek może być zajęty.

Problem jest szczególnie widoczny na telefonach ze słabszym procesorem.

Duża aplikacja JavaScript może działać doskonale na komputerze programisty, a jednocześnie mieć bardzo słaby INP na kilkuletnim smartfonie użytkownika.

Dlatego warto:

• usuwać niepotrzebne biblioteki,
• dzielić kod na mniejsze fragmenty,
• ładować funkcjonalności dopiero wtedy, gdy są potrzebne,
• ograniczać długie zadania JavaScript,
• nie inicjalizować wszystkich komponentów przy pierwszym renderze.

7. Zwróć uwagę na pluginy WordPressa

Sama liczba pluginów nie jest najlepszą miarą wydajności.

30 dobrze napisanych małych pluginów może działać szybciej niż jeden ciężki page builder.

Problem pojawia się wtedy, gdy plugin:

• wykonuje kosztowne zapytania przy każdym wejściu,
• ładuje swój CSS na wszystkich stronach,
• ładuje wszędzie swój JavaScript niezależnie od tego, czy jest potrzebny,
• komunikuje się synchronicznie z zewnętrznym API,
• uruchamia dużo kodu podczas init,
• wykonuje zadania, które powinny działać asynchronicznie.

Dlatego przy poważniejszych problemach wydajnościowych należy profilować aplikację zamiast losowo wyłączać kolejne pluginy WordPressa. Jest to bardziej skomplikwoane technicznie, ale efekty również są dużo lepsze.

8. Minifikuj CSS i JavaScript, ale nie oczekuj cudów

Minifikacja usuwa z kodu elementy niepotrzebne przeglądarce:

• spacje,
• komentarze,
• formatowanie,
• niektóre długie nazwy.

Zmniejsza to rozmiar pliku.

Jest to dobra praktyka produkcyjna, ale obecnie różnica pomiędzy plikiem zminifikowanym i niezminifikowanym, przesyłanym dodatkowo z kompresją Brotli lub GZIP, często jest znacznie mniejsza niż kilka lat temu.

Znacznie większą poprawę może dać niewysyłanie niepotrzebnego kodu w ogóle.

9. Pilnuj liczby requestów i całkowitego transferu

Każdy dodatkowy zasób oznacza kolejną pracę dla przeglądarki.

Nie oznacza to, że trzeba bezwzględnie połączyć wszystkie pliki w jeden. Przy HTTP/2 i HTTP/3 taka strategia często nie ma już sensu.

Nadal jednak warto ograniczać zasoby, które niczego nie wnoszą.

Szczególnie:

• biblioteki JavaScript,
• fonty,
• trackery,
• widgety social media,
• iframes,
• filmy,
• duże obrazy,
• duplikujące się biblioteki.

Optymalizacja powinna polegać na zmniejszeniu ilości wykonywanej pracy, a nie wyłącznie liczby widocznej w raporcie.

10. Obrazy są jednym z największych źródeł oszczędności

Zdjęcie wyświetlane na stronie w rozmiarze 800 × 500 px nie powinno być pobierane jako plik 5000 × 3000 px.

To jeden z najprostszych błędów do wykrycia.

WordPress potrafi automatycznie generować różne rozmiary obrazów, a przeglądarka może wybierać odpowiednią wersję dzięki srcset i sizes.

Warto również stosować nowoczesne formaty:

• WebP,
• AVIF.

W wielu przypadkach pozwalają one znacząco zmniejszyć transfer przy zachowaniu dobrej jakości obrazu.

Nie należy jednak mechanicznie konwertować wszystkiego do jednego formatu. Efekt kompresji trzeba ocenić na rzeczywistych materiałach.

11. Nie używaj lazy loading do wszystkiego

Lazy loading jest bardzo przydatny dla obrazów znajdujących się daleko poniżej pierwszego ekranu.

Przykład:

<img
    src="photo.webp"
    loading="lazy"
    width="800"
    height="600"
    alt="Opis zdjęcia"
>

Dzisiejsze przeglądarki obsługują natywne loading="lazy", więc w wielu przypadkach dodatkowa biblioteka JavaScript nie jest już potrzebna.

Jest jednak jeden ważny wyjątek.

Nie należy lazy-loadować głównego obrazu znajdującego się nad linią załamania, szczególnie jeżeli jest elementem LCP.

Taki obraz powinien zacząć ładować się możliwie wcześnie. Google wprost zaleca, aby obrazy znajdujące się w początkowym viewportcie, szczególnie LCP, nie były ładowane leniwie.

12. Zadbaj o obraz odpowiedzialny za LCP

Jeżeli największym elementem strony jest główne zdjęcie produktu lub hero banner, jego pobranie powinno rozpocząć się jak najwcześniej.

Problem pojawia się, gdy obraz:

• jest ustawiony tylko jako background-image w CSS,
• jest dodawany dopiero przez JavaScript,
• posiada błędny lazy loading,
• jest odkrywany przez przeglądarkę zbyt późno.

W określonych sytuacjach można użyć między innymi:

fetchpriority="high"

lub preloadu zasobu.

Nie należy jednak preloadować kilkunastu grafik jednocześnie. Jeżeli wszystko otrzyma wysoki priorytet, priorytety praktycznie przestają spełniać swoją funkcję.

13. Ustaw rozmiary obrazów i innych elementów

Elementy powinny posiadać znane przeglądarce wymiary.

Dla obrazów mogą to być:

width="800"
height="600"

Dzięki temu przeglądarka może zarezerwować odpowiednią przestrzeń zanim sam plik zostanie pobrany.

Zmniejsza to ryzyko przesuwania układu, czyli pogorszenia CLS.

Podobny problem występuje w przypadku:

• reklam,
• iframe,
• embedów,
• dynamicznych banerów,
• elementów ładowanych przez JavaScript.

14. Optymalizuj fonty

Font internetowy również jest zasobem, który musi zostać pobrany.

Strona wykorzystująca:

• 4 rodziny fontów,
• 5 grubości każdego,
• italic,
• dodatkowe zestawy znaków,

może pobierać znacznie więcej danych niż jest to potrzebne.

Warto ograniczyć liczbę wariantów i korzystać z WOFF2.

Dobrą praktyką jest również:

font-display: swap;

Dzięki temu użytkownik może zobaczyć tekst przy użyciu fontu zastępczego, zanim docelowy font zostanie pobrany.

Dla najbardziej krytycznych fontów czasami uzasadniony jest preload.

15. Ogranicz zewnętrzne skrypty

Strona może być dobrze zoptymalizowana, a mimo to działać wolno przez kod pochodzący z innych serwisów.

Typowe przykłady:

• systemy reklamowe,
• analytics,
• chaty,
• heatmapy,
• widgety opinii,
• social media,
• systemy A/B testing,
• filmy YouTube,
• mapy.

Każdy taki element może pobierać własny JavaScript, ustawiać event listenery i wykonywać kod na głównym wątku.

Na polskich stronach firmowych i sklepach często problem narasta stopniowo: najpierw dodawane są statystyki, później Meta Pixel, Google Ads, chat, narzędzie marketing automation i kolejne widgety. Każdy z nich osobno wydaje się niewielki, ale razem mogą stać się jednym z głównych źródeł problemów z wydajnością.

Rozwiązaniem może być:

• usunięcie niepotrzebnych usług,
• opóźnione uruchamianie,
• ładowanie dopiero po interakcji,
• wykorzystanie lekkich placeholderów zamiast ciężkich iframe.

16. Włącz kompresję HTTP

HTML, CSS, JavaScript, JSON, XML i inne tekstowe formaty bardzo dobrze poddają się kompresji.

Serwer powinien więc przesyłać je z wykorzystaniem np.:

• Brotli,
• GZIP.

Zmniejsza to ilość danych przesyłanych pomiędzy serwerem a przeglądarką.

Nie należy natomiast ponownie kompresować formatów, które już posiadają własną skuteczną kompresję, np. większości obrazów czy filmów.

17. Ustaw odpowiedni browser cache

Pliki statyczne, które zmieniają się rzadko, nie powinny być ponownie pobierane podczas każdej wizyty.

Dotyczy to między innymi:

• CSS,
• JavaScript,
• obrazów,
• fontów.

Odpowiednie nagłówki:

Cache-Control
Expires
ETag

pozwalają przeglądarce ponownie wykorzystać wcześniej pobrane zasoby.

W przypadku plików wersjonowanych, np.:

app.a87c913.js

można stosować bardzo długi czas cache, ponieważ zmiana zawartości powoduje wygenerowanie nowej nazwy pliku.

18. Unikaj niepotrzebnych przekierowań

Każdy redirect oznacza dodatkowy request.

Przykładowo:

http://example.com
↓
https://example.com
↓
https://www.example.com
↓
https://www.example.com/pl/

oznacza kilka operacji zanim użytkownik dotrze do właściwego dokumentu.

W przypadku wejścia użytkownika raz nie musi to być katastrofa, ale podobne łańcuchy wewnątrz strony, CSS, JavaScript lub reklam mogą generować niepotrzebne opóźnienia.

Linkuj bezpośrednio do docelowych adresów.

19. Kontroluj wielkość DOM

Page buildery pozwalają szybko tworzyć skomplikowane layouty, ale często generują bardzo rozbudowany HTML.

Prosty wizualnie element może wyglądać w kodzie tak:

<div>
    <div>
        <div>
            <div>
                <div>
                    <span>Tekst</span>
                </div>
            </div>
        </div>
    </div>
</div>

Pomnożenie podobnej struktury przez setki komponentów niekiedy zwiększa DOM do ogromnych rozmiarów.

Duży DOM oznacza więcej pracy podczas:

• parsowania,
• obliczania stylów,
• layoutu,
• aktualizacji elementów przez JavaScript.

Dlatego optymalizacja frontendu czasami wymaga zmiany samego sposobu budowania komponentów, a nie instalowania kolejnego pluginu cache.

20. WooCommerce wymaga osobnego podejścia

Sklep internetowy jest bardziej wymagający niż typowa strona firmowa.

Mamy tutaj:

• koszyk,
• checkout,
• sesję użytkownika,
• warianty produktów,
• filtry,
• wyszukiwarkę,
• ceny,
• stany magazynowe,
• integracje kurierskie,
• system płatności.

Nie można więc po prostu cache’ować wszystkiego.

Warto osobno analizować:

• listing produktów,
• kartę produktu,
• wyszukiwanie,
• koszyk,
• checkout,
• panel klienta.

Często największym problemem nie jest sama karta produktu, lecz zapytania wykonywane przez filtry, rozbudowane warianty produktów albo pluginy działające podczas każdego requestu.

21. CDN nie naprawi wolnego WordPressa

CDN pozwala dostarczać zasoby z infrastruktury znajdującej się bliżej użytkownika.

Świetnie sprawdza się dla:

• obrazów,
• CSS,
• JavaScript,
• fontów,
• innych plików statycznych.

Nie należy jednak traktować CDN jako lekarstwa na wolny backend.

Jeżeli WordPress potrzebuje trzech sekund na wygenerowanie dokumentu HTML, CDN może częściowo zamaskować problem przez cache, ale nie usuwa jego przyczyny.

Najpierw trzeba ustalić, co rzeczywiście spowalnia aplikację.

22. Nie optymalizuj tylko strony głównej

To jeden z częstszych błędów podczas prac nad PageSpeed.

Firma optymalizuje homepage do wyniku 95, ale użytkownik trafiający z Google bezpośrednio na artykuł lub kartę produktu otrzymuje zupełnie inne doświadczenie.

Należy testować reprezentatywne typy podstron:

• stronę główną,
• landing page,
• artykuł,
• kategorię,
• produkt,
• formularz,
• koszyk,
• checkout.

Każdy template może mieć inne problemy.

23. Testuj przede wszystkim mobile

Wynik desktopowy bardzo często wygląda dobrze nawet na przeciętnie zoptymalizowanej stronie.

Urządzenia mobilne szybciej pokazują problemy:

• słabszy procesor,
• mniejsza pamięć,
• wolniejsze połączenie,
• większy koszt wykonania JavaScript.

Dlatego właśnie od wersji mobilnej powinno się zawsze rozpoczynać analizę PSI.

24. Dane laboratoryjne i dane użytkowników to dwie różne rzeczy

Pojedynczy test PageSpeed jest symulacją wykonaną w określonych warunkach.

Dane terenowe pokazują natomiast doświadczenia prawdziwych użytkowników.

To bardzo ważne rozróżnienie.

Możliwe jest uzyskanie słabego wyniku podczas pojedynczego testu laboratoryjnego i jednocześnie dobrych Core Web Vitals u użytkowników.

Możliwa jest również sytuacja odwrotna.

Dlatego do analizy większego serwisu warto połączyć:

• PageSpeed Insights,
• Chrome DevTools,
• Lighthouse,
• Search Console,
• dane CrUX,
• własny Real User Monitoring.

25. Nie próbuj za wszelką cenę osiągnąć 100/100

PageSpeed jest narzędziem diagnostycznym, a nie celem biznesowym.

Można poświęcić kilkadziesiąt godzin na zmianę wyniku z 96 na 100, nie dając użytkownikowi żadnej zauważalnej poprawy.

Jednocześnie poprawienie LCP z 5 sekund do 2 sekund może mieć bardzo duże znaczenie, nawet jeżeli końcowy wynik Lighthouse nadal nie będzie idealny.

Dlatego priorytety powinny wyglądać mniej więcej tak:

1. usuń poważne problemy z doświadczeniem użytkownika,
2. popraw Core Web Vitals,
3. usuń techniczne bottlenecki,
4. zoptymalizuj największe zasoby,
5. dopiero później zajmuj się kosmetyką wyniku.

Jak wygląda sensowny proces optymalizacji WordPressa?

Zamiast instalować kilka pluginów jednocześnie, warto przeprowadzić proces krok po kroku.

Krok 1. Pomiar

Sprawdź:

• PageSpeed mobile i desktop,
• Core Web Vitals,
• TTFB,
• waterfall requestów,
• wielkość transferu,
• ilość JavaScript,
• ilość CSS,
• LCP element.

Krok 2. Ustal największy problem

Czy ograniczeniem jest:

• backend,
• obraz LCP,
• CSS,
• JavaScript,
• zewnętrzne skrypty,
• fonty,
• struktura HTML?

Nie poprawiaj wszystkiego jednocześnie.

Krok 3. Zmień jeden obszar

Na przykład:

• skonfiguruj cache,
• zoptymalizuj hero image,
• usuń niepotrzebny JS,
• popraw TTFB.

Krok 4. Zmierz ponownie

Sprawdź, czy zmiana rzeczywiście dała efekt.

Krok 5. Kontroluj skutki uboczne

Optymalizacja musi obejmować również testy funkcjonalne.

Po zmianach trzeba sprawdzić między innymi:

• formularze,
• menu,
• popupy,
• koszyk,
• checkout,
• logowanie,
• płatności,
• tracking.

Wynik 100/100 nie ma żadnej wartości, jeżeli po optymalizacji przestaje działać checkout.

Podsumowanie

Optymalizacja WordPressa nie polega na znalezieniu jednego magicznego ustawienia w Google PageSpeed Insights.

Dobra wydajność powstaje z wielu elementów działających razem:

• szybkiego backendu,
• właściwego cache,
• rozsądnej ilości CSS i JavaScript,
• zoptymalizowanych obrazów,
• prawidłowego ładowania fontów,
• ograniczenia zewnętrznych skryptów,
• dobrej struktury HTML,
• odpowiedniej konfiguracji serwera.

PageSpeed Insights jest bardzo dobrym punktem startowym, ponieważ pomaga znaleźć potencjalne problemy. Nie powinien być jednak traktowany jak automat mówiący, co bezwarunkowo należy zmienić.

Najważniejszy pozostaje rzeczywisty użytkownik.

Jeżeli strona szybko pokazuje najważniejszą treść, reaguje natychmiast na interakcje, nie przesuwa elementów podczas ładowania i działa stabilnie również na urządzeniach mobilnych, optymalizacja spełnia swój cel.

A wysoki wynik PageSpeed strony jest wtedy konsekwencją dobrze zbudowanej, szybkiej strony, a nie celem samym w sobie.