You cannot fix LCP without fixing TTFB

Only 44% of mobile pages achieve a good Time to First Byte. That single number explains most of the frustration teams feel after a round of image optimisation produces almost no improvement in Largest Contentful Paint.

TTFB is not a metric that sits beside LCP. It is the floor underneath it.

The arithmetic

LCP breaks into four parts, and they are sequential.

Time to First Byte. Then resource load delay, the gap between the first byte arriving and the browser starting to fetch the LCP resource. Then resource load duration, the time to download it. Then element render delay, the time between the resource arriving and it appearing on screen.

Good LCP is 2.5 seconds at the 75th percentile. Good TTFB is 0.8 seconds. If your TTFB is 1.4 seconds, you have 1.1 seconds left for finding, downloading and painting your hero image, on a mobile connection. That is achievable but tight, and it means every other optimisation is fighting for a share of a budget your server already spent.

Compress the image to half its size and you save perhaps 200 milliseconds of download. You have not touched the 1.4 seconds that came first.

The Australian version of this problem

Physics is part of it and worth stating plainly, because it changes where the fix lives.

A round trip from Sydney to a server on the east coast of the United States is over 200 milliseconds. That is one round trip, and a fresh connection needs several: DNS resolution, then TCP, then the TLS handshake, then the request itself. Before your server has done any work at all, you can be most of the way through your TTFB budget.

Plenty of Australian businesses are on hosting chosen by a developer in another country, or on a platform whose default region is not Sydney, and nobody has checked. It is the cheapest fix on this list and the one least often made.

Check it directly. Run a test from a Sydney location and look at the connection breakdown: DNS, connect, TLS, waiting. If the waiting portion is small but the connect and TLS portions are large, your problem is distance, not code.

The four causes, in the order they usually appear

No edge caching. Every request travels to your origin, waits for the application to run, and travels back. Putting a CDN in front, with the HTML itself cached at the edge rather than only the images and stylesheets, is the difference between a 200 millisecond round trip to a Sydney edge and a 900 millisecond trip to an origin somewhere else. Most sites cache assets at the edge and let the document go all the way home, which is exactly backwards for TTFB.

Uncached CMS output. A page rebuilt from the database on every request, with a dozen queries and a template render, is spending server time on work whose output is identical for every visitor. Static generation, or incremental regeneration where the page is rebuilt on a schedule rather than on demand, removes that entirely for marketing pages.

Redirect chains. Each redirect is a full round trip before the real page even starts. The classic pattern is http to https, then non-www to www, then a trailing slash normalisation, then a legacy URL rewrite. Four round trips, and on mobile that is comfortably half a second before your server does anything useful. Collapse them so any entry point reaches the final URL in one hop, and check your ad landing page URLs specifically, because they are frequently the ones still pointing at an old path.

Cold starts. Serverless functions that have not been called recently take time to boot. On a low-traffic page, a meaningful share of your visitors hit a cold function, and they are disproportionately your first-time visitors from a campaign.

What to measure and where

Field data first. Google's dataset now reports Round Trip Time as a dimension, including a 75th percentile and histograms, which replaced the old connection type bucket. That tells you what your real users' network conditions are, so you know how much of your TTFB is network and how much is server.

Then server timing. The Server-Timing response header lets your application report its own breakdown, database time, render time, cache status, straight into DevTools and into your monitoring. It takes an afternoon to add and it ends the guessing about whether the delay is in your code or in transit.

Then check cache hit rate at the CDN. A CDN with a 20% hit rate on HTML is a CDN that is not doing the job you bought it for.

What good looks like

A well-configured marketing site serves cached HTML from an edge node close to the user in under 200 milliseconds, which leaves more than two seconds for everything else. At that point image work, font loading and priority hints all pay off, because there is budget for them to spend.

Fix the origin first, and everything you do afterwards starts working.