Twoja strona firmowa jest mierzona przez Google trzema liczbami. Nie chodzi o subiektywne wrażenie „szybka czy wolna” — chodzi o trzy konkretne metryki zbierane od prawdziwych użytkowników, które wpływają na ranking w wyszukiwarce. Nazywają się Core Web Vitals i Google podaje wprost, że są częścią systemu rankingowego.
Dwa wydarzenia z ostatnich dwóch lat zmieniły ten obraz: w marcu 2024 jedna z metryk została zastąpiona nową, ostrzejszą. W styczniu 2026 Cloudflare przejęło firmę stojącą za frameworkiem Astro, co układa rynek statycznych stron pod jednego dostawcę. Dla właściciela małej lub średniej firmy oba te wydarzenia mają konsekwencje, których plugin „do cache” w WordPressie nie naprawi. Pokazujemy, co dokładnie mierzy Google, jak sprawdzić swoją stronę w pięć minut i dlaczego decyzja o stacku technologicznym jest ważniejsza niż kolejne wtyczki optymalizacyjne.
Czym są Core Web Vitals i dlaczego Google ich używa
Core Web Vitals to trzy wskaźniki, które Google zaprojektowało jako uniwersalną miarę „doświadczenia strony” (page experience). Pomysł jest prosty: zamiast oceniać setki sygnałów technicznych, sprowadzamy szybkość i jakość strony do trzech wymiarów, które realnie odczuwa użytkownik. Czy strona się ładuje? Czy reaguje na klik? Czy nic na niej nie skacze, gdy próbujesz w coś trafić palcem?
Google nie ukrywa, że Core Web Vitals są częścią systemu rankingowego. W oficjalnej dokumentacji Search Central czytamy wprost, że page experience (w tym CWV) wpisuje się w to, co Google premiuje:
“This, along with other page experience aspects, aligns with what our core ranking systems seek to reward.” — Google Search Central, Understanding Core Web Vitals and Google search results
Innymi słowy: dobre wyniki Core Web Vitals nie zagwarantują pierwszego miejsca, ale słabe wyniki będą Cię ciągnąć w dół. Sam Google dodaje jednak istotne zastrzeżenie:
“Good results in reports like Search Console’s Core Web Vitals report don’t guarantee that your pages will rank at the top of Google Search results; there’s more to great page experience than Core Web Vitals scores alone.” — Google Search Central
Treść, autorytet domeny i sygnały techniczne nadal decydują o reszcie.
To, co odróżnia Core Web Vitals od starszych metryk typu „PageSpeed Score”, to sposób pomiaru. Google nie ocenia Twojej strony przez jednorazowy test laboratoryjny. Ocenia ją na podstawie danych zbieranych od prawdziwych użytkowników Chrome — w ramach raportu CrUX (Chrome User Experience Report). Konkretnie: bierze pod uwagę 75. percentyl ładowań strony, mierzony osobno na urządzeniach mobilnych i stacjonarnych. Tłumacząc to na język biznesu — żeby Twoja strona została uznana za „szybką”, co najmniej trzy czwarte rzeczywistych odwiedzin musi mieścić się w progu „Good” dla każdej z trzech metryk.
To ważne rozróżnienie, bo właściciel strony, który testuje swoją witrynę raz na laptopie z szybkim internetem, widzi inny obraz niż klient, który otwiera ją na telefonie w autobusie. Google patrzy na klienta w autobusie.
Trzy metryki, trzy progi — co znaczą po polsku
Każdy z trzech wskaźników ma osobny próg „Good” i mierzy inny aspekt jakości strony. Warto je znać po imieniu, bo pojawiają się w każdym raporcie z PageSpeed Insights i Search Console.
LCP — Largest Contentful Paint (jak szybko się ładuje)
LCP mierzy, ile czasu mija od momentu wejścia na stronę do wyrenderowania największego elementu w widocznym oknie. Zwykle jest to hero image (duże zdjęcie nad linią zgięcia), baner, mapa albo nagłówek. To jest moment, w którym użytkownik mówi sobie: „OK, strona jest tu, mogę zacząć z niej korzystać”.
Próg „Good”: ≤ 2,5 sekundy mierzone na 75. percentylu. Powyżej 2,5 sekundy — wymaga poprawy. Powyżej 4 sekund — słabe.
Co najczęściej psuje LCP: powolny serwer (długi TTFB — Time to First Byte), niezoptymalizowane obrazy w hero (typowy WordPress: 1,5 MB JPEG zamiast 80 KB WebP), render-blocking JavaScript, brak preloadingu kluczowych zasobów. W praktyce: jeśli Twoja strona ma na górze duże zdjęcie z aparatu, którego nikt nie skompresował, LCP będzie słaby — niezależnie od tego, jak szybki masz serwer.
INP — Interaction to Next Paint (jak szybko reaguje na klik)
To najmłodsza metryka i najbardziej wymagająca. INP mierzy, ile czasu mija od momentu, gdy użytkownik wchodzi w interakcję ze stroną (klika, dotyka palcem, naciska klawisz), do chwili, gdy przeglądarka zdąży wyrenderować odpowiedź na tę akcję. Klikasz przycisk „Dodaj do koszyka” — INP mierzy, ile czasu mija, zanim coś się na ekranie zmieni.
Próg „Good”: ≤ 200 milisekund. „Needs Improvement”: > 200 ms i ≤ 500 ms. „Poor”: > 500 ms.
Wartości wyglądają na drobne, ale to są progi, w których człowiek jeszcze odbiera reakcję jako natychmiastową. Powyżej 200 ms zaczynamy podświadomie czuć, że „coś się zacięło”. Powyżej 500 ms wielu użytkowników klika drugi raz, co potrafi wprowadzić aplikację w niepoprawny stan.
INP jest oficjalnie Core Web Vital od 12 marca 2024 roku, kiedy zastąpił starszą metrykę FID (First Input Delay). To zmiana znacząca, bo FID mierzył tylko pierwszą interakcję na stronie i tylko jej input delay. INP obserwuje wszystkie interakcje i całość czasu — od kliknięcia po wyrenderowanie odpowiedzi:
“FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page.” — web.dev, Interaction to Next Paint (INP)
W praktyce oznacza to, że strony, które miały dobry FID, dziś często mają słaby INP. To częsta sytuacja, jeśli ktoś nie aktualizował diagnostyki swojej strony od 2023 roku — ranking mógł cicho spaść, bo metryka, na którą się patrzyło, już nie jest tą, którą Google używa.
Co psuje INP: ciężki JavaScript ładowany synchronicznie, długie zadania (long tasks) blokujące główny wątek przeglądarki, masa skryptów third-party (analityka, czaty, piksele reklamowe wczytywane bez ograniczeń), event handlery, które wykonują się dłużej niż 50 ms. Najprostsza diagnoza: jeśli Twoja strona ma 30+ wtyczek WordPressa, każda dodająca własny JS — INP prawdopodobnie jest poza progiem „Good”.
CLS — Cumulative Layout Shift (czy nic nie skacze)
CLS mierzy stabilność wizualną. Konkretnie: czy elementy strony nie przesuwają się w nieprzewidywalny sposób w trakcie ładowania, sprawiając, że użytkownik klika nie tam, gdzie zamierzał. Każdy z nas znał tę frustrację — chcesz kliknąć link do artykułu, a w ostatnim ułamku sekundy załaduje się baner reklamowy, layout skacze i klikasz w reklamę zamiast w treść.
Próg „Good”: ≤ 0,1. To liczba bezwymiarowa, kombinacja udziału powierzchni okna, na której coś się przesunęło, i odległości tego przesunięcia. 0,1 to próg, w którym przesunięcia jeszcze nie wpływają realnie na klikanie. 0,25 i więcej — CLS jest „Poor”, a frustracja użytkownika gwarantowana.
Co psuje CLS: obrazy wstawiane bez zadeklarowanych wymiarów (przeglądarka nie wie, ile miejsca zarezerwować, więc layout skacze, gdy obraz się wczyta), reklamy wstrzykiwane dynamicznie po załadowaniu strony, fonty zewnętrzne, które ładują się z opóźnieniem (FOUT — flash of unstyled text), banery cookie, które pchają cały content w dół po pojawieniu się.
CLS jest najłatwiejszą z trzech metryk do naprawienia, jeśli problem leży w samej stronie. Trudniej — jeśli problem to reklamy AdSense albo czat live wstawiany przez stary skrypt.
Jak sprawdzić swoją stronę w pięć minut
Zanim zaczniesz cokolwiek zmieniać, sprawdź, gdzie jesteś. Trzy darmowe narzędzia wystarczą.
1. PageSpeed Insights (pagespeed.web.dev). Wpisujesz URL, dostajesz raport. Najważniejsze: w sekcji „Discover what your real users are experiencing” zobaczysz dane CrUX dla Twojej strony — czyli te same dane, które bierze pod uwagę Google przy ocenie. Jeśli sekcji nie ma, oznacza to, że Twoja strona ma za mało ruchu, by Chrome zebrał statystycznie istotną próbkę. W takim wypadku patrzysz na sekcję laboratoryjną (lab data) — to symulacja, mniej miarodajna, ale lepsze to niż nic.
2. Google Search Console — raport Core Web Vitals. Search Console pokazuje historyczny obraz Twoich stron pogrupowanych po podobnych URL-ach. To narzędzie, które naprawdę warto otwierać raz w miesiącu. Widzisz tam, ile URL-i ma status „Good”, „Needs Improvement” i „Poor” — osobno dla mobile i desktop. Jeśli Search Console mówi, że masz problem z INP na 200 stronach blogowych, to jest konkretny sygnał, gdzie szukać.
3. Cloudflare Web Analytics (jeśli Twoja strona jest na Cloudflare). Cloudflare zbiera własne dane Real User Monitoring — bez cookies, bez localStorage, bez identyfikacji użytkownika. W panelu Cloudflare widzisz LCP, INP i CLS swoich realnych odwiedzających, niezależnie od tego, czy używają Chrome czy innej przeglądarki. To uzupełnia obraz z PageSpeed Insights, bo CrUX patrzy tylko na Chrome, a Cloudflare na wszystkich.
Po trzech sprawdzeniach masz baseline. Ważne: zachowaj te wyniki (screenshot, eksport CSV). Po jakichkolwiek zmianach na stronie chcesz móc porównać „przed” i „po”.
Ostrzeżenie: jednorazowy pomiar PageSpeed Insights z laboratorium potrafi się zmieniać przy każdym odświeżeniu o kilkanaście punktów — to test syntetyczny, podatny na warunki sieciowe Google. Decyzje biznesowe podejmuj na danych CrUX i Search Console (mierzonych na rzeczywistych użytkownikach), nie na pojedynczym wyniku Lighthouse w trybie inkognito.
Co realnie pomaga (i ile to kosztuje)
Naprawa Core Web Vitals nie zaczyna się od migracji strony. Zaczyna się od taniej pracy nad obecną wersją. Hierarchia działań od najtańszych:
1. Obrazy (zwykle największy zwrot z minimalnym kosztem)
Większość stron firmowych ma na hero zdjęcie 1–2 MB w formacie JPEG, wgrane prosto z aparatu albo z banku zdjęć. Konwersja do WebP lub AVIF skraca wagę 3–5×, a w wielu przypadkach to różnica między „Poor” i „Good” w LCP. Dodaj do tego zadeklarowane wymiary (width, height w HTML lub CSS aspect-ratio) — i CLS spada bez dotykania reszty strony. Lazy loading dla obrazów poniżej linii zgięcia jest w HTML5 standardowy (loading="lazy"), wystarczy go włączyć.
2. Skrypty third-party (audyt, nie usuwanie wszystkiego)
Każdy zewnętrzny JavaScript — analityka, czat live, piksele reklamowe, mapa, widget social — ma wpływ na INP. Audyt zaczyna się od listy: co jest zainstalowane i czemu. Często znajdują się relikty po starych kampaniach albo dwa narzędzia robiące to samo. Drugi krok: ładowanie krytyczne vs odroczone. Czat live nie musi być na stronie głównej w pierwszej sekundzie — może załadować się po interakcji użytkownika lub po 3 sekundach idle. Każdy odsunięty z critical path skrypt to mniej długich zadań na main thread.
3. Cache i CDN (jeśli jeszcze nie masz)
Strona bez CDN — niezależnie od stacku — musi serwować wszystko z jednego serwera, na jednym kontynencie. Użytkownik z Krakowa pobiera baner reklamowy z serwera w Niemczech, użytkownik z Wrocławia z tego samego. CDN rozprasza statyczne zasoby po lokalizacjach blisko odwiedzających. Cloudflare, BunnyCDN, KeyCDN, AWS CloudFront — wszystkie sensowne, większość ma free tier wystarczający dla małej firmy. Dla WordPressa na zwykłym hostingu — to często najbardziej zauważalny zysk z najmniejszą inwestycją.
4. Kompresja i HTTP/2 (sprawdź, czy włączone)
Kompresja Brotli daje typowo 15–25% mniejsze pliki niż gzip dla tekstowych zasobów. HTTP/2 (i jeszcze lepiej HTTP/3) eliminuje problem head-of-line blocking i pozwala równolegle pobierać wiele zasobów po jednym połączeniu. Na nowoczesnych hostingach to standard, ale na tańszych planach VPS i klasycznych hostach bywa wyłączone domyślnie. Jednorazowa zmiana konfiguracji potrafi dać kilkaset milisekund w LCP.
5. Migracja stacku (gdy poprzednie nie wystarczyły)
Pierwsze cztery punkty potrafią przesunąć stronę z „Poor” do „Needs Improvement” bez zmiany platformy. Migracja na statyczny framework to ostatni krok — najdroższy, ale jednorazowy i trwały. Z „Needs Improvement” do „Good” przeskakuje się systemowo, a nie kolejną wtyczką. To decyzja, którą warto rozważyć, jeśli: (a) strona jest na WordPressie z wieloma pluginami i każdy update generuje nowe ostrzeżenia w Search Console, (b) i tak planujesz redesign w najbliższych 6–12 miesiącach, (c) ruch z Google jest istotnym kanałem dla biznesu i tracisz pozycje na rzecz konkurencji z lepszymi CWV.
Hierarchia ma znaczenie biznesowe. Migracja na nowy stack robiona jako pierwszy krok bez podstawowej higieny obrazów i skryptów to częsty przypadek, w którym po migracji wynik jest „lepszy, ale nadal nie idealny” — bo te same problemy z obrazami i third-party scripts przeniosły się do nowej technologii. Podstawy najpierw, stack jako rozwiązanie systemowe potem.
Dlaczego WordPress ma trudniej (i co Cloudflare zmieniło w styczniu 2026)
Większość małych i średnich firm w Polsce ma stronę na WordPressie. To nie jest zarzut — WordPress nadal jest dobrym wyborem dla blogów z dynamiczną redakcją, sklepów na WooCommerce i scenariuszy, gdzie klient sam ma edytować treść w panelu. Ale każda technologia ma swoje koszty wbudowane w architekturę. WordPress płaci ten koszt w Core Web Vitals.
Schemat jest powtarzalny: każde wejście na stronę WordPress to render w PHP, zapytania do bazy MySQL, ładowanie kilkudziesięciu wtyczek, każda dorzucająca własny JS i CSS. Wtyczki klasy „cache” leczą objaw — generują statyczne kopie i serwują je zamiast renderować dynamicznie. To pomaga przy LCP, ale prawie nic nie robi dla INP, bo INP zależy od ilości i jakości JavaScriptu na stronie, a ten jest produkowany przez pluginy niezależnie od cache’u.
Statyczne frameworki (Astro, Hugo, 11ty) idą inną drogą: cała strona jest generowana raz, w trakcie buildu, w czyste pliki HTML. Serwer (albo CDN) tylko je serwuje. Nie ma renderowania dynamicznego, nie ma bazy danych w ścieżce krytycznej, JavaScript jest dodawany tylko tam, gdzie jest naprawdę potrzebny.
I tu wchodzi nowość z 2026. 16 stycznia 2026 Cloudflare ogłosiło akwizycję The Astro Technology Company — firmy stojącej za frameworkiem Astro. Fred Schott, dotychczasowy CEO Astro, pozostaje liderem zespołu, projekt pozostaje open source, a Cloudflare zadeklarowało dalsze finansowanie Astro Ecosystem Fund — funduszu wspierającego społeczność otwartoźródłową, w którym partnerami pozostają również Sentry, Webflow, Netlify oraz Wix.
Z perspektywy strategicznej Matthew Prince, CEO Cloudflare, ujął cel akwizycji w komunikacie prasowym:
“Protecting and investing in open source tools is critical to the health of a functioning, free, and open Internet.” — Matthew Prince, CEO Cloudflare
Po stronie Astro Fred Schott dodał:
“Joining Cloudflare allows us to accelerate Astro’s development faster and on a much larger scale. Astro will continue to be the best way for developers to build content-driven websites.” — Fred Schott, CEO The Astro Technology Company
Co to znaczy dla właściciela firmy? Trzy rzeczy.
Po pierwsze, stabilność biznesowa frameworka. Astro było dotąd projektem firmy seedowej, której długoterminowy plan finansowy zależał od kolejnych rund. Dzięki przejęciu mamy framework wspierany przez firmę z giełdy, której usługi już dziś obsługują znaczącą część internetu. Dla strony firmowej, której cykl życia liczy się w latach, to ważny argument przy wyborze technologii.
Po drugie, integracja stack’u. Astro + Cloudflare Pages było już wcześniej naturalną parą, ale teraz to ten sam dostawca. Konfiguracja deployu, edge functions, Cloudflare Workers, middleware — wszystko w jednym ekosystemie, z planowaną głębszą integracją.
Po trzecie, kierunek rynku. Sygnał dla branży jest jasny: statyczne frameworki połączone z globalnym CDN to nie chwilowa moda, tylko model, który będzie się dalej rozwijał. Cloudflare zapowiedział głębszą integrację Astro z Cloudflare Workers — to praktyczna konsekwencja przejęcia, bo dotychczas oba projekty były osobnymi światami spinanymi przez konfigurację adaptera.
To nie jest argument, że WordPress trzeba migrować jutro. To argument, że kiedy następnym razem będziesz planować nową stronę albo redesign — warto zapytać o stack inny niż domyślny. Strony firmowe, landing page’e, blogi, dokumentacja produktu, sklepy z prostą logiką — wszystkie te scenariusze są dziś w zasięgu Astro + Cloudflare.
Jak my projektujemy strony pod Core Web Vitals
W Monaltro standardowo budujemy strony w stacku Astro + Cloudflare Pages. Nie dlatego, że to „modne” — dlatego, że ten stack z założenia generuje strony, które przechodzą Core Web Vitals bez konieczności sięgania po pluginy ratunkowe. Nasze własne strony klientów regularnie utrzymują wyniki PageSpeed w przedziale 95–100. To nie jest nasza obietnica marketingowa — to bezpośrednia konsekwencja decyzji architektonicznych.
Kilka zasad, które stosujemy domyślnie:
Static-first. Strona jest generowana w trakcie buildu — produktem jest statyczny HTML. Serwer (Cloudflare Pages CDN, 300+ lokalizacji globalnie) tylko go serwuje. Czas TTFB (Time to First Byte) liczony w pojedynczych dziesiątkach milisekund. To bezpośrednio przekłada się na LCP poniżej dwóch sekund.
Zero JavaScript by default. Astro ma model „JS tylko tam, gdzie jest potrzebny”. Strona statyczna z tekstem, obrazami i linkami — bez ani jednej linii JS na froncie. Interaktywne komponenty (formularz, slider, mapa) dodajemy świadomie, z dyrektywą client:load lub client:visible. Każda taka decyzja jest osobno przemyślana — dlaczego to wymaga JS, czy nie da się statycznie. Efekt: INP poniżej 100 ms na większości stron, bo nie ma długich zadań, które mogłyby zablokować główny wątek.
Obrazy zoptymalizowane na buildzie. Komponent <Image> Astro generuje WebP i AVIF, dostosowane wielkości dla różnych breakpointów, lazy loading domyślnie poniżej linii zgięcia. Surowe zdjęcie z aparatu (typowo kilka MB) trafia do procesu build i wychodzi jako kilkadziesiąt KB w najlepszym formacie wspieranym przez przeglądarkę odwiedzającego — bez ręcznego kompresowania w Photoshopie.
Fonty z preloadingiem i font-display: swap. Fonty pobieramy lokalnie (nie z Google Fonts, bo to dodatkowy DNS i CSP-issue), preloadujemy te krytyczne, dla reszty stosujemy swap, żeby tekst pojawił się natychmiast w foncie systemowym i podmienił się płynnie po załadowaniu właściwego kroju. CLS pod kontrolą.
Layout z zarezerwowanymi wymiarami. Każdy <img> ma width i height, każdy iframe ma określoną wysokość. Przeglądarka rezerwuje miejsce w trakcie ładowania, layout się nie przesuwa po wczytaniu obrazu czy reklamy.
To nie jest „magia” ani wiedza tajemna — to są podstawy, które framework egzekwuje za nas. WordPress mógłby teoretycznie osiągnąć podobne wyniki, ale wymagałoby to ostrego wyboru tematu, dyscypliny w pluginach, custom kodu w wielu miejscach i ciągłej pracy nad utrzymaniem. Praktycznie — agencje, które takie wyniki na WordPressie pokazują, sprzedają usługę za kwoty porównywalne z migracją na statyczny framework.
Jeśli zastanawiasz się, czy migracja Twojej strony na Astro + Cloudflare ma sens biznesowy, najprostszy test wygląda tak: sprawdź obecne Core Web Vitals (PageSpeed Insights + Search Console) i policz, ile Twoich URL-i jest w statusie „Poor” lub „Needs Improvement”. Jeśli to istotny procent — prawdopodobnie tracisz ranking i konwersje na rzeczach, które są technicznie do uniknięcia. Jeśli rozważasz redesign — to dobry moment, żeby pomyśleć o stacku, który nie wymaga walki z Core Web Vitals.
Podsumowanie
Core Web Vitals to nie hasło branżowe — to trzy konkretne liczby, które Google mierzy u Twoich realnych użytkowników i które wpływają na pozycję Twojej strony w wyszukiwarce. LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund, CLS poniżej 0,1 — taki jest cel.
Trzy rzeczy warto zapamiętać.
Po pierwsze, INP zastąpił FID 12 marca 2024. Wiele stron, które dwa lata temu miały świetny FID, dziś mają słaby INP, bo mierzy wszystkie interakcje, a nie tylko pierwszą. Jeśli ostatni audyt swojej strony robiłeś przed marcem 2024 — powtórz go teraz.
Po drugie, mierz, zanim zmieniasz. PageSpeed Insights, Google Search Console, Cloudflare Web Analytics — trzy darmowe źródła. Zachowaj baseline, żeby móc zmierzyć efekt każdej zmiany.
Po trzecie, wybór technologii ma większy wpływ niż plugin do cache. WordPress można zoptymalizować, ale każda optymalizacja to walka z architekturą. Statyczne frameworki — Astro, Hugo, 11ty — generują strony szybkie z założenia. A po przejęciu Astro przez Cloudflare w styczniu 2026 ten ekosystem jest dziś bezpieczniejszą długoterminową stawką niż rok temu.
Wskazówka: zanim zaczniesz cokolwiek zmieniać na własnej stronie, otwórz pagespeed.web.dev, wpisz swój URL i zachowaj wynik. Bez baseline’u nie zmierzysz, czy zmiana faktycznie pomogła. Z baseline’em każda decyzja techniczna staje się weryfikowalną hipotezą — a tak właśnie wygląda projektowanie stron, w którym dane wygrywają z opinią.