probeo

What do TTFB and FCP measure in the loading timeline?

loading-performance-metrics page

The issue

A slow Time to First Byte or First Contentful Paint means visitors look at a blank screen before anything appears, and every later step in the load, including Core Web Vitals’ LCP, waits behind it. Some of them leave before the page has shown anything.

The causes differ. TTFB is the wait before the server’s first byte arrives: DNS, connection, TLS and the server’s own work, so it is shaped by hosting, caching and distance as much as by code. FCP adds the time the browser spends parsing HTML and loading render-blocking resources before it paints the first text or image. Render-blocking resources tend to accumulate a few at a time, a font here and a script there, and FCP drifts later with no single change to blame.

Scope

Each page is measured on its own. TTFB depends heavily on infrastructure shared by the whole site, so a slow origin or a CDN that isn’t caching affects every page. FCP varies more by template, because templates differ in what blocks rendering.

How to check you have it

  • In probeo: each page records its measured TTFB, and the site view shows the average and percentiles and lists the 20 slowest pages. Probeo also estimates FCP for four network profiles: Broadband (40 Mbps, 30 ms round trip), 5G (75 Mbps, 40 ms), 4G Fast (20 Mbps, 60 ms) and 4G/3G Slow (5 Mbps, 150 ms).
  • By hand: in Chrome DevTools, the Network panel’s timing for the document request shows the wait for the server’s response, and the Performance panel marks FCP.
  • With a tool: PageSpeed Insights shows TTFB and FCP from field data at the 75th percentile when the page has enough traffic.

The fix

Shorten the wait for the first byte, then clear what blocks the first paint.

For TTFB, cache responses at a CDN where they can be cached, reduce the server’s work per request, and remove redirect chains. For FCP, add async or defer to scripts that don’t need to run before the page shows, inline the CSS the first screen needs and load the rest without blocking, and keep synchronous third-party scripts out of the <head>.

Done when: TTFB is 800 ms or less, FCP is within the good threshold at the 75th percentile where there is field data, and the check above comes back clean.

Do not

  • Do not rely on lab tests alone to judge loading.
  • Do not work on FCP before checking TTFB, since a slow first byte delays everything after it.
  • Do not treat these as ranking signals; they explain the Core Web Vitals that are.

The loading timeline

A load runs in a fixed order: DNS lookup, TCP connection, TLS negotiation, then the server’s response. The moment its first byte arrives is TTFB. The browser then parses the HTML, fetches what blocks rendering and paints the first content, which is FCP. LCP comes at or after FCP. A delay at any step pushes back every step after it.

Google’s guidance treats a TTFB of 800 ms or less as good and an FCP of 1.8 s or less as good, at the 75th percentile of field data. TTFB is only the start of the load, so a page can pass on TTFB and still be slow to paint.

FAQ

Is TTFB the same as server response time?

Not exactly. TTFB includes server processing time plus network latency — DNS, TCP, and TLS negotiation. A fast server can still produce slow TTFB if the user is geographically distant or the network path is congested.

Does improving TTFB automatically improve FCP?

It removes one bottleneck. FCP also depends on render-blocking resources. A fast TTFB followed by heavy synchronous CSS and JavaScript will still produce a delayed FCP.

Are TTFB and FCP ranking factors?

Not directly. Core Web Vitals (LCP, INP, CLS) are the ranking signals. TTFB and FCP are diagnostic metrics that help explain why Core Web Vitals may be degraded. A slow TTFB is often the root cause of a slow LCP.

Why does my TTFB differ between lab and field?

Lab tests typically use fast, local connections. Field data reflects real users on varied networks and geographic locations. The gap reveals how much of TTFB is network-dependent versus server-dependent.

Can a CDN fix slow TTFB?

For cacheable responses, yes — a CDN serves content from edge locations closer to users. For dynamic pages that require origin processing, the CDN reduces network latency but cannot eliminate server processing time.

What is the relationship between FCP and LCP?

FCP measures the first visible content; LCP measures the largest visible content. FCP always occurs before or simultaneously with LCP. If FCP is slow, LCP cannot be fast. They are sequential points on the same rendering timeline.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.