Free Server Response Time (TTFB) Test
Measure server Time to First Byte (TTFB), DNS lookup, TCP connect, and TLS handshake latency in real time. Instant server response test.
Zobacz, co się dzieje przed pierwszym bajtem
Wprowadź publiczny adres URL HTTP lub HTTPS powyżej. Wynik oddziela konfigurację połączenia od oczekiwania na żądanie, abyś wiedział, która część wymaga zbadania.
Wiedzieć, co dowodzi wynik
This check proves how long one server took to send the first byte of a response to one Novaverb server, split into DNS lookup, TCP connect, TLS handshake and request wait. It is a server measurement, not a page-speed measurement: no browser rendering happens, so it says nothing about Core Web Vitals or what a visitor on another network experiences.
1. Źródło
One live HTTP/1.1 request over a fresh connection from Novaverb's server in Germany. The result identifies where its evidence came from.
2. Granica
This is one synthetic server-side request from Germany. It is not a visitor's browser TTFB, field data, Core Web Vitals, uptime monitoring, or a global multi-location test.
3. Następna akcja
Użyj ustalenia, aby zweryfikować problem, a następnie połącz przestrzeń roboczą, gdy potrzebujesz historii, monitorowania lub analizy całej witryny.
Co mierzy Sprawdzacz Czasu Odpowiedzi Serwera?
Otwiera jedno nowe połączenie HTTP z serwera Novaverb w Niemczech i mierzy cztery fazy przed przybyciem pierwszego bajtu odpowiedzi: wyszukiwanie DNS, połączenie TCP, handshake TLS i żądanie do pierwszego bajtu. Ich suma to syntetyczny czas połączenia do pierwszego bajtu pokazany w wyniku.
Jak działa test czasu odpowiedzi
Waliduj URL
Akceptowane są tylko publiczne cele HTTP lub HTTPS. Prywatne i zarezerwowane adresy są odrzucane.
Rozwiąż i przypnij IP
DNS jest czasowany, podczas gdy połączenie korzysta z już zwalidowanego publicznego adresu IP, aby zapobiec ponownemu przypisaniu DNS.
Otwórz świeże połączenie
Próba mierzy TCP i, dla HTTPS, TLS bez ponownego użycia wcześniejszego połączenia.
Przeczytaj pierwszy bajt
Po wysłaniu GET, sonda zatrzymuje zegar TTFB, gdy przychodzą pierwsze bajty odpowiedzi.
Jak interpretować pasma przewodnie TTFB
web.dev przedstawia 800 ms lub mniej jako przybliżony dobry cel TTFB, a powyżej 1,800 ms jako słaby. Te pasma są zaprojektowane do interpretacji doświadczeń użytkowników; tutaj są jedynie orientacyjne dla jednego syntetycznego próbki.
Ponowna analiza i porównanie z odpowiednich regionów użytkowników przed stwierdzeniem, że URL jest konsekwentnie szybki.
Użyj podziału faz, aby zobaczyć, czy konfiguracja połączenia czy czas od żądania do pierwszego bajtu dominuje.
Powtórz test, porównaj zachowanie z pamięci podręcznej i bez pamięci podręcznej, a następnie zbadaj dominującą zmierzoną fazę.
Co zawiera ten wynik - i czego nie zawiera
Mierzone w tej sesji
- Jedno wyszukiwanie DNS z serwera Novaverb
- Jedno nowe połączenie TCP do zwalidowanego publicznego IP
- Jedno handshake TLS dla URL HTTPS
- Czas od wysłania żądania do pierwszego bajtu odpowiedzi
- Status HTTP, lokalizacja przekierowania, protokół i widoczny nagłówek serwera
Nie zmierzono ani nie udowodniono
- Czas TTFB z rzeczywistych użytkowników lub przeglądarek z lokalizacji Twoich odwiedzających
- LCP, CLS, INP, FCP lub jakakolwiek ocena Core Web Vitals
- Wykonanie JavaScript, renderowanie, ukończenie wizualne lub gotowość do interakcji
- Czas działania, rozkład percentylowy lub wydajność pod stałym obciążeniem
- Czysty czas wykonania aplikacji oddzielony od opóźnienia zwrotu sieciowego
Co zwykle spowalnia pierwszy bajt?
Wolne autorytatywne DNS, odległość resolvera lub niepamięciowe wyszukiwanie mogą zwiększyć pierwszą fazę.
Długa odległość sieciowa i utrata pakietów dodają dodatkowe przejazdy przed wysłaniem jakiegokolwiek żądania HTTP.
Nowe połączenie HTTPS wymaga negocjacji kryptograficznej; ponowne użycie i nowoczesny TLS mogą zmniejszyć powtarzające się koszty.
Zapytania do bazy danych, wywołania API, kod aplikacji i kontencja zasobów mogą opóźnić generowanie odpowiedzi.
Błąd pamięci podręcznej może zmusić krawędź do kontaktu z źródłem, podczas gdy trafienie może zwrócić znacznie szybciej.
Każde przekierowanie dodaje kolejne żądanie i możliwe kolejne ustawienie DNS, TCP i TLS przed finalną stroną.
Wytyczne dotyczące standardów i pomiarów
Pytania dotyczące czasu odpowiedzi serwera
Czy to ten sam TTFB, który doświadczają moi odwiedzający?
Nie. To syntetyczne żądanie z jednego serwera w Niemczech. Odwiedzający mogą używać innego regionu, ścieżki sieciowej, protokołu, stanu pamięci podręcznej i ponownie używanego połączenia.
Czy TTFB jest kluczowym wskaźnikiem Web Vitals?
Nie. TTFB to podstawowy wskaźnik diagnostyczny, ale kluczowe wskaźniki Web Vitals to LCP, INP i CLS.
Czy czas do pierwszego bajtu równa się czasowi przetwarzania backendu?
Nie. Zawiera przetwarzanie aplikacji lub CDN oraz czas sieciowy na pierwsze bajty, które wracają do sondy.
Czy sprawdzarka śledzi przekierowania?
Nie. Mierzy dokładnie przesłany URL. Jeśli ta odpowiedź przekierowuje, docelowy adres jest pokazany, abyś mógł go przetestować osobno.
Dlaczego wynik zmienia się między uruchomieniami?
Stan pamięci podręcznej DNS i CDN, obciążenie źródła, routing sieciowy, zator i wspólna infrastruktura mogą się różnić. Porównaj wiele próbek i dane z pola.
Co powinienem naprawić najpierw?
Zacznij od największej powtarzanej fazy. Wysoki czas oczekiwania na żądanie wskazuje na zachowanie pochodzenia lub pamięci podręcznej; wysokie fazy połączenia wskazują na odległość, DNS lub konfigurację transportu.
To jest pojedynczy syntetyczny pomiar po stronie serwera z jednej lokalizacji (UE · Niemcy), a nie rzeczywista przeglądarka użytkownika TTFB lub pole Core Web Vitals.
Co przesłać - i czego unikać
Submit any public address. A bare domain, a full URL with a path or a query string are all normalised before the request. A private host is refused. Remember that one measurement from one location is a sample, and a cached hit and a cold miss on the same URL can differ by an order of magnitude.
yourdomain.comKażda forma adresu jest w porządku. http lub https, z www lub bez, pusta domena lub pełna ścieżka - normalizujemy to dla Ciebie.Run it a few timesOdczytaj trend, a nie jedną liczbę - pojedyncze zapytanie różni się w przypadku zimnych pamięci podręcznych.Reading it as 'my users' real speed'To jest jedno syntetyczne żądanie z Niemiec, a nie doświadczenie twoich odwiedzających - traktuj to jako bazę backendową.Expecting Core Web Vitals hereTo mierzy czas serwera (TTFB), a nie renderowanie przeglądarki - użyj narzędzia Core Web Vitals dla danych w terenie.Dokładnie jak ten wynik jest produkowany
The address is normalised and a fresh HTTP/1.1 connection is opened from one Novaverb server, with every phase timed separately: DNS lookup, TCP connect, TLS handshake, request wait and total Time To First Byte. The TTFB is then banded against public web.dev guidance of roughly 800 ms at the 75th percentile, as orientation rather than a verdict.
- Normalizujemy adres, otwieramy nowe połączenie HTTP/1.1 z jednego serwera Novaverb i czasujemy każdą fazę osobno.
- Rejestrujemy wyszukiwanie DNS, połączenie TCP, handshake TLS, czas oczekiwania na żądanie i całkowity czas do pierwszego bajtu (TTFB).
- Porównujemy TTFB z publicznymi wytycznymi web.dev w terenie (≈800 ms na 75. percentylu) - orientacja, a nie werdykt pass/fail.
- Całkowicie wykluczamy renderowanie przeglądarki; to mierzy serwer, a nie Core Web Vitals.
Międzynarodowe standardy, do których odnosi się to sprawdzenie
Three public references define the measurement and the bar. W3C Resource Timing defines the phases that are timed, RFC 9110 defines the HTTP semantics the request follows, and Google's web.dev TTFB guidance supplies the threshold. Because that guidance describes a 75th-percentile field distribution, a single sample is compared to it for orientation only.
Dzieli zapytanie na fazy DNS, TCP, TLS i oczekiwania (TTFB) modelu czasowego W3C.
Przeczytaj specyfikacjęWydaje zgodne z normami zapytanie HTTP i odczytuje status odpowiedzi.
Przeczytaj specyfikacjęOrientuje zmierzony TTFB w stosunku do publicznego pasma wytycznych 800 ms.
Przeczytaj specyfikacjęServer Response Time Checker FAQ
What does the Novaverb Server Response Time Checker measure?
It measures your server-side connection timing for a URL: DNS lookup, TCP connect, TLS handshake, request wait, and total Time To First Byte (TTFB), from one Novaverb server in Germany over a fresh HTTP/1.1 connection.
What is TTFB (Time To First Byte)?
TTFB is the time from starting a request to receiving the first byte of the response. It captures DNS, connection setup, and server processing, reflecting how quickly your backend and network begin answering.
What is a good TTFB value?
As a server-side rule of thumb, under 200 milliseconds is excellent, under 500 milliseconds is acceptable, and above 800 milliseconds warrants investigation. Note web.dev field guidance targets 800 milliseconds at the 75th percentile for real users.
Is this the same as the TTFB my visitors experience?
No. This is one synthetic request from Germany, so it excludes your visitors' distance, devices, networks, and browser behaviour. Real-user TTFB varies by location and connection; treat this number as a clean backend baseline.
Why is my server response time slow and how do I improve it?
Common causes are slow database queries, no caching, and distant hosting. Improve it with server-side and full-page caching, a CDN to shorten network distance, faster backend code, and HTTP keep-alive or connection reuse.
Does this tool measure Core Web Vitals?
No. Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint are browser-rendering and field metrics. This tool measures only server-side connection timing and TTFB, which precede and influence rendering but do not equal it.
Why does the DNS or TLS number vary between checks?
Each check opens a fresh connection, so cold DNS caches, certificate negotiation, and server load cause run-to-run variation. Run several checks and compare the trend rather than reading any single measurement as definitive.
What is the difference between TTFB and page load time?
TTFB measures when the first response byte arrives from the server. Page load time measures when the browser finishes downloading and rendering everything. A fast TTFB is necessary but not sufficient for a fast-feeling page.
Does response time from one location represent global performance?
No. This is a single measurement from Germany and does not reflect users in other regions. For worldwide visibility, use a multi-location or field-data tool; this check is best for tracking your backend from a consistent vantage point.
How does server response time affect SEO?
A slow TTFB delays every downstream metric Googlebot and users experience, from crawl efficiency to Core Web Vitals. Faster server responses help pages render sooner, improving perceived speed, which supports rankings and reduces abandonment.