Darmowe narzędzie · nie wymaga konta

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.

Znany również jako: TTFB test · Time to First Byte · server response time
Dowody pokazane ze źródłemBrak wymaganego kontaBrak wymyślonych metryk
Jeden URL · cztery mierzone fazy

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.

DNSRozwiąż
TCPPołącz
TLSNegocjuj
Pierwszy bajtOdpowiedz
Tylko cele publiczne · IP przypisane po walidacji · brak szacowanego czasu
Model dowodów

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

1

Waliduj URL

Akceptowane są tylko publiczne cele HTTP lub HTTPS. Prywatne i zarezerwowane adresy są odrzucane.

2

Rozwiąż i przypnij IP

DNS jest czasowany, podczas gdy połączenie korzysta z już zwalidowanego publicznego adresu IP, aby zapobiec ponownemu przypisaniu DNS.

3

Otwórz świeże połączenie

Próba mierzy TCP i, dla HTTPS, TLS bez ponownego użycia wcześniejszego połączenia.

4

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.

≤ 800 msDobre pasmo przewodnie

Ponowna analiza i porównanie z odpowiednich regionów użytkowników przed stwierdzeniem, że URL jest konsekwentnie szybki.

801–1,800 msWymaga przeglądu

Użyj podziału faz, aby zobaczyć, czy konfiguracja połączenia czy czas od żądania do pierwszego bajtu dominuje.

> 1,800 msWolna pasmo przewodnie

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?

Wyszukiwanie DNS

Wolne autorytatywne DNS, odległość resolvera lub niepamięciowe wyszukiwanie mogą zwiększyć pierwszą fazę.

TCP i geografia

Długa odległość sieciowa i utrata pakietów dodają dodatkowe przejazdy przed wysłaniem jakiegokolwiek żądania HTTP.

Negocjacja TLS

Nowe połączenie HTTPS wymaga negocjacji kryptograficznej; ponowne użycie i nowoczesny TLS mogą zmniejszyć powtarzające się koszty.

Przetwarzanie pochodzenia

Zapytania do bazy danych, wywołania API, kod aplikacji i kontencja zasobów mogą opóźnić generowanie odpowiedzi.

CDN lub błędy pamięci podręcznej

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.

Przekierowania

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.

Uzyskaj właściwą odpowiedź

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.

Użyj tego w ten sposób
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.
Unikaj tego
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.
Publiczna metodologia

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.

  1. Normalizujemy adres, otwieramy nowe połączenie HTTP/1.1 z jednego serwera Novaverb i czasujemy każdą fazę osobno.
  2. Rejestrujemy wyszukiwanie DNS, połączenie TCP, handshake TLS, czas oczekiwania na żądanie i całkowity czas do pierwszego bajtu (TTFB).
  3. Porównujemy TTFB z publicznymi wytycznymi web.dev w terenie (≈800 ms na 75. percentylu) - orientacja, a nie werdykt pass/fail.
  4. Całkowicie wykluczamy renderowanie przeglądarki; to mierzy serwer, a nie Core Web Vitals.
Zbudowane na publicznych standardach

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.

W3CResource Timing
Resource & Navigation Timing

Dzieli zapytanie na fazy DNS, TCP, TLS i oczekiwania (TTFB) modelu czasowego W3C.

Przeczytaj specyfikację
Googleweb.dev TTFB
Time to First Byte guidance

Orientuje zmierzony TTFB w stosunku do publicznego pasma wytycznych 800 ms.

Przeczytaj specyfikację
Wymieniamy standard tylko tam, gdzie to narzędzie rzeczywiście odczytuje lub mierzy w odniesieniu do niego. Gdy sygnał jest poza bieżącym sprawdzeniem, wynik to wskazuje, zamiast sugerować pokrycie.
Często zadawane pytania

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.

Więcej darmowych sprawdzeń

Zbadaj wszystkie Darmowe Narzędzia Novaverb

Narzędzie SEO witrynyZasięg crawl, strony do indeksowania i linki wewnętrzne
Keyword Research ToolFree AI keyword research tool for search volume, keyword difficulty, …
SERP CheckerCheck live organic search results and AI Overview rankings for …
Website Security CheckerAudit website security posture, TLS/SSL certificates, HTTP security headers, and …
Backlink CheckerExplore backlinks, referring domains, dofollow links, and domain authority for …
Robots.txt CheckerTest and validate robots.txt rules, User-Agent directives, blocked paths and …
Sitemap CheckerValidate XML sitemap structure, URL counts, reachability, and index type. …
Meta Tag CheckerCheck page title length, meta description, H1 heading structure, Open …
HTTP Status & Redirect CheckerTrace HTTP status codes (200, 301, 302, 404, 500) and …
Website MonitorMonitor website availability, HTTP status code, and server response time …
HTTP/2 TestCheck whether your web server supports HTTP/2 via TLS ALPN …
HTTP/3 TestTest whether your web server supports HTTP/3 over QUIC with …
Website Performance TestTest global website loading speed and TTFB waterfall timing across …
GEO CheckerAudit whether ChatGPT, Perplexity, Gemini, and Google AI Overviews can …
Core Web Vitals CheckerCheck real-user Core Web Vitals (LCP, INP, CLS) from Chrome …
PageSpeed CheckerRun a live Lighthouse performance audit to test PageSpeed, Core …
Website Safety CheckerCheck whether a domain or URL is flagged for malware, …
Knowledge Graph CheckerCheck whether a brand, person, product or organization is recognized …
Keyword Gap CheckerCompare your site against competitors to find missing high-traffic keywords, …
Competitor Top PagesFind top organic traffic-driving pages for any competitor domain. See …
Przeglądaj pełne centrum darmowych narzędzi
Sprawdź → zrozum → napraw

Zamień tę kontrolę w zweryfikowaną naprawę

Każde darmowe narzędzie Novaverb to jeden lejek: przeprowadź kontrolę, zrozum dowody, a następnie napraw to i udowodnij, że zostało rozwiązane świeżą kontrolą - bez wymyślonych stanów przejścia.