High TTFB: how to find where the server response time goes

TTFB (time to first byte) is the time from the request to the arrival of the first byte of the reply. If it is high, the page is slow to start, and everything after it (LCP included) is pushed back. But the number bundles several waits: resolving the name, connecting, negotiating HTTPS and, last, the server building the page. Only the last one is “the server’s”. Separate them before blaming anyone.

Step 1: separate the waits

1 In a terminal (on your own computer), run it three times: curl -o /dev/null -s -w "dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} first-byte %{time_starttransfer} total %{time_total}\n" https://yourdomain.tld/.
2 Each number is cumulative. To get how long each part took, subtract the previous one from the next. The server’s wait is first-byte minus tls.
3 Keep the middle of the three measurements. One proves nothing.
Part If it is large, it points to
dns Name resolution: the DNS provider or your resolver. See fast for you, slow for everyone else.
connect minus dns Distance to the server, or a slow network on the measuring side.
tls minus connect The HTTPS negotiation. Rarely the cause.
first-byte minus tls The server building the page. This is what the next steps deal with.

Step 2: if the wait is the server’s

1 Does the page come from cache? Request it twice in a row. On a WordPress site with LiteSpeed Cache, the x-litespeed-cache header should say hit on the second. If it always says miss or does not appear, the page is rebuilt on every visit. See the first LiteSpeed Cache settings and cache rules.
2 Is there a chain of redirects? curl -sIL https://yourdomain.tld/ shows each hop. Every one adds a whole request. Reach the final address in a single one.
3 Slow database queries. Pages with lists, searches and filters come first. See slow queries: how to find them.
4 Heavy plugins, or calls to outside services inside the page itself (an API that takes its time). Switch them off one at a time and measure. See what eats CPU on a website.
5 An old PHP version. The same page runs faster on a newer one. See changing your PHP version without breaking the site.
6 Internal tasks in the middle of a visit. In WordPress, WP-Cron runs when someone visits. See admin-ajax eating your resources.
A good TTFB on the home page proves nothing about the others. The home page is almost always cached. Measure the page people complain about, signed in and signed out, and a search or product page.
Accept that the first visit is always slower. It is the one that builds the cache copy. What counts is the second onwards. If visitors mostly land on the first (fresh content every hour, say), consider warming the cache. See installing and tuning a page cache.

Separated the waits and first byte is still high with the cache working? Send us the numbers from the three measurements and the address.

Open a support ticket

SEE ALSO

Measuring your site speed: which tools, and what the numbers mean

The site is slow: what actually makes a difference

The site is slow: what to measure before you change plan

How to fix a slow LCP

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from 5.940,00 Kz/mo (3-year plan, with coupon)

See plans
  • 0 Users Found This Useful
Was this answer helpful?