TTFB is configured to meet the 800ms threshold

Time to First Byte is the foundation every other performance metric builds on — a slow TTFB adds its full penalty to LCP, FCP, and INP simultaneously. ISO-25010 time-behaviour defines server response time as a core quality characteristic, and marketing pages violate it most commonly by using full server-side rendering with no caching on a single-region origin. A user in London hitting a server in us-east-1 with no CDN experiences 150–250ms of raw network latency before the server even starts generating HTML, plus server processing time. TTFB above 800ms is a direct cause of poor Core Web Vitals scores across all categories and signals to Google's Page Experience system that the server infrastructure is underperforming for users.

Switch marketing pages to static generation so they're served from CDN edge in under 50ms. Remove force-dynamic from any marketing route and let Next.js use its default static rendering.

// app/(marketing)/page.tsx — static by default, no changes needed
export default function HomePage() {
  return <MarketingPage />
}

// If the page needs fresh CMS content, use ISR instead of full SSR
export const revalidate = 3600 // regenerate at most once per hour
export default async function LandingPage() {
  const content = await fetchCMSContent()
  return <LandingPage content={content} />
}

Deploy to Vercel, Netlify, or Cloudflare Pages — these platforms serve ISR-cached HTML from edge nodes globally without any additional CDN configuration.

• ID: marketing-page-speed.core-web-vitals.ttfb-threshold

• Severity: high

• What to look for: Time to First Byte (TTFB) is the time from the browser sending a request to receiving the first byte of the response. For marketing pages, TTFB > 800ms is a red flag. TTFB is determined by: (1) rendering strategy — SSG/static is served from CDN edge (<50ms), SSR with no cache adds server processing time, (2) CDN configuration — is there a CDN in front of the origin? (3) cold start latency — serverless functions have cold start penalties of 200-500ms. Examine next.config.* for output: 'export' or revalidate settings, vercel.json for CDN config, and rendering strategy of the homepage and key landing pages. Count all instances found and enumerate each.

• Pass criteria: Marketing pages (homepage, landing pages) are statically generated (SSG, output: 'export', or ISR with cache hit) so they're served from CDN edge. OR hosting is Vercel/Netlify/Cloudflare Pages which serve static assets globally by default. TTFB budget ≤ 800ms is achievable. At least 1 implementation must be confirmed.

• Fail criteria: All marketing pages use full SSR (force-dynamic or equivalent) with no caching, served from a single-region origin with no CDN. Cold starts add >500ms penalty. TTFB would predictably exceed 800ms on first request.

• Skip (N/A) when: No server-side rendering — project is purely static HTML. TTFB is CDN-only and not configurable in code.

• Detail on fail: "Homepage uses force-dynamic SSR with no cache headers. Hosting is a single-region VPS with no CDN configured. TTFB will predictably exceed 800ms for non-local users."

• Remediation: Use static generation for marketing pages:

  // Next.js App Router — static by default for pages with no dynamic data
  // app/(marketing)/page.tsx
  export default function HomePage() {
    return <HomePage /> // statically rendered at build time
  }
  
  // ISR — regenerate periodically, serve from cache
  export const revalidate = 3600 // revalidate every hour
  export default async function LandingPage() {
    const content = await fetchCMSContent()
    return <LandingPage content={content} />
  }
  

  Deploy to Vercel, Netlify, or Cloudflare Pages — they serve static assets from global edge networks without extra CDN configuration.