--- title: "Core Web Vitals: czym są LCP, INP i CLS" description: "Core Web Vitals 2026: czym są LCP, INP i CLS, aktualne progi, narzędzia pomiarowe i strategie optymalizacji." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/core-web-vitals-czym-sa-lcp-inp-i-cls" category: "SEO & GEO" topic: "Techniczne SEO" updated: "2026-10-28T13:36:30.570Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Core Web Vitals: czym są LCP, INP i CLS Core Web Vitals to trzy zdefiniowane przez Google wskaźniki, które mierzą rzeczywiste doświadczenie użytkowników strony internetowej: Largest Contentful Paint (LCP) dla postrzeganej szybkości ładowania, Interaction to Next Paint (INP) dla interaktywności i Cumulative Layout Shift (CLS) dla stabilności wizualnej. Uznaje się je za spełnione, gdy 75. percentyl odsłon strony wynosi najwyżej 2,5 sekundy dla LCP, najwyżej 200 milisekund dla INP i najwyżej 0,1 dla CLS. ## W skrócie - Progi „good” na poziomie 75. percentyla: LCP 2,5 s lub mniej, INP 200 ms lub mniej, CLS 0,1 lub mniej, osobno dla urządzeń mobilnych i desktopu. - INP 12 marca 2024 roku całkowicie zastąpił FID jako Core Web Vital i jest znacznie bardziej rygorystyczny, ponieważ ocenia wszystkie interakcje w trakcie sesji. - Tylko 43 procent witryn spełnia wszystkie trzy Core Web Vitals na urządzeniach mobilnych (na desktopie 54 procent), co daje realną szansę na wyróżnienie się. - LCP zależy najczęściej od obrazu (73,3 procent stron mobilnych): nigdy nie stosuj lazy loadingu dla obrazu LCP, tylko nadaj mu priorytet za pomocą fetchpriority=high. - CWV to czynnik rozstrzygający przy remisie, a nie główny czynnik rankingowy: Google z nich korzysta, ale podkreśla, że nie ma jednego sygnału, a trafność ma pierwszeństwo. - Do oceny liczą się wyłącznie dane terenowe (Chrome UX Report, 75. percentyl), a nie wartości laboratoryjne z Lighthouse. - W Next.js next/image, next/font i minimalna ilość JavaScriptu po stronie klienta bezpośrednio przekładają się na LCP, CLS i INP; Edge/CDN i HTTP/3 obniżają TTFB. Core Web Vitals to wskaźniki, które łączą [techniczne SEO z rzeczywistym doświadczeniem użytkownika](https://blckalpaca.at/pl/uslugi/agencja-seo). Przekładają abstrakcyjne pojęcia wydajności na trzy mierzalne wartości, które Google zbiera bezpośrednio z przeglądarek prawdziwych odwiedzających. Ten artykuł szczegółowo wyjaśnia LCP, INP i CLS, określa ich realną wagę jako sygnału rankingowego i pokazuje, jak celowo poprawiać te wskaźniki w nowoczesnym stacku złożonym z Next.js, Edge/CDN i HTTP/3. Nacisk położony jest na korzystanie mobilne, przez które na przykład w Austrii odbywa się większość dostępów do internetu. ## Dlaczego Core Web Vitals mają znaczenie dla technicznego SEO Core Web Vitals to ta część wrażeń z korzystania ze strony, którą Google promuje i wykorzystuje w systemach rankingowych. W oficjalnej dokumentacji Google wyjaśnia, że nie istnieje jeden sygnał dotyczący wrażeń z korzystania ze strony, ale Core Web Vitals są wykorzystywane przez systemy rankingowe, a dobre wrażenia z korzystania ze strony mogą przyczynić się do sukcesu w wyszukiwarce przy zapytaniach, dla których istnieje dużo pomocnych treści ([Google Search Central](https://developers.google.com/search/docs/appearance/page-experience)). Te trzy wskaźniki nie są więc głównym czynnikiem rankingowym, ale solidnym sygnałem jakości, który przesądza o wyniku zwłaszcza wtedy, gdy rywalizuje ze sobą kilka merytorycznie równorzędnych wyników. Praktyka pokazuje, jak wiele jest jeszcze do poprawy. Według Web Almanac 2024 tylko 43 procent witryn spełnia wszystkie trzy Core Web Vitals na urządzeniach mobilnych, a na desktopie 54 procent ([HTTP Archive, Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). Jeśli zadbasz o to porządnie, wyróżnisz się na tle ponad połowy mobilnego internetu. Dla Austrii ma to szczególne znaczenie, ponieważ korzystanie z internetu jest tam silnie mobilne: w czerwcu 2024 roku 81,5 procent dostępów do internetu odbywało się z urządzeń mobilnych. Duża część z nich przypadała na aplikacje. Przez mobilne strony WWW przechodziło 31,6 procent wszystkich dostępów ([Statista, Österreichische Webanalyse](https://de.statista.com/statistik/daten/studie/442514/umfrage/anteil-mobiler-geraete-an-der-internet-nutzung-in-oesterreich/)). W przypadku Core Web Vitals liczy się tylko ruch z przeglądarek, a i on jest w dużej mierze mobilny. ## Trzy wskaźniki i ich progi Google dzieli wyniki na good, needs improvement i poor i zawsze mierzy je na poziomie 75. percentyla odsłon, osobno dla urządzeń mobilnych i desktopu. Oficjalne progi „good” to: LCP 2,5 sekundy lub mniej, INP 200 milisekund lub mniej i CLS 0,1 lub mniej ([web.dev](https://web.dev/articles/vitals)). W praktyce 75. percentyl oznacza, że trzy na cztery odsłony muszą osiągnąć próg, a najgorsza ćwiartka się nie liczy. Strona spełnia dany Core Web Vital dopiero wtedy, gdy jest niezawodnie szybka, a nie tylko w idealnych warunkach. - **Largest Contentful Paint (LCP):** mierzy, kiedy zostaje wyrenderowany największy widoczny element w viewporcie. Jest wskaźnikiem zastępczym dla odczuwalnej szybkości ładowania. - **Interaction to Next Paint (INP):** mierzy opóźnienie między interakcją użytkownika a następną widoczną aktualizacją obrazu, w trakcie całej sesji. - **Cumulative Layout Shift (CLS):** mierzy największą serię nieoczekiwanych przesunięć układu w całym cyklu życia strony, czyli to, jak stabilna pozostaje treść ([web.dev](https://web.dev/articles/cls)). Na poziomie pojedynczych wskaźników obraz w segmencie mobilnym jest niejednolity. W 2024 roku 59 procent stron mobilnych osiągnęło dobry wynik LCP, 74 procent dobry wynik INP, a 79 procent dobry wynik CLS ([Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). Na urządzeniach mobilnych LCP jest więc tym z trzech wskaźników, którego progu strony najczęściej nie spełniają. ## LCP w szczegółach: optymalizacja postrzeganej szybkości ładowania W przypadku LCP prawie zawsze chodzi o obraz. W przypadku 73,3 procent stron mobilnych elementem LCP jest obraz ([Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). [Obraz LCP jest zatem najważniejszą pojedynczą dźwignią optymalizacji](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/largest-contentful-paint-lcp-optymalizacja-czasu-ladowania). Typowe przyczyny wolnego LCP leżą w trzech obszarach: to wysoki czas odpowiedzi serwera (TTFB), zasoby blokujące renderowanie, takie jak CSS i JavaScript na ścieżce krytycznej, oraz sam czas ładowania zasobu LCP. Najskuteczniejsze środki zaradcze działają właśnie w tych miejscach: - **Steruj priorytetem:** oznacz obraz LCP atrybutem `fetchpriority="high"` i w razie potrzeby pobierz go wcześnie za pomocą ``, aby przeglądarka nie ustawiała go w kolejce za mniej ważnymi zasobami. - **Nigdy nie ładuj obrazu LCP leniwie:** to rozpowszechniony antywzorzec. Leniwie ładuje swój obraz LCP 16 procent stron mobilnych, a 9,5 procent robi to nawet za pomocą natywnego `loading="lazy"` ([Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). Element LCP znajduje się [above the fold](https://blckalpaca.at/pl/slownik/above-the-fold) i musi być ładowany od razu (eager). - **Używaj nowoczesnych formatów obrazów:** AVIF i WebP wyraźnie zmniejszają rozmiar plików w porównaniu z JPEG, a tym samym skracają czas ładowania zasobów. - **Obniż TTFB dzięki Edge/CDN:** dostarczanie z węzła CDN blisko użytkownika i nowoczesne protokoły transportowe skracają czas odpowiedzi serwera, zanim w ogóle zostanie wyrenderowany choćby jeden piksel. ## INP w szczegółach: zapewnienie interaktywności INP 12 marca 2024 roku zastąpił FID jako Core Web Vital i jednocześnie zaczął być wyświetlany w Search Console zamiast FID ([web.dev](https://web.dev/blog/inp-cwv-march-12)). Ta zmiana nie była kosmetyczna: FID mierzył tylko opóźnienie pierwszej interakcji, a INP ocenia wszystkie interakcje w trakcie sesji i jest znacznie bardziej rygorystyczny. Widać to w liczbach: przy FID w 2024 roku 48 procent stron mobilnych miałoby jeszcze dobre CWV, przy INP jest ich tylko 43 procent ([Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). INP składa się z trzech faz: input delay (czas oczekiwania, aż handler zdarzenia będzie mógł się uruchomić), processing time (wykonanie handlera) i presentation delay (czas do następnej klatki). Zdecydowanie najczęstszą przyczyną słabego INP jest blokujący JavaScript, który zajmuje wątek główny i powoduje kumulację interakcji. Wynikają z tego trzy dźwignie, które szczegółowo omawia artykuł [Optymalizacja INP](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/interaction-to-next-paint-inp-jak-mierzyc-i-poprawic-interaktywnosc): - **Dziel długie zadania (task splitting):** rozbijaj duże zadania JavaScript na mniejsze części i w międzyczasie oddawaj kontrolę przeglądarce, na przykład za pomocą `scheduler.yield()` lub odroczenia, aby działania użytkownika nie musiały czekać. - **Ogranicz częstotliwość zdarzeń (debouncing):** często wywoływane handlery, takie jak zdarzenia przewijania czy wpisywania, uruchamiaj rzadziej, aby kosztowna logika nie działała przy każdym pikselu. - **Wydzielaj pracę (Web Workers):** przenieś intensywne obliczeniowo zadania niezwiązane z interfejsem do Web Workera, aby wątek główny pozostał wolny. ## CLS w szczegółach: utrzymanie stabilności wizualnej CLS ocenia [stabilność wizualną strony](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/cumulative-layout-shift-cls-stabilnosc-wizualna): karane są treści, które po pierwszym wyrenderowaniu nadal przeskakują. Przyczyny są dobrze znane: obrazy i iframe'y bez stałych wymiarów, dynamicznie doładowywane treści nad istniejącą zawartością, późno ładujące się fonty internetowe powodujące przeskok układu oraz powierzchnie reklamowe bez zarezerwowanego miejsca. Środki zaradcze mają bez wyjątku charakter zapobiegawczy: - **Określ wymiary:** dla obrazów i filmów zawsze ustawiaj `width` i `height` lub `aspect-ratio`, aby przeglądarka zarezerwowała miejsce przed załadowaniem. - **Rezerwuj miejsce na elementy dynamiczne:** dla reklam, osadzeń i doładowywanych banerów przewiduj w układzie stałe sloty, zamiast wstawiać je w przepływ treści. - **Złagodź zmianę fontu:** dzięki `font-display` i wstępnie ładowanym fontom ogranicz przelewanie się tekstu przy podmianie fontu. Przy 79 procentach dobrych wyników na urządzeniach mobilnych CLS jest najlepiej opanowanym z trzech wskaźników ([Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). Wynika to z tego, że środki zaradcze są technicznie proste i wystarczy wdrożyć je raz. ## Dobre praktyki: CWV w stacku Next.js i Edge W Next.js wiele optymalizacji CWV jest już wbudowanych w elementy frameworka, ale trzeba z nich świadomie korzystać. `next/image` wymusza podanie wymiarów i dostarcza nowoczesne formaty. Dla najważniejszego obrazu `fetchPriority="high"` podnosi priorytet ładowania, co bezpośrednio przekłada się na LCP. Do Next.js 14 atrybut `priority` ustawiał tę wartość automatycznie. Od Next.js 15 `priority` odpowiada już tylko za preload i ładowanie eager, a `fetchPriority="high"` musisz ustawić samodzielnie ([Next.js, Pull Request #67351](https://github.com/vercel/next.js/pull/67351)). Od Next.js 16 `priority` jest oznaczony jako przestarzały na rzecz `preload`, a [dokumentacja Next.js](https://nextjs.org/docs/app/api-reference/components/image) w większości przypadków zaleca `fetchPriority="high"` lub `loading="eager"`. `next/font` ładuje fonty lokalnie i z własnego hostingu, dzięki czemu unika przeskoku układu spowodowanego fontami, który pogarsza CLS. Streaming przez SSR i React Server Components zmniejsza ilość JavaScriptu wysyłanego do klienta, co łagodzi główną przyczynę słabego INP. Najbardziej krytycznym miejscem w App Routerze jest hydratacja. Każdy interaktywny komponent kliencki musi zostać zhydratowany w przeglądarce, a zbyt dużo JavaScriptu po stronie klienta generuje właśnie te długie zadania, które podbijają INP. W praktyce oznacza to: zostawiać jak najwięcej jako Server Components, ograniczać interaktywność do małych wysp klienckich i celowo doładowywać ciężkie komponenty później. Infrastruktura techniczna wzmacnia te efekty. W sieci 54 procent z ponad 1,3 mld żądań jest już dostarczanych przez CDN, a HTTP/3 jest wprawdzie dostępny na około 30 procentach stron, ale faktycznie używany tylko w przypadku od 7 do 9 procent pierwszych odsłon ([Web Almanac 2024, HTTP](https://almanac.httparchive.org/en/2024/http)). Edge caching i HTTP/3 obniżają TTFB, a tym samym punkt startowy LCP, bez żadnych zmian w kodzie frontendu. Szybsze, dobrze cache'owane dostarczanie stron korzystnie wpływa też na crawl budget i na crawlery [AI](https://blckalpaca.at/pl/slownik/ai), które pobierają zasoby sieci w coraz większym zakresie: ruch Googlebota wzrósł od maja 2024 do maja 2025 roku o 96 procent i stanowi około 50 procent ruchu crawlerów, a udział GPTBota wzrósł z 2,2 do 7,7 procent ([Cloudflare](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/)). Wydajna, przewidywalnie dostarczana strona jest więc atutem także w [Generative Engine Optimization (GEO)](https://blckalpaca.at/pl/uslugi/geo). ## Najczęstsze błędy w optymalizacji CWV - **Traktowanie wyników laboratoryjnych jak rzeczywistości:** zielony wynik Lighthouse w laboratorium nie mówi nic o tym, co ocenia Google. Miarodajny jest 75. percentyl prawdziwych użytkowników. - **Lazy loading obrazu LCP:** najczęstszy strzał w stopę przy LCP. Element above the fold nigdy nie może być ładowany z opóźnieniem. - **Mylenie INP z FID:** jeśli nadal optymalizujesz pod FID, mierzysz niewłaściwą wielkość. Od marca 2024 roku INP jest jedynym istotnym wskaźnikiem interaktywności. - **Sprawdzanie CLS tylko na początku strony:** przeskoki układu często pojawiają się dopiero podczas przewijania lub przy późno wstawianych elementach. CLS jest mierzony przez cały cykl życia strony. - **Testowanie tylko na desktopie:** Google ocenia urządzenia mobilne i desktop osobno, a na urządzeniach mobilnych wszystkie trzy progi spełnia wyraźnie mniej witryn (43 wobec 54 procent, [Web Almanac 2024](https://almanac.httparchive.org/en/2024/performance)). Testy trzeba przeprowadzać na urządzeniach mobilnych z ograniczoną wydajnością CPU i sieci. ## Pomiar: dane laboratoryjne a terenowe i właściwe narzędzia Najważniejsze rozróżnienie to podział na dane laboratoryjne i terenowe. Dane laboratoryjne (lab) powstają w kontrolowanym środowisku, na przykład w Lighthouse, i nadają się do debugowania oraz powtarzalnych porównań. Nie wpływają jednak na ranking. Dane terenowe (field) pochodzą od prawdziwych użytkowników i są analizowane na poziomie 75. percentyla ([web.dev](https://web.dev/articles/vitals)). Tylko te dane od rzeczywistych użytkowników liczą się w ocenie. - **Chrome UX Report (CrUX):** oficjalne źródło danych terenowych, agregowanych od rzeczywistych użytkowników Chrome. Podstawa raportu w Search Console i PageSpeed Insights. - **PageSpeed Insights:** łączy dane terenowe z CrUX u góry z laboratoryjnym przebiegiem Lighthouse poniżej. Idealne narzędzie, by zobaczyć obok siebie rzeczywisty stan i techniczną przyczynę. - **Raport CWV w Search Console:** grupuje adresy URL na podstawie danych terenowych w kategoriach good, needs improvement i poor oraz pokazuje zmiany w czasie dla całej usługi. - **RUM i web-vitals.js:** własny pomiar na prawdziwych użytkownikach w kodzie, na przykład za pomocą biblioteki web-vitals.js, dostarcza ciągłych danych terenowych i szczegółowej diagnostyki, także dla narzędzi takich jak DebugBear. Jeśli konsekwentnie oddzielasz dane laboratoryjne od terenowych, unikasz najczęstszego błędu interpretacyjnego: uznania dobrego wyniku laboratoryjnego za spełniony Core Web Vital. ## CWV jako sygnał rankingowy i uzasadnienie biznesowe Realistyczne oczekiwanie brzmi: Core Web Vitals nie zastępują ani trafności, ani wartościowych treści. Google wyraźnie zaznacza, że nie istnieje jeden sygnał i że zawsze chce pokazywać najtrafniejszą odpowiedź, nawet przy nieoptymalnych wrażeniach z korzystania ze strony, ale dobre wrażenia z korzystania ze strony mogą przesądzić o wyniku przy zapytaniach, dla których istnieje dużo pomocnych treści ([Google Search Central](https://developers.google.com/search/docs/appearance/page-experience)). CWV działają więc jako wzmacniacz i czynnik rozstrzygający, a nie jako droga na skróty, która pozwala ominąć słabe treści. Silniejszą dźwignią jest często konwersja. Udokumentowane przez Google case study redBus pokazuje, że celowa optymalizacja INP zwiększyła sprzedaż o 7 procent, a sam INP poprawił się o 72 procent, m.in. dzięki debouncingowi handlerów przewijania i ograniczeniu zapytań do [API](https://blckalpaca.at/pl/slownik/api) ([web.dev, redBus](https://web.dev/case-studies/redbus-inp)). Te liczby pochodzą z przypadku międzynarodowego, ale mechanizm da się przenieść: szybsze interakcje zmniejszają liczbę porzuceń i zwiększają liczbę finalizowanych transakcji. W austriackim kontekście, gdzie większość dostępów do internetu odbywa się z urządzeń mobilnych ([Statista](https://de.statista.com/statistik/daten/studie/442514/umfrage/anteil-mobiler-geraete-an-der-internet-nutzung-in-oesterreich/)), każda poprawa INP lub LCP na urządzeniach mobilnych bezpośrednio dotyczy dużej części odwiedzających. Uzasadnienie biznesowe dla CWV to więc nie tyle argument [SEO](https://blckalpaca.at/pl/slownik/seo), ile argument sprzedażowy z efektem ubocznym dla SEO. ## Dalsza lektura Core Web Vitals działają najskuteczniej, gdy są osadzone w całym technicznym stacku SEO. LCP zależy od TTFB, a więc od cache'owania na poziomie Edge/CDN i HTTP/3, INP od strategii JavaScriptu i renderowania, a wszystkie trzy korzystają na przejrzystej architekturze Next.js z minimalną ilością JavaScriptu po stronie klienta. Inwestując w to, poprawiasz jednocześnie dostarczanie stron klasycznym crawlerom i crawlerom AI, a tym samym widoczność w GEO. Temat możesz pogłębić w artykułach o [SEO dla JavaScriptu i renderowaniu](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/javascript-seo-renderowanie-i-indeksowanie), [HTTP/3 i infrastrukturze wydajności](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/http3-i-infrastruktura-wydajnosci-dla-seo), [Edge SEO na poziomie CDN](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/edge-seo-optymalizacja-na-poziomie-cdn-z-cloudflare-workers), [CDN i lokalizacji serwera](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/miedzynarodowe-seo-programmatic-seo/cdn-i-lokalizacja-serwera-a-seo-wydajnosc-miedzynarodowa) oraz o [architekturze SEO w Next.js](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/architektura-seo-w-nextjs-15-ssr-ppr-i-server-components). ## Dane i statystyki - INP od 12 marca 2024 roku zastępuje FID jako Core Web Vital i jednocześnie zaczął być wyświetlany w Search Console zamiast FID. — [web.dev (Google / zespół Chrome) (2024)](https://web.dev/blog/inp-cwv-march-12) - Progi „good” (75. percentyl, osobno dla urządzeń mobilnych i desktopu): LCP 2,5 s lub mniej, INP 200 ms lub mniej, CLS 0,1 lub mniej. — [web.dev / Google Web Vitals (2024)](https://web.dev/articles/vitals) - Nie istnieje jeden sygnał dotyczący wrażeń z korzystania ze strony; Core Web Vitals są wykorzystywane przez systemy rankingowe, a dobre wrażenia z korzystania ze strony mogą przyczynić się do sukcesu w wyszukiwarce przy zapytaniach, dla których istnieje dużo pomocnych treści. — [Google Search Central - Understanding page experience in Google Search results (2025)](https://developers.google.com/search/docs/appearance/page-experience) - 43% witryn spełnia wszystkie Core Web Vitals na urządzeniach mobilnych (desktop: 54%); przy FID byłoby to jeszcze 48% na urządzeniach mobilnych. — [HTTP Archive - Web Almanac 2024, Performance (2024)](https://almanac.httparchive.org/en/2024/performance) - Wyniki „good” na urządzeniach mobilnych w 2024 roku: LCP 59%, INP 74%, CLS 79%. — [HTTP Archive - Web Almanac 2024, Performance (2024)](https://almanac.httparchive.org/en/2024/performance) - 73,3% stron mobilnych ma obraz jako element LCP; 16% ładuje swój obraz LCP leniwie (9,5% za pomocą natywnego loading=lazy). — [HTTP Archive - Web Almanac 2024, Performance (2024)](https://almanac.httparchive.org/en/2024/performance) - +7% sprzedaży po optymalizacji INP w redBus; sam INP poprawiony o 72% (m.in. debouncing handlerów przewijania, mniej zapytań fetch). — [Case study web.dev (Google) - redBus (2023)](https://web.dev/case-studies/redbus-inp) - 54% z ponad 1,3 mld żądań jest dostarczanych przez CDN; HTTP/3 jest dostępny na ok. 30% stron, ale faktycznie używany tylko przy od 7 do 9% pierwszych odsłon. — [HTTP Archive - Web Almanac 2024, HTTP (2024)](https://almanac.httparchive.org/en/2024/http) - Googlebot +96% r/r (od maja 2024 do maja 2025) przy ok. 50% udziału wśród crawlerów; GPTBot wzrósł z 2,2% do 7,7% (+305% żądań). — [Cloudflare Blog - From Googlebot to GPTBot: who's crawling your site in 2025 (2025)](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) - W czerwcu 2024 roku 81,5% dostępów do internetu w Austrii odbywało się z urządzeń mobilnych (31,6% przez mobilne strony WWW, 49,9% przez aplikacje). — [Statista, badanie 442514 (źródło: Österreichische Webanalyse / OEWA) (2024)](https://de.statista.com/statistik/daten/studie/442514/umfrage/anteil-mobiler-geraete-an-der-internet-nutzung-in-oesterreich/) ## Najczęściej zadawane pytania ### Jakie wartości LCP, INP i CLS są uznawane za dobre? Strona spełnia Core Web Vitals, gdy 75. percentyl odsłon osiąga następujące wartości „good”: LCP 2,5 sekundy lub mniej, INP 200 milisekund lub mniej i CLS 0,1 lub mniej. Pomiar odbywa się osobno dla urządzeń mobilnych i desktopu. Wartości pochodzą bezpośrednio od Google, z serwisu web.dev. ### Który wskaźnik Core Web Vitals został zastąpiony przez INP? INP (Interaction to Next Paint) 12 marca 2024 roku zastąpił FID (First Input Delay) jako Core Web Vital i jednocześnie zaczął być wyświetlany w Google Search Console zamiast FID. INP jest bardziej rygorystyczny, ponieważ ocenia wszystkie interakcje w trakcie sesji, a nie tylko pierwszą. ### Czy Core Web Vitals są czynnikiem rankingowym? Tak, ale nie pojedynczym głównym czynnikiem. Google wykorzystuje Core Web Vitals w swoich systemach rankingowych, ale podkreśla, że nie istnieje jeden sygnał dotyczący wrażeń z korzystania ze strony, a trafność ma pierwszeństwo. CWV działają przede wszystkim jako czynnik rozstrzygający, gdy kilka wyników jest merytorycznie równorzędnych. ### Czym różnią się dane laboratoryjne od terenowych w Core Web Vitals? Dane laboratoryjne (np. z Lighthouse) powstają w kontrolowanym środowisku testowym i nadają się do debugowania, ale nie wpływają na ranking. Dane terenowe pochodzą od prawdziwych użytkowników, są agregowane w Chrome UX Report na poziomie 75. percentyla i tylko one decydują o ocenie. ### Jak najskuteczniej poprawić LCP? Ponieważ w przypadku 73,3 procent stron mobilnych elementem LCP jest obraz, to właśnie obraz LCP jest najważniejszą dźwignią: nigdy nie stosuj dla niego lazy loadingu, nadaj mu priorytet za pomocą fetchpriority=high, używaj nowoczesnych formatów, takich jak AVIF/WebP, i dostarczaj go przez Edge/CDN z niskim TTFB. ### Które narzędzia poprawnie mierzą Core Web Vitals? Dane terenowe istotne dla rankingu zapewniają Chrome UX Report, raport Core Web Vitals w Search Console i PageSpeed Insights (górna część). Do diagnozy nadają się Lighthouse, DebugBear oraz własny pomiar na prawdziwych użytkownikach za pomocą web-vitals.js. Kluczowe jest, by nie mylić danych laboratoryjnych z terenowymi. ### Dlaczego Core Web Vitals są szczególnie ważne w Austrii? Korzystanie z internetu jest tam w dużej mierze mobilne: w czerwcu 2024 roku 81,5 procent dostępów do internetu w Austrii odbywało się z urządzeń mobilnych. Duża część z nich przypadała na aplikacje, których Core Web Vitals nie dotyczą. Jednak także w przeglądarce duża część ruchu pochodzi z urządzeń mobilnych. Ponieważ tylko 43 procent stron mobilnych spełnia wszystkie Core Web Vitals, wydajność mobilna jest realną przewagą konkurencyjną i bezpośrednio wpływa na konwersję i sprzedaż. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/core-web-vitals-czym-sa-lcp-inp-i-cls). Systemy AI mogą wykorzystywać te treści z podaniem źródła.