Server Response Time and TTFB: How to Speed Up Your Server

Short answer: time to first byte (TTFB) is how long it takes from requesting a page until the first byte of the response arrives. It includes redirects, DNS, connection setup and the time your server needs to build the page. Google’s guidance treats about 0.8 seconds or less as good. The biggest improvements usually come from full-page caching, fixing slow database queries and plugins, better hosting and a CDN; slow TTFB delays LCP on every page and makes crawlers fetch fewer pages.

What TTFB includes

TTFB is not only “server processing time”. From the browser’s point of view, it covers everything before the first byte of HTML arrives:

1. Redirects, if the requested URL redirects before reaching the final page.
2. DNS lookup to find the server’s IP address.
3. Connection setup: TCP and the TLS handshake for HTTPS.
4. Request travel time to the server.
5. Server processing: running the application, querying the database, building HTML.
6. First byte travel time back to the browser.

On an uncached dynamic site, server processing usually dominates. On a well-cached site, network distance and connection setup matter more. The metric is described on web.dev’s TTFB page, which suggests 0.8 seconds or less as a rough guide for most sites.

Why server response time matters for SEO

TTFB is not a Core Web Vital itself, but it sits underneath all of them:

• It delays LCP. Nothing can render before the HTML arrives. If TTFB is 1.5 seconds, reaching a 2.5-second LCP leaves only one second for everything else.
• It affects crawling. Search engines adjust their crawl rate to how quickly and reliably your server responds. Slow responses mean fewer pages crawled per day, which matters on larger sites.
• It affects every page. A slow server is a site-wide problem, unlike a heavy image on one page.
• It affects users on every click. Each page view starts with the wait.

How to measure it properly

The most common mistake is measuring only the home page, often while it is cached, and concluding the server is fast. Better measurement:

• Measure many pages, including products, deep articles, category pages with filters and search results. Uncached and rarely visited pages are where slow TTFB hides.
• Use field data: PageSpeed Insights shows real-user TTFB for URLs and origins with enough traffic, and real user monitoring gives you your own numbers.
• Use the command line: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://www.example.com/page/ prints the time to first byte for a single request. Run it several times, because the first request may warm a cache.
• Check Search Console crawl stats, which show the average response time Googlebot experienced over the last three months. A rising line is an early warning.
• Test from where your visitors are. A server in one country will look fast from nearby and slow from another continent.

Fix 1: cache full pages

For most content sites and many shops, full-page caching is the single most effective fix. Instead of running the application and database for each request, the server returns a stored copy of the HTML.

• WordPress: use a caching plugin or, better, server-level caching provided by the host. Confirm that logged-out visitors receive cached pages by checking the response headers.
• Cache exclusions: carts, checkouts, account pages and personalised content must be excluded. Everything else usually can be cached.
• Cache warm-up: pages that are rarely visited may never be in the cache. Preloading or warming the cache for important URLs helps both visitors and crawlers.
• Edge caching: a CDN that caches HTML, not just images, serves pages from locations near the visitor.

Fix 2: find what makes uncached pages slow

Caching hides problems but does not remove them. Uncached pages, logged-in users and cache misses still hit the application. Common causes of slow processing:

• Plugins that run on every request: related-post calculations, statistics, security scanning, translation lookups, heavy page builders.
• Slow database queries, often from large options tables with autoloaded data, missing indexes, or queries on product meta in large shops.
• External API calls made while building the page, such as fetching social counts, exchange rates or stock levels from another service.
• Outdated software: older PHP versions are noticeably slower than current ones.
• No object cache, so repeated database queries are recalculated on every request.

A profiling tool or a query monitor plugin on a staging copy shows which component takes the time. Remove or replace the slowest one first.

Fix 3: hosting and infrastructure

Sometimes the server itself is the limit:

• Shared hosting with CPU limits slows down under load, including during heavy crawling.
• Too few PHP workers or application processes make requests queue during traffic peaks.
• Server location far from most visitors adds network time to every request.
• Old protocols: HTTP/2 or HTTP/3 and TLS 1.3 reduce connection overhead.

Upgrading hosting is often cheaper than weeks of optimisation work, but only after caching and obvious code problems are addressed, otherwise a bigger server simply runs the same waste faster.

Fix 4: remove avoidable delays before the server

• Redirects: links, ads, e-mails and internal links should point to the final URL. Each redirect adds a full round trip before the real TTFB starts.
• DNS: a fast DNS provider reduces lookup time, particularly for first-time visitors.
• TLS configuration: session resumption and modern TLS versions shorten repeat connections.

A step-by-step plan for a slow WordPress site

WordPress powers a large share of small-business sites, and slow TTFB on WordPress follows familiar patterns. A practical sequence that works on most installations:

1. Take a baseline. Measure TTFB on ten representative URLs, several times each, with and without a cache-busting parameter. Note the numbers.
2. Update PHP and WordPress. Moving to a current PHP version supported by your plugins is one of the cheapest speed gains available.
3. Enable full-page caching through the host’s server cache or a single caching plugin. Do not stack several caching plugins; they conflict.
4. Add a persistent object cache such as Redis or Memcached if the host offers it. It speeds up uncached pages and the admin area.
5. Audit plugins. Deactivate plugins one by one on a staging copy and measure uncached TTFB. Many sites find one or two plugins responsible for most of the processing time.
6. Clean the database. Remove expired transients, old revisions and autoloaded options left behind by plugins you no longer use.
7. Check scheduled tasks. WordPress cron runs on page requests by default. Heavy scheduled jobs can slow random visitors; moving cron to a real server scheduler avoids that.
8. Measure again with the same URLs and compare with the baseline.

For WooCommerce shops, pay extra attention to cart fragment requests, product filtering widgets and large product meta tables, which are frequent sources of slow uncached responses.

Typical causes and fixes at a glance

How Site SEO AI Audit measures server response

SEOAuditBot measures the server response time of every page it crawls, not only the home page, so slow sections and uncached templates become visible. The speed and Core Web Vitals area combines this with compression, page weight and Google PageSpeed data. Because the score weighs each issue by the share of pages it affects, a site-wide slow server shows up clearly at the top of the fix list. The crawler itself stays polite at about three requests per second. See plans for page limits.

Related reading

• How to fix a slow Largest Contentful Paint (LCP)
• Crawl budget explained: when it matters and how to save it
• Core Web Vitals explained: LCP, INP and CLS in plain words
• Redirect chains and loops: how to find and fix them

The bottom line

Server response time is the foundation of page speed. Measure it on many pages, not just the cached home page. Cache full pages for anonymous visitors, find and remove slow plugins and queries, keep software current, remove redirects and use a CDN. Faster responses help visitors, Core Web Vitals and crawling at the same time.

FAQ

What is a good TTFB?

As a rough guide, 0.8 seconds or less is considered good for most sites. Well-cached pages often respond much faster. Measure real-user data and many different pages, not only the home page.

Is TTFB a Core Web Vital?

No. The Core Web Vitals are LCP, INP and CLS. TTFB is a supporting metric, but it directly delays LCP, so a slow TTFB makes a good LCP very hard to reach.

Does server response time affect crawling?

Yes. Search engines reduce crawl rate when a server responds slowly or with errors. On larger sites, faster responses allow more pages to be crawled in the same time.

Will a CDN fix a slow TTFB?

A CDN that caches HTML can greatly reduce TTFB, especially for distant visitors. A CDN that only caches images and scripts will not help the HTML response, which still comes from your slow server.

Why is my TTFB fast in tests but slow for visitors?

Tests often hit cached pages from nearby. Real visitors reach uncached pages, come from far away, use mobile networks or arrive through redirects. Field data from real users shows the true picture.