Edge-Side Includes and Micro-Frontends: Composing UIs at the CDN Layer

Last updated October 2026

Edge-Side Includes (ESI) and micro-frontends are complementary architectural patterns that compose web user interfaces at the CDN or edge layer rather than in a monolithic application server. ESI allows CDN nodes to assemble pages from independently cached fragments, while micro-frontends let separate teams build, deploy, and scale independent UI components that are stitched together at the edge — enabling large-scale web applications to achieve both sub-second load times and independent team deployment cycles.

What Are Edge-Side Includes (ESI)?

Edge-Side Includes is a markup language (originally an Akamai/Oracle specification from 2001) that instructs a CDN or reverse proxy to assemble a page from multiple cached fragments. The core concept:

<!-- Main page template (cached for 1 hour) -->
<html>
<body>
  <header>
    <esi:include src="/fragments/header" />
  </header>
  <main>
    <esi:include src="/fragments/product-listing?category=electronics" />
  </main>
  <aside>
    <esi:include src="/fragments/personalised-recommendations"
                 ttl="0" />
  </aside>
  <footer>
    <esi:include src="/fragments/footer" />
  </footer>
</body>
</html>

In this example:

• The header and footer fragments are cached for hours (rarely change).
• The product listing is cached for minutes (inventory changes periodically).
• Personalised recommendations have zero TTL — fetched fresh on every request.

The CDN assembles the full page from these fragments at the edge, closest to the user. Only the fragments that need fresh data trigger origin server requests. This is dramatically faster than having the origin server render the entire page.

ESI Support in 2026

• Akamai: Full ESI support (they co-created the standard).
• Fastly: ESI support through Varnish VCL with custom ESI processing.
• Cloudflare: No native ESI, but Cloudflare Workers provide equivalent (and more powerful) functionality programmatically.
• Varnish Cache: Full ESI support for self-hosted CDN/reverse proxy setups.
• AWS CloudFront: Lambda@Edge functions provide similar fragment composition.

What Are Micro-Frontends?

Micro-frontends extend the microservices architecture to the frontend. Instead of a single monolithic frontend application, the UI is decomposed into independently developed, tested, and deployed fragments — each owned by a different team.

Key Principles

• Independent deployment: Team A can deploy their header component without coordinating with Team B’s product listing component.
• Technology agnostic: Each micro-frontend can use a different framework (React, Vue, Solid, even vanilla JS) as long as it produces standard HTML/CSS/JS output.
• Isolated state: Micro-frontends do not share global state. They communicate through well-defined APIs, custom events, or a shared event bus.
• Team ownership: Each team owns the full stack for their business domain — from database to API to frontend fragment.

Composition Strategies

How Do You Combine ESI with Micro-Frontends at the Edge?

The most powerful modern approach uses edge compute (Cloudflare Workers, Vercel Edge Functions, Deno Deploy) to compose micro-frontends:

Architecture Pattern

1. Each micro-frontend team deploys their fragment as an independent service (serverless function, container, or static HTML).
2. An edge function (the “shell” or “compositor”) receives the user’s request and determines which fragments to include.
3. The edge function fetches fragments in parallel (or from edge cache when available).
4. Fragments are assembled into a complete HTML document with a shared layout, navigation, and footer.
5. The assembled page is streamed to the client using HTML streaming (chunked transfer encoding), so the browser starts rendering before all fragments have arrived.

Cloudflare Workers Implementation Example

// Edge compositor — Cloudflare Worker
export default {
  async fetch(request) {
    const url = new URL(request.url);

    // Fetch fragments in parallel
    const [header, content, sidebar, footer] = await Promise.all([
      fetch('https://header-service.example.com/fragment', {
        cf: { cacheTtl: 3600 } // Cache header for 1 hour at edge
      }),
      fetch(`https://content-service.example.com${url.pathname}`, {
        cf: { cacheTtl: 300 } // Cache content for 5 minutes
      }),
      fetch('https://recommendations.example.com/sidebar', {
        cf: { cacheTtl: 0 } // Always fresh
      }),
      fetch('https://footer-service.example.com/fragment', {
        cf: { cacheTtl: 86400 } // Cache footer for 24 hours
      }),
    ]);

    // Assemble the page
    const html = `<!DOCTYPE html>
      <html>
      <head><title>My App</title></head>
      <body>
        ${await header.text()}
        <main>${await content.text()}</main>
        <aside>${await sidebar.text()}</aside>
        ${await footer.text()}
      </body></html>`;

    return new Response(html, {
      headers: { 'Content-Type': 'text/html' },
    });
  },
};

What Are the Performance Benefits?

Edge composition provides significant performance advantages over traditional server-side rendering:

• Reduced latency: Fragments are cached at 300+ edge locations worldwide (Cloudflare has PoPs in Mumbai, Chennai, Delhi, Kolkata, and Hyderabad in India). Users receive content from the nearest edge, with sub-50ms TTFB for cached fragments.
• Granular caching: A product page header (changes never) and footer (changes weekly) stay cached even when the product price (changes daily) needs a fresh fetch. In a monolithic SSR setup, any change invalidates the entire page cache.
• Parallel fragment fetching: The edge compositor fetches all fragments simultaneously. Total assembly time equals the slowest fragment, not the sum of all fragments.
• Streaming HTML: The browser receives and starts rendering the header while the product content is still being fetched. This dramatically improves First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

When Should You Use This Architecture?

Good fit:

• Large e-commerce sites with different teams managing header, product pages, search, recommendations, and checkout.
• Multi-brand platforms where shared navigation wraps brand-specific content.
• Content platforms with personalised elements (logged-in user state, recommendations) alongside static content.
• Organisations with 3+ frontend teams that need deployment independence.

Overkill for:

• Small to medium websites built by a single team.
• Applications where all content is highly dynamic and personalised (real-time dashboards, collaborative tools).
• Early-stage startups where speed of iteration matters more than architectural purity.

For Indian development teams, this architecture makes sense when you reach the scale where monolithic deployments cause coordination bottlenecks between teams — typically 3+ teams working on the same frontend application.

What Tools and Platforms Support Edge Composition?

• Cloudflare Workers: 300+ PoPs globally including 5 in India. Free tier: 100K requests/day. Paid: $5/month + $0.50 per million requests. Best for custom edge composition logic.
• Vercel Edge Functions: Integrated with Next.js Middleware. Excellent for Next.js-based micro-frontends.
• Netlify Edge Functions: Deno-based edge compute. Good for Jamstack micro-frontend architectures.
• AWS CloudFront + Lambda@Edge: Enterprise-grade, integrates with AWS ecosystem. Higher complexity and cost but maximum flexibility.
• Module Federation (Webpack 5 / Rspack): Build-time micro-frontend composition. Teams share dependencies and compose at build/runtime. Best for React-heavy organisations.
• single-spa: Client-side micro-frontend orchestrator. Framework-agnostic. Good when edge composition is not feasible.

Frequently Asked Questions

Is ESI still relevant in 2026 or has edge compute replaced it?

Traditional ESI markup is used less frequently, but the concept of fragment-based page composition at the edge is more relevant than ever. Modern implementations use programmable edge compute (Cloudflare Workers, Vercel Edge) instead of ESI markup, providing more flexibility (conditional logic, authentication, A/B testing) than the original ESI specification allowed.

How do micro-frontends handle shared styles and design consistency?

Use a shared design system distributed as an npm package (CSS variables, component library). Each micro-frontend imports the design system at build time. CSS Custom Properties (variables) defined in the shell/compositor propagate to all fragments. Avoid global CSS that can leak between fragments — use CSS Modules, Tailwind with prefix, or shadow DOM for style isolation.

What about SEO for micro-frontend applications?

Edge-composed micro-frontends are SEO-friendly because the assembled HTML is a complete document when it reaches the browser (and Googlebot). Client-side composed micro-frontends require careful handling: use server-side rendering for critical content and ensure Googlebot can render the assembled page. Edge composition is the most SEO-safe approach.

How do micro-frontends communicate with each other?

Use the Custom Events API: fragments dispatch events (e.g., cart-item-added) and listen for events from other fragments. For complex state sharing, use a lightweight event bus or URL-based state (query parameters, hash fragments). Avoid shared global state — it defeats the isolation benefit of micro-frontends.

Can Indian teams use Cloudflare’s India PoPs for edge composition?

Yes. Cloudflare has edge nodes in Mumbai, Chennai, Delhi (Noida), Kolkata, and Hyderabad. Indian users connecting to edge-composed pages receive assembled HTML from the nearest Indian PoP, with sub-20ms edge compute execution time. This means a page assembled from 4 cached fragments can achieve TTFB under 50ms for Indian users — comparable to serving a static HTML file.