Vercel's Edge Runtime Reversal

• Vercel reverted all Edge rendering back to Node.js
• Major shift away from Edge runtime strategy that was previously advocated
• Lee Rob's tweet announcement sparked discussion about Edge naming confusion

Personal Experience with Edge Runtime

• Built one of first major projects using app router server components on Edge (Upload Thing)
• Most routes still served on regional Edge
• Filed multiple issues that got fixed weekend before launch
• Performance has been excellent despite challenges
  • Random packages not working
  • Dependencies having unexpected behaviors
  • Bundle size limitations (1MB limit for Edge bundles)
  • Developer experience inconsistencies

Edge Definition and Components

• Edge Location: Distributed servers worldwide instead of single centralized server
  • Thousands of small servers in different locations
  • Traffic resolves to closest server rather than distant centralized one
  • Major limitation: database location creates latency if database is far from Edge server
• Edge Runtime: Alternative to Node.js
  • Designed to be minimal, isolated, spin up quickly
  • Built for faster cold starts compared to Node
  • Similar to Cloudflare Workers runtime
  • Not actually running Node.js but specialized JavaScript runtime

Streaming and Suspense Benefits

• Edge enables immediate response streaming while waiting for database queries
• User sees page shell immediately, data streams in after
• 200-800ms database latency becomes acceptable when content loads progressively
• Tutorial example: Gallery app with image uploads demonstrating streaming architecture

Vercel's Edge Product Suite Analysis

• Edge Network: Serves static HTML/JS quickly from distributed locations
• Routing Rules: Middleware, redirects, proxies without hitting origin server
  • Example: PostHog analytics proxy to avoid ad blockers
  • Configuration-based routing without code execution
• Edge Config: JSON key-value store persisted across builds and regions

Performance Testing Results

• Node.js runtime with 1 virtual CPU shows faster startups than Edge runtime
• VZ (Vercel's AI code generator) used for extensive testing
• Node 20 performance improvements significant factor in decision
• Cost expectations also proved incorrect - Edge not always cheaper

Partial Pre-Rendering (PPR) Strategy

• Experimental feature enabling hybrid static/dynamic rendering
• Static parts stored as HTML, served immediately from Edge Network
• Dynamic parts stream in after server processing
• 50% faster time to first bite compared to SSR + streaming
• Allows benefits of static for static parts, dynamic for dynamic parts in parallel
• Key enabler for moving away from Edge runtime while maintaining performance

Technical Architecture Comparison

• Traditional: Request → Edge Network → Lambda spin-up → Code load → Response generation → Send
• PPR: Request → Immediate HTML response + parallel server processing → Stream remaining content
• Eliminates wait time for JavaScript bundle loading on server

Database and Global Replication Challenges

• Most data not globally replicated
• Running compute in many regions connecting to single US East database inefficient
• Data sovereignty concerns with global replication
• Race conditions and compliance issues with cross-border data deletion requirements
• Customer preference for private connections to services

Future Implications

• Networks have improved significantly, reducing Edge location benefits
• Vercel function improvements coming soon
• PPR provides path forward without Edge runtime complexity
• Node 20 performance gains unexpected but significant factor