How to fix a slow server response

Why this one comes first

Time to First Byte is how long the browser waits after asking for the page before a single byte of HTML comes back. Nothing can be parsed, no image can be discovered, nothing can be painted. Every millisecond here is added directly to LCP and to every other timing on the page.

That is why it is worth ruling out before you spend a day compressing images. If your first byte takes 1.2 seconds, a perfect front end still gives you a page that starts appearing after 1.2 seconds.

What TTFB is actually made of

• DNS lookup, TCP connection, TLS handshake. Fixed overhead, mostly distance-bound. Typically 100–300ms for a visitor on another continent.
• Redirects. Each one is a complete extra round trip. http://example.com to https://example.com to https://www.example.com is two of them before your server has even started working.
• Server processing. Your application, your database, your plugins. This is the part people mean when they say the server is slow.

Separate them before you act. curl tells you in one command:

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

If ttfb is close to tls, your server is fine and the time is going on connection setup and distance — that is a CDN problem. If there is a large gap between them, the server really is thinking, and a CDN will not help pages it cannot cache.

Fix it in this order

1. Remove the redirect chain

Free, and often 100–400ms. Make sure internal links, your sitemap and your canonical tags all point at the final URL, and collapse multi-hop redirects into one.

2. Turn on full-page caching

The largest single win for most database-backed sites, and the most commonly missed. A cached page skips your application entirely and is served as a static file. On WordPress that means a page cache plugin or server-level caching; on most managed platforms it is a setting you have to switch on. Check that it is actually working — a stray Cache-Control: no-store or a session cookie set on every request quietly disables it site-wide.

3. Put a CDN in front

This removes the distance component for everyone who is not near your server, and with edge caching it can serve most pages without touching your origin at all. If you are on a single server in one region and your visitors are not, this is usually a bigger win than upgrading that server.

4. Find the slow query

If the server is genuinely thinking, profile it rather than guessing. Look for queries without indexes, N+1 patterns in listing pages, and synchronous calls to third-party APIs during page render — that last one is common and brutal, because your page is now only as fast as somebody else’s server.

5. Then, and only then, look at the host

Once redirects are gone, caching is on and a CDN is in front, what remains is the machine. Shared hosting with oversubscribed CPU shows up as a TTFB that is fine at 3am and terrible at peak. If you have done the four steps above and your first byte is still over 600ms under normal load, the hosting is the constraint and moving is a reasonable answer.

Our checker only raises hosting when your measured server response is over 600ms. If your result did not mention it, your bottleneck is somewhere else and a new host would change nothing.