Większość wdrożeń wydajnościowych, które przejmujemy po kimś, wygląda tak samo. Ktoś zainstalował kolejną wtyczkę cache, przeklikał presety, a po dwóch dniach zaczął cofać zmiany, bo posypał się koszyk albo menu. Nikt nie zapisał punktu wyjścia, więc nie da się powiedzieć, co pomogło, a co zaszkodziło. Robimy w WordPressie od lat i ten sam scenariusz wraca niezależnie od skali projektu. Kolejność działań waży tu więcej niż wybór narzędzia, dlatego optymalizacja szybkości strony zaczyna się od planu, a nie od instalacji.
Spis treści
Najpierw pomiar, potem jakakolwiek wtyczka
Zanim ruszysz konfigurację, zrób kopię motywu potomnego i bazy. Część poprawek trzeba będzie wycofać, a bez punktu odniesienia wycofywanie zamienia się w zgadywanie. Kilka minut roboty, które później ratują cały tydzień.
Pomiar mobilny i desktopowy siedzą w osobnych wpisach cache. Zwykłe odpytanie adresu rozgrzewa wyłącznie wariant desktopowy, więc test mobilny trafia na zimny cache i pokazuje wynik zaniżony. Pierwszy przebieg po pełnym czyszczeniu zawsze wypada gorzej, bo łączone pliki CSS i JavaScript dopiero się generują.
Ta sama konfiguracja daje różne liczby między przebiegami, dlatego patrzę na medianę z kilku pomiarów, nie na pojedynczy odczyt. Do iteracji wygodniejsze jest narzędzie lokalne: działa szybko i nie limituje zapytań. Werdykt wystawia narzędzie Google, natomiast sam wskaźnik z panelu hostingu nie mówi nic o tym, co właściwie naprawiać.
Jak czytać raport, żeby trafić w wąskie gardło zamiast zgadywać
Raport otwieramy zawsze w tej samej kolejności, bo dopiero ona układa się w diagnozę:
- surowe metryki, zanim spojrzysz na listę sugestii
- węzeł LCP i to, czym on w ogóle jest
- harmonogram żądań sieciowych
- rozbicie pracy głównego wątku
- przyczyny przesunięć layoutu
Suma czasu odpowiedzi serwera, opóźnienia wykrycia obrazu i czasu jego pobrania od razu pokazuje, czy winny jest hosting, szablon czy grafika. Jeśli to czas odpowiedzi serwera ciągnie wynik w dół, żadna wtyczka tego nie nadrobi i rozmowa schodzi na wydajny hosting stron firmowych. Trzy odrębne rozmowy i trzy odrębne kosztorysy.
Gdy główny wątek zajmuje się głównie stylami i przeliczaniem layoutu, a nie wykonywaniem skryptów, wycinanie JavaScriptu nic nie da. Szukaj wtedy rozmiaru arkusza i liczby elementów w drzewie. Wpis o długim zadaniu wskazujący na sam dokument oznacza skrypty inline i handlery wklejone w szablonie, nie plik biblioteki. No i najczęstszy błąd: prace zaczynają się od tego, co najłatwiej kliknąć, zamiast od największego kosztu w raporcie.
LCP: najczęściej winna jest widoczność elementu, nie waga obrazu
Najdroższy pojedynczy problem to element LCP schowany do czasu inicjalizacji JavaScriptu. Karuzela, slider albo sekcja budowana przez skrypt czekają na cały łańcuch zależności. Kompresja pliku niczego wtedy nie ratuje, skoro przeglądarka dowiaduje się o obrazie dopiero po wykonaniu kodu.
Wskazówka preloadu działa tylko wtedy, gdy stoi na samej górze sekcji head, przed danymi strukturalnymi i skryptami analitycznymi. Niżej gubi sens, bo parser dociera do niej za późno. Sprawdź też, czy baner na telefonie nie jest serwowany w pełnym rozmiarze desktopowym zamiast wariantu generowanego przez WordPressa. W szablonach premium to błąd niemal seryjny.
Obrazy tła malowane przez skrypt hurtem, razem z tymi spod ekranu, konkurują o pasmo z obrazem LCP i potrafią zjeść cały zysk z optymalizacji grafiki. Przy karuzelach czai się jeszcze jedna pułapka: odsłonięcie pierwszego slajdu bez ukrycia pozostałych naprawia LCP, ale generuje przesunięcia layoutu. Jedna metryka rośnie kosztem drugiej.
CLS i fonty: kompromis, którego nie załatwia jedna reguła w CSS
Reguły zabezpieczające layout wpisane w arkusz motywu nie zadziałają, jeśli ten arkusz ładuje się asynchronicznie. Muszą trafić inline do sekcji head i zostać wykluczone z optymalizacji, inaczej docierają po pierwszym malowaniu.
Ten sam mechanizm dotyczy krojów pisma. Deklaracje fontu w łączonym, asynchronicznym arkuszu przychodzą za późno, więc podmiana kroju przesuwa nagłówki. Wstrzyknięcie deklaracji inline usuwa problem kolejności, ale wstrzymuje wyświetlenie tekstu i pogarsza FCP. Preload wag poprawia stabilność, tyle że te kilkanaście kilobajtów jedzie z wysokim priorytetem obok obrazu LCP i psuje wynik po drugiej stronie. Wybieraj.
Bez fallbacku z dopasowanymi metrykami wybierasz między FCP a CLS, a wariant z font-display: optional jest decyzją właściciela marki, nie techniczną. Pamiętaj też, że automatycznie generowany krytyczny CSS nie zawiera stylów dokładanych przez JavaScript, więc rezerwację wysokości sliderów wypisuje się ręcznie.
TBT rośnie po dobrej zmianie i nie jest to regres
Praca JavaScriptu jest w zasadzie stała. Dopóki strona ładowała się wolno, wykonywała się poza oknem pomiaru. Po przyspieszeniu wchodzi do środka i zaczyna być liczona. Skok TBT tuż po skróceniu FCP to sygnał, że zmiana zadziałała, a nie powód do jej cofania.
Opóźnianie skryptów do pierwszej interakcji bywa kuszące. Ale zastosowane do jQuery, menu i slidera kończy się niedziałającą nawigacją. To obejście, nie diagnoza, i tak trzeba je klientowi nazwać. Łączenie i opóźnianie są przy tym sprzężone: plik wykluczony tylko z jednej listy i tak wyląduje we wspólnej, opóźnianej paczce.
Wykluczaj konkretne pliki zamiast całych katalogów. Wykluczenie katalogu wyciąga na ścieżkę krytyczną również ciężkie biblioteki, które miały tam spokojnie zostać. Sprawdź przy okazji, czy wzorzec pasuje do rzeczywistej nazwy, skoro zminifikowany wariant biblioteki nazywa się inaczej niż źródłowy.
Utrzymanie: co się psuje trzy miesiące po wdrożeniu
Wszystkie zmiany idą do motywu potomnego, a podmiany plików robimy filtrami na uchwytach. Inaczej pierwsza aktualizacja szablonu kasuje robotę bez śladu. Podmienione minifikaty i subsety fontów trzeba przegenerować po każdej aktualizacji i wersjonować w adresie, bo długi cache przeglądarki potrafi trzymać stary plik miesiącami.
Kolejka generowania krytycznego CSS jest ograniczona i przy wielojęzyczności zapycha się tłumaczeniami oraz adresami technicznymi. Efekt? Część podstron nigdy go nie dostaje. Czyszczenie cache nie kasuje przy tym ani krytycznego CSS, ani wariantu mobilnego. To osobne mechanizmy i sprawdza się je osobno.
Po każdej zmianie w kodzie weryfikujemy logowanie, mapę witryny, kanał RSS, stronę błędu 404 i wersje językowe. Dziennik zmian z listą ślepych uliczek oszczędza kolejnemu wykonawcy powtarzania testów, które już raz zostały wycofane. Bez tej dyscypliny wynik Core Web Vitals WordPress cofa się sam, po aktualizacjach wtyczek i zwykłych zmianach treści.
Podsumowanie: rozsądna kolejność zamiast listy wtyczek
Zmierz, przeczytaj raport w ustalonej kolejności, napraw LCP, potem stabilność layoutu, a dopiero na końcu obciążenie głównego wątku. Tak wygląda u nas optymalizacja szybkości strony w praktyce, a ta sekwencja wynika z zależności między metrykami, nie z upodobań.
Rozdzielaj to, co zmierzone, od tego, co ocenione, i mów wprost, kiedy poprawka jest obejściem. Wynik pomiaru mobilnego ma spory rozrzut, więc raportuj zakres z kilku przebiegów zamiast jednej efektownej liczby. Klient, który rozumie ten rozrzut, nie dzwoni o siódmej rano z pytaniem o dwa punkty w dół.
Jeśli potrzebujecie audytu wydajności, modernizacji istniejącego systemu, integracji, automatyzacji albo wdrożenia MVP, zapraszamy do kontaktu. Warto połączyć to z audytem SEO serwisu, bo szybkość i widoczność w wyszukiwarce ciągną się nawzajem. Chętnie przejrzymy waszą konfigurację i powiemy, co realnie warto poprawić.
