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.
Critical because a response time over 3 seconds causes majority user abandonment before the page renders, making the site effectively unusable for a large share of real-world visitors.
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.
ID: site-health-check.performance-signals.response-time
Severity: critical
What to look for: Extract the time_total value (in seconds, as a decimal) from the curl -w output. Enumerate all response timing metrics available (DNS lookup, connect, TLS handshake, time to first byte, total time). This measures the total elapsed time from DNS resolution through connection, TLS handshake, sending the request, and receiving the complete response body.
Pass criteria: The time_total value is strictly less than 3.0 seconds. Report the exact measured time rounded to 1 decimal place (e.g., "Response time: 1.2s"). Times under 1.0s are excellent; 1.0-2.0s is acceptable; 2.0-3.0s is slow but passing.
Fail criteria: The time_total value is 3.0 seconds or greater.
Skip (N/A) when: The curl request received a connection error or DNS failure (no timing data is meaningful if the connection was not established).
Report even on pass: Report the exact response time: "Response time: 0.8s (well under the 3.0s threshold)."
Detail on fail: "Response time was 4.2 seconds — over the 3-second threshold". Include the actual time measured.
Remediation: Response times over 3 seconds cause significant user abandonment. Common fixes:
Enable server-side caching with Cache-Control headers in your next.config.js or server config. Use a CDN (Vercel, Cloudflare, Fastly) to serve from edge locations closer to users. Check for slow database queries or blocking API calls in server-side rendering. Verify with:
curl -s -o /dev/null -w 'time_total: %{time_total}s\ntime_starttransfer: %{time_starttransfer}s\n' -L {URL}
This identifies whether the delay is in server processing (time_starttransfer) or download.