Edge SSR vs Static SSG: Latency and Cost Tradeoffs

In modern web architecture discussions, edge computing is often promoted as the definitive solution for high-concurrency web applications. Deploying server-side rendering (SSR) compute across 300+ global edge nodes promises millisecond compute latency close to every user on the planet.

However, in production environments, edge SSR introduces distinct latency overheads, operational complexities, and egress billing risks that many development teams fail to anticipate. For high-converting B2B platforms, SaaS documentation hubs, and agency client builds, pure Static Site Generation (SSG) distributed over an edge CDN consistently outperforms dynamic edge runtime execution in real-user Core Web Vitals and infrastructure cost.

Below is an engineering analysis of when to deploy pure static pre-rendering versus dynamic edge compute, backed by real-world Time to First Byte (TTFB) benchmarks and caching topologies.

1. The Physics of TTFB: Edge Cache vs. Edge Compute

To understand why pure static assets consistently outperform edge SSR, consider the lifecycle of an HTTP GET request under both architectural paradigms:

[Pure Edge SSG Architecture]
User Request ──> Anycast CDN Edge ──> Cache Hit (Memory/SSD) ──> 15ms TTFB Delivery

[Dynamic Edge SSR Architecture]
User Request ──> Anycast CDN Edge ──> Worker V8 Isolate Spin-Up (Cold/Warm)
                                          │
                                          ├──> Origin DB / D1 / KV Lookup (Network Hop: 40-120ms)
                                          ├──> React / Framework HTML Serialization (15-35ms)
                                          └──> Dynamic Response Stream ──> 90-180ms TTFB Delivery

Pure Edge SSG Delivery (Sub-25ms TTFB)

In a static architecture built with Astro SSG and distributed via Cloudflare Pages or AWS CloudFront:

1. Every HTML document, inline CSS payload, and SVG asset is generated ahead of time at build time.
2. The entire compiled document tree is cached in RAM and NVMe storage across every edge point of presence (PoP).
3. The incoming request is terminated at the local edge node without executing dynamic application logic or querying an origin database.
4. Median TTFB globally: 12ms to 28ms.

Dynamic Edge SSR Execution (80ms - 220ms TTFB)

In an edge SSR architecture (such as Next.js edge runtimes or dynamic Workers):

1. The request reaches the edge node and initializes or warms a lightweight V8 isolate.
2. The edge worker must assemble personalized or dynamic HTML by querying external datastores: KV, edge SQL databases (like Cloudflare D1, PlanetScale, or Supabase), or third-party headless CMS GraphQL APIs.
3. While the compute node sits physically near the user, the database origin frequently resides in a centralized data center (e.g., us-east-1 or eu-central-1).
4. Every round-trip database query incurs speed-of-light speed constraints. Even with global read replicas, cross-region replication lag and serialization overhead routinely inflate TTFB beyond 100ms.

For search crawlers and conversion-critical landing pages, this difference directly impacts your Core Web Vitals & Conversion Audits score and Largest Contentful Paint (LCP) trajectory.

2. Real-World TTFB Benchmarks: Global Latency Matrix

We tested identical landing page payloads (45 KB document size, 14 KB critical inline CSS, modern SVG illustrations) across 5 global geographic regions over 1,000 requests.

The benchmark compares Edge Static (Cloudflare Pages SSG) against Edge SSR (Workers with KV Lookup) and Centralized Node.js SSR (Frankfurt AWS EC2):

The benchmark reveals two critical engineering conclusions:

• Edge SSG is impervious to distance: Because immutable static assets reside natively in local edge memory, global latency variance is negligible (12ms in Frankfurt vs. 26ms in Sydney).
• Edge SSR degrades with distributed data dependencies: When an edge worker must coordinate with backend databases or headless APIs, distance penalties re-emerge immediately.

3. The Financial Equation: Infrastructure Runaway vs. Flat-Rate Edge

Beyond raw performance, infrastructure billing models diverge dramatically as page traffic scales:

Total Monthly Cost Comparison at 2,000,000 Monthly Pageviews

[Edge SSR (Worker Invocations + KV Reads + Egress)]
  ├── Worker Requests: 2,000,000 x $0.30 / 1M = $0.60
  ├── CPU Execution Time: 2,000,000 x 25ms = 50,000 CPU sec = $12.50
  ├── KV / Database Read Operations: 4,000,000 reads = $2.00
  ├── Upstream Origin Headless CMS Bandwidth & Rate Limit Tiers = $150.00 - $400.00
  └── Total Operating Cost: $165.10 - $415.10 / month (Variable & Risky)

[Edge SSG (Static Pre-Rendered Build via Cloudflare Pages)]
  ├── Static HTML Bandwidth: Unlimited at $0.00 egress
  ├── Edge Invocations: $0.00 (Served via Global Cache Layer)
  ├── Origin Database Queries: 0 queries during visitor runtime
  └── Total Operating Cost: $0.00 - $20.00 / month (100% Fixed)

In an edge SSR architecture, sudden traffic spikes from viral social media campaigns or automated AI scrapers multiply compute execution cycles and trigger unexpected tier upgrades on upstream headless APIs.

In an SSG architecture engineered with Headless & Static Web Engineering, the entire production bundle is baked into flat files. Even a sudden surge of 100,000 simultaneous concurrent users incurs zero database pressure and zero incremental compute billing.

4. The Modern Hybrid Architecture: Islands over Compute

Does choosing Static Site Generation mean sacrificing dynamic functionality? Not when you employ modern Islands Architecture and client-side edge micro-queries:

<!-- Example: Static Shell with Dynamic Edge Micro-Island -->
<header class="site-header">
  <!-- 100% Pre-Rendered Static HTML (Zero Runtime Overhead) -->
  <a href="/" class="brand-logo">2RUN</a>
  <nav class="nav-links">
    <a href="/services/">Services</a>
    <a href="/case-studies/">Case Studies</a>
  </nav>

  <!-- Dynamic Island: Only executes micro-fetch for authenticated state -->
  <auth-badge-island client:idle>
    <template shadowrootmode="open">
      <span class="user-greeting" id="user-display">Loading...</span>
    </template>
  </auth-badge-island>
</header>

Under this pattern:

1. The Critical Path Remains 100% Static: 98% of the document—including all marketing content, typography, Schema graphs, and navigation—is delivered instantly via static cache.
2. Dynamic Elements Hydrate Post-FCP: Truly dynamic features (user authentication, shopping carts, localized currency pricing) hydrate lazily using client-side micro-APIs.
3. Googlebot and Bingbot Experience Instant Paints: Search engine crawlers parse pristine semantic HTML without waiting for JavaScript execution or server-side hydration loops.

If your platform requires authenticated portals or custom lead generation engines, see our approach to Interactive Web Applications & Portals.

5. Architectural Decision Matrix

Use the following architectural criteria to determine whether your next platform requires Edge SSR or Edge SSG:

Engineering Conclusion

For 95% of high-value business websites and agency client builds, full Edge SSR is architectural over-engineering that increases financial risk and TTFB latency without delivering measurable user value.

By building on immutable, pre-rendered static foundations with selective client-side islands, engineering teams achieve true sub-30ms global response times, eliminate backend security vulnerabilities, and establish durable Pass Core Web Vitals performance.

If you are planning an enterprise headless migration or evaluating architecture tradeoffs for your clients, contact our Tallinn engineering studio to discuss your technical specifications.