Time to First Byte Server response time determines whether frontend work has any effect at all
Time to First Byte measures the time until the first byte of the response. The value is not one of the Core Web Vitals, but it is their root: it is the first part of every main content load time and sets the lower bound for everything that follows. In Christian Schreiber's own survey, it is the reason why the majority of slow websites are slow.
Guideline: 800 millisecondsOwn data: as of August 2026
TTFB consists of five steps, and server processing takes the largest share
Five things happen before the first byte: DNS resolution, connection setup, TLS negotiation, possible redirects and the processing of the request on the server. On a well-configured platform, the first three steps together rarely cost more than a hundred milliseconds. Redirects are a frequent item that is easy to fix: every chain from request to target costs a full round trip.
The lion's share arises in the last step, and there a single question decides: does the response come from the cache or from the application? A cache hit costs milliseconds, a miss costs the full processing including database and repository access.
A high TTFB leaves too little time for any frontend optimization
The threshold for the main content load time is 2.5 seconds. If 1.5 seconds of that pass before the first byte arrives, one second remains for transfer, layout and rendering. That is not enough on a mobile connection. That is why the order of work is not negotiable: first the response time, then the frontend.
Christian Schreiber's own survey shows how common this case is. For 80.3 percent of AEM websites with a slow main content load time, the server response time alone already exceeds the threshold. For Magnolia, it is 78.8 percent. Across all measured websites, the median is 666 milliseconds for AEM and 668 milliseconds for Magnolia. For the slow websites, it rises to 1,565 and 1,668 milliseconds respectively.
Improve TTFB: three patterns that lower the cache hit ratio
- Parameters without a page of their own. Campaign and tracking parameters either create their own cache variant or bypass the cache entirely. Both can be caught in the cache rule.
- Overly coarse invalidation. If every publication discards large parts of the cache, the platform effectively runs without a cache during busy editorial periods.
- Sessions for anonymous visitors. If a session is created for every visit, every response is individual and therefore cannot be reused.
All three are measurable, namely as the cache hit ratio per page type in live operation. This figure belongs next to the real-user data, because it shows the cause that the real-user data only shows as an effect.
A good TTFB does not fix input responsiveness or layout stability
A low response time does not by itself produce good Core Web Vitals. It creates the room for them. Input responsiveness and layout stability arise entirely in the browser and are not affected by server time. A common misconception in migration projects is that moving to a cloud environment settles the values. In fact, delivery improves, while the same scripts, tags and personalizations in the browser produce the same values as before.
TTFB in relation to LCP, INP and CLS
The response time directly affects Largest Contentful Paint and indirectly affects Interaction to Next Paint, because a page that arrives late executes its scripts later and therefore collides more often with early inputs. It has no effect on Cumulative Layout Shift.
How the values are distributed in the DACH region and which datasets are behind them is shown in the Core Web Vitals Benchmark. The system-specific causes are on the pages on Adobe Experience Manager Performance and Magnolia CMS Performance.
Book a free performance analysis
30 minutes via video call. You see whether your values arise in operations or in the frontend.
Frequently asked questions about Time to First Byte
What is Time to First Byte?
The time between requesting a page and the arrival of the first byte of the response. It includes DNS resolution, connection setup, TLS negotiation, redirects and the processing time on the server. Google gives 800 milliseconds as a guideline.
Is Time to First Byte a Core Web Vital?
No. The value is not one of the three assessed metrics, but it is the first part of every Largest Contentful Paint. A page with a response time of 1.5 seconds can practically no longer stay within the threshold of 2.5 seconds, regardless of how well the frontend performs.
How high is the value on large platforms in the DACH region?
The median is 666 milliseconds for Adobe Experience Manager and 668 milliseconds for Magnolia CMS. For websites whose main content loads too slowly, however, it is 1,565 and 1,668 milliseconds respectively.
Does a content delivery network help?
For delivery, yes, because paths become shorter and the application is relieved. For processing in the browser, no: input responsiveness and layout stability arise after delivery and remain unaffected. A content delivery network is a foundation, not a measure that produces green values on its own.
How can you tell that the cache layer is the problem?
By the spread. If the value is good for some page types and poor for others, the cache hits differently. Typical causes are requests with parameters that create their own variants, an invalidation that discards too much on every publication, and sessions that are created for anonymous visitors and make every response individual.