Stale-while-revalidate configured for APIs
Why it matters
Every read-only API endpoint that responds with no-cache forces the browser to wait for a full network round-trip before rendering data — even for data that changes infrequently. stale-while-revalidate flips this: the browser serves the last cached response immediately (zero perceived latency), then fetches a fresh copy in the background. ISO 25010:2011 time-behaviour measures the round-trip cost; the user-visible gain is instant page paint for the common case, with fresh data arriving shortly after.
Severity rationale
High because serving all API responses with `no-cache` forces users to wait for a full network round-trip on every data fetch, adding hundreds of milliseconds to perceived load time even when cached data would be adequate.
Remediation
Add Cache-Control: public, max-age=60, stale-while-revalidate=86400 to API responses where serving slightly stale data is acceptable. Exclude personalized or mutation endpoints — those must use private, no-cache.
// app/api/products/route.ts
export async function GET() {
const products = await fetchProducts()
return Response.json(products, {
headers: { 'Cache-Control': 'public, max-age=60, stale-while-revalidate=86400' },
})
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Deep Dive Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · time-behaviour — Time Behaviour (performance efficiency)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-deep-dive·automated