Part of our Web Hosting Performance Statistics 2026 research.
Summary
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%.
What the data covers
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.
Half the web has a fast server, one in seven is slow
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.
Server speed is a near-hard ceiling on loading
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.
| TTFB band | Share of sites | Pass LCP | Median TTFB |
|---|---|---|---|
| Good (at or below 800 ms) | 51.3% | 85.3% | 500 ms |
| Needs improvement (800 to 1,800 ms) | 34.9% | 59.7% | 1,200 ms |
| Poor (over 1,800 ms) | 13.7% | 6.3% | 2,500 ms |
Mobile, p75 TTFB, 10.6M origins, May 2026 CrUX.
6.3%
Share of poor-TTFB sites that pass LCP, versus 85.3% of good-TTFB sites. Fix TTFB first.
Source: PageSpeed Matters analysis, mobile 75th-percentile field data, May 2026.
If your server burns 2.5 seconds, you are already over the 2.5-second LCP budget before a single image has loaded.
Fix the server before the front end
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.
Sources
- Chrome User Experience Report (CrUX) documentation, Google: https://developer.chrome.com/docs/crux
Embed this research
Paste this on your site to embed the chart. It links back to the source automatically.
<iframe id="psm-ttfb-benchmark" src="https://www.pagespeedmatters.com/embed/data-studies/ttfb-benchmark" width="100%" height="600" style="width:100%;border:1px solid #E2E3E1;border-radius:12px" loading="lazy" title="51.3% of Sites Have a Good TTFB - the Slow Ones Pass LCP Just 6.3% of the Time - PageSpeed Matters"></iframe>
<script>window.addEventListener("message",function(e){if(e&&e.data&&e.data.psmEmbed==="ttfb-benchmark"&&e.data.height){var f=document.getElementById("psm-ttfb-benchmark");if(f){f.style.height=e.data.height+"px";}}});</script>
<p style="font:14px/1.5 system-ui,sans-serif">Source: <a href="https://www.pagespeedmatters.com/resources/data-studies/ttfb-benchmark">51.3% of Sites Have a Good TTFB - the Slow Ones Pass LCP Just 6.3% of the Time - PageSpeed Matters</a></p>
Frequently asked questions
What is a good TTFB (server response time) in 2026?
51.3% of Sites Have a Good TTFB. The Slow Ones Pass LCP Just 6.3% of the Time.
How was this measured?
Chrome User Experience Report (CrUX) real-user field data, May 2026 release, mobile, 75th-percentile TTFB. 10.6 million origins that report TTFB, bucketed by Google's thresholds (good at or below 800 ms, needs-improvement 800 to 1,800 ms, poor above 1,800 ms). For each band we computed the share passing LCP (p75 LCP at or below 2,500 ms).
A slow server response pushes every other metric back, so TTFB is usually where we start. Need help with this? See our Core Web Vitals optimization services.