Skip to main content
SlapMyWeb

Performance fix

How to Fix a Slow Time to First Byte

Cut server response time so everything else on the page can start sooner.

Difficulty
Medium
Impact
High
Time
1-3 hours

Before

curl -w 'connect: %{time_connect}s  ttfb: %{time_starttransfer}s\n' -o /dev/null -s https://example.com
connect: 0.180s  ttfb: 1.940s

After

curl -w 'connect: %{time_connect}s  ttfb: %{time_starttransfer}s\n' -o /dev/null -s https://example.com
connect: 0.020s  ttfb: 0.140s
Before and after code for: How to Fix a Slow Time to First Byte

Time to First Byte measures how long your server takes to send the first byte of a response. Everything else waits on it, so a slow TTFB caps Largest Contentful Paint no matter how well the front end is built. Under 800 milliseconds is the target; above 1.8 seconds it is the page's main problem.

Why it matters

TTFB is the floor under every other timing metric. A 1.5-second server response means LCP cannot be better than 1.5 seconds however small the images are: so front-end optimisation on a slow server is wasted effort.

How to fix it

  1. Find out where the time goes

    Split TTFB into DNS, connection, TLS and server processing. A browser's network panel or a curl timing breakdown shows which stage dominates: the fix is completely different for each.
  2. Cache what does not change per user

    Full-page caching for anonymous traffic removes application and database work entirely. This is usually the single largest win on a CMS.
  3. Fix the slow queries

    If server processing dominates, profile the request. An unindexed query or an N+1 pattern in a page's data loading is the usual cause.
  4. Put a CDN in front

    A CDN answers from a node near the visitor instead of your origin, which removes most of the connection and TLS time for everyone far from your server.

The code

Beforebash
curl -w 'connect: %{time_connect}s  ttfb: %{time_starttransfer}s\n' -o /dev/null -s https://example.com
connect: 0.180s  ttfb: 1.940s
Afterbash
curl -w 'connect: %{time_connect}s  ttfb: %{time_starttransfer}s\n' -o /dev/null -s https://example.com
connect: 0.020s  ttfb: 0.140s

On your platform

WordPress

A page cache plugin plus object caching removes most PHP and MySQL work per request. Shared hosting is frequently the real limit.

Next.js

Prefer static generation or ISR over server rendering for pages that are not per-user, and check that data fetches during render are not crossing the public internet to reach your own API.

Sources

Fixed that one.
Now find the rest.

A free audit ranks every issue on your site by the score points it costs, and links each one straight to its guide.

Run a free audit
Free foreverNo signupLive scan progress