PageSpeed Insights i Core Web Vitals: ile kosztuje wolna strona i co naprawić najpierw

Aktualizacja: 1 października 2026 · Autor: Szymon Sanecznik, SEMownia

Wynik 38/100 w PageSpeed Insights potrafi wywołać w firmie panikę. Programista mówi, że „na jego komputerze działa szybko”, agencja SEO chce budżetu na optymalizację, a zarząd pyta, ile to kosztuje i co da, tyle że nikt nie potrafi odpowiedzieć w złotówkach, więc decyzja zapada na wyczucie albo wcale. Znam to z wielu spotkań.

Pokazuję tu, jak czytać raport PageSpeed Insights, które liczby mają znaczenie, ile szybkość waży w SEO i w Google Ads, a ile w konwersji. Najważniejsze od razu: o ocenie strony decydują dane terenowe od prawdziwych użytkowników, sam wynik 0–100 jest drugorzędny. A w mojej symulacji sklepu z 225 000 zł przychodu miesięcznie optymalizacja za 15 000 zł zwraca się w rok dopiero wtedy, gdy współczynnik konwersji wzrośnie o ok. 2,2%. Na końcu znajdziesz też listę, co naprawić najpierw w WordPressie i w sklepie internetowym.

Czym są Core Web Vitals i PageSpeed Insights?

Core Web Vitals (podstawowe wskaźniki internetowe) to trzy miary Google opisujące, jak użytkownik doświadcza strony: LCP mierzy czas wyświetlenia największego elementu treści, INP mierzy opóźnienie reakcji na kliknięcia i dotknięcia, a CLS mierzy nieoczekiwane przesunięcia układu. PageSpeed Insights to bezpłatne narzędzie Google, które pokazuje te wskaźniki dla adresu URL z danych realnych użytkowników i z testu laboratoryjnego.

Czy Core Web Vitals to po prostu „wynik PageSpeed”? Niestety często tak się je traktuje. Liczba 0–100 na górze raportu to ocena testu laboratoryjnego Lighthouse, przeprowadzonego jednorazowo na symulowanym urządzeniu, natomiast Core Web Vitals to dane terenowe, czyli rozkład doświadczeń prawdziwych osób odwiedzających stronę. Strona może mieć wynik 45 i zaliczać wszystkie trzy wskaźniki albo wynik 85 i nie zaliczać żadnego, bo jej klienci korzystają z wolniejszych telefonów niż te w teście.

Od 12 marca 2024 roku INP (Interaction to Next Paint) zastąpił w Core Web Vitals wcześniejszy wskaźnik FID. Raport dla zarządu nadal pokazuje FID? Ktoś pracuje na nieaktualnej definicji.

Jakie są progi LCP, INP i CLS w 2026 roku?

Progi nie zmieniły się od wprowadzenia INP. Google ocenia je na 75. percentylu wszystkich odsłon, osobno dla urządzeń mobilnych i komputerów, co oznacza, że co najmniej 75% wizyt musi mieścić się w progu „dobrze”, żeby strona dostała zieloną ocenę dla danego wskaźnika.

Wskaźnik	Co mierzy	Dobrze	Wymaga poprawy	Słabo
LCP (Largest Contentful Paint)	czas do wyświetlenia największego elementu treści (zwykle zdjęcie główne lub nagłówek)	≤ 2,5 s	2,5–4 s	> 4 s
INP (Interaction to Next Paint)	opóźnienie między interakcją a widoczną reakcją strony	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	suma nieoczekiwanych przesunięć układu	≤ 0,1	0,1–0,25	> 0,25
TTFB (pomocniczo, nie jest Core Web Vital)	czas do pierwszego bajtu odpowiedzi serwera	≤ 0,8 s	0,8–1,8 s	> 1,8 s

W raporcie Search Console obowiązuje zasada „najgorszy wskaźnik wygrywa”: jeśli grupa adresów ma dobry INP, ale słaby CLS, cała grupa ma status „słabo”. Jeden poprawiony wskaźnik statusu nie zmieni.

Dla skali: według Web Almanac 2025 (dane CrUX z lipca 2025) wszystkie trzy wskaźniki zalicza 48% witryn na urządzeniach mobilnych i 56% na komputerach, przy czym na mobile najsłabszy jest LCP (62% witryn z dobrym wynikiem), dalej INP (77%) i CLS (81%). Jeśli Twoja strona nie zalicza LCP na telefonach, jesteś w dużej grupie. Marne pocieszenie. Traktuj to raczej jako wskazówkę, od czego zacząć.

Jak czytać raport PageSpeed Insights: dane terenowe a laboratoryjne

Raport ma dwie części. Pierwsza mówi, jak jest. Druga podpowiada, dlaczego.

Dane terenowe (CrUX)

Górna sekcja „Sprawdź, jak strona działa u prawdziwych użytkowników” pochodzi z Chrome User Experience Report (CrUX), czyli z danych z ostatnich 28 dni od zalogowanych użytkowników Chrome, którzy zgodzili się na przesyłanie statystyk. PageSpeed Insights pokazuje wartość 75. percentyla dla LCP, INP, CLS oraz pomocniczo FCP i TTFB.

Trzy rzeczy, które często umykają:

• Adres czy cała domena. Jeśli dany adres ma za mało ruchu, narzędzie pokazuje dane dla całego źródła (origin), czyli wszystkich stron w domenie. Wtedy zielony wynik strony głównej nie mówi nic o konkretnej karcie produktu, a gdy i domena ma za mało ruchu, danych terenowych nie ma wcale i zostaje test laboratoryjny oraz własny pomiar.
• Opóźnienie. Dane obejmują 28 dni wstecz. Poprawka wdrożona wczoraj? W pełni zobaczysz ją po około czterech tygodniach.
• Tylko Chrome. Safari od wersji 26.2 (grudzień 2025) potrafi mierzyć LCP i INP, ale CrUX, PageSpeed Insights i Search Console nadal opierają się wyłącznie na danych z Chrome, więc jeśli duża część Twoich klientów korzysta z iPhone’ów, raport Google pokazuje tylko część obrazu. Pełniejszy obraz da własny pomiar RUM (Real User Monitoring), czyli zbieranie wskaźników z przeglądarek Twoich użytkowników.

Dane laboratoryjne (Lighthouse)

Dolna sekcja to jednorazowy test Lighthouse. Wersja mobilna symuluje średniej klasy telefon na sieci komórkowej, wersja desktopowa emuluje komputer z łączem przewodowym, a wynik 90–100 jest oceniany jako dobry, 50–89 jako wymagający poprawy, poniżej 50 jako słaby. Skacze o kilka punktów przy każdym teście, bo zależy od chwilowego obciążenia serwera, sieci i zasobów zewnętrznych, np. skryptów reklamowych, więc do oceny zmian biorę kilka pomiarów.

Wynik laboratoryjny przydaje się do diagnozy i do porównania „przed i po” w kontrolowanych warunkach. Do oceny, czy strona jest szybka dla klientów, się nie nadaje. Od 2025 roku Lighthouse (wersja 13) zastąpił dawne audyty tzw. insights, czyli zestawem wskazówek pogrupowanych według przyczyny, np. dotyczących elementu LCP czy zasobów blokujących renderowanie. Jeśli Twój zespół pracuje na starych zrzutach ekranu z listą audytów, nazwy pozycji mogą się nie zgadzać z obecnym raportem.

Jak czytam raport w 5 minut

1. Wybieram widok mobilny. Tam zwykle jest większość ruchu i gorsze wyniki.
2. Sprawdzam, czy dane terenowe dotyczą adresu, czy całej domeny.
3. Patrzę na trzy Core Web Vitals. Zapisuję, który jest czerwony lub pomarańczowy.
4. Dla LCP sprawdzam w części laboratoryjnej, jaki element jest LCP i jak rozkłada się jego czas (TTFB, opóźnienie i czas pobierania zasobu, opóźnienie renderowania).
5. Dopiero na końcu patrzę na wynik 0–100, wyłącznie jako punkt odniesienia do porównań po zmianach.

Raport dla pojedynczego adresu to tylko próbka. Obraz całej witryny daje raport „Podstawowe wskaźniki internetowe” w Search Console, który grupuje podobne adresy, a jak włączyć go do comiesięcznej rutyny, opisałem w artykule o Google Search Console i pięciu raportach do czytania co miesiąc.

Ile Core Web Vitals ważą w SEO?

To pytanie słyszę najczęściej. Stanowisko Google w dokumentacji Search Central jest jednoznaczne w obie strony. Z jednej strony: „Core Web Vitals są używane przez nasze systemy rankingowe” i Google zaleca osiągnięcie dobrych wyników. Z drugiej: dobre wyniki w raporcie Search Console lub w narzędziach zewnętrznych nie gwarantują pozycji na szczycie, a wyszukiwarka zawsze stara się pokazać najbardziej trafną treść, nawet jeśli doświadczenie na stronie jest słabsze.

Google dodaje, że przy wielu zapytaniach dostępnych jest dużo pomocnych treści i wtedy dobre doświadczenie na stronie może przyczynić się do sukcesu, co zarządom tłumaczę mniej więcej tak: szybkość nie wyciągnie słabej treści na pierwszą stronę, natomiast może przeważyć, gdy kilka stron odpowiada na zapytanie podobnie dobrze.

Co to znaczy dla budżetu? Nie finansowałbym optymalizacji szybkości z argumentem „wzrośniemy w Google”. Jeśli jedynym uzasadnieniem jest SEO, a treść i linki są słabsze niż u konkurencji, pieniądze lepiej wydać na treść. Szybkość broni się przede wszystkim konwersją i kosztem ruchu płatnego. Dlatego przy optymalizacji konwersji oceniam ją razem z ofertą i koszykiem, a nie jako osobny projekt.

Jak szybkość strony wpływa na Google Ads i Wynik Jakości?

Mitów jest tu sporo. Zacznę od tego, co Google pisze w pomocy Google Ads.

• Wynik Jakości (Quality Score) to narzędzie diagnostyczne. Do aukcji nie wchodzi. Składa się z trzech elementów: przewidywanego CTR, trafności reklamy i jakości strony docelowej, a każdy z nich dostaje ocenę „powyżej średniej”, „średnio” lub „poniżej średniej” w porównaniu z innymi reklamodawcami z ostatnich 90 dni.
• Ranking reklamy (Ad Rank) uwzględnia jakość reklamy i strony docelowej. Google ocenia m.in. przydatność i trafność strony oraz łatwość nawigacji. Według pomocy Google Ads reklamy wyższej jakości często prowadzą do niższego CPC.
• Szybkość jest wymieniona w zaleceniach z nazwy. W poradach dotyczących jakości strony docelowej Google pisze, że szybkość ładowania może zadecydować o tym, czy ktoś opuści stronę, czy kupi, i zaleca jej poprawę oraz dostosowanie strony do urządzeń mobilnych.

Czego Google nie mówi: nie ma oficjalnej tabeli „LCP 2,5 s = ocena powyżej średniej”, a jakość strony docelowej ocenia przede wszystkim trafność i użyteczność. Nie obiecuję więc klientom spadku CPC o konkretny procent po skróceniu LCP. To możliwy efekt uboczny. Nic więcej.

Główny mechanizm jest prostszy. W Google Ads płacisz za kliknięcie, także wtedy, gdy strona nie zdążyła się załadować, więc każda osoba, która kliknęła reklamę i zamknęła kartę przed wyświetleniem treści, to koszt bez żadnej szansy na sprzedaż. Pomoc Google Ads w opisie raportu stron docelowych przytacza tezę, że sekunda opóźnienia na mobile może obniżyć konwersje w handlu detalicznym nawet o 20%. To deklaracja Google bez opisanej tam metodologii, więc traktuję ją jako sygnał kierunku. Do budżetu bym jej nie wpisywał.

Od czego zacząć? W Google Ads otwórz raport „Strony docelowe” i posortuj adresy według kosztu, a pięć adresów z największym wydatkiem sprawdź w PageSpeed Insights jako pierwsze, bo tam każda poprawa konwersji pracuje na największej kwocie.

Szybkość strony a konwersja: co wiadomo, a co jest mitem

W sieci krąży wiele liczb typu „0,1 s szybciej = +7% sprzedaży”, tylko że większość z nich nie ma źródła albo pochodzi z badań sprzed dekady, przeprowadzonych na zupełnie innych stronach niż Twoja. Na czym w takim razie można się oprzeć? Widzę dwa źródła:

Badanie	Metoda	Wynik	Ograniczenia
Vodafone (web.dev, 2021)	test A/B: dwie wersje strony docelowej, ruch płatny podzielony po równo, różnice tylko techniczne	LCP lepszy o 31%, sprzedaż wyższa o 8%, stosunek leadów do wizyt +15%, koszyków do wizyt +11%	jedna firma, jeden kraj, jedna strona; publikacja Google
Deloitte „Milliseconds Make Millions” (dane z 2019 roku)	regresja na naturalnych wahaniach szybkości, 37 marek, 30 mln sesji, 4 tygodnie	poprawa szybkości mobilnej o 0,1 s skorelowana ze wzrostem konwersji o 8,4% w handlu detalicznym i 10,1% w turystyce	korelacja, a nie eksperyment; dane laboratoryjne Lighthouse; badanie zamówione przez Google; autorzy zastrzegają, że wyniki mogą nie odzwierciedlać całego internetu

Związek szybkości z konwersją jest dobrze udokumentowany, ale jego siła zależy od strony, branży i od tego, jak wolno było na starcie. Poprawa z 6 s do 3 s zwykle daje więcej niż z 2,4 s do 1,9 s, bo przy wolnej stronie traci się po drodze znacznie więcej osób, które w ogóle nie zobaczyły oferty i wróciły do wyników wyszukiwania. Dlatego w symulacji poniżej odwracam pytanie i zamiast przyjmować liczby z Deloitte, sprawdzam, jaki wzrost jest potrzebny, żeby inwestycja się zwróciła.

I jeszcze jedno. Niska konwersja często nie ma nic wspólnego z szybkością, więc jeśli sprzedaż spadła przy stabilnym ruchu, najpierw sprawdź ceny, dostępność towaru i działanie koszyka, a dopiero potem zamawiaj audyt wydajności. Kolejność takiej diagnozy opisałem w artykule o spadku konwersji sklepu mimo dobrego ruchu.

Przykład liczbowy (symulacja): ile jest warta poprawa LCP?

Weźmy średni sklep internetowy, którego właściciel dostał wycenę optymalizacji. Liczby są wymyślone na potrzeby symulacji, chodzi o metodę, którą możesz powtórzyć na własnych danych.

Założenia: sklep ma 60 000 sesji miesięcznie, współczynnik konwersji 1,5%, średnią wartość zamówienia 250 zł netto i marżę brutto 35%. LCP na mobile (75. percentyl) wynosi 4,2 s, cel to poniżej 2,5 s. Koszt optymalizacji to 15 000 zł jednorazowo (programista, zmiana motywu, obrazy, CDN) plus 500 zł miesięcznie na utrzymanie i monitoring, przy czym ruch i średnia wartość zamówienia się nie zmieniają. Sprawdzam trzy scenariusze wzrostu współczynnika konwersji: +2%, +5% i +8% względnie (czyli np. z 1,50% do 1,53%, 1,575% i 1,62%). Górny scenariusz odpowiada wynikowi testu Vodafone. Nie zakładam, że powtórzy się u każdego.

Pozycja	Stan obecny	+2% CR	+5% CR	+8% CR
Zamówienia miesięcznie	900	918	945	972
Przychód miesięcznie	225 000 zł	229 500 zł	236 250 zł	243 000 zł
Dodatkowy przychód	—	4 500 zł	11 250 zł	18 000 zł
Dodatkowy zysk brutto (35%)	—	1 575 zł	3 937,50 zł	6 300 zł
Zysk netto z poprawy po kosztach utrzymania	—	1 075 zł	3 437,50 zł	5 800 zł
Zwrot 15 000 zł	—	ok. 14 mies.	ok. 4,4 mies.	ok. 2,6 mies.
Wynik po 12 miesiącach	—	−2 100 zł	+26 250 zł	+54 600 zł

Próg opłacalności. Żeby inwestycja zwróciła się w 12 miesięcy, dodatkowy zysk brutto musi pokryć 1 250 zł miesięcznie (15 000 zł / 12) plus 500 zł utrzymania, czyli 1 750 zł. Przy zysku brutto 78 750 zł miesięcznie oznacza to wzrost współczynnika konwersji o ok. 2,2%. Tę liczbę stawiam obok wyceny od programisty i zadaję jedno pytanie: czy naprawdę spodziewasz się poprawy konwersji o więcej niż 2,2%?

Część płatna. Jeśli 25 000 z tych sesji pochodzi z Google Ads przy CPC 1,20 zł (koszt 30 000 zł), ROAS kampanii wynosi 3,13, a przy wzroście konwersji o 5% rośnie do 3,28 bez zmiany stawek i bez dokładania choćby złotówki do budżetu. W symulacji nie zakładam spadku CPC, bo Google nie podaje przelicznika szybkości na Wynik Jakości, a jeśli CPC jednak spadnie, będzie to zysk ponad plan.

Co z tego wynika?

• Przy małym sklepie (np. 10 000 sesji) ta sama optymalizacja za 15 000 zł potrzebuje sześć razy większej poprawy, żeby się zwrócić. Szybkość skaluje się z ruchem.
• Najtańsze poprawki (obrazy, atrybuty, kolejność ładowania) często dają większość efektu, dlatego zanim zamówisz nowy motyw, sprawdź, ile da tydzień pracy programisty nad istniejącym, bo w audytach często widzę, że duża część problemu siedzi właśnie w tych drobiazgach.
• Scenariusz +2% jest prawie na granicy błędu pomiaru. Taki efekt trudno odróżnić od sezonowości bez testu.

Co naprawić najpierw w WordPressie i sklepie?

Poprawki dzielę według wskaźnika, bo każdy z nich ma inne przyczyny i innego „właściciela” w zespole. LCP to zwykle serwer, obrazy i motyw. INP to JavaScript, w tym skrypty marketingowe. CLS to szablon i elementy wstawiane dynamicznie.

Wskaźnik	Próg „dobrze”	Typowa przyczyna w WordPressie i sklepie	Poprawka
LCP	≤ 2,5 s	wolny hosting i brak cache strony (wysoki TTFB); duże zdjęcie główne lub slider; zdjęcie LCP ładowane leniwie (loading="lazy"); obraz ustawiony jako tło w CSS	cache strony i CDN; zdjęcie w formacie WebP lub AVIF w rozmiarze dopasowanym do ekranu; usunięcie leniwego ładowania z elementu LCP; fetchpriority="high" na zdjęciu głównym; rezygnacja ze slidera na rzecz jednego zdjęcia
INP	≤ 200 ms	długie zadania JavaScript (powyżej ok. 50 ms); ciężkie wtyczki, kreatory stron, czaty, widżety opinii, nadmiar tagów marketingowych; bardzo duży DOM	przegląd i usunięcie zbędnych skryptów; opóźnienie ładowania widżetów do interakcji; podział długich zadań; ograniczenie liczby elementów na stronie (np. filtry i menu)
CLS	≤ 0,1	obrazy bez width i height; banery cookies, paski promocyjne i reklamy wstawiane nad treścią; podmiana fontów	wymiary lub aspect-ratio dla obrazów; zarezerwowane miejsce na banery i osadzenia; baner zgód jako nakładka, a nie element przesuwający treść; preload fontów i font-display

Dwie liczby z Web Almanac 2025 pokazują, jak częste są podstawowe błędy: ok. 16–17% stron ładuje leniwie obraz, który jest elementem LCP, a ok. 62% stron mobilnych ma co najmniej jeden obraz bez określonych wymiarów. To poprawki na godziny.

Kolejność, którą stosuję

1. Szablony przed pojedynczymi adresami. W sklepie liczą się trzy szablony: karta produktu, kategoria i strona główna lub strona docelowa kampanii. Poprawka w szablonie działa na tysiące adresów.
2. LCP na szablonie z największym kosztem reklam. Według web.dev większość czasu LCP powinna przypadać na pobranie dokumentu HTML i zasobu LCP, a opóźnienia przed pobraniem i przed renderowaniem powinny być małe. Jeśli rozkład w raporcie wygląda inaczej, wiesz, gdzie szukać.
3. Skrypty zewnętrzne. Czat, widżety, piksele i stare tagi często psują INP, a część z nich siedzi w Google Tag Managerze od lat i nikt już nie pamięta, kto je dodał ani po co. Procedurę przeglądu opisałem w artykule o audycie Google Tag Managera w 30 minut.
4. CLS na końcu, bo zwykle jest najrzadszym problemem, ale baner zgód i pasek promocji to dwie pierwsze rzeczy do sprawdzenia.

WordPress od wersji 6.8 domyślnie stosuje tzw. speculative loading: pobiera z wyprzedzeniem stronę, gdy użytkownik zaczyna klikać w link. Przejścia między stronami przyspieszają. Pierwsze wejście z reklamy, które zwykle decyduje o wyniku kampanii, zostaje bez zmian. Wtyczka „optymalizująca wszystko” też nie zastąpi decyzji, które skrypty są potrzebne.

Jak zmierzyć, czy optymalizacja się opłaciła?

Najczęstszy błąd to ocena po wyniku PageSpeed: „było 38, jest 72, sukces”. Tyle że wynik laboratoryjny nie jest celem biznesowym. Efekt mierzę na trzech poziomach:

• Wskaźniki techniczne: dane terenowe w PageSpeed Insights i raport Search Console. Po wdrożeniu poprawek możesz uruchomić weryfikację w Search Console, która monitoruje grupę adresów przez 28 dni.
• Zachowanie: w GA4 współczynnik konwersji i odsetek sesji z zaangażowaniem dla ruchu mobilnego, w podziale na szablony stron, porównywane w tych samych tygodniach rok do roku albo jako segment poprawiony kontra niepoprawiony.
• Pieniądze: przychód i zysk na sesję z ruchu płatnego, a w Google Ads koszt konwersji dla stron docelowych, które zmieniłeś.

Najmocniejszy dowód daje test, jak w przypadku Vodafone: część ruchu na wersję poprawioną, część na starą, bez innych różnic. Gdy test nie jest możliwy, wdrażaj zmiany etapami, na jednym szablonie naraz, i zapisuj daty wdrożeń, bo bez tego po trzech miesiącach nikt w firmie nie odróżni efektu szybkości od sezonu, promocji i zmian w kampaniach. Wskaźniki techniczne i biznesowe dobrze mieć w jednym raporcie dla zarządu, o czym piszę w artykule o dashboardzie dla zarządu.

Pierwszy miesiąc pracy nad szybkością

Tydzień 1: stan wyjściowy. Raport „Strony docelowe” w Google Ads posortowany po koszcie, PageSpeed Insights (mobile) dla 5 najdroższych adresów i trzech głównych szablonów, raport Search Console z grupami adresów. Zapisz wartości LCP, INP i CLS z danych terenowych oraz współczynnik konwersji mobile z GA4.

Tydzień 2: szybkie poprawki. Usunięcie leniwego ładowania z elementu LCP, kompresja i wymiary obrazów, fetchpriority dla zdjęcia głównego, rezerwacja miejsca na baner zgód. Przegląd wtyczek i tagów: lista skryptów z właścicielem i celem.

Tydzień 3: decyzje kosztowne. Wycena zmian w hostingu, cache, motywie lub szablonie sklepu, a potem porównanie tej wyceny z progiem opłacalności z symulacji, czyli odpowiedź na pytanie, ile procent wzrostu konwersji potrzebujesz, żeby wydatek się zwrócił.

Tydzień 4: pomiar. Uruchomienie weryfikacji w Search Console, adnotacje z datami wdrożeń, segmenty w GA4. Pierwsza ocena danych terenowych po 28 dniach od ostatniej zmiany.

Więcej o mierzeniu i porządkowaniu danych znajdziesz w kategorii Analityka marketingowa.

Mini-słownik pojęć

• LCP (Largest Contentful Paint) — czas do wyświetlenia największego elementu treści w widocznej części strony.
• INP (Interaction to Next Paint) — opóźnienie między interakcją użytkownika a widoczną reakcją strony; od 12 marca 2024 roku zastępuje FID.
• CLS (Cumulative Layout Shift) — miara nieoczekiwanych przesunięć elementów strony podczas jej używania.
• CrUX (Chrome User Experience Report) — zbiór danych o doświadczeniach realnych użytkowników Chrome, źródło danych terenowych.
• Lighthouse — narzędzie do testów laboratoryjnych, z którego pochodzi wynik 0–100 w PageSpeed Insights.
• 75. percentyl — wartość, poniżej której mieści się 75% wizyt; według niej Google ocenia wskaźniki.
• TTFB (Time to First Byte) — czas do otrzymania pierwszego bajtu odpowiedzi serwera; wskaźnik pomocniczy.
• Jakość strony docelowej — element Wyniku Jakości w Google Ads oceniający trafność i użyteczność strony po kliknięciu reklamy.

Źródła

• web.dev: Web Vitals
• web.dev: How the Core Web Vitals metrics thresholds were defined
• web.dev: INP becomes a Core Web Vital on March 12
• web.dev: Optimize Largest Contentful Paint, Optimize INP, Optimize CLS, Time to First Byte
• web.dev: Vodafone: A 31% improvement in LCP increased sales by 8%
• Google Search Central: Understanding page experience in Google Search results
• Search Console Help: Core Web Vitals report
• Google for Developers: About PageSpeed Insights
• Chrome for Developers: Lighthouse is moving to performance insight audits
• Google Ads Help: About Quality Score
• Google Ads Help: About Ad Rank
• Google Ads Help: Wskazówki poprawy Wyniku Jakości i strony docelowej
• Google Ads Help: Evaluate the performance of your landing pages
• HTTP Archive: Web Almanac 2025 — Performance
• Deloitte / Google: Milliseconds Make Millions (PDF)
• DebugBear: Firefox and Safari now support two Core Web Vitals metrics
• Search Engine Journal: Safari update enables tracking two Core Web Vitals metrics
• Make WordPress Core: Speculative loading in WordPress 6.8