DNSResolve
Free tool, no account required
Free Server Response Time Checker: DNS, TCP, TLS and TTFB
The Novaverb server response time checker sends one live HTTP/1.1 request from a server in Germany and times DNS lookup, TCP connect, TLS handshake and the wait for the first byte.
Also known as: TTFB test, Time to First Byte, server response time
Evidence shown with sourceNo account requiredNo invented metrics
One URL, four measured phases
See what happens before the first byte
Enter a public HTTP or HTTPS URL above. The result separates connection setup from request wait so you know which part deserves investigation.
TCPConnect
TLSNegotiate
First byteRespond
Public targets only, IP pinned after validation, no estimated timing
Definition
What is a server response time checker?
A server response time checker measures how long a web server takes to begin answering one request. The Novaverb Server Response Time Checker opens one fresh HTTP/1.1 connection from a server in Germany and reports Time to First Byte, split into DNS lookup, TCP connect, TLS handshake and request wait.
Scope
What does the server response time checker measure?
The server response time checker measures four phases before the first response byte arrives: DNS lookup, TCP connection, TLS handshake for an HTTPS address, and request to first byte. Alongside the timings, the tool reads the HTTP status, the protocol and TLS version, the visible server header and any redirect location.
Who it is for
Who is the server response time checker for?
The server response time checker is for anyone who must decide whether a slow page starts at the server. A developer runs it after a deploy or a cache change, a site owner runs it before blaming a host, and an SEO specialist runs it to separate backend delay from rendering problems.
Why it matters
Why use a server response time checker?
A server response time checker catches a slow first byte before it delays everything the browser loads afterward. Splitting the total into connection setup and request wait shows whether time is lost to distance, DNS or TLS, or to origin and cache behavior, so the repair goes to the right layer.
Method
How does the server response time checker work?
The server response time checker works in four steps. The address is validated as a public HTTP or HTTPS target. DNS is timed while the connection stays pinned to the validated public IP. A fresh TCP connection opens, with TLS for HTTPS. GET is sent and the clock stops at the first response bytes.
- We normalize the address, open a fresh HTTP/1.1 connection from one Novaverb server and time each phase separately.
- We record DNS lookup, TCP connect, TLS handshake, request wait and total Time To First Byte (TTFB).
- We band the TTFB against Google's public web.dev field guidance at the 75th percentile - orientation, not a pass/fail verdict.
- We exclude browser rendering entirely; this measures the server, not Core Web Vitals.
Input
What do you enter into the server response time checker?
Enter any public address into the server response time checker, either a bare domain or a full URL with a path or query string. The address is normalized before the request, and private or reserved hosts are refused. Redirects are not followed, so a redirecting address reports only the timing of its redirect response.
Use it like this
yourdomain.comAny address form is fine. http or https, with or without www, a bare domain or a full path - we normalize it for you.Run it a few timesRead the trend, not one number - a single request varies with cold caches.Avoid this
Reading it as 'my users' real speed'This is one synthetic request from Germany, not your visitors' experience - treat it as a backend baseline.Expecting Core Web Vitals hereThis measures server timing (TTFB), not browser rendering - use the Core Web Vitals tool for field vitals.Result
What does a server response time checker report contain?
A server response time checker report contains the connection to first byte total with its guide band, a split between request wait and connection setup with each share of the total, and one card per measured phase. Further rows show HTTP status, protocol, server header, redirect target and, when response headers reveal it, a cache hit or miss.
Reading it
How do you read a server response time result?
Read a server response time result by finding the largest phase first. A high request wait points toward origin or cache behavior, while high DNS, TCP or TLS phases point toward distance or transport setup. The guide band is orientation for one synthetic sample, so run the test several times and compare the trend.
What does the Server Response Time Checker measure?
It opens one fresh HTTP connection from Novaverb's server in Germany and measures four phases before the first response byte arrives: DNS lookup, TCP connection, TLS handshake and request-to-first-byte. Their sum is the synthetic connection-to-first-byte time shown in the result.
How the response-time test works
Validate the URL
Only public HTTP or HTTPS targets are accepted. Private and reserved addresses are rejected.
Resolve and pin the IP
DNS is timed, while the connection uses the already validated public IP to prevent DNS rebinding.
Open a fresh connection
The probe measures TCP and, for HTTPS, TLS without reusing a previous connection.
Read the first byte
After sending GET, the probe stops the TTFB clock when the first response bytes arrive.
How to interpret the TTFB guide bands
web.dev presents 800 ms or less as a rough good TTFB target and above 1,800 ms as poor. Those bands are designed for user-experience interpretation; here they are orientation only for one synthetic sample.
Re-test and compare from relevant user regions before concluding the URL is consistently fast.
Use the phase breakdown to see whether connection setup or request-to-first-byte dominates.
Repeat the test, compare cached and uncached behavior, then investigate the dominant measured phase.
What this result includes - and what it does not
Measured in this run
- One DNS lookup from the Novaverb server
- One new TCP connection to the validated public IP
- One TLS handshake for an HTTPS URL
- Time from sending the request until the first response byte
- HTTP status, redirect location, protocol and visible server header
Not measured or proven
- Real-user or browser TTFB from your visitors' locations
- LCP, CLS, INP, FCP or any Core Web Vitals assessment
- JavaScript execution, rendering, visual completion or interaction readiness
- Uptime, percentile distribution or performance under sustained load
- Pure application execution time separated from network return latency
What commonly makes the first byte slow?
Slow authoritative DNS, resolver distance or an uncached lookup can increase the first phase.
Long network distance and packet loss add round trips before any HTTP request is sent.
A fresh HTTPS connection requires cryptographic negotiation; reuse and modern TLS can reduce repeated cost.
Database queries, API calls, application code and resource contention can delay response generation.
A cache miss may force the edge to contact the origin, while a hit can return much faster.
Every redirect adds another request and possibly another DNS, TCP and TLS setup before the final page.
Standards and measurement guidance
W3C, Navigation Timing Level 2Defines responseStart as the point immediately after the first response byte is received.
web.dev, Optimize TTFBExplains the rough 800 ms and 1,800 ms guide bands and why TTFB is not a Core Web Vital.
RFC 9110, HTTP SemanticsThe HTTP status and response semantics underlying the measured request.
Server response time questions
Is this the same TTFB my visitors experience?
No. It is a synthetic request from one server in Germany. A visitor may use a different region, network path, protocol, cache state and reused connection.
Is TTFB a Core Web Vital?
No. TTFB is a foundational diagnostic metric, but the Core Web Vitals are LCP, INP and CLS.
Does request-to-first-byte equal backend processing time?
No. It includes application or CDN processing plus the network time for the first bytes to return to the probe.
Does the checker follow redirects?
No. It times the exact submitted URL. If that response redirects, the destination is shown so you can test it separately.
Why does the result change between runs?
DNS and CDN cache state, origin load, network routing, congestion and shared infrastructure can all vary. Compare multiple samples and field data.
What should I fix first?
Start with the largest repeated phase. A high request wait points toward origin or cache behavior; high connection phases point toward distance, DNS or transport setup.
This is a single synthetic server-side measurement from one location (EU, Germany), not a real user's browser TTFB or field Core Web Vitals.
Source
Where does the server response time checker get its data?
The server response time checker gets its data from one live HTTP/1.1 request over a fresh connection, sent from Novaverb's server in Germany when you run it. Every phase shown is timed during that request. If the probe cannot complete a public connection within the timeout, the tool reports that no response time was measured.
Limits
What does the server response time checker not tell you?
The server response time checker does not tell you what visitors experience. One synthetic server-side request from Germany is not a visitor's browser TTFB, field data, Core Web Vitals, uptime monitoring or a global multi-location test. Request wait also includes the network return path, so it is not pure application execution time.
Evidence
What does a server response time result prove?
A server response time result proves how long one server took to send the first byte to one Novaverb server on one run, and which phase consumed that time. It cannot prove the page is fast or slow for real users, because no browser rendering happens and a cached hit and a cold miss can differ widely.
1. Source
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. Boundary
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. Next action
Use the finding to verify a problem, then connect a workspace when you need history, monitoring, or site-wide analysis.
Standards
Which standards does the server response time checker apply?
The server response time checker applies W3C Resource Timing, RFC 9110 and the web.dev Time to First Byte guidance. Resource Timing defines the DNS, TCP, TLS and wait phases that are timed. RFC 9110 defines the HTTP semantics of the request and response. The guidance supplies the guide bands, which describe a 75th percentile field distribution.
W3CResource Timing
Resource & Navigation Timing
Breaks the request into the DNS, TCP, TLS and wait (TTFB) phases of the W3C timing model.
Read the specificationIETFRFC 9110
HTTP Semantics
Issues a standards-compliant HTTP request and reads the response status.
Read the specificationGoogleweb.dev TTFB
Time to First Byte guidance
Orients your measured TTFB against the public 800 ms field-guidance band.
Read the specificationWe list a standard only where this tool genuinely reads or measures against it. Where a signal is outside a live check, the result says so instead of implying coverage.
Verification
How can you verify a server response time result yourself?
Verify a server response time result by timing the same URL with a command-line HTTP client that prints DNS, connect, TLS and first byte times, or by reading the document request in the browser network panel. Expect different absolute numbers from another location, and compare which phase dominates instead of the totals.
Example
What does a typical server response time finding look like?
A typical server response time finding is a page whose request wait dominates the total while DNS, TCP and TLS stay small, with a response header marking a cache miss. That pattern points at origin work or caching, not distance. A second run that returns a cache hit can report a much shorter wait.
Cost
Is the server response time checker free?
The server response time checker is free and needs no account to run a live request and see the full phase breakdown. A free Novaverb account is needed only for what one public run cannot do: saving the evidence, monitoring response time over time and turning a finding into a rechecked task.
In a workspace
What does a Novaverb workspace add to the server response time checker?
A Novaverb workspace adds saved evidence, monitoring over time and site-wide analysis to the server response time checker, which measures one URL once. Site Health Audit continues the job: it evaluates the URLs captured by a crawl of the whole site against supported technical checks, orders the findings by severity and records fresh rechecks.
When to go further
When is a free server response time checker not enough?
A free server response time checker is not enough when the question covers more than one URL at one moment. Judging a whole site, proving that a fix held after release, watching for a slowdown under load, or comparing the regions where customers live all need recurring or site-wide measurement, not a single sample.
Next step
What should you do after running the server response time checker?
After running the server response time checker, repeat the test to confirm the pattern, then compare cached and uncached behavior. Investigate the dominant phase next: caching and origin work for a high request wait, DNS or distance for slow setup. If the URL redirected, test the destination separately, then compare with field data.
Related tools
Which free tools pair with the server response time checker?
Several free tools pair with the server response time checker. The Website Performance Test adds community probes in other regions and an HTML transfer phase. The HTTP Status & Redirect Checker traces the redirect chain this tool does not follow. The Core Web Vitals Checker shows the real-user field data a server timing cannot.
Website SEO CheckerHomepage status, indexability, title, headings and links from one live scan
Keyword Research ToolFree keyword research tool: monthly searches, cost per click, ad …
SERP CheckerFree SERP checker: the organic results for a keyword in …
Website Security CheckerFree website security checker: a limited outside check of a …
WordPress Security Configuration CheckerFree WordPress security checker: eight public configuration areas on a …
Backlink CheckerFree backlink checker: see the referring domains, link totals, follow …
Robots.txt CheckerFree robots.txt tester: fetch a site's live robots.txt and see …
Sitemap CheckerFree sitemap checker: find a site's XML sitemaps from robots.txt …
Meta Tag CheckerFree meta tag checker: a page's live title, meta description, …
HTTP Status & Redirect CheckerFree redirect checker: trace every hop of a URL's redirect …
Website MonitorFree website status checker: one live request to your address …
HTTP/2 TestFree HTTP/2 test: opens one live TLS connection to a …
HTTP/3 TestFree HTTP/3 test: attempts a real QUIC connection to a …
Website Performance TestFree website performance test: time one request to your URL …
GEO CheckerFree GEO checker: retrieve, quote, cite and graph signals from …
Core Web Vitals CheckerFree Core Web Vitals checker: real-user LCP, INP and CLS …
PageSpeed CheckerFree PageSpeed checker: a Lighthouse lab audit of a public …
Website Safety CheckerFree website safety checker: see whether a URL is listed …
Knowledge Graph CheckerFree Knowledge Graph checker: look up a brand or name …
Keyword Gap CheckerFree keyword gap analysis: keywords a competitor ranks for and …
Competitor Top PagesFree competitor top pages tool: a domain's leading pages by …
Questions
What do people ask about the server response time checker?
People ask the server response time checker FAQ what TTFB is, what a good value looks like, and whether the number matches what visitors experience. Other questions cover why DNS or TLS varies between runs, whether redirects are followed, how first byte differs from page load time, and what to fix first.
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?
There is no single number that fits every site. This checker bands your measured TTFB against Google's public web.dev field guidance at the 75th percentile and shows the verdict beside the value, so the band moves when the guidance does. Treat a synthetic result as a backend baseline; real users add distance and device time on top.
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 behavior. 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.