DNSResolve
Free tool, no account required
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.
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
Evidence model
Know what the result proves
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. 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.
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.
Get the right answer
What to submit - and what to avoid
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.
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.Public methodology
Exactly how this result is produced
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.
- 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 public web.dev field guidance (≈800 ms at the 75th percentile) - orientation, not a pass/fail verdict.
- We exclude browser rendering entirely; this measures the server, not Core Web Vitals.
Built on public standards
The international standards this check applies
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
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.
Common questions
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.
More free checks
Explore all Novaverb Free Tools
Website SEO CheckerCrawl coverage, indexable pages, and internal links
Keyword Research ToolCheck the exact query's available search volume, keyword difficulty and …
SERP CheckerInspect the returned organic results for a keyword and country, …
Website Security CheckerAudit website security posture, TLS/SSL certificates, HTTP security headers, and …
WordPress Security Configuration CheckerCheck eight externally observable WordPress configuration areas: XML-RPC, wp-login.php, debug …
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 CheckerDiscover sitemap declarations, inspect the root document and fetch a …
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 MonitorRun one live availability check and retain an evidence sample …
HTTP/2 TestCheck whether the exact submitted hostname negotiates HTTP/2 through TLS …
HTTP/3 TestTest whether your web server supports HTTP/3 over QUIC with …
Website Performance TestCompare HTTP response timing from available probe locations and inspect …
GEO CheckerInspect observable page signals that support retrieval, answer extraction, attribution …
Core Web Vitals CheckerCheck 75th-percentile real-user LCP, INP and CLS from Chrome field …
PageSpeed CheckerRun one Lighthouse lab audit to inspect performance, accessibility, best-practices …
Website Safety CheckerCheck whether a domain or URL is flagged for malware, …
Knowledge Graph CheckerLook up matching entities for a brand, person, product or …
Keyword Gap CheckerFind ranking keywords observed for a competitor and not observed …
Competitor Top PagesFind the pages with the highest estimated organic traffic in …