Przyspieszanie stron internetowych jako usługa – jak zarabiać na optymalizacji Core Web Vitals, zdjęć i konfiguracji serwera

Klient wysyła zrzut z PageSpeed Insights: 38/100 na urządzeniach mobilnych. Pytanie zwykle brzmi: „Ile kosztuje doprowadzenie tego do zielonego wyniku?”. Problem w tym, że z samej liczby 38 nie da się jeszcze rozsądnie wycenić pracy.

Taki wynik może powodować jeden źle obsłużony obraz na pierwszym ekranie, kilkaset kilobajtów JavaScriptu z buildera, skrypty reklamowe, wolna odpowiedź PHP, brak pełnego cache strony albo kilka problemów naraz. Dwie witryny z identycznym wynikiem Lighthouse mogą wymagać zupełnie innego zakresu prac.

Dlatego przyspieszanie stron jest usługą, na której można zarabiać nie dzięki znajomości przycisku „minify”, lecz dzięki umiejętności znalezienia wąskiego gardła, bezpiecznego wdrożenia poprawki i udowodnienia efektu pomiarem. Klient może sam uruchomić PageSpeed Insights. Płaci za odpowiedź na trudniejsze pytanie: dlaczego strona jest wolna i co dokładnie trzeba z nią zrobić.

Audyt przed wyceną: najpierw ustal, co rzeczywiście spowalnia stronę

Aktualne Core Web Vitals obejmują trzy podstawowe wskaźniki:

• LCP – Largest Contentful Paint: dobry wynik to maksymalnie 2,5 s,

• INP – Interaction to Next Paint: dobry wynik to maksymalnie 200 ms,

• CLS – Cumulative Layout Shift: dobry wynik to maksymalnie 0,1.

Nie chodzi jednak o pojedynczy test wykonany w idealnych warunkach. Ocena Core Web Vitals odnosi się do 75. percentyla wizyt, czyli w uproszczeniu: co najmniej trzy czwarte doświadczeń użytkowników powinno mieścić się w dobrym zakresie.

To pierwsze miejsce, w którym można odróżnić usługę ekspercką od mechanicznego „przyspieszania WordPressa”.

Wynik Performance 95/100 w Lighthouse nie oznacza automatycznie zaliczonych Core Web Vitals. Lighthouse wykonuje test laboratoryjny w kontrolowanych warunkach. Dane rzeczywistych użytkowników w PageSpeed Insights pochodzą z Chrome UX Report, czyli CrUX, i obejmują ruch z poprzednich 28 dni.

Po wdrożeniu poprawki można więc zobaczyć natychmiastową zmianę w teście laboratoryjnym, a jednocześnie przez pewien czas nadal widzieć słabsze dane terenowe. To nie musi oznaczać, że optymalizacja nie zadziałała.

Nie należy też sprzedawać Core Web Vitals jako gwarancji pozycji w Google. Dobre CWV są wykorzystywane przez systemy rankingowe Google, ale ich zaliczenie nie gwarantuje wysokiej pozycji. Strona z LCP 1,8 s i słabą treścią nie wyprzedzi automatycznie lepszego merytorycznie konkurenta.

Od czego zacząć audyt

Przed podaniem klientowi ceny sprawdziłbym co najmniej:

• stronę główną,

• jedną typową podstronę,

• kluczowy landing page,

• kartę produktu i kategorię, jeżeli to sklep,

• mobile i desktop oddzielnie,

• dane rzeczywistych użytkowników, jeżeli są dostępne,

• Lighthouse,

• zakładkę Network w Chrome DevTools,

• zakładkę Performance,

• odpowiedź pierwszego dokumentu HTML,

• element będący LCP,

• ilość i sposób wykonywania JavaScriptu,

• obrazy ładowane przed pierwszym ekranem,

• fonty,

• cache,

• charakter backendu i hostingu.

Dopiero potem można odpowiedzieć, czy klient potrzebuje dwóch godzin konfiguracji, czy przebudowy fragmentu frontendu.

Dobra diagnostyka wygląda bardziej jak tabela decyzji niż lista „10 sposobów na szybszą stronę”.

To również dobry moment na sprawdzenie ryzyka.

Prosta witryna usługowa na WordPressie z formularzem kontaktowym jest zupełnie innym zleceniem niż WooCommerce z koszykiem, logowaniem, płatnościami, cenami zależnymi od użytkownika, filtrowaniem AJAX i zewnętrznym systemem magazynowym.

Im więcej elementów dynamicznych, tym bardziej niebezpieczne staje się bezmyślne włączanie cache i opóźnianie skryptów.

Przed rozpoczęciem zmian trzeba mieć kopię zapasową albo środowisko testowe. Przy sklepie test „strona się otwiera” nie wystarcza. Po zmianach muszą działać co najmniej koszyk, checkout, płatność, logowanie, formularze, filtry i wszystkie mechanizmy zależne od sesji użytkownika.

Obrazy, JavaScript, cache i serwer: poprawiaj przyczynę, a nie czerwony komunikat

Najłatwiej sprzedać klientowi „optymalizację zdjęć”, bo problem jest widoczny. Plik JPEG o szerokości 4000 px i wadze kilku megabajtów na stronie firmowej wygląda podejrzanie nawet bez narzędzi diagnostycznych.

Tyle że „konwertuj wszystko do WebP i włącz lazy loading” nie jest profesjonalną procedurą.

Przy obrazach trzeba kolejno sprawdzić:

1. w jakim rozmiarze grafika jest rzeczywiście wyświetlana,

2. jaki plik pobiera telefon, a jaki komputer,

3. czy działają srcset i sizes,

4. czy format WebP albo AVIF przyniesie realną oszczędność,

5. czy poziom kompresji nadal daje akceptowalną jakość,

6. czy grafika jest widoczna na pierwszym ekranie,

7. czy nie jest elementem LCP,

8. kiedy przeglądarka odkrywa jej adres,

9. z jakim priorytetem zaczyna ją pobierać,

10. czy zarezerwowano dla niej miejsce w layoucie.

Lazy loading dobrze sprawdza się przy zdjęciach znajdujących się niżej na stronie. Obraz LCP ładowany leniwie może natomiast pogorszyć wynik, bo przeglądarka zacznie pobierać kluczowy element później, niż powinna.

Podobnie z preload i wysokim priorytetem pobierania. Nie należy oznaczać wszystkiego jako ważne. Jeżeli pięć zasobów dostanie najwyższy priorytet, mechanizm przestaje pomagać w wyborze tego jednego, który naprawdę jest potrzebny jako pierwszy.

Przykład modelowy: dlaczego sama kompresja nie zawsze naprawia LCP

Załóżmy, że obraz hero waży 850 KB i jest elementem LCP. Po optymalizacji ma 170 KB.

Logiczne oczekiwanie: LCP powinno spaść bardzo mocno.

Po kolejnym teście poprawa okazuje się niewielka.

W Network widać jednak, że obraz nie jest wykrywany od razu z HTML, lecz dopiero po wykonaniu skryptu. Transfer jest już pięć razy mniejszy, ale pobieranie nadal zaczyna się zbyt późno.

W takiej sytuacji kolejne ściskanie JPEG-a o 20 KB nie rozwiązuje głównego problemu. Trzeba poprawić moment odkrycia zasobu albo sposób renderowania pierwszego ekranu.

To właśnie jest różnica między wykonywaniem zaleceń z raportu a diagnozowaniem wydajności.

INP: minifikacja JavaScriptu nie rozwiązuje każdego problemu

Przy INP trzeba patrzeć nie tylko na wagę pliku JavaScript, lecz także na koszt jego wykonania.

Plik może mieć po kompresji niewiele kilobajtów, a mimo tego wykonywać kosztowne operacje podczas kliknięcia użytkownika. Problem pojawia się szczególnie przy:

• rozbudowanych builderach,

• filtrach produktów,

• kalkulatorach i konfiguratorach,

• mapach,

• czatach,

• systemach reklamowych,

• narzędziach marketing automation,

• rozbudowanych skryptach analitycznych,

• kodzie reagującym na scroll, kliknięcia i zmianę rozmiaru okna.

Jeżeli kliknięcie filtra uruchamia długie zadanie na głównym wątku, samo dopisanie defer do pliku nie naprawi interakcji.

Czasem najlepsza optymalizacja brzmi brutalnie: ten skrypt nie powinien uruchamiać się w tym momencie.

Można go załadować dopiero po potrzebnej akcji, ograniczyć jego zakres, zastąpić lżejszym rozwiązaniem albo usunąć funkcję, której prawie nikt nie używa.

To bywa trudniejsze do sprzedaży niż „włączę minifikację”, ale właśnie za takie decyzje klient płaci specjaliście.

CLS: tu problem często jest prostszy, ale łatwo go przeoczyć

Przy wysokim CLS najpierw szukałbym elementów, które pojawiają się po rozpoczęciu renderowania i przesuwają już widoczną treść.

Typowe źródła:

• obraz bez zarezerwowanego miejsca,

• banner ładowany nad treścią,

• reklama o nieznanej wcześniej wysokości,

• iframe,

• pasek cookies,

• komunikat promocyjny,

• późno dołączony font zmieniający geometrię tekstu.

Najgorszą strategią jest poprawianie CLS przez przypadkowe zmiany CSS do momentu, aż Lighthouse pokaże zielony kolor. Trzeba znaleźć element odpowiadający za przesunięcie i usunąć jego przyczynę.

Cache ma kilka warstw

Hasło „włącz cache” jest za mało precyzyjne.

W praktyce można mieć do czynienia między innymi z:

• cache przeglądarki – ogranicza ponowne pobieranie statycznych zasobów,

• full-page cache – przechowuje gotowy HTML zamiast za każdym razem generować stronę od początku,

• object cache – np. Redis, który może ograniczyć koszt powtarzalnych operacji i zapytań,

• PHP OPcache – przechowuje skompilowany bytecode PHP,

• cache CDN/edge – może obsługiwać zasoby albo całe odpowiedzi bliżej użytkownika.

Każda warstwa rozwiązuje inny problem.

Redis nie naprawi ciężkiego JavaScriptu. CDN nie usunie złego zapytania SQL. Minifikacja CSS nie pomoże, jeżeli serwer przez 1,5 sekundy nie zaczyna wysyłać HTML.

Na WordPressie można spotkać m.in. LiteSpeed Cache, WP Rocket czy W3 Total Cache, ale wybór wtyczki nie powinien być punktem wyjścia. Najpierw trzeba ustalić środowisko.

Przykład: pełne możliwości serwerowego page cache LiteSpeed są szczególnie istotne wtedy, gdy hosting rzeczywiście korzysta z odpowiedniej technologii serwerowej. Instalowanie konkretnej wtyczki tylko dlatego, że dobrze wypada w poradnikach, jest odwróceniem kolejności diagnozy.

Przy WooCommerce trzeba dodatkowo bardzo uważać na:

• koszyk,

• checkout,

• konto użytkownika,

• informacje zależne od sesji,

• indywidualne ceny,

• dynamiczne fragmenty strony.

Zbyt agresywny cache może dać piękny test szybkości i jednocześnie zepsuć sklep.

Gdy problem zaczyna się przed frontendem

Wysoki TTFB zmienia kolejność pracy.

Jeżeli przeglądarka długo czeka na pierwszy dokument HTML, nie zaczyna jeszcze normalnie przetwarzać właściwej strony. Wtedy warto sprawdzić:

• możliwości serwera,

• obciążenie CPU,

• limity pamięci,

• I/O,

• konfigurację PHP i PHP-FPM,

• OPcache,

• pełny cache HTML,

• bazę danych,

• ciężkie zapytania,

• autoload w WordPressie,

• połączenia z zewnętrznymi API,

• wykonywane przy każdym żądaniu wtyczki.

To również moment, w którym czasem trzeba powiedzieć klientowi, że hosting jest częścią problemu.

Nie oznacza to jednak, że każdą wolną stronę należy przenosić na droższy serwer. Jeśli TTFB jest dobry, a przeglądarka dostaje kilka megabajtów niepotrzebnego JavaScriptu, migracja może kosztować klienta pieniądze i prawie nie zmienić doświadczenia użytkownika.

CSS i fonty też potrafią blokować pierwszy ekran

Przy CSS należy sprawdzać przede wszystkim:

• zasoby blokujące renderowanie,

• nieużywane style,

• ogromne arkusze generowane przez builder,

• critical CSS,

• style ładowane globalnie mimo użycia na jednej podstronie.

Łączenie wszystkich plików CSS albo JavaScript w jeden pakiet nie jest już uniwersalną receptą na szybkość. Trzeba patrzeć na protokół, cache, kolejność pobierania i rzeczywistą zawartość plików.

Fonty również wymagają selekcji. Jeżeli projekt używa jednej rodziny w wariantach 400, 600 i 700, pobieranie dwóch rodzin po sześć grubości każda jest trudne do obrony.

Do sprawdzenia są:

• liczba rodzin,

• liczba wariantów,

• format,

• subset znaków,

• font-display,

• sposób hostowania,

• zasadność preloadu wybranych fontów.

Preload każdego fontu jest tym samym błędem co ustawienie wysokiego priorytetu wszystkim obrazom. Priorytet ma sens tylko wtedy, gdy rzeczywiście coś priorytetyzuje.

Jak z optymalizacji zrobić rentowną usługę, a nie serię niekończących się poprawek

Największy błąd biznesowy pojawia się przed pierwszą zmianą w kodzie: stała cena zostaje podana bez diagnozy.

Klient pokazuje wynik 35/100. Wykonawca mówi „800 zł”. Po rozpoczęciu prac wychodzi WooCommerce, Elementor, kilkadziesiąt wtyczek, trzy systemy analityczne, zewnętrzny chat, niestandardowy checkout i serwer, do którego nikt nie ma pełnego dostępu.

Zlecenie, które miało zająć kilka godzin, zjada dwa dni.

Lepiej sprzedawać usługę etapami.

1. Audyt wydajności

Zakres:

• pomiar,

• identyfikacja wąskich gardeł,

• rozdzielenie problemów frontend/backend,

• lista zmian według priorytetu,

• ocena ryzyka,

• wycena wdrożenia.

2. Optymalizacja jednorazowa

Zakres:

• pomiar bazowy,

• zabezpieczenie strony,

• wdrożenie ustalonych zmian,

• test funkcjonalny,

• ponowny pomiar,

• raport przed/po.

3. Rozszerzona optymalizacja techniczna

Dla serwisów wymagających pracy z:

• własnym kodem,

• bazą danych,

• serwerem,

• integracjami,

• niestandardowym frontendem,

• rozbudowanym e-commerce.

4. Utrzymanie wydajności

To osobna usługa, a nie sztuczne przedłużanie jednorazowego zlecenia. Ma sens szczególnie tam, gdzie strona regularnie się zmienia.

Wynik może pogorszyć:

• aktualizacja motywu,

• nowa wtyczka,

• system reklamowy,

• kolejny tracker,

• nowy slider,

• zmiana hostingu,

• przebudowa strony głównej,

• nowa funkcja sklepu.

Ile można za taką usługę policzyć

Publiczne polskie oferty z 2026 roku pokazują duży rozrzut. Audyt wydajności można znaleźć od około 600 zł, wdrożenie optymalizacji od około 1500 zł, a zestawienia cen dla pełniejszej optymalizacji Core Web Vitals pokazują często poziom około 1500–5000 zł za usługę. Przy sklepach i bardziej problematycznych instalacjach zakres może dojść do kilku tysięcy złotych więcej.

Nie traktowałbym tych kwot jako cennika do skopiowania. Są punktem odniesienia.

Lepszy model to:

cena = szacowany czas pracy × stawka + bufor ryzyka + konkretne koszty dodatkowe

Przykład kalkulacyjny, nie stawka rynkowa:

• audyt: 2 h,

• przygotowanie kopii i testów: 1 h,

• optymalizacja obrazów i LCP: 2 h,

• cache/backend: 2 h,

• CSS/JS: 2 h,

• testy końcowe: 1 h.

Razem: 10 godzin.

Przy cenie projektu wynoszącej 2000 zł daje to 200 zł przychodu za godzinę przed podatkami i kosztami działalności.

Jeżeli jednak błędnie wyceniona praca rozrośnie się z 10 do 20 godzin, efektywna wartość godziny spada do 100 zł.

Dlatego zakres usługi jest ważniejszy niż efektownie wyglądający cennik.

Do ceny szczególnie powinny podnosić ostrożność:

• WooCommerce,

• wiele różnych szablonów podstron,

• własny kod,

• rozbudowane integracje,

• VPS wymagający konfiguracji,

• duża baza,

• stary PHP lub stary CMS,

• ciężki builder,

• brak stagingu,

• brak wiarygodnych backupów.

Kiedy nie podawać stałej ceny

Najpierw sprzedałbym audyt, jeśli:

• nie ma odpowiednich dostępów,

• system jest bardzo stary,

• strona ma wiele wcześniejszych „optymalizacji”,

• działa kilka narzędzi cache jednocześnie,

• klient nie wie, kto utrzymuje serwer,

• duża część funkcji jest napisana indywidualnie,

• nie można bezpiecznie przeprowadzić testów,

• klient oczekuje gwarantowanego 100/100,

• warunkiem zapłaty ma być konkretna pozycja w Google.

Ostatnie dwa punkty są szczególnie ważne.

Nie powinno się gwarantować 100/100 w PageSpeed. Wynik laboratoryjny zmienia się wraz z warunkami testu, a doprowadzanie każdej podstrony do idealnej liczby może wymagać kompromisów niewspółmiernych do efektu biznesowego.

Nie powinno się również gwarantować określonego wzrostu pozycji Google wyłącznie dzięki CWV. Szybkość jest jednym z elementów jakości strony, a nie przełącznikiem pozycji SEO.

Co pokazać klientowi po pracy

Raport „było czerwone, jest zielone” jest za słaby.

Zapisz przynajmniej:

• URL,

• datę,

• rodzaj urządzenia,

• rodzaj danych: LAB albo FIELD,

• LCP,

• INP, jeśli dla danego źródła jest dostępny,

• CLS,

• TTFB jako wskaźnik pomocniczy,

• element LCP,

• najważniejsze wykryte problemy,

• wykonane zmiany.

Porównanie musi używać tej samej metody.

Nie ma sensu zestawiać starego wyniku z telefonu klienta z nowym testem Lighthouse wykonanym w innych warunkach i przedstawiać różnicy jako twardego efektu optymalizacji.

Po wdrożeniu trzeba też przeprowadzić test funkcjonalny.

Minimalna lista:

• strona główna,

• kluczowe podstrony,

• mobile,

• desktop,

• menu,

• formularze,

• wyszukiwarka,

• logowanie,

• błędy konsoli,

• zachowanie po wyczyszczeniu cache.

Dla e-commerce dodatkowo:

• karta produktu,

• warianty,

• dodawanie do koszyka,

• usuwanie z koszyka,

• kupony,

• checkout,

• konto klienta,

• płatność,

• filtry i wyszukiwarka produktów.

Zielony Lighthouse nie rekompensuje niedziałającego przycisku „Kupuję i płacę”.

FAQ – najczęstsze pytania o usługę przyspieszania stron

Czy można zagwarantować 90 albo 100 punktów w PageSpeed Insights?
Nie powinno się tego gwarantować bez wcześniejszej analizy. Wynik Lighthouse zależy od strony, urządzenia i warunków testowych, a osiąganie ostatnich kilku punktów może wymagać usuwania funkcji potrzebnych biznesowo. Celem powinno być usunięcie istotnych problemów wydajnościowych, a nie zdobycie odznaki 100/100 za wszelką cenę.

Czy dobre Core Web Vitals automatycznie poprawią pozycję w Google?
Nie. Google wykorzystuje Core Web Vitals w swoich systemach rankingowych, ale dobre wyniki nie gwarantują wysokiej pozycji. Optymalizacja poprawia techniczne warunki strony i doświadczenie użytkownika, lecz nie zastępuje trafnej treści i pozostałych elementów wpływających na ranking.

Dlaczego wynik PageSpeed różni się między kolejnymi testami?
Lighthouse wykonuje pomiar laboratoryjny i jego wynik może się nieznacznie zmieniać między uruchomieniami. Dlatego zamiast reagować na różnicę dwóch punktów, lepiej patrzeć na powtarzające się problemy i konkretne metryki.

Dlaczego wyniki na telefonach są zwykle gorsze niż na komputerze?
Telefon ma zwykle słabszy procesor i pracuje w mniej przewidywalnych warunkach sieciowych. Ciężki JavaScript, który na mocnym laptopie jest prawie niezauważalny, na urządzeniu mobilnym może blokować główny wątek znacznie dłużej.

Co oznacza brak danych rzeczywistych użytkowników w PageSpeed Insights?
Najczęściej nie ma wystarczającej próbki CrUX dla konkretnego adresu lub originu. Wtedy nadal można diagnozować stronę laboratoryjnie, ale nie należy udawać, że Lighthouse jest tym samym co dane FIELD.

Czy wyniki CrUX zmienią się od razu po wdrożeniu poprawki?
Nie. PageSpeed Insights korzysta z danych CrUX agregowanych z poprzednich 28 dni. Świeża poprawka może być widoczna natychmiast w laboratorium, ale jej wpływ na dane rzeczywistych użytkowników będzie pojawiał się stopniowo.

Czy zmiana hostingu zawsze przyspieszy stronę?
Nie. Migracja ma sens wtedy, gdy problem rzeczywiście leży po stronie odpowiedzi serwera albo ograniczeń środowiska. Jeżeli backend odpowiada szybko, a stronę blokują obrazy i JavaScript, droższy serwer może niewiele zmienić.

Czy CDN jest potrzebny każdej stronie?
Nie. Korzyść zależy między innymi od lokalizacji użytkowników, hostingu i rodzaju treści. Polska strona obsługująca głównie klientów z Polski z dobrze skonfigurowanego lokalnego serwera może zyskać mniej niż serwis obsługujący ruch z wielu kontynentów.

Czy WebP lub AVIF automatycznie poprawią LCP?
Nie. Mniejszy plik pomaga, ale LCP może być opóźniony przez późne wykrycie obrazu, niski priorytet, wolny TTFB albo blokowanie renderowania. Format jest tylko jednym elementem całego łańcucha.

Czy lazy loading można włączyć dla wszystkich zdjęć?
Nie. Zdjęcia znajdujące się poza pierwszym ekranem zwykle są dobrymi kandydatami. Kluczowa grafika LCP powinna być traktowana inaczej, ponieważ jej opóźnienie może pogorszyć wynik.

Czy Redis zawsze przyspieszy WordPressa?
Nie. Object cache pomaga w określonych scenariuszach backendowych, szczególnie przy powtarzalnych operacjach i zapytaniach. Nie naprawi ciężkiego frontendu ani źle zoptymalizowanego obrazu LCP.

Czy po optymalizacji strona może ponownie zwolnić?
Tak. Aktualizacja, nowa wtyczka, dodatkowy tracker, zmiana layoutu albo nowy skrypt reklamowy potrafią ponownie pogorszyć wydajność. Dlatego w serwisach regularnie rozwijanych monitoring ma więcej sensu niż traktowanie optymalizacji jako czynności wykonywanej raz na zawsze.

Jeżeli masz zacząć od jednej rzeczy, nie instaluj kolejnej wtyczki optymalizacyjnej i nie kompresuj hurtowo wszystkich obrazów. Najpierw uruchom PageSpeed Insights, oddziel dane LAB od FIELD, ustal na mobile, która metryka nie przechodzi, a następnie znajdź jej konkretną przyczynę. Gdy LCP jest słabe, zacznij od elementu LCP i TTFB. Gdy problemem jest INP, przejdź do pracy głównego wątku i JavaScriptu. Gdy zawodzi CLS, znajdź element faktycznie przesuwający layout. Dopiero po diagnozie wybieraj narzędzie i wyceniaj wdrożenie.

Dodatkowe informacje na: https://hd-biznes.com/blog.