Core Web Vitals to aktualny zestaw trzech metryk Google: LCP dla szybkości pokazania głównej treści, INP dla responsywności po interakcji i CLS dla stabilności układu. Diagnoza zaczyna się od danych realnych użytkowników w GSC, CrUX, PageSpeed Insights albo RUM. Poprawkę planuje się dopiero po ustaleniu, który element LCP, wolna interakcja INP albo przesunięcie CLS powoduje problem.
Core Web Vitals w SEO - rola i granice tematu
Core Web Vitals w SEO służą do oceny doświadczenia użytkownika na ważnych adresach i szablonach, a nie do zdobywania abstrakcyjnego wyniku 100/100. Metryki pokazują, czy strona szybko odsłania główną treść, reaguje na działania i zachowuje stabilny układ.
To część SEO technicznego i jakości strony, ale nie zastępuje trafności treści, intencji, indeksowalności, linkowania ani architektury informacji. Szybka strona z nieprzydatną treścią nadal ma słaby powód, żeby istnieć w indeksie.
Ten artykuł odpowiada na pytanie, czym są LCP, INP i CLS oraz jak przejść od raportu do diagnozy i poprawki. Pełne poradniki po GSC, JavaScript SEO, hostingu, CDN, analityce RUM i projektowaniu frontendu są tematami sąsiednimi.
LCP, INP i CLS - co mierzy każda metryka?
Każda metryka Core Web Vitals opisuje inny etap doświadczenia: ładowanie, interakcję albo stabilność. Dlatego nie ma jednej poprawki na „słabe Core Web Vitals” bez ustalenia, która metryka faktycznie zawodzi.
| Metryka | Co mierzy? | Co czuje użytkownik? | Pierwsze pytanie diagnostyczne | Typowe przyczyny |
|---|---|---|---|---|
| LCP Largest Contentful Paint | Mierzy, kiedy największy element treści widoczny w pierwszym widoku jest gotowy dla użytkownika. | Użytkownik widzi główną treść strony bez długiego czekania. | Który element jest LCP i co opóźnia jego pokazanie? | wolny serwer, duży obraz hero, opóźnione odkrycie zasobu, blokujący CSS lub JS, renderowanie po stronie klienta |
| INP Interaction to Next Paint | Mierzy responsywność strony po interakcjach, takich jak kliknięcie, tapnięcie lub wpisanie tekstu. | Strona szybko reaguje po akcji użytkownika i nie sprawia wrażenia zablokowanej. | Która interakcja jest najwolniejsza i czy blokuje ją JavaScript, layout albo render? | długie zadania JS, ciężkie event handlery, hydracja, duży DOM, praca layoutu, skrypty zewnętrzne |
| CLS Cumulative Layout Shift | Mierzy nieoczekiwane przesunięcia układu podczas ładowania i używania strony. | Elementy nie uciekają spod kursora i nie zmieniają położenia w nieprzewidywalny sposób. | Który element przesuwa układ i czy ma zarezerwowane miejsce przed załadowaniem? | obrazy bez wymiarów, reklamy, iframe, bannery, fonty, dynamiczne treści wstawiane nad istniejącą treścią |
Progi Core Web Vitals - kiedy wynik jest dobry?
Dobry wynik Core Web Vitals oznacza, że co najmniej 75 procent wizyt mieści się w dobrym progu dla danej metryki. Ocenę prowadzi się osobno dla urządzeń mobilnych i desktopowych, bo problemy oraz warunki sieciowe mogą być zupełnie inne.
| Metryka | Dobry wynik | Wymaga poprawy | Słaby wynik | Jak interpretować? |
|---|---|---|---|---|
| LCP | 2,5 s lub mniej | powyżej 2,5 s do 4 s | powyżej 4 s | Problem zwykle dotyczy serwera, odkrycia zasobu LCP, rozmiaru zasobu albo renderowania elementu. |
| INP | 200 ms lub mniej | powyżej 200 ms do 500 ms | powyżej 500 ms | Problem zwykle dotyczy pracy głównego wątku, zdarzeń, hydracji, renderu albo kosztu aktualizacji UI. |
| CLS | 0,1 lub mniej | powyżej 0,1 do 0,25 | powyżej 0,25 | Problem zwykle dotyczy braku zarezerwowanego miejsca albo zmian układu poza kontrolą użytkownika. |
Próg nie mówi jeszcze, co naprawić. LCP powyżej 4 sekund może wynikać z wolnego serwera, ale też z opóźnionego obrazu hero. Słaby INP może być skutkiem jednego ciężkiego formularza, a CLS może pochodzić z banera, którego nie ma w teście laboratoryjnym.
Dane terenowe i laboratoryjne - dlaczego oba typy są potrzebne?
Dane terenowe odpowiadają, czy realni użytkownicy mają problem, a dane laboratoryjne pomagają znaleźć techniczną przyczynę. Błąd zaczyna się wtedy, gdy wynik Lighthouse traktuje się jako pełny obraz doświadczenia użytkowników.
Search Console i CrUX pokazują dane z realnych wizyt, więc są dobre do priorytetyzacji. Lighthouse, DevTools i WebPageTest są lepsze do debugowania, bo pokazują waterfall, main thread, element LCP, interakcje i przesunięcia layoutu w kontrolowanym teście.
Jeśli dane terenowe są złe, problem dotyczy użytkowników. Jeśli test laboratoryjny jest zły, masz wskazówkę diagnostyczną. Te dwa zdania często oszczędzają kilka godzin błędnych wniosków.
Narzędzia do Core Web Vitals - które narzędzie odpowiada na jakie pytanie?
Narzędzia do Core Web Vitals trzeba dobierać do etapu diagnozy: najpierw wykrycie problemu w danych użytkowników, potem znalezienie przyczyny technicznej, a na końcu monitoring po wdrożeniu.
| Narzędzie | Typ danych | Na co odpowiada? | Ograniczenie |
|---|---|---|---|
| Google Search Console | Dane terenowe z CrUX | Które grupy URL-i mają status Dobry, Wymaga poprawy albo Słaby dla LCP, INP i CLS. | Raport grupuje podobne URL-e, obejmuje tylko adresy zindeksowane i wymaga wystarczającej liczby danych użytkowników. |
| PageSpeed Insights | Dane terenowe i laboratoryjne | Czy konkretny URL ma problem w danych użytkowników oraz jakie podpowiedzi pokazuje test Lighthouse. | Wynik laboratoryjny nie jest tym samym co realne doświadczenie wszystkich użytkowników. |
| CrUX | Zbiorcze dane realnych użytkowników Chrome | Jak metryki wyglądają w czasie dla originu, URL-a albo wybranych segmentów, jeśli dane są dostępne. | Brak danych nie oznacza braku problemu. Często oznacza zbyt małą próbkę. |
| Lighthouse | Test laboratoryjny | Co dzieje się w kontrolowanym teście i jakie zasoby, skrypty lub obrazy mogą pogarszać wynik. | Jedna konfiguracja testu nie odtwarza wszystkich urządzeń, sieci, interakcji i sesji użytkowników. |
| Chrome DevTools | Debug techniczny | Który element jest LCP, które zadania blokują INP i co powoduje przesunięcia layoutu. | Narzędzie pokazuje przyczyny, ale wymaga interpretacji i testów na reprezentatywnych urządzeniach. |
| RUM albo monitoring własny | Dane użytkowników konkretnej strony | Jak metryki różnią się według szablonu, kraju, urządzenia, przeglądarki, kampanii i typu użytkownika. | Wymaga wdrożenia pomiaru i kontroli jakości danych. To nie jest to samo co zwykły raport GA4. |
Jak diagnozować Core Web Vitals krok po kroku?
Diagnoza Core Web Vitals powinna przechodzić od metryki do przyczyny, a nie od losowej listy rekomendacji. Najpierw ustalasz, co jest słabe, gdzie występuje i czy dotyczy URL-a, szablonu czy całego serwisu.
Najszybszy start to zapis objawu jako relacji: objaw użytkownika wskazuje metrykę, metryka wskazuje narzędzie, a narzędzie zawęża poprawkę do komponentu, zasobu albo interakcji.
| Objaw | Najbliższa metryka | Gdzie sprawdzić? | Decyzja po diagnozie |
|---|---|---|---|
| Pierwszy ekran długo pokazuje pustkę albo loader | LCP | Sprawdź element LCP w PageSpeed Insights lub DevTools, potem waterfall zasobu i TTFB. | Napraw serwer, odkrycie zasobu LCP, obraz hero, krytyczny CSS albo renderowanie pierwszego widoku. |
| Kliknięcie w menu, filtr, formularz albo koszyk reaguje z opóźnieniem | INP | Szukaj wolnej interakcji w danych terenowych, RUM albo w panelu Performance w Chrome DevTools. | Ogranicz długie zadania JavaScript, hydrację, ciężkie event handlery, koszt layoutu i pracę dużego DOM. |
| Treść przesuwa się po załadowaniu obrazu, reklamy, fontu albo banera | CLS | Porównaj dane terenowe z trace w Lighthouse lub DevTools i znajdź element powodujący przesunięcie. | Zarezerwuj miejsce w layoucie, ustaw wymiary zasobów, kontroluj osadzenia i unikaj wstawek nad treścią. |
| Search Console pokazuje Słaby status dla grupy podobnych URL-i | LCP / INP / CLS | Otwórz przykład URL-a z grupy i sprawdź, czy problem powtarza się w szablonie strony. | Napraw komponent lub szablon, a nie tylko pojedynczy adres. Potem monitoruj nowe dane użytkowników. |
| Lighthouse wygląda dobrze, ale raport GSC nadal pokazuje problem | Najczęściej INP albo CLS | Porównaj segment mobile/desktop, realne urządzenia, interakcje po załadowaniu i dane z dłuższego okresu. | Nie uznawaj jednego testu laboratoryjnego za dowód naprawy. Szukaj scenariusza, którego test nie odtwarza. |
Ustal metrykę i urządzenie
Nie zaczynaj od ogólnego wyniku PageSpeed. Sprawdź, czy problem dotyczy LCP, INP czy CLS oraz czy występuje na mobile, desktopie czy w obu segmentach.
Oddziel URL od szablonu
Jeśli problem powtarza się na produktach, artykułach albo kategoriach, diagnozuj komponent i szablon. Jedna poprawka może naprawić setki adresów.
Porównaj dane terenowe i laboratoryjne
Dane terenowe mówią, czy użytkownicy realnie mają problem. Dane laboratoryjne pomagają znaleźć przyczynę w kontrolowanym środowisku.
Znajdź element, interakcję albo przesunięcie
Dla LCP znajdź element LCP, dla INP najwolniejszą interakcję, a dla CLS element, który zmienia położenie układu.
Wdróż najmniejszą poprawkę o dużym wpływie
Najpierw napraw błąd w szablonie, zasobie krytycznym albo skrypcie, który odpowiada za najgorszy status. Nie przebudowuj wszystkiego naraz.
Waliduj trend po czasie
GSC i CrUX wymagają nowych danych użytkowników. Po wdrożeniu monitoruj trend, a nie pojedynczy test wykonany zaraz po deployu.
LCP - jak poprawić ładowanie głównej treści?
Poprawa LCP polega na szybszym pokazaniu największego elementu treści w pierwszym widoku. Najpierw trzeba ustalić, który element jest LCP, a potem sprawdzić, czy opóźnia go serwer, zasób, sieć czy renderowanie.
| Obszar LCP | Co oznacza problem? | Co sprawdzić? | Typowe poprawki |
|---|---|---|---|
| TTFB | Przeglądarka długo czeka na pierwszą odpowiedź serwera. | cache, CDN, hosting, SSR, redirecty, backend, czas odpowiedzi API | skróć czas odpowiedzi, usuń zbędne przekierowania, włącz cache, przenieś statyczne zasoby bliżej użytkownika |
| Resource load delay | Zasób LCP jest odkrywany za późno. | czy obraz hero jest w HTML-u, CSS background, lazy loading, preload scanner, fetchpriority | nie lazy-loaduj elementu LCP, pokaż go w HTML-u, użyj preload albo fetchpriority tylko dla zasobu krytycznego |
| Resource load duration | Zasób LCP ładuje się zbyt długo. | rozmiar obrazu, format, wariant responsywny, kompresja, CDN, cache-control | użyj właściwych wymiarów, nowoczesnego formatu, kompresji, srcset, cache i CDN |
| Element render delay | Zasób jest pobrany, ale element długo nie pojawia się na ekranie. | CSS blokujący render, fonty, JS, hydracja, klientowe renderowanie treści | ogranicz CSS krytyczny, opóźnij JS niekrytyczny, użyj SSR lub SSG dla ważnej treści, uprość pierwszy widok |
Najczęstszy błąd to poprawianie kompresji obrazka bez sprawdzenia, czy ten obrazek jest w ogóle odkrywany wcześnie. Jeśli element LCP jest w CSS background, czeka na JavaScript albo ma lazy loading, sam format pliku może nie rozwiązać problemu.
INP - jak poprawić reakcję strony na interakcje?
Poprawa INP polega na skróceniu czasu od akcji użytkownika do kolejnej widocznej reakcji strony. W praktyce chodzi o ograniczenie pracy głównego wątku, ciężkich handlerów zdarzeń, hydracji i kosztownych aktualizacji interfejsu.
| Część INP | Co mierzy? | Typowe przyczyny | Typowe poprawki |
|---|---|---|---|
| Input delay | Czas od akcji użytkownika do rozpoczęcia obsługi zdarzenia. | główny wątek zajęty długim zadaniem, parsowaniem JS, hydracją albo skryptem zewnętrznym | dziel długie zadania, opóźnij skrypty niekrytyczne, ogranicz JS na starcie, nie blokuj main thread |
| Processing duration | Czas wykonywania logiki po interakcji. | ciężkie event handlery, duże obliczenia, walidacje, render wielu komponentów, nadmiar stanu | zmniejsz zakres aktualizacji, przenieś obliczenia, użyj web workerów, uprość komponenty i formularze |
| Presentation delay | Czas od zakończenia logiki do pokazania kolejnej klatki. | kosztowny layout, style recalculation, malowanie, duży DOM, animacje wpływające na layout | zmniejsz DOM, unikaj layout thrashing, animuj transform i opacity, ogranicz pracę renderowania |
INP często wymaga pracy developerskiej, bo problem nie zawsze widać w samym wyglądzie strony. Formularz, filtr, menu, koszyk, kalkulator albo panel rezerwacji może działać poprawnie funkcjonalnie, ale reagować z opóźnieniem na słabszym urządzeniu.
CLS - jak zatrzymać nieoczekiwane przesunięcia układu?
Poprawa CLS polega na zarezerwowaniu miejsca dla elementów, zanim się załadują albo zmienią rozmiar. Wiele problemów nie wymaga przyspieszania strony, tylko stabilnego layoutu.
| Przyczyna | Jak ją rozpoznać? | Poprawka |
|---|---|---|
| Obrazy i wideo bez wymiarów | Element ładuje się po czasie i zmienia wysokość kontenera. | Dodaj width, height albo aspect-ratio i serwuj odpowiedni rozmiar zasobu. |
| Reklamy, iframe i osadzenia | Zewnętrzny element pojawia się po renderze i wypycha treść. | Zarezerwuj miejsce w layoucie, ustaw min-height albo kontroluj warianty wysokości. |
| Treść dynamiczna nad istniejącą treścią | Baner, komunikat, alert albo moduł rekomendacji pojawia się bez akcji użytkownika. | Wstawiaj element w zarezerwowanym miejscu albo pokazuj go po interakcji, która uzasadnia zmianę. |
| Fonty | Podmiana fontu zmienia szerokość i wysokość tekstu. | Użyj font-display, preload dla krytycznych fontów i dopasowania metryk, jeśli font mocno zmienia layout. |
| Animacje wpływające na layout | Element zmienia top, left, width albo height, przez co przesuwa inne elementy. | Animuj transform i opacity, a nie właściwości wymuszające przeliczanie układu. |
CLS z danych terenowych może różnić się od Lighthouse, bo przesunięcia mogą pojawić się po przewinięciu strony, po akcji użytkownika, po zgodzie cookies albo po załadowaniu zewnętrznego modułu.
Priorytety Core Web Vitals - co poprawiać najpierw?
Priorytet w Core Web Vitals wynika z połączenia statusu metryki, znaczenia URL-a i skali problemu w szablonie. Najpierw naprawia się to, co jest słabe, powtarzalne i dotyczy stron ważnych dla ruchu lub konwersji.
| Reguła | Dlaczego? |
|---|---|
| Najpierw status Słaby | Przejście z Poor do Needs Improvement zwykle daje większy efekt użytkownikom niż dopieszczanie adresów już oznaczonych jako dobre. |
| Najpierw szablony z ruchem i konwersją | Wpis z niskim ruchem może być mniej pilny niż szablon kategorii, produktu albo landing generujący sprzedaż. |
| Najpierw mobile, jeśli tam jest użytkownik | Metryki ocenia się osobno dla mobile i desktopu. Priorytet powinien odpowiadać rzeczywistemu udziałowi urządzeń. |
| Najpierw przyczyna, potem narzędzie | Nie optymalizuj pod zielony komunikat. Napraw element, interakcję albo przesunięcie, które realnie psuje doświadczenie. |
| Jedna zmiana, jeden pomiar | Jeśli zmienisz obraz, fonty, JS i layout naraz, trudniej ocenić, co naprawdę poprawiło albo pogorszyło wynik. |
Core Web Vitals nie zawsze są pierwszym zadaniem technicznego SEO. Jeśli URL nie może trafić do indeksu albo nie ma jasnej roli w serwisie, poprawianie LCP, INP i CLS powinno poczekać na decyzję o indeksowalności, jakości i architekturze.
| Sytuacja | Pierwszy krok |
|---|---|
| URL nie jest indeksowalny | Najpierw usuń noindex, błędny canonical, blokadę crawlowania, błąd 4xx/5xx albo konflikt w sitemapie. |
| Problem dotyczy strony bez ruchu i bez roli biznesowej | Najpierw oceń, czy URL powinien istnieć i być linkowany. Zielone CWV nie uzasadnią słabej strony. |
| Brakuje danych terenowych | Użyj Lighthouse, DevTools i testów manualnych do diagnozy, ale nie wyciągaj wniosków o realnych użytkownikach bez danych. |
| Wkrótce powstaje nowy szablon albo redesign | Wpisz wymagania LCP, INP i CLS w projekt komponentów, obrazów, fontów, JS i analityki, zamiast łatać stary widok. |
Core Web Vitals a SEO - co realnie zmieniają?
Core Web Vitals wspierają SEO wtedy, gdy poprawiają doświadczenie na URL-ach, które odpowiadają na intencję, mogą być pobrane przez Google i mają sens biznesowy. Google rekomenduje dobre wyniki jako element page experience, ale metryki nie zastępują trafnej treści, indeksowalności, linkowania ani architektury informacji.
Najbardziej praktyczna interpretacja jest prosta: jeśli dwa URL-e podobnie odpowiadają na intencję, lepsze doświadczenie może wspierać skuteczność. Jeśli strona nie odpowiada na intencję, jest zablokowana albo nie ma wartościowej treści, same zielone metryki nie wystarczą.
Poprawa LCP, INP i CLS zwykle ma sens także poza SEO: użytkownik szybciej widzi ofertę, sprawniej używa formularzy i rzadziej klika przypadkowe elementy po przesunięciu układu.
Najczęstsze błędy w pracy z Core Web Vitals
Najczęstsze błędy wynikają z mylenia narzędzia z celem. Core Web Vitals nie są testem estetyki ani listą checkboxów, tylko diagnozą konkretnych problemów użytkownika.
Optymalizacja pod 100 punktów w PageSpeed
Wynik laboratoryjny jest pomocny, ale nie jest głównym celem. Celem jest dobre doświadczenie realnych użytkowników na ważnych szablonach.
Diagnoza tylko strony głównej
Problem często dotyczy produktów, kategorii, artykułów, formularzy albo stron lokalnych. Strona główna może wyglądać dobrze i maskować ryzyko w szablonach.
Mówienie o FID zamiast INP
FID jest starszą metryką. Aktualny zestaw Core Web Vitals obejmuje LCP, INP i CLS, dlatego analiza interakcji powinna opierać się na INP.
Lazy loading elementu LCP
Obraz albo blok będący LCP nie powinien czekać na scroll lub późne uruchomienie JavaScriptu. To opóźnia główną treść.
Preload wszystkiego
Preload pomaga tylko wtedy, gdy dotyczy naprawdę krytycznego zasobu. Nadmiar priorytetów konkuruje o sieć i może pogorszyć wynik.
Usuwanie skryptów bez decyzji biznesowej
Analityka, chat, tagi reklamowe i narzędzia consent mogą obciążać stronę, ale trzeba je oceniać według wpływu, celu i możliwości opóźnienia.
Brak miejsca dla obrazów, reklam i embedów
CLS zwykle wynika z braku zarezerwowanego miejsca w layoucie. Wiele przesunięć powstaje dlatego, że przeglądarka nie zna wymiarów elementu przed jego załadowaniem.
Natychmiastowe oczekiwanie zmian w GSC
Po wdrożeniu Google Search Console potrzebuje nowych danych użytkowników. Walidacja nie jest ponownym indeksowaniem i nie daje wyniku w dniu deployu.
Granice tematu - co jest tylko kontekstem?
Core Web Vitals łączą SEO, frontend, analitykę i infrastrukturę, ale ten wpis nie powinien rozlewać się na każdy temat techniczny. Tematy poboczne są tu tylko wtedy, gdy pomagają podjąć decyzję o LCP, INP albo CLS.
| Temat poboczny | Rola w tym artykule |
|---|---|
| Google Search Console | Tutaj używamy raportu Core Web Vitals do diagnozy LCP, INP i CLS. Pełna interpretacja raportów GSC, zapytań i indeksowania to osobny przewodnik. |
| PageSpeed Insights i Lighthouse | Opisujemy je jako narzędzia diagnostyczne. Pełny poradnik po każdej opcji Lighthouse nie jest celem tej strony. |
| JavaScript SEO | JavaScript pojawia się wtedy, gdy blokuje LCP, pogarsza INP albo ukrywa treść. Renderowanie, SSR, CSR i routing mają własny artykuł. |
| Hosting, CDN i frontend development | Wspominamy je tylko jako przyczyny lub poprawki metryk. Dobór infrastruktury i przebudowa aplikacji są szerszym zakresem wdrożeniowym. |
| Analityka i RUM | RUM pomaga mierzyć realnych użytkowników, ale pełna architektura analityki, zgód i raportowania nie należy do głównej intencji tego wpisu. |
Powiązane tematy techniczne
Powiązane tematy rozwijają decyzje, które zaczynają się od Core Web Vitals, ale szybko przechodzą do indeksowania, renderowania, audytu technicznego albo projektowania strony.
gdzie Core Web Vitals mieszczą się w kolejności crawl, index, render, mobile i architektura
jak czytać raporty, grupy URL-i i dane terenowe zanim przejdziesz do debugowania technicznego
co sprawdzić, gdy renderowanie, hydracja lub ciężki JS pogarszają LCP albo INP
jak połączyć Core Web Vitals z crawlem, indeksowaniem, treścią, linkami i priorytetami biznesowymi
kiedy problemy z szybkością i interakcją wynikają z decyzji projektowych, szablonów i komponentów
Chcesz sprawdzić, czy problem jest w metryce, szablonie czy wdrożeniu?
Sprawdzimy dane terenowe, raport Core Web Vitals w GSC, PageSpeed Insights, Lighthouse, DevTools, szablony stron, obrazy, fonty, JavaScript, CLS, INP, LCP i priorytety wdrożenia.
FAQ
01Co to są Core Web Vitals?
Core Web Vitals to zestaw metryk Google opisujących realne doświadczenie użytkownika na stronie. Aktualnie obejmują LCP dla ładowania głównej treści, INP dla responsywności po interakcji i CLS dla stabilności układu.
02Czy Core Web Vitals wpływają na SEO?
Core Web Vitals są częścią sygnałów doświadczenia strony i pomagają ocenić jakość korzystania z URL-a, ale nie zastępują trafności treści, indeksowalności, linków, intencji i jakości strony. W praktyce mają największy sens na adresach i szablonach, które mają ruch, sprzedaż albo dużą widoczność.
03Jakie wyniki LCP, INP i CLS są dobre?
Dobry wynik to LCP 2,5 sekundy lub mniej, INP 200 milisekund lub mniej oraz CLS 0,1 lub mniej. Ocena powinna dotyczyć 75. percentyla wizyt i osobno segmentów mobile oraz desktop.
04Czym różnią się dane terenowe od laboratoryjnych?
Dane terenowe pochodzą od realnych użytkowników i pokazują faktyczne doświadczenie w różnych warunkach. Dane laboratoryjne pochodzą z kontrolowanego testu i pomagają znaleźć przyczyny problemu, ale nie są pełnym obrazem wszystkich użytkowników.
05Dlaczego PageSpeed Insights pokazuje co innego niż Search Console?
Search Console korzysta z danych terenowych i grup URL-i, a PageSpeed Insights pokazuje zarówno dane terenowe, jeśli są dostępne, jak i wynik testu laboratoryjnego dla konkretnego adresu. Różnice są normalne, bo narzędzia odpowiadają na inne pytania.
06Czy trzeba mieć 100 punktów w PageSpeed Insights?
Nie. 100 punktów nie jest celem biznesowym ani gwarancją SEO. Ważniejsze jest, czy kluczowe URL-e mają dobre LCP, INP i CLS u realnych użytkowników oraz czy poprawki nie psują treści, konwersji i funkcji strony.
07Co zastąpiło FID w Core Web Vitals?
FID zastąpiła metryka INP, czyli Interaction to Next Paint. INP lepiej opisuje responsywność, bo uwzględnia interakcje w trakcie całej wizyty, a nie tylko pierwsze opóźnienie wejścia.
08Ile trwa walidacja poprawek Core Web Vitals w GSC?
Walidacja w Google Search Console wymaga zebrania nowych danych użytkowników i może trwać około 28 dni. Uruchomienie walidacji nie wymusza ponownego indeksowania ani natychmiastowej zmiany statusu.
09Od czego zacząć poprawę Core Web Vitals?
Zacznij od najgorszej metryki na ważnym szablonie lub URL-u. Ustal, czy problem dotyczy LCP, INP czy CLS, sprawdź dane terenowe, znajdź techniczną przyczynę w narzędziu laboratoryjnym i wdrażaj zmiany pojedynczo.
Źródła i dalsza lektura
- Google Search Central - Core Web Vitals and Google Search
- Google Search Console Help - Core Web Vitals report
- web.dev - Web Vitals
- web.dev - Largest Contentful Paint
- web.dev - Interaction to Next Paint
- web.dev - Cumulative Layout Shift
- web.dev - lab and field data differences
- web.dev - Optimize Largest Contentful Paint
- web.dev - Optimize Interaction to Next Paint
- web.dev - Optimize Cumulative Layout Shift