Szybkość strony – co to jest i jak ją zmierzyć?

Czym jest szybkość strony

Trzy metryki, którymi mierzy to Google

Google porządkuje te momenty w trzy wskaźniki Core Web Vitals: Largest Contentful Paint1 dla czasu wyświetlenia głównej treści, Cumulative Layout Shift dla stabilności układu i Interaction to Next Paint dla responsywności. Dokumentacja opisuje ostatni z nich jako „a stable Core Web Vital metric that assesses responsiveness”.2 Zastąpił on wcześniejsze First Input Delay, które mierzyło wyłącznie pierwszą interakcję, a nie całą wizytę.

Tylko pierwsza z tych metryk dotyczy szybkości w potocznym rozumieniu. Pozostałe dwie opisują to, czy strona zachowuje się przewidywalnie, a przeskakujący układ irytuje niezależnie od tego, jak szybko się wczytał.

Ten sam adres, trzy pomiary, trzy wyniki

Zmierzyliśmy 1 września 2026 czas do pierwszego bajtu dla trzech własnych stron, wywołując każdą trzykrotnie pod rząd. Wyniki dla huba słownika: 673 ms, potem 102 ms, potem 102 ms. Dla hasła słownikowego: 637 ms, następnie 99 i 96 ms.3

Różnica nie wzięła się z sieci ani z obciążenia serwera. Pierwsze wywołanie trafiło na pustą pamięć podręczną i wymusiło wygenerowanie strony, kolejne dostały gotową kopię. Ta sama strona, ta sama chwila, ta sama przeglądarka, a wynik różni się sześciokrotnie.

Wniosek jest niewygodny dla każdego, kto raportuje szybkość jedną liczbą. Pojedynczy pomiar nie opisuje nawet jednej strony, bo nie wiadomo, czy trafił na kopię z pamięci, czy na generowanie od zera. Sensowny odczyt wymaga powtórzenia i zapisania obu stanów osobno: pierwszy mówi, ile kosztuje wygenerowanie strony, kolejne, co dostaje typowy odwiedzający.

Fałszywy alarm, który kosztował cały audyt

Ta sama lekcja w ostrzejszej wersji. Zewnętrzny audyt opisał kiedyś naszą część serwisu jako ładującą się ponad trzy sekundy. Pomiar w przeglądarce pokazał co innego: pierwsza odpowiedź serwera w 78 ms, pełne załadowanie w 574 ms, przy 194 kB przesłanych danych.3

Przyczyna rozjazdu okazała się prozaiczna. Narzędzie audytujące pobierało pełne pliki PNG o wadze 1,17 MB zamiast wersji WebP ważącej 55 kB, którą realna przeglądarka dostaje automatycznie. To ponad dwudziestokrotna różnica w wadze obrazu. Narzędzie nie kłamało, tylko mierzyło warunki, w których nikt tej strony nie ogląda.

Stąd praktyczna kolejność: najpierw ustalić, co dokładnie mierzy narzędzie, potem czytać wynik. Ma to znaczenie także przy ocenie hostingu, bo część winy za wolne ładowanie przypisuje się serwerowi na podstawie pomiarów, które serwera w ogóle nie dotyczyły.

Najczęstsze pytania

Ile pomiarów potrzeba, żeby ocenić szybkość strony?
Co najmniej kilka pod rząd. Pierwsze wywołanie może trafić na pustą pamięć podręczną i dać wynik kilkukrotnie gorszy od kolejnych.

Które metryki liczą się w Core Web Vitals?
Largest Contentful Paint, Cumulative Layout Shift i Interaction to Next Paint. Ta ostatnia zastąpiła First Input Delay, mierzące tylko pierwszą interakcję.

Dlaczego narzędzia dają różne wyniki dla tej samej strony?
Bo mierzą w różnych warunkach. Część pobiera pełne pliki graficzne zamiast lżejszych formatów, które dostaje zwykła przeglądarka.

Czy szybkość strony wystarczy, żeby uznać ją za dobrą?
Nie. Szybkość jest jednym z filarów SXO, ale to, co widać above the fold, ocenia się osobno.

Źródła

1. web.dev (Google), Web Vitals — zestaw metryk Core Web Vitals. web.dev/articles/vitals

2. web.dev (Google), Interaction to Next Paint (INP) — status metryki i zakres pomiaru. web.dev/articles/inp (odczyt 1.09.2026).

3. Pomiary własne: czas do pierwszego bajtu dla trzech stron essaseo.pl, po trzy wywołania na stronę (1.09.2026), oraz wcześniejszy pomiar pełnego załadowania strony słownika w przeglądarce.