The Web's "Compression Algorithm": Static → Web 2.0 → SPA → SSR/Edge
The web didn’t evolve because developers got bored. It evolved because latency, state, and economics kept forcing us to move responsibility between server, client, and edge. This post gives you the mental model and the checklist to choose the right rendering architecture in 2021+
Axel Domingues
This blog started as “learn Machine Learning, Deep Learning and Reinforcement Learning.”
It ended as “build a system that can survive.”
In 2021, I’m taking that lesson back to the web—because the web is the most successful distributed system most engineers will ever ship to millions of users.
And it has one recurring pattern:
The web keeps “compressing” complexity by moving work to a different place.
Server → browser → server again (SSR) → edge.
Not as a trend.
As a response to constraints.
- crisp mental models
- pragmatic tradeoffs
- and checklists you can actually use in design reviews
The “Compression Algorithm” Mental Model
When I say “compression algorithm”, I mean this:
We take product requirements (SEO, interactivity, personalization, performance, reliability, cost) and compress them into a delivery shape by deciding where computation and state live.
Every era of the web is a different answer to one question:
Where does the work happen?
- on the server
- in the browser
- or on the edge (CDN/serverless)
Each move wins something and costs something.
If you remember nothing else from this post, remember this:
The core question
Where does truth live, and where do you pay the latency bill?
The Three Forces That Keep Rewriting “Best Practice”
If you want to predict the next “web era”, don’t watch framework hype.
Watch these forces:
Latency
Users feel round-trips. Architectures evolve to hide or remove them.
State
Once you have real state (auth, carts, drafts, permissions), you need contracts and boundaries.
Economics
Bandwidth, compute, and developer time are always constrained—even when budgets are “big”.
Tooling maturity
Browser APIs, JS engines, CDNs, and frameworks enable new tradeoffs (and new failure modes).
These forces explain why the web swings like a pendulum:
- Static → Web 2.0: “We need interactivity without full reloads.”
- Web 2.0 → SPA: “We can build apps in the browser like desktop apps.”
- SPA → SSR/SSG: “We overpaid in performance, SEO, and complexity.”
- SSR → Edge/Hybrid: “We want dynamic experiences at CDN latency.”
A Quick Timeline (The Part People Argue About)
I’m not going to do a history lecture. I’m going to do a tradeoff timeline.
How it worked
- Server renders HTML, returns a document.
- The browser is mostly a viewer.
- State is minimal; pages are “snapshots”.
What it optimized
- Simple deploys
- Great cacheability
- Low operational complexity
What broke
- Rich interactions required full reloads.
- Anything “app-like” felt heavy and slow.
How it worked
- Server still owns rendering, but the browser starts requesting data and updating parts of the page.
- Interactivity becomes incremental.
What it optimized
- Faster UX without full reloads
- A path to “app-like” experiences
- Early separation of “data” vs “markup”
What broke
- Complexity leaks into client-side JS.
- You now have two systems to reason about: server rendering + client behavior.
How it worked
- The browser downloads a JS app.
- The server provides APIs.
- Routing, state, rendering, and caching move client-side.
What it optimized
- Product teams shipping UI quickly
- Reusable component architectures
- Rich client behavior (desktop-like)
What broke
- Performance became fragile (bundle size, waterfalls, slow devices).
- SEO became “special handling”.
- You introduced client/server consistency problems (auth, caching, version drift).
How it worked
- Render HTML on the server (or at build time), then hydrate with JS.
- You get fast first paint + app interactivity.
What it optimized
- SEO
- Time-to-first-byte / first contentful paint (when done well)
- A more predictable “page” delivery model
What broke
- Hydration mismatch and complexity.
- Server costs reappear.
- Cache invalidation becomes a design problem again.
How it works
- Use CDNs, edge functions, and hybrid rendering strategies.
- Personalize near users, cache aggressively, stream where possible.
What it optimizes
- Lower latency globally
- Flexible caching + personalization
- A “best of both” approach in many cases
What breaks
- Debuggability (distributed runtime)
- Subtle consistency and rollout issues
- Vendor/platform constraints
The key lesson is not “SSR good” or “SPA bad.”
The lesson is:
The Architecture Decision Hidden in Every Web App
Every web system has to answer these questions, whether you admit it or not:
- Where is your “source of truth” state? (server DB, browser memory, edge cache)
- How is that state projected into UI? (HTML, JSON → React, streamed fragments)
- How do you cache it without lying? (CDN, browser cache, Redis, revalidation)
- How do you deploy changes safely? (versioning, rollbacks, compatibility)
If you treat these as “implementation details,” your system will eventually punish you.
The Four Archetypes You’ll Actually Ship
Most teams don’t ship “an architecture.”
They ship one of these four archetypes (or a hybrid).
Static + CDN
Pre-render pages (SSG) and push to a CDN.
Best for content and “mostly-read” experiences.
SPA + API
JS app in the browser calling backend APIs.
Best for highly interactive, authenticated apps.
SSR + API
Server renders initial HTML, then client hydrates.
Best for SEO + performance-sensitive pages with real interactivity.
Hybrid / Edge-rendered
Mix SSG, SSR, and edge personalization.
Best for global products that need speed and dynamic behavior.
The mistake is trying to decide between them as ideologies.
You decide by constraints.
Choosing Your Rendering Strategy (A Practical Checklist)
Use this in design reviews. It’s intentionally blunt.
Step 1 — Classify your UX: “content” or “application”?
- Content-heavy: marketing, docs, blog, browse pages → lean SSG/SSR
- App-heavy: dashboards, editors, trading terminals → lean SPA/hybrid
If you’re mixed, you’re headed toward hybrid anyway.
Step 2 — Define your state: what must be correct?
List state that cannot lie:
- auth + permissions
- money + inventory + quotas
- identity + privacy
- drafts + collaboration
If correctness dominates, you’ll keep more logic server-side (or you’ll build a lot of compensations).
Step 3 — Draw the “latency budget”
Pick a target for:
- initial page response time (TTFB)
- time-to-interactive on mid devices
- p95/p99 expectations (yes, for the frontend)
If you don’t define the budget, the bundle will define it for you.
Step 4 — Choose your caching posture (explicitly)
- Cache everything (content sites) → SSG + CDN + revalidation
- Cache carefully (personalized apps) → split public/private, key caches, avoid user-leaks
- Cache almost nothing (highly dynamic) → optimize server + avoid waterfalls
Step 5 — Decide what runs where
- server: correctness + security + expensive compute
- client: interactivity + local responsiveness
- edge: fast personalization + global speed, but limited runtime
Step 6 — Plan migration paths (because you will change)
The best architecture is one you can evolve:
- SPA → SSR for critical routes
- SSR → SSG for stable content
- add edge for localized personalization
- split “app shell” from “content delivery”
- no observability
- brittle deploys
- no performance budgets
- unclear ownership for caching and invalidation
What Each Approach Costs You (The Part Roadmaps Usually Hide)
Let’s be honest about the bills.
You pay in content pipelines and invalidation strategy.
If “content is code,” you need:
- previews
- staged publishing
- cache busting / revalidation rules
- a plan for dynamic fragments (search, personalization, auth)
It’s cheap to run, but you still need process discipline.
You pay in performance budgets and client/server consistency.
You need:
- bundle governance (or you’ll ship 5MB apps)
- API evolution discipline
- careful auth handling (tokens, refresh, CSRF considerations)
- caching that doesn’t leak user data
SPAs are powerful—but they are easy to operate badly.
You pay in complexity: two runtimes, two failure modes.
You need:
- hydration discipline (avoid “works locally, breaks in prod”)
- clear separation of server-only and client-only code
- smart caching and revalidation (or you’ll DDoS yourself)
- performance observability both server and client
SSR is a great tool. It’s also a great way to invent subtle bugs.
You pay in debuggability and distributed operations.
You need:
- traceability across edge + origin
- careful rollouts (edge caches make “instant rollback” less instant)
- runtime constraints awareness (CPU/memory/timeouts)
- explicit data boundaries (what’s safe to compute at edge)
Hybrid systems win speed—but require operational maturity.
The “Where Does State Live?” Map
Here’s the simplest mental model I know that stays useful for years:
- Server state is authoritative (correctness, security, auditability)
- Client state is experiential (UX, responsiveness, local intent)
- Edge state is opportunistic (performance, locality, caching)
And every bug you’ve seen in web systems is usually a violation of that map.
- Client “optimistically” shows a thing that the server rejects → user confusion
- Cache returns a personalized page to the wrong user → security incident
- SSR renders a view that hydration can’t reproduce → flaky UI
A Reference Architecture You Can Actually Explain to a Team
Here’s the framing I like in architecture discussions:
- Delivery layer: CDN + caching rules (public vs private)
- Rendering layer: SSG/SSR/hybrid, per route
- Interaction layer: client app shell for high-interactivity sections
- API layer: contract-first design, versioning discipline
- Data layer: DB + cache + jobs (we’ll get there later this year)
The key is per-route strategy:
- marketing/docs/blog routes: SSG/SSR + CDN
- authenticated app routes: SPA/hybrid
- critical landing pages: SSR with strict performance budgets
- global personalization: edge middleware (carefully)
The Playbook: How I Decide in Real Projects
If I’m advising a team from scratch, I usually recommend:
Default to hybrid by routes
Don’t pick “one rendering mode.” Pick per route, based on constraints.
Push correctness server-side
Auth, permissions, money, and privacy stay authoritative on the server.
Make performance a budget
Budgets force tradeoffs early. Without them, you ship accidental slowness.
Treat caching as a feature
Caching has owners, rules, invalidation strategy, and tests.
And I try to keep one rule visible on a wall:
One rule that prevents most pain
If you can’t explain “where state lives” and “how it becomes UI,” you don’t have an architecture yet.
Common Misconceptions (That Cause Expensive Rewrites)
SSR can be faster for first paint, but it can also be slower overall if:
- your server is under-provisioned
- your pages are uncached
- your hydration payload is still huge
The fastest SSR page is usually the one that behaves like static content with smart revalidation.
SPAs can be fine when:
- the page is behind auth (SEO irrelevant)
- your critical public routes use SSR/SSG
- you use metadata rendering intentionally
The real question is “which routes matter for discovery?” not “is SPA allowed?”
Edge reduces network latency, but it can increase complexity:
- distributed caching and rollouts
- harder debugging
- constraints on runtime and data access
Edge is a tool. Use it where it buys measurable latency wins.
In web systems, “later” means:
- you already shipped the bundle
- your users already formed an opinion
- your team already normalized slowness
Performance needs budgets, guardrails, and CI checks—early.
Closing: Why This Is the Right Starting Point for 2021
Reinforcement learning trained me to think in feedback loops:
- small assumptions become huge failures
- hidden costs show up at scale
- and the system always tells on you—eventually
The web is the same.
Your rendering strategy is not a framework choice.
It’s an economic and operational decision about:
- latency and UX
- correctness and state
- deployment and safety
- and what your team can maintain
What’s Next
Next month we go one layer deeper and treat HTTP as a distributed systems API—without the buzzwords.
Because once you understand HTTP semantics (caching, idempotency, retries, proxies), you stop designing “APIs” and start designing systems that survive the real internet
HTTP as a Distributed Systems API (Without the Buzzwords)
HTTP isn’t just “how browsers talk to servers.” It’s a mature distributed-systems contract with semantics for caching, retries, concurrency, intermediaries, and evolution. If you design APIs without those semantics, production will teach you them anyway.
From Research Rig to System: 2020 Postmortem and the Real Amazing Result
2020 is when I stopped training agents and started building a trading system: environments, evaluation discipline, safety, and a live loop that survives outages. This is the postmortem — and the first result that actually held up in reality.