Why Is My TTFB So High: How to Fix Time to First Byte

What TTFB measures and what counts as high

TTFB runs from the moment navigation starts to the moment the first byte of the response arrives. For a real visitor that includes more than your server's thinking time. It covers any redirects, the DNS lookup, the TCP connection, the TLS handshake, the time the request spends travelling, the time your server takes to build the page and the time the first byte takes to travel back.

TTFB is not one of the three Core Web Vitals, and Google describes these thresholds as a rough guide rather than a pass mark. It matters because it comes first. If the HTML takes 1.5 seconds to arrive, your LCP cannot be better than 1.5 seconds plus the time to load and draw the main element, which makes the 2.5 second LCP target very hard to meet. The LCP guide shows how TTFB fits into the four parts of LCP time.

In Lighthouse the related audit is called Reduce initial server response time, or document request latency in newer versions. It is measured from Google's test servers, so it shows the server's speed from one place at one moment. The TTFB in the field data section of PageSpeed Insights comes from real Chrome users and includes their redirects and network conditions.

Common causes of a high TTFB

Redirects are easy to miss because your own tests usually request the final URL. A visitor who types the bare domain or follows an old link may go from http:// to https://, then to www, then to a trailing slash version. Each step is a full round trip before your server even starts on the real page. The redirect chain guide explains how to collapse these.

How to measure TTFB and split it into stages

Use curl from a terminal, or from your server over SSH to remove network distance from the picture. This command prints each stage in seconds, measured from the start of the request:

curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" https://example.com/

Each figure is cumulative. Read the gaps between them:

• dns high: DNS lookup is slow. Rare once the record is cached, but it affects first visits.
• connect minus dns high: the server is far away or the network is congested.
• tls minus connect high: distance again, or an old TLS set-up without session reuse.
• ttfb minus tls high: your server is slow to build the page. This is the most common finding.

Run it five times in a row. The first result may include a cold cache; the later ones show the steady state. To compare cached and uncached responses, add a random query string, which most page caches treat as a new page:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" "https://example.com/?nocache=$RANDOM"
done

Add -L to follow redirects and see the total cost of a chain, and -I on its own to read headers such as x-cache, cf-cache-status or age, which tell you whether a cache answered.

In the browser

In Chrome DevTools, open the Network panel, reload, click the document request and open the Timing tab. Waiting for server response is the server time. The rows above it show the connection stages, and redirects appear as separate requests at the top of the list.

Ask the server where the time goes

A Server-Timing header lets your code report its own stages, and DevTools shows them in the Timing tab. For example, a page that reports database and template time:

Server-Timing: db;dur=420, tpl;dur=95, cache;desc="MISS"

The changes that cut TTFB most

Full-page caching

For pages that look the same to every visitor who is not logged in, the biggest win by far is serving a stored copy of the finished HTML instead of building it again. A cached page is typically returned in well under 100 ms from the server. On nginx you can cache responses from PHP-FPM directly:

# in the http block
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PAGES:50m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
map $http_cookie $skip_cache { default 0; ~wordpress_logged_in 1; }

location ~ \.php$ {
    fastcgi_cache PAGES;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    add_header X-Cache $upstream_cache_status;
    # existing fastcgi_pass and params here
}

Never cache pages that differ per visitor, such as baskets, checkouts and account pages, and make sure the cache bypasses logged-in users.

Find slow code

When pages must be built per request, profile them. On WordPress, the Query Monitor plugin lists every database query with its time and the plugin that ran it. Look for pages with hundreds of queries, single queries over 50 ms and HTTP API calls made during the page build. Turn on the MySQL slow query log to catch problems across the whole site:

sudo mysql -e "SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 0.5;"
sudo tail -f /var/lib/mysql/$(hostname)-slow.log

A persistent object cache such as Redis also helps database-heavy sites by keeping the results of repeated queries in memory between requests.

Move HTML closer to visitors

A CDN only helps TTFB if it caches the HTML itself. Putting images and CSS on a CDN is good for those files, but the page request still travels to your server. If your audience is spread across countries, cache HTML at the edge, for example with a Cloudflare cache rule set to cache eligible HTML for anonymous visitors, or with Cloudflare APO on WordPress. The CDN and origin redirects guide covers loops that can appear when you change CDN settings.

Platform notes

• WordPress: use one page caching plugin, or the cache your host provides, not both. Check PHP is a current supported version. Remove plugins that run heavy queries on every page, and check WP-Cron is not running long tasks during visitor requests; on busy sites, trigger it from a real server cron job instead. See WordPress page speed.
• Plesk: under the domain's PHP settings, the PHP-FPM pm.max_children value limits how many requests run at once. If it is too low, requests queue and TTFB climbs at busy times. Check the domain's error log for messages saying the limit was reached. Plesk also offers nginx caching per domain.
• Shopify: the server and CDN are managed for you, so TTFB problems usually come from heavy Liquid in the theme, such as large loops over collections or many apps injecting code. Test with a fresh copy of the default theme to compare.
• Next.js: pages rendered on every request are slower than static or incrementally regenerated pages. Use static generation where content allows, and cache data fetches. See Next.js page speed.

A worked example

A WordPress shop for a small UK business has a field TTFB of 1.9 seconds on mobile. A curl test with a random query string gives about 1.7 seconds each time, while the same page without the query string returns in 0.15 seconds with X-Cache: HIT. The server is fast when the cache answers, so the slow part is building the page.

Query Monitor shows 400 database queries on product category pages, almost all from a related-products plugin running a separate query for each item. Replacing it with the theme's built-in related products cuts the count to 60 queries and the uncached build time to 0.45 seconds. The team also finds that every visitor arriving from an old campaign link goes through two redirects, and updates the links. Four weeks later the field TTFB sits under 0.6 seconds, and mobile LCP has improved by a similar amount.

The fix, step by step

Edge cases worth knowing

• Cache warm-up. After a cache is cleared, the first visitor to each page waits for a full build. Pages that get little traffic may almost always be uncached; a preload option in your caching tool helps.
• Cookies and query strings. Tracking parameters such as utm_source and cookies set by plugins can make the cache skip a page. Configure the cache to ignore marketing parameters.
• Logged-in users. Admins and members usually bypass the cache, so their TTFB is always higher. Do not judge site speed from your own logged-in browser.
• Early hints and streaming. Some platforms send a 103 Early Hints response or stream the start of the HTML early. These can lower measured TTFB without changing total build time, so look at LCP as well.
• Lab versus field. One test location can be fast while visitors on another continent see slow times. Compare field data with tests from several locations.

Keeping TTFB low

Add a simple check to your routine: run the curl stage command on your home page and one page from each template every month, cached and uncached, and keep the numbers in a spreadsheet. A sudden rise usually follows a new plugin, a theme update or a hosting change, and it is far easier to trace within a week than within a year.

Watch the TTFB figure in the field data in PageSpeed Insights and the Core Web Vitals report in Search Console, because real-visitor numbers include redirects and distance that lab tests miss. Re-test after every caching or CDN change, and read the cache status header to confirm the cache is still answering.