Server Response Time

Every millisecond of server delay pushes back Largest Contentful Paint, increases bounce rate, and compounds into lost rankings. TTFB is the foundation — fix it first before optimizing anything else on the page.

What is server response time?

Server response time measures how long a server takes to send the first byte of data back to a browser after receiving a request. The browser cannot parse HTML, load CSS, or request images until this first byte arrives — making TTFB the upstream bottleneck for every subsequent performance metric.

TTFB is composed of three sequential phases:

1. Redirect duration — time spent following HTTP redirects before reaching the final URL
2. Connection duration — time to complete TCP handshake and TLS negotiation
3. Backend duration — time for the server to process the request, query the database, and generate the response

The formula: TTFB = Redirect time + Connection time + Backend processing time

Why server response time matters for SEO

TTFB sits at the top of the page load waterfall. Every other metric — LCP, FCP, TBT — depends on a fast first byte. Three reasons this matters in practice:

1. Core Web Vitals dependency. Largest Contentful Paint cannot be fast if TTFB is slow. A 600 ms TTFB leaves only 1,900 ms to load and render the LCP element before crossing Google's 2,500 ms "good" threshold — extremely difficult at scale.
2. User abandonment. Every 100 ms of added latency increases abandonment probability before the page loads. For e-commerce, Amazon found a 100 ms delay reduces sales by 1%. That compounds across thousands of sessions.
3. Crawl efficiency. Googlebot also waits for TTFB. Slow server response reduces how many pages Google can crawl per session, shrinking effective crawl budget for large sites.

What are the TTFB benchmarks?

Google PageSpeed Insights and industry tools use a consistent scale:

How server response time is measured

TTFB is measured in milliseconds from the moment the browser sends the HTTP request to when the first byte of the response body is received. Most performance tools expose TTFB in their waterfall charts as the "waiting" phase of the first document request.

What causes slow server response time?

Diagnosing TTFB means isolating which of the three phases is slow. The most common culprits:

• Shared hosting — CPU and memory shared across hundreds of sites; any spike on a neighbour slows yours
• Unoptimised databases — slow queries, missing indexes, or bloated revisions/spam tables add hundreds of milliseconds per page request
• No caching — dynamic pages generated fresh for every visitor, even when content hasn't changed
• Heavy plugins or modules — each plugin adding PHP or Node processing overhead to every request
• Geographic distance — origin server in the US serving users in Asia adds 150-200 ms of network latency alone
• DNS resolution delays — slow DNS providers add 50-100 ms before any connection begins
• Redirect chains — each extra redirect adds a full round-trip before the final response starts

How to improve server response time

The fastest wins come from caching and hosting upgrades. Work down this list by impact:

1. Upgrade hosting. Move from shared to VPS, dedicated, or managed cloud. The jump from shared to VPS hosting typically cuts TTFB by 200-400 ms instantly.
2. Implement server-side caching. Cache rendered HTML at the CDN edge or with a page cache plugin. Pre-cached pages return in under 50 ms regardless of server power.
3. Use a CDN. Serve content from edge nodes close to users. A CDN alone can cut TTFB by 50-70% for international visitors.
4. Optimise the database. Add indexes to frequently queried columns, remove unused plugins, clean up post revisions. A database audit often recovers 100-300 ms.
5. Enable HTTP/2 or HTTP/3. Multiplexed connections eliminate the head-of-line blocking that slows HTTP/1.1 requests.
6. Enable compression. Gzip or Brotli compression reduces response body size and transfer time, particularly for large HTML pages.
7. Minimise redirects. Every redirect hop adds a round-trip. Use direct URLs wherever possible. Redirect to the final destination in one hop.

Tools to measure server response time

Server response time vs page load time — what's the difference?

TTFB and page load time measure different phases. Understanding the distinction prevents misdiagnosing performance problems.

6 best practices for server response time

1. Set a TTFB budget under 200 ms for all primary landing pages — not just the homepage.
2. Cache at every layer — CDN edge, object cache (Redis/Memcached), page cache, and opcode cache (OPcache for PHP).
3. Monitor from multiple geographic locations. A UK server may score 90 ms in Europe but 400 ms in Asia. Use WebPageTest's multi-region tests.
4. Test under load. TTFB during a 10-user test means nothing at 1,000 concurrent users. Use k6 or Loader.io to simulate realistic traffic.
5. Audit redirects regularly. Redirect chains accumulate over time. Run a crawl quarterly and collapse multi-hop chains to single hops.
6. Review after every major plugin or dependency update. A single bloated plugin can add 200 ms to every request without any other code change.

Common server response time mistakes to avoid

• Testing only from one location — TTFB varies by 200-400 ms depending on user geography
• Ignoring database optimisation — slow queries are the most common cause of high backend time
• Not caching authenticated pages — logged-in users hit uncached pages and see full backend time on every load
• Using a CDN without origin caching — cache misses still hit the slow origin server, defeating the purpose
• Relying on PageSpeed alone — lab data; use CrUX (real user data) to confirm actual TTFB for your visitors

Frequently asked questions

Related glossary terms

Sources

Akshay VR

Marketing Head · theStacc · ex-Sr Marketing Specialist, ARKA 360 · Malappuram, Kerala

Akshay leads editorial and content operations at theStacc. He writes about SEO craft, technical optimisation, and the performance decisions that compound into ranking wins — including the infrastructure choices most teams overlook.

LinkedIn Author page More terms by Akshay