Core Web Vitals: co to jest, jak czytać PageSpeed Insights i co poprawić najpierw

Co to są Core Web Vitals: trzy wskaźniki i progi Google

To trzy liczby, którymi Google opisuje, jak strona zachowuje się u prawdziwych ludzi: kiedy widać główną treść, jak szybko strona reaguje na dotknięcie i czy nic nie przesuwa się pod palcem.

LCP (Largest Contentful Paint, czyli wyświetlenie największego elementu) mierzy, po ilu sekundach od wejścia widać największy element pierwszego ekranu: zwykle zdjęcie w nagłówku, czasem duży blok tekstu. INP (Interaction to Next Paint, czyli czas od interakcji do odświeżenia ekranu) mierzy, ile mija od kliknięcia, dotknięcia albo naciśnięcia klawisza do chwili, gdy strona pokaże reakcję. Przewijanie i najechanie kursorem się nie liczą. CLS (Cumulative Layout Shift, czyli suma przesunięć układu) mierzy, jak bardzo elementy przesuwają się same, na przykład gdy tekst zjeżdża w dół, bo nad nim doładował się baner.

Progi podaje web.dev, serwis zespołu Chrome w Google. Dobrze jest, gdy LCP nie przekracza 2,5 sekundy, INP 200 milisekund, a CLS 0,1. Słaby wynik zaczyna się powyżej 4 sekund, 500 milisekund i 0,25, a wszystko pomiędzy to strefa „wymaga poprawy”. Liczy się 75. percentyl, czyli wartość, którą spełnia co najmniej 75 na 100 wizyt. Według web.dev to kompromis: większość odwiedzających ma mieć dobre wrażenia, a kilka wizyt na fatalnym łączu nie ma przekreślać wyniku.

Telefony i komputery ocenia się osobno, choć progi są te same, ustalone według web.dev głównie pod możliwości telefonów. Gorzej wypada zwykle wersja mobilna: według rozdziału o wydajności w Web Almanac 2025, raporcie HTTP Archive opartym na danych z Chrome z lipca 2025 r., dobre Core Web Vitals miało 48 procent witryn na telefonach i 56 procent na komputerach. Najczęściej odpada LCP: na telefonach dobry wynik miało 62 procent witryn, przy 77 procentach dla INP i 81 procentach dla CLS.

Jeśli czytasz poradnik, który jako trzeci wskaźnik podaje FID (First Input Delay), to tekst sprzed marca 2024 r. INP zastąpił FID 12 marca 2024 r. FID mierzył tylko opóźnienie przed obsługą pierwszej interakcji, a INP bierze pod uwagę wszystkie kliknięcia i dotknięcia podczas wizyty, więc trudniej go zaliczyć. Web Almanac 2024 pokazał to na liczbach: z FID dobre Core Web Vitals na telefonach miałoby 48 procent witryn, a z INP miało 43 procent.

Progi trzech wskaźników według web.dev i dokumentacji PageSpeed Insights, liczone na 75. percentylu wizyt, osobno dla telefonów i komputerów.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

PageSpeed Insights: jak czytać wynik krok po kroku

PageSpeed Insights to bezpłatne narzędzie Google, które nie wymaga konta. Na jednym ekranie pokazuje dwa różne pomiary, a większość nieporozumień bierze się z ich pomylenia.

Wynik 0–⁠100 potrafi się zmienić między dwoma testami bez żadnej zmiany na stronie. Dokumentacja Lighthouse wymienia powody: inne reklamy albo test A/B na stronie, inna trasa w sieci, inne urządzenie testujące, rozszerzenia przeglądarki i antywirus. Radzi więc traktować wydajność jak rozkład wyników, a nie jedną liczbę. Przy porównaniu przed zmianą i po niej robię po kilka testów i porównuję medianę, czyli wynik środkowy.

Obok wydajności raport ma osobne wyniki dostępności, dobrych praktyk i SEO. Nie wchodzą one do oceny trzech wskaźników. Dostępność sprawdź przy okazji; piszę o niej w przewodniku dostępność sklepu internetowego.

1. Wpisz adres konkretnej podstronyNie tylko strony głównej. Sprawdź też podstronę, na którą trafia najwięcej osób z Google albo z reklam, bo każda ma inny pierwszy ekran i inne skrypty.
2. Zacznij od wersji mobilnejRaport ma osobne widoki dla telefonu i komputera. Problemy zwykle widać najpierw na telefonie, bo test symuluje słabszy procesor i wolniejsze łącze niż na komputerze.
3. Przeczytaj górną część: dane od prawdziwych użytkownikówTo dane z CrUX (Chrome User Experience Report), czyli zbiorczego raportu Google z wizyt w Chrome z ostatnich 28 dni. Tu jest ocena trzech wskaźników: zaliczona, gdy 75. percentyl LCP, INP i CLS mieści się w progach. Gdy INP ma za mało danych, wystarczą LCP i CLS. Gdy brakuje danych LCP albo CLS, oceny nie ma.
4. Sprawdź, czego dotyczą daneGdy podstrona ma za mało wizyt, narzędzie pokazuje dane całej witryny, a gdy i tych brakuje, nie pokazuje nic. Zanim wyciągniesz wnioski, upewnij się, czy patrzysz na ten adres, czy na całą domenę.
5. Dolna część to test laboratoryjnyWynik 0–⁠100 liczy Lighthouse, program Google, który raz ładuje stronę na symulowanym telefonie średniej klasy z ograniczonym łączem, z serwera w Ameryce Północnej, Europie albo Azji. 90 i więcej to wynik dobry, 50–⁠89 wymaga poprawy, poniżej 50 jest słaby.
6. Zobacz, które pomiary ciągną wynik w dółWynik to średnia ważona pięciu pomiarów. W Lighthouse 10 i nowszych największą wagę, 30 procent, ma TBT (Total Blocking Time, czyli łączny czas, przez który skrypty blokowały przeglądarkę), po 25 procent LCP i CLS, a po 10 procent FCP (pierwsze wyświetlenie treści) i Speed Index (tempo, w jakim zapełnia się ekran). INP bez prawdziwych kliknięć zmierzyć się nie da, więc TBT służy w teście za jego przybliżenie. Web.dev zaznacza, że to tylko przybliżenie, a nie zamiennik.
7. Na końcu lista podpowiedziPod wynikiem są diagnozy: za duże obrazy, skrypty blokujące wyświetlanie, kod firm zewnętrznych. Zacznij od tych, które dotyczą wskaźnika oblanego w danych od użytkowników; reszta może poczekać.

Lighthouse a CrUX: dane z laboratorium i od prawdziwych użytkowników

Test laboratoryjny pokazuje jedną wizytę w ustalonych warunkach. Dane terenowe pokazują, co przeżyli Twoi odwiedzający przez ostatnie cztery tygodnie. Ocena LCP, INP i CLS pochodzi tylko z tych drugich.

Web.dev wylicza, skąd biorą się różnice. Test startuje z pustą pamięcią podręczną, a stały klient ma już część plików w telefonie. Symulowany ekran może mieć inny element LCP niż duży telefon odwiedzającego. Test idzie przez jedno łącze z jednego miejsca, a Twoi klienci łączą się z różnych sieci. Wniosek z tego samego tekstu: o priorytetach decydują dane terenowe, a laboratorium służy do szukania przyczyn i testów przed wdrożeniem.

Różnicę widać nawet w skali całego internetu. Web Almanac 2025 podaje, że mediana TBT na telefonach w teście laboratoryjnym wzrosła w rok o 58 procent, do 1916 milisekund, a w tym samym czasie odsetek witryn z dobrym INP u prawdziwych użytkowników wzrósł z 74 do 77 procent. Autorzy tłumaczą to między innymi tym, że prawdziwe telefony są coraz mocniejsze, a test używa wciąż tego samego emulowanego urządzenia. Wynik 45 w laboratorium przy zaliczonej ocenie terenowej nie jest więc powodem do paniki.

Dwie rzeczy łatwo przeoczyć. Według metodologii CrUX dane pochodzą tylko z Chrome na komputerach i Androidzie, od osób, które synchronizują historię przeglądania i wysyłają statystyki użytkowania. Safari i Chrome na iPhonie do tych danych nie trafiają, więc jeśli Twoi klienci korzystają głównie z iPhone’ów, ocena opisuje tylko część z nich. Druga sprawa: strona trafia do CrUX dopiero przy wystarczającym ruchu, a Google nie podaje progu. Mała firmowa strona często nie ma więc żadnych danych terenowych. Zostaje Ci test laboratoryjny oraz panel Performance w Chrome DevTools, który według dokumentacji Chrome pokazuje LCP, CLS i Twój własny INP, gdy sam klikasz po stronie na swoim telefonie albo komputerze.

Dwa rodzaje danych w PageSpeed Insights według dokumentacji narzędzia i web.dev.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Raport Core Web Vitals w Search Console

PageSpeed Insights sprawdza jeden adres. Search Console pokazuje całą witrynę, pogrupowaną w podobne strony, i pozwala potwierdzić, że poprawka zadziałała.

Raport, w polskiej dokumentacji Google nazywany też „Podstawowe wskaźniki internetowe”, korzysta z tych samych danych CrUX z 28 dni co górna część PageSpeed Insights. Ma osobne widoki dla telefonów i komputerów, a ta sama strona może mieć na nich różny stan.

Podobne adresy Search Console łączy w grupy, na przykład wpisy na blogu albo karty produktów. Stan grupy to stan jej najsłabszego wskaźnika: jeśli LCP jest dobry, a CLS wymaga poprawy, cała grupa wymaga poprawy. Stany nazywają się „Dobrej jakości”, „Wymagana poprawa” i „Słabej jakości”. Gdy witryna jest dopiero co dodana do Search Console (Google nazywa ją tam „usługą”) albo z danego typu urządzeń jest za mało wizyt, raport pokazuje brak danych i pojedyncze adresy sprawdzasz w PageSpeed Insights.

1. Otwórz raport dla telefonówZobacz, ile adresów jest w każdym stanie i który wskaźnik jest problemem: LCP, INP czy CLS.
2. Otwórz szczegóły problemu i przykładowe adresyGrupa to zwykle strony z tego samego szablonu, więc jeden przykładowy adres często wystarczy, żeby znaleźć przyczynę dla całej grupy.
3. Sprawdź przykład w PageSpeed InsightsDolna część raportu pokaże, który element jest elementem LCP, co zajmuje główny wątek i co się przesuwa.
4. Wdróż poprawkę i kliknij „Rozpocznij śledzenie”Zaczyna się 28-dniowy okres monitorowania. Problem uznaje się za naprawiony, jeśli przez ten czas nie wystąpi w żadnym adresie. Według pomocy Search Console kliknięcie nie zleca ponownego indeksowania ani żadnych innych działań Google, tylko uruchamia to monitorowanie.

Czy Core Web Vitals wpływają na pozycję w Google i na sprzedaż

Wpływają, ale mniej, niż sugerują oferty „przyspieszania strony pod SEO”. Google pisze o tym wprost w dokumentacji wyszukiwarki.

Na stronie Google Search Central o wrażeniach z korzystania ze strony (page experience) Google pisze, że jego systemy rankingowe używają Core Web Vitals. Zastrzega jednak, że nie ma jednego sygnału „wrażeń ze strony”, że dobre wyniki w raporcie Core Web Vitals czy w innych narzędziach nie gwarantują wysokich pozycji i że wyszukiwarka zawsze stara się pokazać najtrafniejszą treść, nawet jeśli jakość strony jest poniżej normy. Dobra jakość strony pomaga według Google wtedy, gdy na to samo zapytanie jest wiele przydatnych treści.

Mit: „wynik 100 w PageSpeed Insights podniesie mnie w Google”. Liczba 0–⁠100 to test laboratoryjny, a nie ocena LCP, INP i CLS, a nawet zaliczona ocena nie gwarantuje pozycji. Google pisze wprost, że gonienie idealnego wyniku tylko z myślą o SEO może nie być najlepszym wykorzystaniem Twojego czasu. Ta sama dokumentacja każe też zapytać, czy strona działa przez HTTPS, dobrze wygląda na telefonie, nie przytłacza treści reklamami, nie zasłania jej natrętnymi oknami na cały ekran i czy łatwo w niej odróżnić główną treść. Szybkość to jedna pozycja z tej listy.

O sprzedaży najczęściej słyszysz liczby z badania „Milliseconds Make Millions”. Zamówił je Google, a przeprowadziły firmy 55 i Deloitte: pod koniec 2019 r. przez 30 dni śledzono mobilne wersje 37 stron dużych marek z Europy i USA, ponad 30 milionów sesji. Gdy każda strona na ścieżce zakupu była szybsza o 0,1 sekundy w czterech mierzonych wskaźnikach, w sklepach o 9,1 procent więcej osób przechodziło z karty produktu do koszyka, a klienci wydawali o 9,2 procent więcej. W turystyce rezerwacji było o 10 procent więcej, a w serwisach zbierających zapytania o 21,6 procent więcej osób dochodziło do strony z formularzem. Tak podaje opis badania na web.dev.

Czytaj to z trzema zastrzeżeniami. Badanie zamówiła firma, która promuje te wskaźniki. To obserwacja dużych marek, a nie eksperyment na małych firmach. Mierzono też inne wskaźniki niż dzisiejsza trójka, a jeden z nich (First Meaningful Paint) został wycofany. Bezpieczny jest skromniejszy wniosek: wolna strona na telefonie kosztuje Cię część osób, a ile, pokaże dopiero Twój pomiar konwersji przed zmianą i po niej. Jak go ustawić, opisuję w przewodniku konwersja na stronie internetowej.

Kiedy nie warto gonić wyniku i czego nie robić

Celem są progi w danych od prawdziwych użytkowników, a nie zielona setka w teście. Gdy strona je spełnia, czas lepiej włożyć w ofertę i treść niż w kolejne punkty testu.

• Strona już zalicza ocenęJeśli Search Console pokazuje „Dobrej jakości” na telefonach i komputerach, nie przebudowuj strony dla wyniku 0–⁠100. Popraw raczej ofertę, tekst i formularz.
• Brak danych przy małym ruchuTo nie błąd ani kara. Sprawdź test laboratoryjny na telefonie, popraw rzeczy oczywiste, takie jak ciężkie zdjęcie w nagłówku, i wróć do tematu, gdy ruch urośnie.
• Nie wyrzucaj banera zgód ani analityki dla punktówBaner jest potrzebny, gdy strona używa narzędzi wymagających zgody, a analityka mówi Ci, skąd przychodzą klienci. Zmień sposób ich ładowania, co opisuję niżej.
• Wolna strona to nie zawsze przyczyna braku zapytańGdy ludzie wchodzą, a nie piszą, przyczyną bywa raczej oferta, cena albo brak zaufania niż ułamek sekundy LCP. Szybkość usuwa przeszkodę, ale nie sprzedaje za Ciebie.
• Nie wierz w „100/100 i top 3”Pozycji w Google nikt nie zagwarantuje, a Google pisze, że dobre wyniki jej nie gwarantują. Pytaj wykonawcę o ocenę w danych od użytkowników po 28 dniach, a nie o zrzut ekranu z testu.
• Nie przebudowuj całej strony tylko dla wskaźnikówMa to sens, gdy motyw albo kreator nie pozwala poprawić podstaw, na przykład obrazu w nagłówku czy kolejności skryptów. Przy przebudowie pilnuj przekierowań; piszę o tym w przewodniku przebudowa strony bez utraty ruchu.

Co najczęściej psuje LCP na małej stronie i jak to naprawić

Na telefonach element LCP to według Web Almanac 2025 obraz w 76 procentach stron. Zanim zaczniesz zmieniać serwer, sprawdź, co dzieje się z tym jednym zdjęciem.

Web.dev dzieli LCP na cztery części: czas do pierwszej odpowiedzi serwera (TTFB, Time to First Byte), opóźnienie, zanim przeglądarka w ogóle zacznie pobierać obraz, czas pobierania i opóźnienie wyświetlenia. Na dobrze zrobionej stronie TTFB i pobieranie zajmują po około 40 procent czasu, a oba opóźnienia po mniej niż 10 procent. Ta sama dokumentacja ostrzega, że samo zmniejszenie zdjęcia nie musi pomóc, bo zaoszczędzony czas może przejść na czekanie z wyświetleniem. Dlatego najpierw ustalam, która część trwa najdłużej, a dopiero potem wybieram poprawkę.

Najtańsze poprawki dotyczą samego znacznika obrazu. Główne zdjęcie nie może mieć loading="lazy", czyli leniwego ładowania, które odkłada pobranie do chwili, aż obraz zbliży się do ekranu; według Web Almanac 2025 robi tak około 16–⁠17 procent stron. Powinno mieć fetchpriority="high", ale tylko ono albo najwyżej dwa obrazy, bo wysoki priorytet dla wszystkiego nic nie daje. Adres zdjęcia ma być wprost w kodzie HTML, a nie w atrybucie data-src podmienianym przez skrypt slidera, bo wtedy przeglądarka dowiaduje się o obrazie dopiero po uruchomieniu skryptu.

Te typowe przyczyny wypisze też bezpłatny skan strony: zmierzy czas odpowiedzi serwera i sprawdzi, czy główny obraz nie ma leniwego ładowania, czy zdjęcia mają wymiary i nowoczesny format i ile skryptów wstrzymuje wyświetlanie. Ocenę z prawdziwych wizyt nadal czytasz w PageSpeed Insights. Format, rozmiar i wymiary zdjęć krok po kroku opisuje przewodnik o zdjęciach na stronie.

• Zdjęcie w nagłówku prosto z aparatuPlik ma kilka megabajtów i 4000 pikseli szerokości, a telefon pokazuje kilkaset. Przygotuj kilka rozmiarów (atrybut srcset), zapisz w WebP albo AVIF i skompresuj.
• Slider na pierwszym ekraniePierwszy slajd często czeka na skrypt slidera, a kolejne konkurują z nim o łącze. Jeśli slider musi zostać, pierwszy obraz niech będzie zwykłym obrazem w HTML, a ukryte slajdy dostaną niższy priorytet.
• CzcionkiGdy elementem LCP jest nagłówek tekstowy, może on czekać na plik czcionki z sieci. Web.dev zaleca wartość font-display inną niż auto i block oraz mniejsze pliki czcionek.
• Skrypty i style w nagłówku koduSynchroniczne skrypty i duże arkusze stylów w sekcji head wstrzymują wyświetlanie. Skrypty, które nie są potrzebne do pierwszego ekranu, ładuj z atrybutem defer albo async.
• Wolny serwer albo brak pamięci podręcznejGdy strona składa się od nowa przy każdym wejściu, TTFB rośnie. Pomaga pamięć podręczna gotowego HTML, mniej przekierowań i CDN, czyli sieć serwerów bliżej odwiedzających. PageSpeed Insights uznaje TTFB do 800 milisekund za dobry, choć to wskaźnik eksperymentalny.
• Główny obraz jako tło w CSSPrzeglądarka znajdzie go dopiero po pobraniu arkusza stylów. Wstaw go jako zwykły obraz albo każ przeglądarce pobrać go z wyprzedzeniem (preload).

Czat, piksel i baner zgód: co psuje INP i CLS

INP psują najczęściej skrypty, które zajmują przeglądarkę w chwili, gdy klient dotyka ekranu. Na małej stronie to zwykle nie Twój kod, tylko dodatki: czat, piksele reklamowe, tagi i baner zgód.

Przeglądarka ma jeden główny wątek do obsługi kliknięć i rysowania strony. Jeśli w chwili dotknięcia przycisku wykonuje akurat skrypt czatu, kliknięcie czeka. Web.dev w poradniku o tagach pisze, że INP jest wrażliwy na rywalizację o ten wątek i że większy kontener menedżera tagów idzie w parze ze słabszym INP.

Baner zgód szkodzi na dwa sposoby. Wsuwany u góry po wyświetleniu strony spycha treść w dół, a web.dev nazywa banery cookies bardzo częstym źródłem przesunięć układu. Do tego kliknięcie „Akceptuję” często uruchamia naraz wszystkie skrypty, które czekały na zgodę, i to ono bywa najwolniejszą interakcją na stronie. Web Almanac 2024, na danych firmy RUMvision ze stron, które ona mierzy, podaje, że tylko 53 procent stron mobilnych z platformą zgód miało dobry INP. Jak ustawić baner zgodnie z prawem i wymaganiami Google, opisuję w przewodniku Consent Mode v2 i baner cookies.

Piksel Meta to w praktyce skrypt: kod bazowy z dokumentacji Meta wczytuje plik fbevents.js asynchronicznie, czyli bez wstrzymywania wyświetlania strony. Potem i tak wykonuje się w głównym wątku, tak jak tag Google Ads czy skrypt map ciepła. Web Almanac 2024 wymienia skrypty śledzące zachowanie odwiedzających i platformy zgód wśród głównych przyczyn słabego INP.

• Baner zgód na dole albo jako okno nad treściąPrzyklejony do dołu ekranu albo okno nad stroną nie przesuwa treści. Skrypt banera wstaw bezpośrednio w kodzie z atrybutem async, a nie przez menedżera tagów, który go opóźnia. Zapytaj dostawcę, czy po kliknięciu „Akceptuję” rozkłada uruchamianie skryptów w czasie.
• Czat jako fasadaDokumentacja Chrome opisuje fasadę: lekki przycisk wyglądający jak dymek czatu, a prawdziwy widżet ładuje się dopiero po kliknięciu. Wymienia Intercom, Drift, Help Scout i Messengera. Koszt podaje na przykładzie Drift: dymek z licznikiem nowych wiadomości pojawi się dopiero po załadowaniu prawdziwego widżetu.
• Tagi usuń, zamiast blokowaćNieużywane tagi usuń z kontenera, bo zablokowany wyjątkiem tag dalej jest w kodzie. Tagi niepotrzebne do pierwszego wrażenia uruchamiaj po pełnym załadowaniu strony (wyzwalacz Window Loaded) i tylko na podstronach, gdzie są potrzebne.
• Piksel tylko tam, gdzie coś mierzyJeśli nie prowadzisz i nie planujesz kampanii Meta, piksel zwykle nie jest Ci potrzebny. Jeśli prowadzisz, sprawdź, czy nie jest wstawiony dwa razy: w kodzie strony i przez menedżera tagów. Web.dev zwraca uwagę na takie dublowanie.
• Wymiary obrazów i miejsce na osadzeniaKażdy obraz i film ma atrybuty width i height albo proporcje w CSS (aspect-ratio), a miejsce na mapę, film czy widżet opinii jest zarezerwowane z góry. Według Web Almanac 2025 co najmniej jeden obraz bez wymiarów ma 62 procent stron mobilnych.
• Czcionki bez skokuGdy czcionka z sieci podmienia systemową, tekst zmienia szerokość i przesuwa resztę strony. Web.dev zaleca font-display: optional albo dopasowanie czcionki zastępczej właściwością size-adjust.

Wideo w nagłówku, modele 3D i filmy z YouTube

Ciężkie elementy nie muszą psuć wskaźników, jeśli ładują się we właściwej kolejności: najpierw lekki obraz, a pełny element dopiero wtedy, gdy jest potrzebny.

Film w tle nagłówka liczy się do LCP. Web.dev podaje, że dla elementu wideo liczy się czas załadowania obrazu podglądu (atrybut poster) albo wyświetlenia pierwszej klatki, zależnie od tego, co nastąpi wcześniej. Lekki, dobrze skompresowany obraz podglądu często decyduje więc o LCP bardziej niż sam film. Film na pierwszym ekranie niech będzie krótki, bez dźwięku i w rozmiarze dopasowanym do ekranu telefonu.

Osadzony film z YouTube ładuje odtwarzacz razem z jego skryptami, nawet jeśli nikt go nie włączy. Dokumentacja Chrome poleca fasadę: obraz z przyciskiem odtwarzania, a odtwarzacz dopiero po kliknięciu, na przykład z biblioteki lite-youtube-embed. Ceną jest to, że automatyczne odtwarzanie może nie działać niezawodnie.

Model 3D rysuje się w elemencie canvas, którego nie ma na liście elementów branych pod uwagę przy LCP. O LCP decyduje więc obraz podglądu albo nagłówek obok, a sam model może ładować się później. Pobieranie i przygotowanie sceny zajmuje jednak procesor telefonu, więc gdy model startuje razem ze stroną, może ucierpieć INP. Budżet pliku, podgląd i kolejność ładowania opisuję w przewodniku model 3D na stronie internetowej, a filmy produktowe w przewodniku animacja 3D produktu.

Plan naprawy: od najtańszej zmiany do przebudowy

Kolejność ustalam według dwóch pytań: który wskaźnik oblewa w danych od użytkowników i która poprawka wymaga najmniej pracy. Tak wygląda plan, od którego zaczynam przy cudzej stronie.

1. Ustal, co oblewa i gdzieSearch Console albo górna część PageSpeed Insights: telefon czy komputer, LCP, INP czy CLS, które grupy stron. Bez tego poprawiasz na ślepo.
2. Popraw obraz LCPBez leniwego ładowania, z fetchpriority="high", w odpowiednim rozmiarze i formacie, z adresem wprost w HTML. To zwykle zmiana w jednym szablonie.
3. Nadaj wymiary i zarezerwuj miejsceAtrybuty width i height przy obrazach, proporcje dla filmów i map, baner zgód na dole albo nad treścią.
4. Zrób przegląd dodatkówWypisz wszystkie skrypty zewnętrzne, wtyczki i tagi. Przy każdym zapytaj, kto z niego korzysta i do czego. Co nikomu nie służy, usuń.
5. Zmień sposób ładowania tego, co zostajeCzat jako fasada, tagi po załadowaniu strony i tylko na potrzebnych podstronach, skrypty z defer albo async, mniej odmian czcionki.
6. Serwer, pamięć podręczna i CDNGdy TTFB jest wysoki mimo lekkiej strony, problem leży w hostingu albo jego konfiguracji.
7. Nowy szablon albo platformaDopiero gdy kroków 2–⁠6 nie da się zrobić w obecnym motywie, kreatorze albo systemie. Platformy porównuję w przewodniku WordPress, Webflow czy Framer.

Typowe poprawki: który wskaźnik poprawiają, ile wymagają pracy i kto je zwykle robi.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Ile to kosztuje i ile trwa

Narzędzia są bezpłatne. Płacisz czasem, swoim albo wykonawcy, a efekt w danych od użytkowników zobaczysz dopiero po kilku tygodniach.

PageSpeed Insights, Search Console i Lighthouse w przeglądarce Chrome nic nie kosztują. Do automatycznych testów wielu adresów jest API PageSpeed Insights, ale jego dokumentacja zapowiada, że przestanie ono zwracać dane od prawdziwych użytkowników, i odsyła po nie do CrUX API.

Najwięcej kosztuje nie sama poprawka, tylko diagnoza na nieznanej stronie i ograniczenia platformy. Zmiana atrybutów głównego zdjęcia w szablonie, który znasz, to krótka praca. Ta sama zmiana w gotowym motywie albo kreatorze bez dostępu do kodu bywa niemożliwa bez obejść albo zmiany motywu. Dlatego przed wyceną zawsze pytam, na czym stoi strona i kto ma dostęp do jej kodu.

Czas liczysz w tygodniach. Dane CrUX obejmują kroczące 28 dni, więc po wdrożeniu poprawki przez kilka tygodni widzisz mieszankę starych i nowych wizyt. Weryfikacja w Search Console też trwa 28 dni, a jeśli w tym czasie problem wróci choćby na jednym adresie, poprawiasz i zaczynasz od nowa. Od poprawki do zielonego raportu licz więc co najmniej cztery tygodnie, a przy drugim podejściu około ośmiu. Wszystko to pod warunkiem, że strona ma dość ruchu, żeby w ogóle mieć dane od użytkowników.

Jak mogę pomóc

Prowadzę JFlow Labs sam, z Mikołowa, i pracuję zdalnie z firmami z całej Polski. Strony, które buduję, przed oddaniem sprawdzam w PageSpeed Insights na wersji mobilnej i na prawdziwych telefonach.

Jeśli Twoja strona oblewa Core Web Vitals, zaczynam od diagnozy: dane z Search Console, kilka testów laboratoryjnych przykładowych adresów, lista dodatków i plan poprawek w kolejności z tego przewodnika. Szybkość jest jednym z bloków audytu SEO, który kosztuje u mnie 1500–⁠3500 zł netto; co zawiera, opisuję w przewodniku audyt SEO, a zakres usługi na stronie pozycjonowanie stron. Poprawki wdrażam sam, gdy mam dostęp do kodu albo motywu, a jeśli stronę prowadzi inna firma, dostaje ode mnie listę do zrobienia.

Gdy obecnej strony nie da się sensownie przyspieszyć, buduję nową i od pierwszego dnia pilnuję w niej szybkości: landing page lub strona wizytówka kosztuje 2500–⁠5000 zł netto, strona firmowa wielopodstronowa 6000–⁠14 000 zł, sklep internetowy 9000–⁠22 000 zł, a opieka po wdrożeniu, z monitoringiem dostępności i czasu ładowania, 300–⁠900 zł miesięcznie. Pełne zakresy są na stronie cennik, a opis usługi na stronie strony internetowe. Powiem Ci wprost, czy poprawki w ogóle Ci się opłacą.

Kwoty netto z mojego cennika.

Pytania i odpowiedzi