Edge-native caching
Cache HTML and API responses at the edge to shorten the first-byte wait for users worldwide.
Edge performance playbook
How to get sub-50ms TTFB using Edge Runtime.
Vercel Edge apps can be fast, but server timing matters. Use caching, streaming, and edge-aware architecture to trim TTFB.
Streaming delivery
Send the first byte as soon as possible and hydrate progressively for faster perceived performance.
Server timing visibility
Measure TTFB in production and correlate it with release changes and regressed requests.
Why TTFB matters more than most teams realise
Time to First Byte is the foundation that every other metric sits on. Before the browser can parse HTML, discover images, or begin rendering — it has to wait for the server to respond. A 600ms TTFB means you've spent 600ms before a single pixel has moved. For LCP, which starts counting from navigation, high TTFB is a ceiling on how fast you can ever score — regardless of how well you optimise images and fonts.
Google's threshold for "Good" TTFB is 800ms. But for Next.js apps on Vercel Edge, 50–100ms is achievable on cached responses — a 8× improvement that flows directly into LCP scores.
Fix 1 — Route marketing pages through the Edge Runtime
In Next.js, Server Components run in Node.js by default — in a single AWS region. If your users are in Europe and your origin is us-east-1, every request travels across the Atlantic before a byte is sent. The Edge Runtime fixes this by running your function at the closest point-of-presence to the user:
// app/(marketing)/page.tsx
export const runtime = 'edge';
export default function HomePage() {
// Renders at the edge PoP closest to each user
return <MarketingPage />;
}
Edge Runtime has limitations: no Node.js APIs, no file system, no long-running processes. It works best for pages that are mostly static with light personalisation (reading cookies or geolocation headers). Data-heavy pages with complex database queries should stay in Node.js with aggressive response caching.
Fix 2 — Cache static responses at the edge with revalidation
For marketing pages, blog posts, and product listings that don't change per-user, edge caching turns a 50ms origin response into a 5ms cached response. In Next.js, configure this with therevalidate export or fetch cache options:
// Cache this page for 1 hour, revalidate in background
export const revalidate = 3600;
// Or per-fetch for data calls
const data = await fetch('/api/products', {
next: { revalidate: 60 },
});
Stale-while-revalidate means the first user after cache expiry triggers a background revalidation — they still get the cached (fast) response. Subsequent users get the fresh content at the same sub-10ms TTFB.
Fix 3 — Stream the HTML shell before data is ready
React's streaming architecture in Next.js App Router means you can send the outer HTML shell — including the <head>, navigation, and hero section — before data-dependent inner sections are ready. The browser starts parsing, building the DOM, and preloading critical assets immediately, while Suspense boundaries fill in async content when it arrives:
// Browser receives shell HTML instantly
export default async function Page() {
return (
<>
<HeroSection /> {/* streamed first */
<Suspense fallback={<Skeleton />}>
<ProductGrid /> {/* arrives after DB query */
</Suspense>
</>
)
}
Fix 4 — Move database reads closer to the edge with connection pooling
Even with Edge Runtime, a database call to a single-region Postgres instance adds 60–200ms of network latency for non-US users. Solutions: use PlanetScale, Neon, or Turso (edge-native databases with global replicas), or add a KV store (Vercel KV, Upstash Redis) for frequently-read data that doesn't need the full relational query path.
For most ecommerce teams, moving product catalogue data to a Redis-backed edge cache reduces TTFB on category pages from 400–600ms to under 30ms — and the data is fresh enough (60s TTL) for real-world use.
Monitoring TTFB in production
TTFB is sensitive to infrastructure changes: CDN configuration updates, database migration to a new region, or a new third-party middleware in the request chain can all spike it silently. Without automated monitoring, you'll discover the regression through a drop in organic traffic, not an alert.
AuditJet tracks TTFB on all monitored pages on a scheduled basis and alerts your team when it crosses your configured threshold — with a direct link to the audit showing which phase of the request (DNS, TLS, server wait, download) grew. Run a free audit to see your current TTFB baseline.
Cut TTFB on the edge without sacrificing reliability.
AuditJet helps teams reduce backend latency and keep edge-powered apps fast for every user.