Skip to main content

Service Evaluation

Edge-Side Includes vs Prerendering: SEO Verdict

ESI vs atomic prerendering for SEO: which model delivers complete crawler HTML, better DOM consistency, and crawl efficiency.

7 min readUpdated
Apply the checklist with ostr.ioRead related guides →
Edge-Side Includes vs Prerendering: SEO Verdict

Article

Edge-side Includes and atomic prerendering are both answers to the same architectural question: how do you serve fast, complete HTML from a CDN edge without requiring every request to hit an application server? They reach different answers through different mechanisms, and those differences have direct implications for DOM consistency, crawl efficiency, and AI crawler readiness.

This article compares both approaches at the engineering level so teams can choose the right delivery architecture for their specific SEO and performance requirements.

How Edge-side Includes Work

ESI (Edge-side Includes) is a markup language that instructs CDN edges to assemble HTML fragments before serving the response. A page template includes ESI tags that reference external fragment URLs:

html
<!-- Product page template with ESI -->
<html>
  <head>
    <title>Product Name</title>
    <esi:include src="/api/product/123/meta" />
  </head>
  <body>
    <esi:include src="/fragments/header" ttl="3600" />
    
    <div class="product-static">
      <h1>Product Name</h1>
      <p>Product description...</p>
    </div>
    
    <!-- Dynamic price fetched fresh per request -->
    <esi:include src="/api/product/123/price" ttl="60" />
    
    <esi:include src="/fragments/footer" ttl="3600" />
  </body>
</html>

When Cloudflare, Fastly, or Varnish processes this template, it sends parallel requests to each fragment URL, receives the HTML responses, inserts them into the template at the ESI tag positions, and serves the assembled HTML to the requester.

For crawlers, the result looks like a complete HTML page. The assembly happens at the CDN edge — invisible to Googlebot. TTFB is fast because the static template is cached; fragment fetch latency is the only variable.

Raster technical flow diagram for Edge-side Includes vs. Pre-rendering: Which Delivers Better SEO? — delivery paths, caching, and crawler-facing HTML.

How Atomic Prerendering Works Differently

Atomic prerendering generates the complete final HTML of a page by executing the full application stack — JavaScript, data fetching, component rendering — in headless Chrome. The result is a static snapshot that represents the page's fully rendered state at a specific point in time.

This snapshot is cached in CDN and served to crawlers on request. When Googlebot fetches a prerendered URL:

  1. CDN receives the request with Googlebot's User-Agent
  2. CDN routes to the prerendered snapshot
  3. Complete HTML is returned from cache, no assembly required
  4. TTFB is at CDN cache speed — typically 40–100ms

The difference from ESI: there are no real-time fragment requests. The page is not assembled per request. It was assembled once during snapshot generation, and every crawler receives the same static output.

DOM Consistency Comparison

DOM consistency — the match between what crawlers index and what users see — differs significantly between ESI and prerendering.

ESI DOM consistency:

ESI delivers fresh fragment content on each request. The price fragment fetched for the user and the price fragment fetched for Googlebot are generated at the same moment and should be identical — unless the fragment depends on user-specific parameters, session state, or geographic variables. In those cases, ESI can serve different content to users and crawlers even when WAF access is not the issue.

ESI's consistency vulnerability is timing: fragments assembled for Googlebot at 2 PM may reflect different inventory data than fragments assembled for a user at 2:01 PM. For rapidly changing data, this is acceptable. For content that should be crawler-stable, it introduces risk.

Prerendering DOM consistency:

Prerendering snapshots represent the page at generation time. Googlebot receives the same snapshot on every visit until the snapshot is refreshed. DOM consistency is 100% — the snapshot is the definitive state. The prerender delta (difference between snapshot and live page) is the only consistency variable, managed through Cache Warming API and TTL configuration.

Freshness Comparison

ESI freshness:

ESI is inherently real-time for fragments with low TTL. A price fragment with a 60-second TTL is at most 60 seconds stale. For e-commerce where price accuracy is critical — and where serving wrong prices to crawlers creates legal and commercial risk — ESI's per-request freshness is a significant advantage.

Prerendering freshness:

Prerendering snapshots have finite TTL. When content changes, the snapshot may be stale until the next generation cycle or until a Cache Warming API trigger refreshes it. For content that changes continuously (live inventory, real-time pricing), snapshot staleness is a real limitation.

The resolution: event-driven snapshot refresh. When a price update is published, trigger a snapshot regeneration for the affected product URLs. Combined with appropriate TTL settings, this achieves effective freshness for most e-commerce scenarios.

Raster comparison panel summarizing architectural tradeoffs discussed in Edge-side Includes vs. Pre-rendering: Which Delivers Better SEO?.

Performance Comparison

MetricESIAtomic Prerendering
TTFBMedium (fragment fetch latency)Fast (CDN cache, no assembly)
Render cost for GooglebotZero (static HTML)Zero (static HTML)
DOM consistencyHigh with care (no hydration risk)100% (no real-time assembly)
Freshness for dynamic dataReal-time (low TTL)Bounded by snapshot TTL
Infrastructure complexityMedium (CDN ESI support required)Medium (headless rendering pipeline)
Shadow DOM / JS contentNot accessibleFully captured

When ESI Is the Right Choice

  • E-commerce with real-time pricing requirements: Prices, inventory, promotional discounts that must be accurate within seconds for legal or commercial reasons.
  • Personalized static content: Header elements that vary by geography or membership tier but are derived from deterministic server logic, not client-side state.
  • Teams already operating Fastly or Varnish: ESI is native to these CDNs. Teams with existing ESI infrastructure can extend it to SEO use cases without adding a prerendering pipeline.

When Prerendering Is the Right Choice

  • JavaScript-heavy pages with complex rendering: Content that depends on client-side data fetching, feature flags, or dynamic component trees that ESI cannot assemble at the fragment level.
  • Shadow DOM, Web Components, or Canvas content: ESI cannot extract content from advanced JavaScript rendering patterns. Headless Chrome prerendering can.
  • 100% DOM consistency requirement: For acquisition-critical templates where navDemotion risk must be eliminated, prerendering's snapshot model is the only reliable path.
  • AI crawler readiness: Prerendered snapshots contain complete JSON-LD, heading structure, and entity-rich content in the static HTML — essential for semantic density optimization for GPTBot and ClaudeBot.

Combining ESI and Prerendering

The most sophisticated architectures use both, with routing logic that directs each request type to the optimal delivery path:

nginx
# Route by User-Agent at reverse proxy
locationlocation / {
  # Search crawlers → prerendered snapshot
  ifif ($http_user_agent ~* "Googlebot|GPTBot|ClaudeBot|Bingbot") {
    proxy_passproxy_pass http://prerender-cache;
    breakbreak;
  }
  
  # Users → ESI-assembled dynamic content
  proxy_passproxy_pass http://esi-enabled-cdn;
}

Crawlers receive prerendered HTML with 100% DOM consistency and full JavaScript-rendered content. Users receive ESI-assembled pages with real-time fragment data and optimized performance. Each audience gets the delivery mechanism designed for their constraints.

FAQ

Frequently Asked Questions

Fastly and Varnish support ESI natively. Akamai has limited ESI support. Cloudflare does not support standard ESI, but Cloudflare Workers can implement ESI-like fragment assembly through custom logic.

Yes, if JSON-LD is served as a fragment from an origin endpoint. The JSON-LD is inserted into the template at the ESI tag position and appears in the assembled HTML that crawlers receive. Teams implementing this must ensure the JSON-LD fragment reflects accurate page data, not stale or default values.

ESI reduces TTFB compared to origin-rendered pages, which benefits FCP and LCP. It does not affect CLS or INP, which depend on client-side rendering behavior.

The infrastructure cost profiles differ. ESI adds fragment request overhead to CDN operations but requires no compute for snapshot generation. Prerendering requires periodic snapshot generation (compute cost) but serves those snapshots from CDN cache without per-request overhead. For large-scale sites with infrequent content changes, prerendering is typically more cost-efficient. For real-time content, ESI avoids the freshness management overhead of prerendering. !Raster matrix diagram of operational levers, risks, and validation checks for Edge-side Includes vs. Pre-rendering: Which Delivers Better SEO?.

Editorial trust

Written by prerender Editorial · Engineering Team. We build and run pre-rendering infrastructure for more than 200 engineering teams, which is where the numbers and code samples on this page come from.

Last updated . Editorial scope and review policy: About prerender.info.