How Edge Stream Rendering (ESR) Boosts Front‑End Performance

Background

First‑page scenarios (e.g., SEO, paid traffic) often suffer from poorer performance than subsequent pages because users cannot benefit from connection reuse or local cache, and many client‑side optimizations (preload, prefetch, prerender) are unavailable.

Ideas

Idea 1: SSR

Server‑Side Rendering outputs the first‑screen dynamic content from the server, eliminating a second request, but it can cause long white‑screen times for distant servers and still requires loading JS/CSS before the page becomes visible.

Idea 2: CSR + CDN

Cache the static HTML framework in CDN so users see the page skeleton quickly, then fetch dynamic content asynchronously on the client. This reduces white‑screen time but delays the final dynamic content compared with SSR.

Idea 3: ESI

Edge Side Include (ESI) lets CDN cache static parts while dynamically assembling the page, yet the first byte still waits for all dynamic fragments, offering little improvement over SSR.

Idea 4: Edge Stream Rendering (ESR)

By using edge computing, ESR streams static content first from the CDN edge node, then initiates dynamic requests at the edge and streams the dynamic fragments after the static part, achieving a short TTFB and early page skeleton display.

Rendering Process

The edge node quickly returns the static portion (e.g., header, skeleton) and concurrently fetches dynamic fragments, appending them to the response stream. This yields a short first‑byte time, early static rendering, and dynamic content that arrives without blocking the static part.

Demo Comparison

Experiments on a typical first‑page (alicdn) under various network throttling (Wi‑Fi, 4G, 3G) show that ESR consistently delivers the main elements earlier and reduces white‑screen time compared with traditional SSR.

Overall Architecture

ESR relies on templates that separate static and dynamic sections. Three template types are supported:

Original HTML with ESI‑style markers.

Static template stored on CDN.

Dynamic blocks fetched via edge workers.

During rendering, the edge parses the template top‑to‑bottom, returning static fragments immediately and fetching dynamic fragments on demand, allowing interleaved static and dynamic streams.

Static Content Handling

Static fragments can be returned first and then followed by dynamic content (big‑pipe style) or wait for all dynamic parts before completing the response.

Dynamic Content Handling

Three dynamic delivery modes are defined:

Full HTML from backend, extracted via markers (large payload).

Only dynamic fragment HTML returned by backend (smaller payload).

Backend returns data only; edge renders HTML from a static template (minimal payload).

Edge Routing

Routing configuration (JSON) determines which pages use ESR, redirect, or proxy modes. Only pages listed in the config follow the ESR flow; others fall back to origin.

Stability & Exception Handling

DNS fallback to origin if CDN fails.

Disable edge computing on errors and revert to dynamic acceleration.

On edge rendering errors after static part is sent, inject a location.reload() script with a bypass flag.

Gray Release

Edge code, routing config, and page content can be released gradually using weighted traffic splitting and version flags, with cache invalidation on full release.

Smooth Release

To avoid mismatches between front‑end assets and back‑end HTML during phased deployments, version numbers are used to ensure compatible static resources are served together.

Edge CDN Providers

AliCDN: supports service‑worker‑like edge computing.

Akamai: only simple request rewriting, no streaming.

Cloudflare: supports edge workers but integration may be complex.

Implementation Plan & Results

A pilot on a first‑page scenario in Indonesia showed ESR reduces TTFB by ~1 s, white‑screen time by ~1 s, and core content display time by ~500 ms.