Response time is under 3 seconds

Google's research shows 53% of mobile users abandon pages that take over 3 seconds to load. Response time directly determines first-byte latency — everything else (rendering, JavaScript hydration, asset loading) starts after this baseline. A server that takes 4 seconds to respond has wasted the entire user's attention budget before a single pixel renders. ISO 25010 performance-efficiency captures this: response time is the most fundamental performance metric because it gates every subsequent interaction. Slow response times also hurt Lighthouse performance scores and Core Web Vitals, compounding SEO and conversion impact.

Diagnose where the time is spent before optimizing. Break down the components with:

curl -s -o /dev/null -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' -L https://yoursite.com

If time_starttransfer is slow (server processing), check for blocking database queries, synchronous external API calls in SSR, or cold-start delays on serverless functions. If time_total is slow but TTFB is fast, the response body is large — enable compression (see compression-enabled check). Use a CDN (Vercel Edge, Cloudflare) to serve static pages from regions near your users. For Next.js, ensure pages that can be statically rendered use generateStaticParams or ISR rather than full SSR on every request.