The metrics that explain your Core Web Vitals
Core Web Vitals tell you whether a page loads, responds and stays stable well enough for visitors. The supporting metrics show where the time goes, so you know what to fix.
Time to First Byte (TTFB) covers the server and the network. First Contentful Paint (FCP) and Speed Index cover early rendering, and Total Blocking Time (TBT) covers main-thread work during load. Page weight and request count describe what the page asks the browser to download.
These metrics fit together in order. TTFB is part of FCP, and Largest Contentful Paint (LCP) can never come before FCP. TBT is the lab signal most closely linked to Interaction to Next Paint (INP). The Core Web Vitals article covers LCP, INP and CLS themselves.
Time to First Byte: how quickly the server starts answering
TTFB is the time from the start of navigation until the first byte of the HTML response arrives. It includes redirects, service worker startup, DNS lookup, the connection and TLS handshake, and the time the server spends building the response.
Google's guidance on web.dev treats 0.8 seconds or less as good and anything above 1.8 seconds as poor. Nothing can render before the first byte, so a slow TTFB pushes back every later metric.
Common causes are uncached server-side rendering, slow database queries, redirect chains and a long distance between user and server. Caching HTML at a CDN close to users and linking straight to final URLs both help.
Where you measure from matters. A single synthetic check, such as the Website Launch Readiness Checker, measures TTFB from one server location. The result includes the network distance from that server, and your visitors may be much closer or much farther away.
FCP and Speed Index: when content first appears
FCP marks the first time any content renders: text, an image (including a CSS background image), an SVG or a non-white canvas. Google treats 1.8 seconds or less as good and more than 3 seconds as poor, at the 75th percentile.
A slow FCP with a fast TTFB usually points to render-blocking resources. Stylesheets and synchronous scripts in the head both have to finish before the first paint.
Speed Index measures how quickly the visible area fills in during load. Lighthouse captures the load frame by frame and scores how fast the viewport reaches its final appearance. It is a lab-only metric, and lower is better.
Speed Index rewards pages that show most of their content early, even if one last element arrives late. Two pages with the same LCP can score quite differently.
Total Blocking Time: a lab proxy for responsiveness
A long task is any main-thread task that runs for more than 50 milliseconds. While it runs, the browser cannot respond to a click or key press. TBT adds up the part of each long task beyond 50 milliseconds, counted after FCP during a lab load.
Tasks of 120, 40 and 80 milliseconds give a TBT of 100 milliseconds: 70 from the first task, nothing from the second and 30 from the third.
TBT belongs in the lab because it needs a controlled load with no real user input. A low TBT often goes with a good INP in the field, but it can miss slow event handlers that only run when someone clicks. Use it to catch regressions before release, and confirm responsiveness with field INP.
Page weight and request count
Page weight is the total number of bytes a page downloads, and request count is how many files it fetches. Neither is a timing metric, but both drive the timings. More bytes take longer on slow connections, and each new origin needs its own DNS lookup, connection and TLS handshake.
Look at transfer size, which is what crossed the network after compression, separately from decoded size. A script that transfers as 300 KB can decompress to several times that, and the browser has to parse and run all of it.
HTTP/2 and HTTP/3 carry many requests over one connection, so a high request count costs less than it did with HTTP/1.1. Third-party origins still need extra connections, and every script still has to run. A budget for bytes and requests per page type, checked in your build, catches growth before it reaches users.
Why to track the 75th percentile, not the average
Load times have a long tail. Most visits cluster around a typical value, while a minority on slow phones or networks take far longer. An average blends both groups into a number that describes almost nobody.
A percentile reads straight off the distribution. The 75th percentile (p75) is the value that three out of four visits meet or beat, so it moves when a sizable group of users gets slower. Core Web Vitals are assessed at p75, and the same habit works for field TTFB and FCP.
Split the data by device type and connection before comparing, since a fast desktop majority can hide a slow mobile minority. When you investigate a problem, check p95 as well: one visit in twenty is slower than that value.