In one paragraph
Slow time to first byte means the tested request waited longer than the configured budget before response headers arrived. The delay can include network and connection setup as well as server work, depending on the measurement. Compare equivalent timings, profile the affected route, and use appropriate caching or delivery improvements. Do not assume a high value proves the application code alone is slow.
Why it matters
The browser needs a response before it can start processing that document's content. A delayed first byte therefore constrains the loading timeline, but TTFB is not the whole page experience. A route doing useful server rendering can have a higher TTFB and still deliver content sooner than a fast empty shell with substantial later work.
TTFB is not itself a Core Web Vital. Guidance commonly uses 0.8 seconds or less as good and over 1.8 seconds as poor, while recognising that the result must be interpreted with content delivery and user-centric timings.
Navigation timing can include redirects, DNS, connection establishment, and other phases. Individual probes and monitoring products do not always include the same boundaries. Compare definitions and locations rather than calling one tool wrong because its number differs.
How WebAuditOS evaluates this finding
The supplied rule times the final request until response headers, excluding prior redirects and its own DNS lookup. It includes the relevant network round trip and connection setup when a new connection is needed. Up to 800 ms passes; over 800 through 1,800 ms warns; over 1,800 ms fails. Missing responses or the documented twenty-second timeout are not graded.
Later requests may reuse a connection, and the scanner's location is not necessarily your visitors' location. One reading per page can also reflect temporary load. The value is a probe-specific diagnostic, not pure backend execution time or a complete field TTFB distribution.
How to fix it
- Confirm the exact timing boundaries, URL, status, cache state, and probe location. Repeat under comparable conditions before investigating a single marginal outlier as a permanent regression.
- Compare a representative static response and the dynamic page on the same delivery path. If both are slow, inspect network, edge, connection setup, and hosting. If the dynamic route is uniquely slow, investigate rendering and backend dependencies. A difference is evidence to explore, not an infallible diagnosis.
- Inspect browser navigation timing or a controlled command-line breakdown. For example:
curl -sS -o /dev/null -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} first-byte %{time_starttransfer}' https://example.com/
These curl values are cumulative elapsed timestamps, not independent phase durations to add together. Their first-byte boundary also differs from the documented scanner's DNS-excluding definition. Interpret them consistently.
- Profile the route. Look for expensive queries, missing indexes, blocking external API calls, rendering cost, worker exhaustion, and cold starts. Use framework or APM evidence rather than changing database settings at random.
- Cache suitable public output at the application or edge. Define freshness, invalidation, variant keys, and authenticated bypass before rollout. A CDN caching only assets does not automatically remove origin HTML work.
- Improve delivery geography where it matches the audience. An edge cache can help public HTML close to users; dynamic uncached work still depends on the origin and architecture. Choose hosting and availability settings based on measured demand.
- Review connection reuse, redirect chains, and TLS separately. They affect real navigation even when excluded from a particular final-request metric. Do not hide a detour merely by measuring only its last response.
- Rescan, monitor origin and edge diagnostics, and compare LCP and FCP. Retain performance gains only when data correctness and actual user journeys remain sound.
What the fix can break
Shared caching can expose personal data or serve wrong currencies, permissions, or prices. Test separate sessions and correct purge behaviour using safe test data. Faster wrong content is not a performance success.
An edge changes how the origin sees client addresses. Trust forwarded identity and IP information only from intended proxies, and update logging or rate controls accordingly.
Keeping instances warm can cost money without fixing an expensive route. Optimise from evidence and compare the operational tradeoff rather than applying a universal server-upgrade recommendation.
Questions
Why is the scanner slower than our local monitoring?
Its network distance, connection state, and timing boundaries may differ. Compare the same endpoint and measurement definition from relevant regions.
Does the scanner include redirects?
The supplied rule excludes earlier redirects and times the final response. Visitors still pay the full navigation cost.
Is TTFB a direct Core Web Vital?
No. It is a diagnostic that can influence loading outcomes such as LCP. Evaluate those outcomes too.
Which related checks help?
Review LCP, FCP, and the Core Web Vitals guide.