Build-Time or Request-Time OG Images: Choosing a Strategy

There are two ways to produce an OG image for a page. You can render it once when you build the site, or you can render it when someone first asks for it. Both work. They trade speed against freshness in different ways, and the right choice depends on how often the content changes.

Build time

At build time, a script renders every image and writes it to disk or a CDN. The site then serves a plain file. The request is fast, the cost is paid once per build, and nothing can fail at request time because the image already exists.

The downside is staleness. If an editor changes a title, nothing updates until the next build. For a site that publishes every few days this is fine. For a site where content changes minute by minute, it is a constant chore.

Request time

At request time, the image URL points to a route that renders the card on demand and caches the result. The first request for a new page is slow because it renders. Every later request is a cache hit. Changing the data changes the cache key, so the image updates without a deploy.

The cost is the first render and the cache layer. A cold render of a headless browser is measured in seconds, so a cache with a fast check, such as a HEAD request before rendering, matters more than the rendering code itself.

How to choose

• Pages that change rarely, such as a landing page or an about page: build time. Simple and very fast.
• Posts and product pages edited by a team: request time with caching, or a rebuild triggered by a publish webhook.
• User-generated pages with thousands of variants: request time only. Pre-rendering every combination is wasteful.
• Anything shared heavily right after publishing: pre-warm the cache on publish so the first crawler does not pay the render cost.

Crawlers are impatient. Many give up after a few seconds, so a slow first render can leave the preview blank. That is the real reason to pre-warm, more than the cost of the render itself.