The Edge Rendering Spectrum: The Decision Framework We Use for Content Sites

There is no one-size-fits-all approach to rendering web content. Deciding whether a page should be static, edge-rendered, or fully server-generated is one of the highest-leverage technical decisions you can make for performance, cost, and user experience. In 2026, with options multiplying — static build, Server Islands, edge SSR, server SSR, CSR — the problem is no longer "how do I render this" but "which part renders where."

We've been running mintec.co and several client sites on Astro + Cloudflare Pages for six months, mixing static builds with Server Islands and edge functions. Here are the real numbers, the decision framework we built from them, and the lessons learned.

The Spectrum: Six Rendering Levels

Most rendering analyses compare two options (SSG vs SSR) and stop there. In practice, there are at least six levels, each serving a different content profile:

The key isn't picking one level for the entire site — it's assigning each page or component to the right level. That's what makes this spectrum useful as a decision framework, not just a classification.

Our Production Data

We've measured these levels on real projects. The table above isn't theoretical — it maps to metrics from:

• mintec.co: static build (level 1) with Server Islands (level 3) for the project counter and dynamic testimonials. Full build in ~30s. Hosting: $0/month on Cloudflare Pages. Lighthouse 99/100.
• Multilingual editorial portal: 2,500+ pages in 3 languages. Static build (level 1). 95% of content served from CDN without executing a single function. Average TTFB of 98ms from edge in Panama for Latin American users.
• Luxury brand portal with 4K galleries: Server Islands (level 3) for deferred video loading. LCP went from 6.2s to 1.2s. INP of 98ms.

The pattern that keeps repeating: 80% of a content site can be static (level 1). 15% needs Server Islands (level 3). Only 5% requires edge SSR or higher (levels 4-6). When we violate this rule — and we have — we pay in infrastructure complexity and budget overruns.

The Decision Framework: Four Questions

Deciding the rendering level for each page or component comes down to four questions. We formulated these after several over-engineering attempts — that temptation we've talked about before.

1. How often does this data change?

This is the most important question. If content updates manually (blog posts, service pages), the answer is "at deploy time" — and the right choice is static build (level 1 or 2). If data changes hourly (pricing, inventory), you need Server Islands or Live Collections (level 3). If it changes on every request (personalized dashboard), you're at level 4+.

2. Does content vary by user or location?

No personalization → static or Server Island. Regional personalization (local currency pricing, country-specific testimonials) → Server Islands work if the number of variants is manageable. 1:1 personalization (each user sees something different) → edge SSR or server SSR.

3. How much traffic does it get, and from where?

For sites with predominantly Latin American audiences, latency matters more than in markets with better infrastructure. Our measurements show a static build served from Cloudflare edge (level 1) has a TTFB of 50-120ms across Latin America. Edge SSR from the same edge (level 4) adds 100-200ms of function execution time. Server SSR from a Miami VPS (level 5) can exceed 600ms for a user in Peru. On mid-range devices over 3G/4G connections, that difference can turn an acceptable page into one the user abandons.

4. How much interactivity does the page need?

Little to no interaction → static (level 1-2). Specific interactive components → islands (level 2-3). The entire page is an application → CSR (level 6) with SSR on critical routes.

The Decision Matrix

Combining the four questions, here's the matrix we use on every project:

What We Learned Applying This

Three concrete lessons after six months of applying this framework to real projects:

Over-engineering starts at level 3. Server Islands are so easy to implement in Astro 6+ that the temptation is to island-ize everything. On one project, the team made the footer a Server Island. The footer didn't need fresh data or personalization. It was faster and simpler as static HTML. The rule: if you can predict the output at build time, don't make it an island.

Edge isn't free. Although Cloudflare Workers has a generous free tier, every Server Island or edge function invocation adds latency and cost. We measured a page with 3 Server Islands had a TTFB 2.3x higher than the same page with 0 islands (98ms vs 225ms). For most cases, it's worth it — but it proves you shouldn't add islands for technical aesthetics, only when data requires it.

LatAm needs the edge more than other markets. Cloudflare's 300+ points of presence make static builds served from the edge competitive even against local servers. We've seen traditional Miami-hosted sites perform worse for Central American users than a static build on Cloudflare Pages. For our Latin American clients, static build + edge is almost always the right combination, with Server Islands only for the minimum components that genuinely need live data.

When to Move Up the Spectrum

The framework isn't rigid. There are cases where moving up makes sense even when the four questions say otherwise. Our Astro vs Next.js benchmarks show that a project can benefit from edge SSR even with mostly static content if it needs complex multilingual rendering or cross-browser accessibility that requires server-side logic.

The difference between a good web architect and a great one isn't knowing how to implement Server Islands or edge functions — it's knowing when not to use them. That judgment is what separates a fast, maintainable site from an over-architecture that feels modern but costs more than it delivers.

If you're defining the architecture for your next content site, start minimal (static build) and scale up only when the data demands it. That discipline, more than any specific technology, is what actually determines production performance.