DNSResolve
Free tool, no account required
Test Your Website From Different Locations
The Novaverb website performance test times one HTTP request to your URL from a probe in Germany or from community probes in ten cities, and shows DNS, TCP, TLS, first byte and HTML transfer.
Also known as: TTFB, page speed waterfall, DNS/TLS timing
Evidence shown with sourceNo account requiredNo invented metrics
One URL, five measured phases
See the connection before the page can render
The Germany probe follows HTTP redirects, measures every request, then visualizes the final document response without inventing browser or Core Web Vitals data.
TCPConnect
TLSSecure
First byteRespond
HTMLTransfer
Public targets only, live request from Germany, no estimated timing
Definition
What is a website performance test?
A website performance test times how a server and network deliver one page request. The Novaverb Website Performance Test measures DNS, TCP, TLS, request to first byte and document transfer for a public URL, from Novaverb's probe in Germany, from one community probe city, or from ten cities compared side by side.
Scope
What does the website performance test measure?
The website performance test measures five phases of one request: DNS lookup, TCP connect, TLS handshake, request to first byte and HTML transfer. In Germany mode the tool also records each redirect hop, the final response headers, the content encoding, the TLS version, the body bytes received and the declared content length.
Who it is for
Who should test a website from different locations?
Teams with visitors in more than one region should test a website from different locations. A developer checks whether a CDN serves distant users from an edge, a site owner compares a home market with an export market, and an SEO specialist looks for the delivery stage that slows a key landing page.
Why it matters
Why run a website performance test?
A website performance test exposes a delivery gap before customers in a distant region meet it. A single total hides which stage is slow, so the waterfall reports each phase separately, and comparing cities shows whether delay comes from distance to the origin, missing edge coverage or slow work before the first byte.
Method
How does the website performance test work?
The website performance test submits the exact public URL to the selected live probe and keeps that probe's location with the result. The probe resolves DNS, opens a fresh TCP connection, negotiates TLS, sends GET, times the first byte and then times the document transfer. Only the phases that probe returns are shown.
- We submit the exact public URL to the selected live probe and retain that probe's location with the result.
- We show only the timing phases returned by that probe; Novaverb's own probe provides the most detailed split.
- We label each location as one synthetic sample and exclude browser rendering, subresources and real-user field data.
Input
What do you enter into the website performance test?
Enter the exact public address into the website performance test, including its path and query when they matter, then choose a measurement location. A bare domain is normalized to a full URL. A private host is refused. Redirect handling depends on the mode you select and is stated with the result.
Use it like this
yourdomain.comAny address form works. http or https, with or without www, a bare domain or a full path - we normalize it for you.A URL that redirectsFine - we trace every hop first, then measure the final destination.Avoid this
Expecting full page-load / render timeThis times the server and connection phases (TTFB), not browser rendering of the whole page.Expecting your users' field numbersIt is one synthetic request from a fixed location - use Core Web Vitals for real-user field data.Result
What does a website performance test report contain?
A website performance test report from the Germany probe contains the final response TTFB with its guide band, the measured request total, a five-phase waterfall with each share, a redirect journey and the final response headers. A multi-location report lists every city with its TTFB, total request time and phase timings, plus the fastest and slowest location.
Reading it
How do you read a website performance test result?
Read a website performance test result by looking for the phase that dominates the waterfall. High DNS suggests the name servers, high TCP suggests distance or route quality, high first byte wait suggests cache misses or origin work, and high HTML transfer suggests document size or encoding. Across cities, look for large gaps between regions.
What does the Website Performance Test measure?
It measures DNS, TCP, TLS, request-to-first-byte and document transfer for a public URL. Choose Novaverb's Germany direct probe, one Globalping community location, or compare ten cities across Asia, Europe, the Americas, Africa and Oceania.
Measurement methods, locations and free limits
Choose the Novaverb direct probe for a controlled measurement, one Globalping city for a regional check, or all ten cities for a five-region comparison. The two methods stay separate because they have different redirect, capture and retention boundaries.
🇩🇪 Germany location
- Runs on Novaverb infrastructure over a fresh HTTP/1.1 connection.
- Follows up to five HTTP redirects and shows the final response waterfall.
- Captures the response body up to about 3 MB and keeps declared length separate.
- Does not consume third-party probe tests.
🌍 One city or all 10
- A currently online probe in the selected city requests the exact submitted URL.
- Returns DNS, TCP, TLS, first-byte, download and total timing with city and timing evidence.
- Does not follow Novaverb's redirect loop; test a returned 3xx destination separately.
- Probe identity metadata is intentionally hidden from the public result.
- The target and measurement are processed by Globalping and may remain retrievable for up to seven days.
How free use is limited: each selected city runs one live request. Comparing every location runs several requests, so temporary capacity limits may apply. If a probe is unavailable, Novaverb leaves that location unmeasured instead of estimating a result.
How the performance waterfall works
DNS lookup
Resolve the hostname, while the connection remains pinned to the validated public IP.
TCP connect
Open a fresh connection; no previous socket is reused.
TLS handshake
Negotiate HTTPS with SNI and HTTP/1.1 when the URL is secure.
First byte
Measure from sending GET until the first response bytes arrive.
HTML transfer
Measure from first byte through the captured document body, up to about 3 MB.
How to read the TTFB guide bands
web.dev gives 800 ms or less as a rough good TTFB target and above 1,800 ms as poor. Novaverb applies those guide bands to the final response's connection-to-first-byte sample, not to the complete redirect journey.
Repeat from user-relevant regions before concluding the URL is consistently fast.
Use the waterfall to identify whether setup or request wait dominates.
Retest, compare cache states and investigate the largest repeated phase.
What this result includes - and what it does not
Measured in this run
- Fresh DNS, TCP and TLS setup for every request
- Request-to-first-byte and captured body transfer
- HTTP redirects, status and final response headers
- Body bytes received and declared Content-Length kept separate
- One measuring region: EU, Germany
Not measured or proven
- CSS, JavaScript, images, fonts or third-party resources
- Browser parsing, rendering, visual completion or interaction readiness
- LCP, INP, CLS, FCP or a Lighthouse performance score
- Real-user percentiles, uptime or sustained-load behavior
- Pure origin execution time separated from CDN and network latency
How to improve the dominant phase
High DNS time
Review authoritative DNS latency and reliability; compare multiple runs because resolver cache state varies.
High TCP time
Reduce distance with an edge or CDN and investigate route quality or packet loss.
High TLS time
Check certificate chain, modern TLS support and connection reuse in actual browsers.
High first-byte wait
Inspect CDN cache misses, database work, external calls and application or origin contention.
High HTML transfer
Reduce document size and verify appropriate content encoding, while remembering this test captures only the document.
Standards and measurement guidance
W3C, Navigation TimingDefines navigation phases including requestStart, responseStart and responseEnd.
W3C, Resource TimingDefines response timing and distinguishes transferred and encoded body sizes.
web.dev, Optimize TTFBExplains the rough 800 ms and 1,800 ms guide bands.
RFC 9110, HTTP SemanticsDefines the HTTP methods, status and response semantics used by the probe.
Globalping, API specificationDefines community probe selection, HTTP timing fields, polling, free limits and result retention.
Website performance test questions
Is this a complete page-speed test?
No. It measures connection and document-response timing only. A complete browser test must also load dependencies, execute scripts and render the page.
Why is this different from Chrome or Lighthouse?
The probe runs from a server in Germany over a fresh HTTP/1.1 connection. Your browser can use another route, protocol, cache and reused connection, then perform rendering work this test never attempts.
Does it follow redirects?
Yes, up to five HTTP redirects. Each hop is independently measured with a fresh request; the main waterfall is the final response.
Does total time mean page load time?
No. It is the sum of connection phases and captured document transfer for one request. It excludes subresources, code execution, rendering and interaction readiness.
Why can downloaded bytes differ from Content-Length?
Content-Length is a server-declared header. Body received is what this bounded probe actually captured; large responses may stop near the 3 MB safety limit.
Why do results change between runs?
DNS and CDN cache state, origin load, network routing and shared infrastructure vary. Diagnose patterns across repeated samples and real-user data, not one run.
Each number is a single synthetic request from the selected probe; it does not measure browser rendering, Core Web Vitals or real users.
Source
Where does the website performance test get its data?
The website performance test gets its data from live probes: Novaverb's own probe in Germany, or community probes that are online in the selected cities. Each number is one fresh HTTP request measured by that probe at that moment. When no matching probe returns a completed measurement, the location is marked unavailable.
Limits
What does the website performance test not tell you?
The website performance test does not tell you how a page renders or what real users experience. Each number comes from the selected probe. Germany mode follows redirects and captures up to about 3 MB, while community-probe mode measures the exact submitted URL. Neither mode loads CSS, JavaScript, images or fonts, or measures Core Web Vitals.
Evidence
What does a website performance test result prove?
A website performance test result proves the request timings the selected probe supplied for one request at one moment. From it you can conclude which phase took longest from that location. You cannot conclude page load time, a lab audit score or a persistent regional difference, because every location is a single synthetic sample.
1. Source
Novaverb's Germany probe or selected community probes. The result identifies where its evidence came from.
2. Boundary
Each number comes from the selected probe. Novaverb's Germany mode follows redirects and captures up to about 3 MB; community-probe mode measures the exact submitted URL. Neither mode measures rendering, Core Web Vitals or real users.
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 website performance test apply?
The website performance test applies W3C Navigation Timing, RFC 9110 and the web.dev Time to First Byte guidance. Navigation Timing defines the DNS, connection, TLS, wait and transfer phase model. RFC 9110 defines the HTTP semantics used to follow the redirect chain. The guidance supplies the band applied to the final response sample.
W3CNavigation Timing
Navigation & Resource Timing
Labels available request phases using the common DNS, connection, TLS, wait and transfer model.
Read the specificationIETFRFC 9110
HTTP Semantics
Follows the redirect chain per HTTP semantics before the final measurement.
Read the specificationGoogleweb.dev TTFB
Time to First Byte guidance
Bands the measured TTFB against public field guidance.
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 website performance test result yourself?
Verify a website performance test result by repeating the same URL from the same location and checking that the dominant phase stays the same. For the Germany probe, a command-line HTTP client that prints per-phase timings gives an independent comparison, and the final response headers in the report can be matched against your own request.
Example
What does a typical website performance test finding look like?
A typical website performance test finding is a URL that answers quickly in the cities near its origin and slowly in a distant region, with the extra time sitting in TCP, TLS and first byte. That pattern suggests distant visitors reach the origin directly instead of a nearby edge, which is a delivery problem.
Cost
Is the website performance test free?
The website performance test is free and needs no account, in Germany mode and with community probes. Comparing every city runs several live requests and depends on which community probes are online, so an unavailable location is left unmeasured. An account is needed for saved evidence, recurring measurement and tasks that are rechecked.
In a workspace
What does a Novaverb workspace add to the website performance test?
A Novaverb workspace adds what one website performance test cannot keep: saved evidence, monitoring over time and analysis of the whole site from a crawl. Site Health Audit continues the job by grading the crawled URLs against a defined criteria library, ranking the findings into a work-list and re-running a check against fresh evidence.
When to go further
When is a free website performance test not enough?
A free website performance test is not enough when one sample cannot answer the question. Rendering, interactivity and Core Web Vitals need browser lab and real-user data. A regional slowdown that comes and goes needs repeated measurement on a schedule. A site with many templates needs every important URL measured, not the single one submitted.
Next step
What should you do after you test a website from different locations?
After you test a website from different locations, rerun the slow location to confirm the gap is persistent. Then work on the dominant phase: DNS reliability, an edge or CDN for distance, certificate and TLS setup, cache misses and origin work for first byte wait, or document size for HTML transfer. Retest when the change is live.
Related tools
Which free tools pair with the website performance test?
Free tools that pair with the website performance test cover what a connection probe leaves out. The Server Response Time Checker gives a fixed Germany baseline with cache hit or miss state. The PageSpeed Checker runs a lab audit that loads the page in a controlled environment. The Core Web Vitals Checker reports real-user field data.
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 …
Server Response Time CheckerFree server response time checker: one live request from Germany, …
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 …
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 website performance test?
People ask the website performance test FAQ whether this is a complete page-speed test, why results differ from a browser or a lab audit, and whether redirects are followed. They also ask what the connection waterfall is, why timings differ by probe location, why downloaded bytes differ from Content-Length, and how to improve distant regions.
What does the Novaverb Website Performance Test measure?
It measures the full connection waterfall for a URL, DNS lookup, TCP connect, TLS handshake, Time To First Byte, and HTML transfer, from Novaverb's Germany probe or selected community probes placed across world regions.
How is this different from the single-location speed check?
The speed check runs only from Germany. This performance test can additionally run from community probes in multiple world regions, letting you compare connection timing across geographies rather than from one fixed vantage point.
Does this test measure Core Web Vitals or rendering?
No. Each number reflects network and server connection timing only. It does not run a browser, so it cannot measure Largest Contentful Paint, layout shift, interactivity, JavaScript execution, or anything about how the page visually renders.
What is the connection waterfall in this test?
It is the ordered breakdown of a request: DNS resolves the hostname, TCP establishes the connection, TLS negotiates encryption, TTFB captures server wait, and HTML transfer downloads the initial document. Each stage exposes where time is spent.
Why are timings different from each probe location?
Each probe is a separate physical location, so distance to your server and CDN edge changes DNS, connection, and transfer times. Regions far from your hosting or without nearby edge nodes will consistently show higher latency.
What is a good TTFB across regions?
Aim for a result inside the good band in your primary markets and reasonably consistent numbers elsewhere. Large gaps between regions usually indicate missing CDN coverage or origin-only serving for distant users, which a content delivery network can flatten.
How do I improve performance for distant regions?
Put a CDN in front of your origin so static assets and cached HTML serve from edge nodes near users. Also enable modern protocols and caching so far-away regions are not paying full origin round-trips.
Is one probe measurement reliable on its own?
Treat each number as a single sample from one probe at one moment, subject to transient network conditions. Run repeated checks and compare trends across regions rather than drawing conclusions from any isolated measurement.
Does this test represent what real users experience?
Not exactly. Probes approximate network paths but are not your actual visitors on their devices, browsers, and connections. Use this for comparing server and network delivery across regions, and pair it with field data for true real-user performance.
Why compare response time across regions?
Distance and routing can change connection and first-byte time. Regional probes help locate delivery gaps, but they do not measure browser rendering, real users or search-engine behavior.