Time to First Byte under 800ms at 75th percentile

ab-001996 · performance-core.loading-resource-priority.ttfb-target

Severity: criticalactive

Why it matters

ISO-25010 time-behaviour starts the clock the moment a user's browser makes a request. TTFB above 800ms at the 75th percentile means a quarter of your users wait over a second before a single byte arrives — before any CSS, JavaScript, or content can render. Slow TTFB compounds every downstream metric: LCP, FCP, and INP all start later. For server-rendered applications without caching, every page hit cold-starts an origin server and may trigger database queries, turning user-perceived speed into a hostage of backend latency.

Severity rationale

Critical because TTFB sets the floor for every subsequent performance metric; a slow origin delays LCP, FCP, and INP simultaneously with no mitigation possible on the client.

Remediation

Reduce origin latency by caching rendered output at the edge. For Next.js, enable Incremental Static Regeneration on data-heavy routes:

// app/products/page.tsx
export const revalidate = 60  // regenerate at most once per 60 seconds

For fully static pages, force static generation:

export const dynamic = 'force-static'

Place a CDN (Vercel Edge Network, Cloudflare, or AWS CloudFront) in front of your origin so cached responses are served from the edge nearest the user. Also ensure frequently-queried database columns are indexed — uncached queries are a leading cause of TTFB spikes above 800ms.

Detection

ID: ttfb-target
Severity: critical
What to look for: Count all relevant instances and enumerate each. Before evaluating, extract and quote any relevant configuration or UI text found. Check server response time by examining framework config for SSR caching, CDN configuration, database query optimization patterns, or API latency. If using Next.js, check for revalidate settings on pages (ISR). Look for evidence of caching strategies (cache headers, CDN, service worker).
Pass criteria: Framework is configured with caching (ISR, SSG, or edge caching), OR there is evidence of CDN usage with geographic edge servers, OR database queries are optimized with indexes and connection pooling. Project documentation indicates target TTFB monitoring. A partial or placeholder implementation does not count as pass. Report the count even on pass.
Fail criteria: No caching strategy detected, server renders every request from scratch, or TTFB metrics show consistent values over 800ms. Database queries appear to lack optimization.
Skip (N/A) when: The project is a pure static site (no server rendering) or has no user-facing pages.
Detail on fail: Specify the measured TTFB and root cause. Example: "All routes server-rendered without caching; 75th percentile TTFB 1.2s. No database indexes on frequently queried tables." or "ISR set to 3600 seconds but no CDN in front; each request hits server".
Remediation: TTFB represents server responsiveness — the time until the first byte of the response arrives. Optimize by caching, using a CDN, or reducing server-side processing:

For Next.js, enable Incremental Static Regeneration (ISR):
```
export const revalidate = 60  // revalidate every 60 seconds
```
Or use Static Generation for static pages:
```
// app/page.tsx
export const dynamic = 'force-static'  // generates at build time
```
Ensure a CDN is in front of your origin, and optimize database queries with indexes and query caching.

External references

iso-25010:2011 · performance-efficiency.time-behaviour — Time Behaviour

Taxons

performance

History

2026-04-18·v1.0.0·Initial import from performance-core·automated

Why it matters

Remediation

Reduce origin latency by caching rendered output at the edge. For Next.js, enable Incremental Static Regeneration on data-heavy routes:

// app/products/page.tsx
export const revalidate = 60  // regenerate at most once per 60 seconds

For fully static pages, force static generation:

export const dynamic = 'force-static'

Detection

ID: ttfb-target
Severity: critical
What to look for: Count all relevant instances and enumerate each. Before evaluating, extract and quote any relevant configuration or UI text found. Check server response time by examining framework config for SSR caching, CDN configuration, database query optimization patterns, or API latency. If using Next.js, check for revalidate settings on pages (ISR). Look for evidence of caching strategies (cache headers, CDN, service worker).
Pass criteria: Framework is configured with caching (ISR, SSG, or edge caching), OR there is evidence of CDN usage with geographic edge servers, OR database queries are optimized with indexes and connection pooling. Project documentation indicates target TTFB monitoring. A partial or placeholder implementation does not count as pass. Report the count even on pass.
Fail criteria: No caching strategy detected, server renders every request from scratch, or TTFB metrics show consistent values over 800ms. Database queries appear to lack optimization.
Skip (N/A) when: The project is a pure static site (no server rendering) or has no user-facing pages.
Detail on fail: Specify the measured TTFB and root cause. Example: "All routes server-rendered without caching; 75th percentile TTFB 1.2s. No database indexes on frequently queried tables." or "ISR set to 3600 seconds but no CDN in front; each request hits server".
Remediation: TTFB represents server responsiveness — the time until the first byte of the response arrives. Optimize by caching, using a CDN, or reducing server-side processing:

For Next.js, enable Incremental Static Regeneration (ISR):
```
export const revalidate = 60  // revalidate every 60 seconds
```
Or use Static Generation for static pages:
```
// app/page.tsx
export const dynamic = 'force-static'  // generates at build time
```
Ensure a CDN is in front of your origin, and optimize database queries with indexes and query caching.