A Slow Server Passes Google's Loading Test 6% of the Time. A Fast One Passes 85%.

Every performance conversation starts with images and JavaScript. But before the browser can paint a single pixel, it has to wait for the server to answer, and for one site in seven that wait runs past 1.8 seconds. Time To First Byte is the number nobody optimizes and everybody is limited by, and the field data shows exactly how much it decides.

That opening wait is not a technicality. It is dead time the visitor spends staring at a blank screen, and it sets the ceiling on how fast anything else can appear. Slow starts push people away before a page has a chance to make its case, and because loading speed feeds Google's Core Web Vitals, a sluggish server drags down search visibility along with conversions and trust.

To find out how much server speed actually matters, we measured Time To First Byte across 10.6 million sites using Google's Chrome User Experience Report, the real-user field data collected from Chrome visitors across the web. The relationship it revealed is one of the strongest in all of web performance: a fast server passes the loading test 85% of the time, a slow one just 6%.

The figures come from the Chrome User Experience Report, Google's record of real-user experience, at the 75th percentile on mobile, for the 10.6 million origins that report Time To First Byte. Google buckets TTFB into three bands: good at 800 milliseconds or less, needs-improvement between 800 and 1,800 ms, and poor above 1,800 ms. Loading is judged good when a site's Largest Contentful Paint, the moment its main content appears, lands at 2.5 seconds or less. For each server-speed band we computed the share of sites and the share that go on to pass the loading test.

Time To First Byte measures the delay before the server sends the first byte of the page: the sum of DNS lookup, connection, and the server's own time to produce a response. It is the most upstream thing a page does, and the web is split roughly in half on it. 51% of sites have a good TTFB, responding in 800 milliseconds or less. About a third sit in the needs-improvement band. And 13.7% are poor, with a median of 2.5 seconds just to start responding.

That distribution matters because the wait is unavoidable. It is time counted before the browser has anything to work with, spent while the visitor sees nothing at all. For the one site in seven in the poor band, two and a half seconds are gone before a single image or headline can begin to load.

The good news in that split is how many sites are close. The needs-improvement band is not stuck; it is a third of the web sitting a few hundred milliseconds away from good, usually because of a missing cache layer, a database query that could be faster, or an origin serving visitors from a single distant location. These are not deep architectural problems. They are the ordinary friction of a server doing more work per request than it needs to, and each one is a place where a modest change pays off directly in loading speed.

The reason TTFB deserves a study of its own is not the distribution. It is what the metric predicts. Sort every site by its TTFB band and look at how often each group passes LCP, and the relationship is dramatic. Among sites with a good TTFB, 85.3% pass. Among sites with a poor TTFB, only 6.3% do, a 13-fold gap. That is not a soft correlation. It is close to a hard ceiling.

It makes mechanical sense. LCP measures when the largest content element paints, and TTFB is time spent before the browser has anything to paint. If your server burns 2.5 seconds, you are already over the 2.5-second LCP budget before a single image has loaded. No front-end optimization can recover time that was spent before the front end even started, which is why compressing images on a slow-server site is rearranging deck chairs.

The most actionable slice is the middle. Sites in the needs-improvement band pass LCP 59.7% of the time, essentially a coin flip. That is the group where server work changes outcomes: shave a needs-improvement TTFB down into the good range and you move a site from a 60% to an 85% chance of passing LCP. It is the highest-impact, least-glamorous optimization on the web.

Mobile, p75 TTFB, 10.6M origins, May 2026 CrUX.

TTFB is the metric to check first and fix first, because it sets a near-hard ceiling on loading. A good server responds in a median 500 milliseconds and passes LCP 85.3% of the time, while a poor one burns 2,500 milliseconds before the first byte and passes just 6.3%, a 13-fold gap that no image or JavaScript work can recover. The fixes live on the server side, where putting a CDN in front of the origin and caching aggressively pull most sites into the good band, backed by hosting that is not oversubscribed.

The most valuable move is on the swing group. Sites in the needs-improvement band pass LCP 59.7% of the time, close to a coin flip, so shaving a few hundred milliseconds off the server pushes them toward the 85% that good-TTFB sites reach. Do the work in the other order and you polish a front end into a ceiling built on the back end. Get the server answering fast, and every image and script optimization downstream finally has room to translate into a passing LCP.