Jak szybko powinna ładować się strona internetowa? Progi Core Web Vitals i pomiar

Ładowanie strony internetowej jest wystarczająco szybkie wtedy, gdy u co najmniej 75 procent odwiedzin największy element ekranu pojawia się w ciągu 2,5 sekundy (LCP), strona odpowiada na kliknięcie w 200 milisekund (INP), a układ nie przeskakuje bardziej niż o 0,1 w skali CLS. Tak brzmią dziś progi Core Web Vitals, które Google publikuje na web.dev. Jedna liczba w stylu „strona ma się wczytać w 2 sekundy” nie wystarcza, bo użytkownik ocenia trzy różne rzeczy: czy coś widać, czy coś działa i czy nic nie ucieka spod palca.

W tym tekście pokazujemy aktualne progi, poprawiamy kilka mitów, które wciąż krążą po sieci (FCP i TTI nie są Core Web Vitals, a FID od 2024 roku nie istnieje w tym zestawie), uczymy Was mierzyć wynik w PageSpeed Insights i w danych z prawdziwych przeglądarek, a na końcu dajemy listę przyczyn, które najczęściej psują każdy z trzech wskaźników. Piszemy z perspektywy zespołu, który testuje wydajność aplikacji webowych u klientów, więc sporo tu o tym, jak włączyć szybkość strony do procesu QA, a nie tylko do jednorazowego audytu.

Jak szybko powinna ładować się strona internetowa?

Krótka odpowiedź: główna treść widoczna do 2,5 sekundy, reakcja na każde kliknięcie do 200 milisekund, stabilny układ z CLS do 0,1. Te trzy progi web.dev nazywa „dobrymi” i każe je oceniać na 75. percentylu wszystkich wizyt, osobno dla telefonów i komputerów. Percentyl ma znaczenie: nie wystarczy, że strona jest szybka na Waszym laptopie w biurze. Ma być szybka dla trzech na cztery wizyty, także z telefonu w pociągu.

Stare porady mówią o „pełnym załadowaniu w 2 sekundy”. Problem w tym, że pełne załadowanie (Fully Loaded Time) nie jest żadnym oficjalnym progiem, a na nowoczesnej stronie, która dociąga w tle analitykę, czaty i piksele reklamowe, potrafi trwać długo po tym, jak użytkownik już czyta i klika. Dla czytelnika liczy się, kiedy widzi to, po co przyszedł, i czy przycisk „Kup” reaguje od razu. Dlatego mierzymy LCP i INP, a nie stoper do ostatniego bajtu.

Czym są Core Web Vitals i jakie mają progi?

Core Web Vitals to trzy wskaźniki, które Google uznaje za najważniejsze dla doświadczenia użytkownika: szybkość pojawienia się treści, responsywność i stabilność wizualna. Każdy ma trzy przedziały oceny. Według dokumentu web.dev o definiowaniu progów strona ma dobry wynik, jeśli co najmniej 75 procent odsłon mieści się w progu „dobry”.

Warto zapamiętać różnicę między INP a starym FID. FID mierzył tylko opóźnienie pierwszej interakcji i tylko do momentu, w którym przeglądarka zaczęła ją obsługiwać. INP patrzy na wszystkie interakcje w trakcie wizyty i liczy cały czas aż do narysowania kolejnej klatki: opóźnienie wejścia, czas wykonania kodu obsługi zdarzenia i opóźnienie prezentacji. Strona, która ładnie reaguje na pierwsze kliknięcie, a potem zamraża się przy filtrowaniu listy produktów, w FID wypadała dobrze, w INP już nie.

Dlaczego FCP, TTI i FID to już nie Core Web Vitals?

Bo zestaw się zmienił, a wiele artykułów o szybkości stron, łącznie z poprzednią wersją tego tekstu, tego nie odnotowało. First Contentful Paint (FCP) nigdy nie był Core Web Vital, to wskaźnik pomocniczy, przydatny do diagnozy. Time to Interactive (TTI) został usunięty z wyniku Lighthouse w wersji 10, opisanej na blogu Chrome for Developers w lutym 2023 roku, a jego 10 procent wagi przeszło na CLS. First Input Delay (FID) przestał być Core Web Vital 12 marca 2024 roku, kiedy według web.dev zastąpił go INP.

Co to znaczy dla Was w praktyce? Jeśli w raporcie z audytu albo w dokumentacji projektu widzicie progi FCP poniżej 1 sekundy i TTI poniżej 2 sekund jako „wymagania Google”, potraktujcie je jako historyczne. FCP możecie dalej śledzić jako wskaźnik diagnostyczny, ale cele biznesowe i kryteria akceptacji warto opisać w LCP, INP i CLS.

Czy szybkość ładowania strony wpływa na sprzedaż i SEO?

Wpływa, ale uczciwie trzeba oddzielić dane od mitów. Często cytowane zdanie „każda sekunda opóźnienia obniża konwersję o 20 procent” krąży bez wskazania badania, więc go nie powtarzamy. Lepiej udokumentowane jest badanie Deloitte Digital i Google „Milliseconds Make Millions” z 2020 roku na 37 markach z Europy i USA: poprawa szybkości mobilnej strony o 0,1 sekundy podniosła konwersję o 8,4 procent w handlu detalicznym i o 10,1 procent w turystyce, a klienci sklepów wydawali średnio 9,2 procent więcej. To wyniki z konkretnej próby marek, nie prawo przyrody, ale kierunek jest jasny.

Z SEO jest podobnie. Dokumentacja Google Search mówi, że dobre Core Web Vitals są zgodne z tym, co nagradzają główne systemy rankingowe, i zaleca ich osiągnięcie, ale nigdzie nie obiecuje, że szybka strona wyprzedzi wolniejszą z lepszą treścią. Szybkość jest jednym z sygnałów doświadczenia strony, a nie przepustką na pierwsze miejsce. W naszych projektach widzimy, że największy efekt biznesowy daje nie sam wynik w PageSpeed, tylko stabilność krytycznych ścieżek pod obciążeniem: koszyka, logowania, płatności.

Dobrze to widać w projekcie dla Argos z branży e-commerce. Zakres obejmował automatyzację testów i uporządkowanie procesów QA, a wśród efektów potwierdzonych przez klienta jest redukcja awarii w okresach szczytowych o 72 procent i wzrost konwersji o 12 procent dzięki stabilności checkoutu i płatności. To nie jest wynik optymalizacji LCP, tylko dowód na to, że użytkownik płaci za stronę, która działa wtedy, kiedy jest mu potrzebna. Przebieg projektu opisujemy w case study jak skrócić testy regresyjne z 5 dni do 10 godzin.

Jak szybko ładują się strony w praktyce?

Słabiej, niż sugerują poradniki. Web Almanac 2024 organizacji HTTP Archive, oparty na danych Chrome UX Report, pokazuje, że dobre wszystkie trzy Core Web Vitals ma 43 procent stron na telefonach i 54 procent na komputerach. Najtrudniejszy na telefonach jest LCP: dobry wynik osiąga 59 procent stron mobilnych.

Z tego wykresu płyną dwa praktyczne wnioski. Po pierwsze, jeśli Wasza strona przechodzi wszystkie trzy progi na telefonach, jesteście w mniejszości, która ma realną przewagę. Po drugie, na desktopie INP jest dobry u 97 procent stron, na telefonach tylko u 74 procent. Testowanie szybkości wyłącznie na komputerze dewelopera daje więc fałszywie spokojny obraz. Laptop z 32 GB pamięci jest świetnym narzędziem do pisania kodu i fatalnym przedstawicielem Waszych klientów.

Jak zmierzyć ładowanie strony internetowej?

Ładowanie strony internetowej mierzy się na dwa sposoby i oba są potrzebne. Dane z pola (field data) pochodzą od prawdziwych użytkowników Chrome i trafiają do Chrome UX Report (CrUX), z opóźnieniem i w oknie 28 dni. Dane laboratoryjne (lab data) to pomiar w kontrolowanych warunkach, na przykład w Lighthouse, który powtórzycie w każdej chwili, ale który nie zna Waszych prawdziwych urządzeń i sieci. Google ocenia stronę danymi z pola, a naprawia się ją danymi z laboratorium.

Jak czytać PageSpeed Insights krok po kroku:

1. Wpiszcie adres konkretnej podstrony, nie tylko strony głównej. Karta produktu i koszyk ładują się inaczej niż strona startowa.
2. Zacznijcie od górnej sekcji „Discover what your real users are experiencing”. To dane z CrUX. Jeśli ich brakuje, strona ma za mały ruch i trzeba oprzeć się na laboratorium albo własnym pomiarze.
3. Przełączcie widok między telefonem i komputerem. Ocenę „passed” dostajecie osobno dla każdego z nich.
4. Dopiero potem przejdźcie do wyniku Lighthouse. Liczba od 0 do 100 to wskaźnik laboratoryjny, który nie wpływa bezpośrednio na ocenę Core Web Vitals.
5. W sekcji diagnostyki szukajcie elementu LCP i długich zadań na głównym wątku. To one najczęściej tłumaczą słaby LCP i INP.

Jeśli chcecie mieć dane z pola dla każdej wersji aplikacji, dodajcie bibliotekę web-vitals (Google Chrome, wersja 5 i nowsze) i wysyłajcie wyniki do własnej analityki. Przykład w czystym JavaScripcie:

import {onLCP, onINP, onCLS} from 'web-vitals';

function wyslij(metryka) {
  const dane = JSON.stringify({
    nazwa: metryka.name,      // LCP, INP albo CLS
    wartosc: metryka.value,
    ocena: metryka.rating,    // good, needs-improvement, poor
    adres: location.pathname,
    wersja: document.documentElement.dataset.release || 'brak'
  });
  navigator.sendBeacon('/api/web-vitals', dane);
}

onLCP(wyslij);
onINP(wyslij);
onCLS(wyslij);

Atrybut z numerem wersji to drobiazg, który oszczędza godziny. Kiedy INP nagle rośnie, od razu widzicie, od którego wydania, i nie musicie zgadywać, która zmiana spowolniła stronę. Do szukania przyczyny przydaje się wariant biblioteki z przypisaniem przyczyny (import z web-vitals/attribution), który podaje między innymi element odpowiedzialny za LCP.

Co najczęściej psuje LCP, INP i CLS?

Każdy wskaźnik ma swoich typowych winowajców. Dokumentacja web.dev dzieli LCP na cztery części: czas do pierwszego bajtu (TTFB), opóźnienie startu pobierania zasobu, czas pobierania i opóźnienie renderowania. Według web.dev dwie części „opóźnienia” powinny być bliskie zeru, a większość czasu powinno zajmować pobranie dokumentu i samego zasobu LCP. INP składa się z trzech faz: opóźnienia wejścia, przetwarzania i prezentacji. Poniżej zebraliśmy przyczyny, które spotykamy najczęściej.

Klasyczne porady z poprzedniej wersji tego tekstu, czyli kompresja Gzip lub Brotli, nowoczesne formaty obrazów (WebP, AVIF), cache w nagłówkach HTTP, CDN i atrybuty async oraz defer przy skryptach, nadal są słuszne. Zmienia się kolejność pracy: najpierw dane z pola mówią, który wskaźnik i która podstrona są słabe, potem laboratorium wskazuje przyczynę, a dopiero na końcu wybieracie technikę. Optymalizacja w odwrotnej kolejności kończy się często tym, że zespół tydzień kompresuje obrazki na stronie, której problemem był INP.

Jeśli chcecie przećwiczyć tę ścieżkę na własnych przykładach, Lighthouse, DevTools i WebPageTest są w programie szkolenia optymalizacja wydajności aplikacji webowych, a samą pracę z panelem Performance i siecią w przeglądarce ćwiczycie na szkoleniu testowanie interfejsów webowych z użyciem DevTools.

Jak wpisać szybkość strony w proces testów?

Szybkość strony psuje się zwykle po cichu: jedna biblioteka tutaj, jeden tag marketingowy tam. Dlatego najlepiej traktować ją jak każde inne wymaganie niefunkcjonalne, z kryterium akceptacji i testem w potoku. Z naszego doświadczenia działa pięć kroków.

Czwarty krok bywa pomijany, a to on najczęściej decyduje o pieniądzach. Strona, która ma świetny LCP przy jednym użytkowniku, potrafi zwolnić kilkukrotnie w Black Friday. Różnicę między pomiarem szybkości ładowania a testem obciążenia, rodzaje testów i metryki serwera opisujemy w artykule testy wydajnościowe: co to jest, rodzaje, metryki i narzędzia, a praktyczny plan testu w JMeterze w tekście JMeter i testy wydajnościowe. Narzędzie możecie opanować na szkoleniu testowanie wydajnościowe JMeter.

Testy wydajności aplikacji webowych prowadzimy u klientów jako testy wydajności z raportem i rekomendacjami, a gdy problem jest szerszy niż jedna strona, zaczynamy od audytu QA. O tym, jak zespoły łączą wydajność z jakością w praktyce, rozmawia się co roku na Testing Ground Conference, największej konferencji z obszaru QA w Polsce, której edycja 2027 odbędzie się w maju w Warszawie.

Powiązane na blogu Quality Island

• Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia
• JMeter i testy wydajnościowe: plan testu, metryki i typowe błędy
• Testowanie aplikacji webowych: co sprawdzić, jakie testy i jakimi narzędziami
• Testowanie e commerce: jak testować sklep internetowy
• Web Testing Heuristic Checklist: heurystyki testowania aplikacji webowych

Pełna lista źródeł

• Google, web.dev, Web Vitals, stan na 2026. Stąd trzy Core Web Vitals, progi dobre i zasada 75. percentyla.
• Google, web.dev, Defining the Core Web Vitals metrics thresholds, 2020, aktualizowane. Stąd przedziały dobry, do poprawy i słaby.
• Google, web.dev, Interaction to Next Paint (INP), 2023, aktualizowane. Stąd progi 200 i 500 ms.
• Google, web.dev, Interaction to Next Paint becomes a Core Web Vital, 12.03.2024. Stąd data zastąpienia FID przez INP.
• Chrome for Developers, What’s new in Lighthouse 10, 2023. Stąd usunięcie TTI i nowa waga CLS.
• HTTP Archive, Web Almanac 2024, rozdział Performance, 2024. Stąd odsetki stron z dobrymi Core Web Vitals.
• Deloitte Digital i Google, Milliseconds Make Millions, 2020. Stąd wpływ 0,1 s na konwersję w handlu i turystyce.
• Google Search Central, Understanding Core Web Vitals and Google search results, 2026. Stąd stanowisko Google o roli Core Web Vitals w wyszukiwarce.
• Google, web.dev, Optimize Largest Contentful Paint oraz Optimize Interaction to Next Paint, 2024. Stąd części LCP i fazy INP.
• GoogleChrome, biblioteka web-vitals, wersja 6.2.3 sprawdzona w rejestrze npm 10.10.2026. Stąd API onLCP, onINP, onCLS.
• Dane własne Quality Island, 2026: case study Argos z liczbami potwierdzonymi przez klienta, cennik usługi testów wydajności odczytany 10.10.2026.