Dynamic Open Graph Image Generation at CDN Edge: Social Sharing Thumbnails on Demand

Last year I watched a client's product launch fall flat on Twitter — not because the feature was bad, but because every single share showed the same generic fallback image. Their build pipeline had generated 12,000 static OG images overnight, yet the crawlers for Slack, LinkedIn, and iMessage all got a stale placeholder. If you've ever tailgated a deploy just to fix a social thumbnail, you know that feeling. That's exactly why we moved OG generation to the edge.

Why Static Builds Can't Keep Up With Social Crawlers

For years, the standard approach was simple: generate your open graph images at build time, upload them to S3 or your origin, and call it a day. It works fine when you've got a few hundred blog posts that rarely change. It completely falls apart when you're dealing with user-generated content, personalized titles, or anything that updates more than once a day. I've worked with media sites where the build would take 45 minutes just to re-render thumbnails after a headline change, and by then editors had already pushed three more updates.

The other problem nobody tells you about is how aggressive social crawlers are. They don't behave like browsers. Facebook's crawler, Twitterbot, and Slack's unfurler won't wait around for lazy-loaded assets and they don't execute much JavaScript. They expect an og:image URL that returns a valid image in under a couple seconds, ideally with proper Cache-Control and Content-Type headers as defined in the HTTP Working Group Specifications. If your origin is slow or your CDN isn't configured to handle that crawler traffic separately, you’ll see timeouts and fallback images. Our Image CDN Architecture Design: Building a Scalable Image Processing Pipeline covers that separation in more detail, but for OG images the stakes are higher because you don't get a second chance — the crawler caches what it sees first.

// Edge worker: intercept OG image requests and generate on demand
// Example using Cloudflare Workers + Satori (HTML-to-SVG) + resvg
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (!url.pathname.startsWith('/og/')) {
      return fetch(request);
    }

    const title = url.searchParams.get('title')?.slice(0, 120) || 'Untitled';
    const author = url.searchParams.get('author') || 'Editorial Team';
    
    // Generate SVG from JSX template, then convert to PNG at the edge
    const svg = await satori(
      <div style={{ display: 'flex', background: '#0a0a0a', color: 'white', width: 1200, height: 630, padding: 64 }}>
        <h1 style={{ fontSize: 72, fontWeight: 800 }}>{title}</h1>
        <p style={{ fontSize: 32, opacity: 0.8 }}>{author}</p>
      </div>,
      { width: 1200, height: 630, fonts: [await loadFont(env)] }
    );

    const png = await resvgRender(svg); // WASM-based, runs in worker isolate
    
    return new Response(png, {
      headers: {
        'Content-Type': 'image/png',
        'Cache-Control': 'public, max-age=86400, stale-while-revalidate=604800',
        'CDN-Cache-Control': 'public, max-age=31536000',
        'Vary': 'Accept-Encoding'
      }
    });
  }
}

Rendering at the Edge Without Blowing Your Compute Budget

When I first tried this approach back in 2020, we were running headless Chrome on Lambda. It worked, but it was painfully slow — 1.5 to 2 seconds per image, plus you'd pay for a full browser launch on every cold start. You don't need that anymore. Modern edge runtimes let you generate a 1200x630 PNG without spinning up a browser at all. Libraries like Satori, Vercel's OG library, and custom Canvas/WebAssembly builds can render text, gradients, and even remote images entirely inside a Worker isolate in under 150ms.

The trick is keeping the template lightweight and the dependencies small. Don't bundle a full image manipulation suite to the edge. I keep one worker that only handles OG rendering, with fonts subsetted and hosted on R2 or KV, and images fetched from your existing image CDN. That way the edge function does one job: compose text and layout into a PNG. For actual photo resizing or format negotiation, let your main image pipeline handle it. If you're already automating variants for the front end, this pattern slots right in alongside your Responsive Image CDN Automation: Generating srcset Variants on the Fly workflow — same origin, different route and cache rules. And like we discuss in Balancing Lazy Loading and Preloading with CDN: Optimal Image Loading Strategies, you’ll want to be explicit about what's preloaded for users versus what's fetched only for crawlers.

# Cache rules optimized for social crawlers (Varnish / Fastly VCL or CDN config)
# Serve stale while revalidating so crawlers never wait for a render

sub vcl_fetch {
  if (req.url ~ "^/og/") {
    # Edge-generated images can be cached for a year, revalidated in background
    set beresp.ttl = 365d;
    set beresp.grace = 7d;
    set beresp.http.Cache-Control = "public, max-age=86400, stale-while-revalidate=604800";
    set beresp.http.CDN-Cache-Control = "public, max-age=31536000, immutable";
    
    # Don't cache errors - let next crawler retry quickly
    if (beresp.status >= 400) {
      set beresp.ttl = 60s;
      set beresp.grace = 0s;
    }
  }
}

# Normalize query params to improve hit ratio: sort and lowercase title
sub vcl_hash {
  if (req.url ~ "^/og/") {
    set req.url = querystring.sort(req.url);
  }
}

Cache Control, Invalidation, and What It Really Costs

Here's where most teams get tripped up: they generate images dynamically but cache them like static assets. OG images need two cache layers. The edge cache should be long-lived — think 30 to 365 days — because the URL with its query string is the cache key. If the title changes, the URL changes (/og/post-123?title=New+Headline), so you get automatic invalidation. The browser/social crawler cache can be shorter, 1 to 7 days, so platforms re-scrape without you having to purge. Guidance on stale-while-revalidate and CDN-Cache-Control from web.dev Articles is surprisingly relevant here, even though it was written for regular images.

You also need to think about hit ratio. On a site doing 2 million shares a month, we measured that 78% of OG requests were repeat crawls of the same 10% of URLs. That makes edge caching incredibly effective — you're really only paying for the first render. The economics flip completely once your hit ratio crosses about 85%. I tracked this for three months after migrating a news client from origin-based Puppeteer to edge Satori, and the difference wasn't subtle.

The numbers below are averaged from that migration (Fastly Compute + R2, ~4.2M OG requests/month). Your costs will vary by provider, but the pattern holds: edge, on-demand rendering is faster and cheaper than either pre-building everything or rendering at origin, as long as you set cache headers correctly.

Putting It Together: A Production Edge Worker That Actually Ships

Enough theory — let's build the thing. For most stacks, the sweet spot is a 1200x630 PNG generated inside a CDN Worker (Cloudflare Workers, Fastly Compute, or AWS Lambda@Edge) using an HTML-to-image pipeline like Satori + resvg. You don't need headless Chrome at the edge. That approach will blow your 50ms CPU limit and cost you $0.60 per 1,000 renders. Satori, on the other hand, converts JSX-style markup to SVG in under 15ms, and resvg renders it to PNG in another 8-12ms. My production bundle sits at 1.4MB gzipped, cold starts in ~25ms, and hits p95 of 38ms end-to-end on a cache MISS.

The trick isn't the rendering — it's everything around it. Your worker should parse the URL (e.g., /og/product-123.png?title=...&price=... or better, fetch data by ID from KV/Origin), inject it into a locked-down template, and return with aggressive caching. Don't pass raw user HTML. You'll get layout thrashing and injection hell. Use a fixed template with inline styles, subsetted fonts, and absolute positioning. For typography, I subset Inter and JetBrains Mono to Latin + numbers only — cuts a 180KB font down to 28KB and saves ~90ms on first fetch. If you need richer icons, don't inline a dozen SVGs per request; consider what we cover in SVG Delivery Optimization Through CDN: Inline, External, and Sprite Approaches — for OG workers, inlining a pre-optimized sprite is fastest but external fetches kill your TTFB.

Here's a stripped-down Cloudflare Worker pattern we've run at ~4.2M renders/month. It caches the final PNG at the edge for 7 days, serves stale while revalidating for 24 hours, and keeps font binaries in cache as well:

import satori from 'satori';
import { Resvg } from '@resvg/resvg-wasm';
import interSubset from './fonts/Inter-Bold-subset.ttf';

export default {
  async fetch(req, env, ctx) {
    const url = new URL(req.url);
    if (!url.pathname.startsWith('/og/')) return fetch(req);

    const cache = caches.default;
    let res = await cache.match(req);
    if (res) return res;

    // Fetch product data - never trust query params for pricing/text
    const id = url.pathname.split('/')[2]?.replace('.png','');
    const data = await env.KV.get(`product:${id}`, { type: 'json' }) 
              || await fetch(`https://origin.example.com/api/${id}`).then(r=>r.json());

    const svg = await satori({
      type: 'div',
      props: {
        style: { width: 1200, height: 630, display: 'flex', background: '#0a0a0b', color: 'white', padding: 48 },
        children: [
          { type: 'div', props: { style: { fontSize: 64, fontWeight: 700, lineHeight: 1.1 }, children: data.title.slice(0, 80) } },
          { type: 'div', props: { style: { fontSize: 32, color: '#a1a1aa', marginTop: 16 }, children: `$${data.price} • ${data.category}` } }
        ]
      }
    }, { width: 1200, height: 630, fonts: [{ name: 'Inter', data: interSubset, weight: 700, style: 'normal' }] });

    const resvg = new Resvg(svg, { fitTo: { mode: 'width', value: 1200 } });
    const png = resvg.render().asPng();

    res = new Response(png, {
      headers: {
        'Content-Type': 'image/png',
        'Cache-Control': 'public, max-age=604800, stale-while-revalidate=86400, stale-if-error=604800',
        'CDN-Cache-Control': 'public, max-age=2592000',
        'Content-Length': png.length
      }
    });
    ctx.waitUntil(cache.put(req, res.clone()));
    return res;
  }
}

Advanced Patterns and Why Your OG Images Still Break in Production

If your OG images look great in development but fail in the wild, it's almost always fonts or crawler quirks. Social crawlers don't run JavaScript, they don't respect your client-side meta injection, and they timeout fast — Facebook's crawler gives up after ~4 seconds, LinkedIn after 3. If your worker does a lazy origin fetch that takes 800ms, you've already eaten 20% of their budget before you even render. We pre-warm KV on content publish via webhook and set a Cache-Tag header so a CMS update purges og:product-123 in under 150ms globally. Without that, you'll serve stale $49 pricing for a week while Slack unfurls the wrong thumbnail. And don't forget to strip cruft — run Image Metadata Stripping at CDN Edge: EXIF Removal for Privacy and Performance logic on the final PNG; we've seen iPhone screenshots leak GPS into OG images when teams piped user uploads directly into templates.

Fonts will betray you in subtle ways. Emoji, CJK, or even a single curly quote outside your subset will render as tofu (□). Satori doesn't do fallback automatically, so you need to chain fonts: Inter for Latin, Noto Sans JP for Japanese, and a tiny emoji fallback like Twemoji at 12KB. Test with the worst-case title, not "Hello World." Another gotcha: layout shift from dynamic text length. Clamp titles to 2 lines with overflow: hidden and textOverflow: 'ellipsis' in Satori's style object, and reserve a fixed 140px footer for branding so a 120-character title doesn't push your price off-canvas. For product grids where you composite multiple thumbnails, the old sprite debate matters again — CSS Sprite Generation and CDN Optimization: When Sprites Still Beat HTTP/2 sounds unrelated to OG, but the same trade-off applies: one composited fetch at build time versus N fetches at render time. At the edge, one sprite fetch from R2 (18ms) beats four parallel origin fetches (4 x 45ms + image decode).

When it breaks, debug like a CDN engineer, not a frontend dev. First, curl -A "facebookexternalhit/1.1" -I https://yourdomain.com/og/test.png — if you return cache-control: private or Vary: Cookie, you're uncaching yourself for bots. Second, check your logs for 1101 or CPU timeout errors; if you see more than 0.5% of renders exceeding 50ms CPU, you need to slim your template or move image compositing to Tier 1 cache. We've added a X-OG-Render-Ms header and log it to Grafana — anything over 60ms gets alerted. Finally, use the actual validators: Facebook Sharing Debugger, LinkedIn Post Inspector, and X Card Validator. They don't just preview — they show you the exact crawler IP, redirect chain, and whether your og:image:width and og:image:height tags match the real PNG dimensions. Mismatched dimensions are the #1 reason for blurry or cropped thumbnails on LinkedIn.

Frequently Asked Questions