Response Time: a beginner's guide
Measure server response latency
Response time: what your server's stopwatch is really measuring
Response time is the umbrella term for how long a web server takes to respond to a request. The most common specific measurement is time to first byte (TTFB), which is the time from when the client sends the request to when the very first byte of the response arrives. TTFB captures everything that happens before the page content starts streaming: DNS lookup, TCP connection, TLS handshake, request transmission, server processing, database queries, and the start of the response. It is the fastest, simplest, single-number proxy for "how responsive does this server feel?" — and it is one of the most important inputs into a user's perception of speed.
You should care because TTFB is the floor of every other web performance metric. If your TTFB is 1.5 seconds, then every page load on your site has at least 1.5 seconds of latency before anything can render. No amount of JavaScript optimization, image compression, or CDN tuning will make a slow TTFB faster. Google's official guidance is that TTFB should be under 600 ms for a "good" experience and under 1.8 seconds at the absolute outside. Most modern websites can hit 200-400 ms with reasonable infrastructure; the slow ones are usually slow because of unoptimized database queries, missing caches, or hosting in the wrong geographic region for their audience.
The five things every response-time measurement breaks down:
DNS resolution. How long it took to look up the domain (hopefully cached, hopefully fast).
TCP connection. How long the initial three-way handshake took (basically the network round trip).
TLS handshake. How long the encryption negotiation took (one or two round trips, depending on TLS version).
Request sending. How long the HTTP request itself took to transmit (usually negligible for GETs).
Server processing time. How long the server actually spent generating the response — this is the part you control, and the part that matters most for tuning.
Three questions a response-time check answers:
Is my server actually fast, or is the slowness coming from somewhere else?
Where in the stack (DNS, TCP, TLS, application) is the bottleneck?
For users in distant regions, how much of the slowness is geographic latency vs. server-side?
The cost of slow response times is the floor of your entire user experience being too high. The fix usually involves caching, database optimization, geographic distribution (a CDN), or all three. Measuring TTFB is the first step in any performance investigation, and is built into every modern browser's developer tools and every monitoring platform.
The Response Time endpoint, in plain language
In one sentence: Measure server response latency
Measures the time to first byte (TTFB) and total response time for a domain. Provides latency breakdown including DNS (Domain Name System), TCP connect, TLS (Transport Layer Security) handshake, and server processing time.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Performs timed HTTP (HyperText Transfer Protocol) requests and breaks down latency into components: DNS (Domain Name System) resolution, TCP connection establishment, TLS (Transport Layer Security) handshake, time to first byte, and total content transfer time.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Response Time tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Response time directly impacts user experience and SEO (Search Engine Optimization) rankings. Understanding the latency breakdown helps identify bottlenecks in DNS (Domain Name System), TLS (Transport Layer Security), or server processing.
Picture this in real life. Imagine an SRE. Here's the situation they're walking into: Monitor server response times to detect performance degradation. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Response Time tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Response Time tool is built for you:
Why does my website feel slow on real devices, even though it looks fine on mine?
Which specific change would give me the biggest speed boost for the least work?
Am I losing visitors and search rankings because of performance problems I cannot see?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Founders watching their conversion rates, marketers trying to lift landing-page revenue, ecommerce operators chasing every percentage point of speed, and developers tuning Core Web Vitals. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and visitors bounce, conversions drop, and your search ranking quietly slides — all from a problem nobody on the team can see. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the free plan. The technical details: `GET /v1/domain/response-time`.
When would I actually use this?
If you're still on the fence about whether the Response Time tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an SRE, a performance engineer, and a product manager — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Performance Monitoring
Imagine you're an SRE. Monitor server response times to detect performance degradation.
Why it matters: Identify performance issues before they impact users.
Story 2: Bottleneck Analysis
Imagine you're a performance engineer. Analyze latency breakdown to identify whether issues are in DNS (Domain Name System), TLS (Transport Layer Security), or server processing.
Why it matters: Focus optimization efforts on the right component.
Story 3: Competitive Benchmarking
Imagine you're a product manager. Compare response times against competitors to benchmark performance.
Why it matters: Set performance targets based on competitive landscape.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Response Time tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
Before a high-traffic marketing campaign or product launch.
After a redesign, to make sure performance did not regress.
When your conversion rate drops without an obvious cause.
On a recurring schedule, to enforce a performance budget for your team.
If you can see yourself in even one of those bullets, the Response Time tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Response Time tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Response Time tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/response-time?domain=example.com"What you need to provide
You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to measure response time for | example.com |
samples | number | Optional | Number of measurement samples (1-5, default: 3) | 3 |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
samples | number | Number of measurement samples taken |
timing | object | Aggregate timing stats (min, max, avg, median, p90, p99) in ms |
individual | array | Individual sample measurements (totalMs, ttfbMs) |
status | string | Performance rating: fast, acceptable, or slow |
statusDescription | string | Human-readable performance description |
recommendations | array | Performance improvement suggestions |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.
HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.
TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.
SEO (Search Engine Optimization) — Everything you do to help search engines like Google find, understand, and rank your website.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.