Platform vs Custom

This page clearly distinguishes between what static.bio built ourselves versus what Vercel and Next.js provide automatically. This transparency matters for evaluating portability and understanding performance attribution.

What's Custom

These are optimizations we explicitly implemented:

API Route Architecture

Using /api/profile/[username]/route.ts instead of Next.js page components to avoid React runtime injection. This eliminates ~50-100KB of React hydration code.

Framework-Agnostic Renderer

Standalone @static-bio/render package with zero framework dependencies. Pure function: renderProfilePage(input) → HTML. Can be used outside Next.js.

Inline CSS

All CSS inlined in <style> tag. Eliminates HTTP request for CSS file (~50-100ms saved). We manually maintain PUBLIC_CSS constant.

System Font Stack

Using only system fonts. Eliminates font download (typically 50-200KB, 100-300ms).

Database Optimization

Single SQL query with JSON aggregation to fetch profile + links. Reduces round-trips from 2 to 1 (~10-20ms saved). Strategic indexes on username, hostname, etc.

Code Optimizations

Function inlining, eliminated logging overhead, proxy fast-path optimization. Total savings: ~4-7ms per request.

Zero JavaScript Architecture

No <script> tags on public pages. This is an architectural constraint we enforce, not a Next.js feature. CI tests enforce this.

What Comes from the Platform

These are provided automatically by Vercel/Next.js:

Edge Runtime

Vercel Edge Runtime provides:

  • Sub-10ms cold starts (vs ~100ms Node.js)
  • Global edge locations (runs closer to users)
  • Automatic scaling

CDN Infrastructure

Vercel's global CDN provides:

  • Points of Presence (POPs) worldwide
  • Automatic routing to nearest edge
  • HTTP/2 and HTTP/3 support

Compression

Automatic compression:

  • Brotli compression (automatic)
  • TLS termination (automatic)
  • Connection reuse (HTTP/2, automatic)

Why This Matters

Portability

If we needed to move away from Vercel, we would need to replicate:

  • Edge runtime: Could use Cloudflare Workers, AWS Lambda@Edge, or similar
  • CDN/POPs: Could use Cloudflare, AWS CloudFront, or similar
  • HTTP/2, TLS, Brotli: Standard features available on most platforms

What we wouldn't need to reimplement:

  • Renderer library (framework-agnostic)
  • API route design (could adapt to any serverless platform)
  • SQL queries and schema (PostgreSQL is portable)
  • HTML/CSS output (same everywhere)

Performance Attribution

Performance comes from both:

  • Our optimizations: Zero JS, inline CSS, system fonts, single query, function inlining (~50-200ms saved)
  • Platform features: Edge runtime, CDN proximity, HTTP/2, Brotli (~50-100ms saved)

Both are necessary. Our optimizations ensure minimal payload and processing. Platform features ensure fast delivery. Together, they achieve sub-100ms TTFB in typical conditions (NA/EU ~20-50ms, higher in distant regions).