Dobry czas odpowiedzi strony, mierzony jako czas do pierwszego bajtu (TTFB) dla strony HTML, to w przybliżeniu poniżej 200 milisekund dla strony z cache i poniżej 600 milisekund dla strony dynamicznej. Wytyczne Google web.dev uznają za dobry czas do pierwszego bajtu wynoszący 0,8 sekundy lub mniej. Powyżej mniej więcej sekundy odwiedzający zaczynają odczuwać oczekiwanie, zanim cokolwiek pojawi się na ekranie. Te liczby to praktyczne wskazówki, a nie sztywne limity: ważniejsze jest, aby czas odpowiedzi był stabilny i abyś zauważał, gdy zaczyna się zmieniać.
Ten poradnik wyjaśnia, co mierzy czas odpowiedzi, czym różni się od czasu ładowania strony, dlaczego monitor i przeglądarka pokazują różne wartości i jak go śledzić, aby spowolnienia były naprawiane, zanim zamienią się w awarie.
Czas odpowiedzi to nie czas ładowania strony
Te dwa pojęcia często się mylą, ale mierzą co innego.
Czas odpowiedzi to czas, w jakim serwer odpowiada na pojedyncze żądanie. W przypadku monitora zwykle oznacza czas od wysłania żądania do otrzymania odpowiedzi.
Czas ładowania strony to czas, w jakim przeglądarka wyświetla stronę gotową do użycia. Obejmuje czas odpowiedzi dokumentu HTML, a do tego pobranie i uruchomienie CSS, JavaScriptu, fontów i obrazów – często dziesiątki kolejnych żądań.
Strona może mieć krótki czas odpowiedzi i długie ładowanie, na przykład gdy serwer odpowiada w 150 milisekund, ale strona ładuje potem trzy megabajty JavaScriptu. Tę stronę frontendu omawiają nasze wskazówki, jak przyspieszyć ładowanie strony. Bywa też odwrotnie: dobrze zoptymalizowany frontend nie ukryje serwera, który przez cztery sekundy generuje HTML. Czas odpowiedzi zależy od Twojego serwera i hostingu. Ładowanie strony zależy od frontendu. Liczy się jedno i drugie, a każde wymaga innych poprawek. Jeśli chodzi o ładowanie strony, monitorowanie szybkości stron w Uptimecheck codziennie uruchamia Google Lighthouse na urządzeniach mobilnych i desktopie i wysyła alert, gdy wynik mobilny strony spadnie poniżej Twojego limitu.
Z czego składa się czas do pierwszego bajtu
Czas do pierwszego bajtu, czyli TTFB, to czas od rozpoczęcia żądania do nadejścia pierwszego bajtu odpowiedzi. Składa się z kilku etapów:
Zapytanie DNS: zamiana nazwy hosta na adres IP.
Połączenie TCP: wymiana pakietów potrzebna do otwarcia połączenia.
Handshake TLS: uzgodnienie szyfrowania dla HTTPS.
Przetwarzanie na serwerze: aplikacja działa, odpytuje bazę danych i buduje odpowiedź.
Pierwszy bajt w sieci: początek odpowiedzi w drodze z powrotem.
Każdy etap dla swojej strony możesz zobaczyć za pomocą curl:
curl -o /dev/null -s -w „dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n” https://northwind.shop/
Wartości są skumulowane. Jeśli tls wynosi 0,12 sekundy, a ttfb 0,95 sekundy, serwer generował stronę przez około 0,8 sekundy. Nad tą liczbą warto pracować. Jeśli duże są etapy DNS lub połączenia, problemem jest odległość, sieć lub DNS, a nie Twoja aplikacja. Uptimecheck dzieli czas odpowiedzi każdego sprawdzenia na te same fazy: DNS, połączenie, TLS, serwer i pobieranie.
Dlaczego monitory i przeglądarki pokazują różne wartości
To normalne, że monitor dostępności, narzędzia deweloperskie przeglądarki i narzędzie do testów wydajności pokazują różne czasy odpowiedzi dla tej samej strony. Najczęstsze powody:
Lokalizacja. Sprawdzenie z innego kontynentu wydłuża każdy z powyższych etapów. Serwer w Sztokholmie odpowiada odwiedzającemu ze Sztokholmu szybciej niż sprawdzeniu ze wschodniego wybrzeża USA.
Ponowne użycie połączenia. Przeglądarka utrzymuje połączenia otwarte i używa ich ponownie. Sprawdzenie monitora często za każdym razem otwiera nowe połączenie, więc przy każdym żądaniu płaci za DNS, TCP i TLS.
Cache. Przeglądarka może mieć stronę lub jej części w pamięci podręcznej, a CDN może serwować kopię z cache w jednych regionach, a w innych nie.
Co jest mierzone. Jedno narzędzie podaje TTFB, inne łączny czas pobrania całej odpowiedzi, a jeszcze inne pełne ładowanie strony.
Cookies i logowanie. Zalogowani użytkownicy często omijają cache strony, więc ich odpowiedzi są wolniejsze niż anonimowe sprawdzenie.
Żaden z tych czynników nie sprawia, że któraś liczba jest błędna. Ważne, aby porównywać to samo z tym samym: to samo sprawdzenie, z tej samej lokalizacji, w czasie. Monitor, który co minutę mierzy to samo żądanie, daje spójny punkt odniesienia, a reagujesz właśnie na zmiany względem niego.
Rozsądne cele – praktyczne wskazówki
Poniższe przedziały to praktyczne wskazówki dla odpowiedzi serwera na stronę HTML lub wywołanie API, mierzonej z lokalizacji w miarę blisko serwera. To punkt wyjścia do ustalenia własnego punktu odniesienia, a nie standard.
Rodzaj odpowiedziKomfortowoWarto zbadaćStrona z cache lub plik statyczny przez CDNponiżej 100–200 mspowyżej 400 msStrona dynamiczna (CMS, sklep, aplikacja)poniżej 300–600 mspowyżej 1 sProsty endpoint API do odczytuponiżej 100–300 mspowyżej 800 msWyszukiwanie, raporty, ciężkie zapytaniaponiżej 1–2 spowyżej 3 s
Dwie uwagi do tabeli. Po pierwsze, doliczaj odległość w sieci: sprawdzenie z innego kontynentu może dodać kilkaset milisekund, a tego Twoja aplikacja nie naprawi. Po drugie, najważniejsza jest kolumna, którą ustalasz sam. Jeśli Twój koszyk zwykle odpowiada w 350 ms, a dziś w 900 ms, coś się zmieniło, nawet jeśli 900 ms na papierze nadal wygląda akceptowalnie.
Co spowalnia czas odpowiedzi
Gdy czas odpowiedzi rośnie, przyczyną jest prawie zawsze jedno z poniższych:
Wolne zapytania do bazy danych: brakujący indeks, zapytanie, które rośnie razem z tabelą, albo wtyczka wykonująca dziesiątki zapytań na stronę.
Brak cache stron lub obiektów: każde żądanie buduje tę samą stronę od zera.
Zewnętrzne wywołania w trakcie żądania: API płatności, wysyłki, wyszukiwania lub analityki wywoływane synchronicznie, gdy odwiedzający czeka.
Za mało workerów: żądania ustawiają się w kolejce, gdy wszystkie workery PHP-FPM, Node lub serwera aplikacji są zajęte.
Brak zasobów: CPU na granicy, swapowanie pamięci albo dysk zatkany operacjami I/O kopii zapasowych lub zapisu logów.
Zimne starty: funkcje serverless i kontenery przeskalowane do zera potrzebują czasu, aby obsłużyć pierwsze żądanie.
Odległość: odwiedzający daleko od serwera, bez CDN po drodze.
To kolejki sprawiają, że czas odpowiedzi ma znaczenie dla dostępności. Gdy odpowiedzi zwalniają, każde żądanie dłużej zajmuje workera, pula się zapełnia, a nowe żądania czekają lub są odrzucane. Spowolnienie, które zaczyna się od dodatkowych pół sekundy, może skończyć się błędem 503 Service Unavailable przy następnym szczycie ruchu.
Śledź trend, a nie pojedyncze sprawdzenie
Pojedyncze wolne sprawdzenie niewiele znaczy. Chwilowy problem z siecią, pauza garbage collectora albo chybienie cache mogą spowolnić jedno żądanie. O problemie świadczy dopiero wzorzec:
Skokowa zmiana: czas odpowiedzi rośnie po wdrożeniu, aktualizacji wtyczki lub zmianie hostingu i już taki zostaje.
Powolny wzrost: czas odpowiedzi rośnie co tydzień trochę, w miarę jak rośnie tabela lub log.
Wzorzec dobowy: czas odpowiedzi skacze codziennie o tej samej godzinie – często przez kopię zapasową, import albo cron job konkurujący o zasoby.
Różnica między regionami: jeden region jest wolny, a inny działa dobrze, co wskazuje raczej na CDN, routing lub DNS niż na serwer.
Uptimecheck zapisuje czas odpowiedzi każdego sprawdzenia dla każdego monitora dostępności i monitora API, pokazuje go na wykresach z medianą i 95. percentylem, a cotygodniowe i comiesięczne raporty e-mail zawierają średni czas odpowiedzi obok dostępności. Dzięki tej historii widzisz skokową zmianę w dniu, w którym się pojawia, a nie kilka tygodni później.
Wysyłaj alerty przy utrzymującym się spowolnieniu
Alert przy każdym wolnym sprawdzeniu generuje szum, a hałaśliwe alerty są ignorowane. Wysyłaj alerty przy spowolnieniu, które trwa. Praktyczne podejście:
Zmierz punkt odniesienia dla każdego ważnego endpointu przez tydzień lub dwa.
Ustaw próg ostrzeżenia wyraźnie powyżej normalnych wahań, na przykład dwa do trzech razy powyżej zwykłego czasu odpowiedzi.
Wysyłaj alert tylko wtedy, gdy spowolnienie utrzymuje się przez kilka kolejnych sprawdzeń lub minut.
Ostrzeżenia o spowolnieniu kieruj na kanał zespołu, a powiadomienia push na telefon zostaw dla ewidentnych awarii.
Ustaw limit czasu (timeout) dla każdego sprawdzenia. Odpowiedź, która trwa 30 sekund, jest dla odwiedzającego awarią, niezależnie od kodu statusu.
W Uptimecheck limit wolnej odpowiedzi ustawiasz osobno dla każdego monitora. Gdy trzy sprawdzenia z rzędu są wolniejsze niż limit, dostajesz alert o spowolnieniu, a kolejny, gdy monitor znów przyspieszy. Czas spowolnienia nie liczy się jako przestój.
Te same zasady dotyczą każdego konfigurowanego alertu. Nasz poradnik o ograniczaniu fałszywych alertów w monitorowaniu dostępności szerzej omawia potwierdzanie i progi, a artykuł o wyborze progów alertów serwera wyjaśnia, jak ustawić limity dla CPU, pamięci i dysku. Gdy czasy odpowiedzi rosną, monitorowanie serwera obok sprawdzeń dostępności pokazuje, czy przyczyną jest serwer, więc nie musisz zgadywać między bazą danych, siecią a kodem.
Checklista czasu odpowiedzi
Zmierz TTFB kluczowych stron i endpointów za pomocą curl, z miejsca blisko serwera.
Monitoruj te same strony co minutę i zachowuj historię.
Zapisz punkt odniesienia dla każdego endpointu i porównuj z nim, a nie z ogólną liczbą.
Badaj skokowe zmiany po wdrożeniach i powolne wzrosty na przestrzeni tygodni.
Cache’uj, co się da, naprawiaj wolne zapytania i wyprowadzaj zewnętrzne wywołania poza żądanie.
Wysyłaj alerty przy utrzymującym się spowolnieniu i przekroczeniu limitu czasu, a nie przy pojedynczych wolnych sprawdzeniach.
Podsumowanie
Dobry czas odpowiedzi to taki, który jest niski jak na dany rodzaj strony, bliski Twojemu punktowi odniesienia i stabilny w czasie. W praktyce celuj w kilkaset milisekund dla stron dynamicznych i wyraźnie mniej dla stron z cache. Mierz go zawsze tak samo, obserwuj trend i traktuj utrzymujący się wzrost jako wczesne ostrzeżenie, bo dzisiejsza wolna strona to często jutrzejsza awaria.
Uptimecheck zapisuje czasy odpowiedzi przy każdym sprawdzeniu, więc widzisz nie tylko awarie, ale i spowolnienia. Wypróbuj za darmo przez 14 dni, bez karty kredytowej.