I was tired of building 474 separate pages for Open Graph Images

Prior blog post (if you want the full context): If I work really hard on my Open Graph Images, People will share my Blog Posts (2021 Aug)

Here’s the gist:

Open Graph images are those little pictures that show up when your site is shared on social media. […] Each individual blog post (on my website) has a dedicated Open Graph image page.

These Open Graph pages had the URL shape /web/:title/opengraph/ and there were 474 of them.

This was great from a purist’s perspective (in that the Open Graph pages were built similarly to how I build other websites) but my perspective has changed a bit. I don’t think that server rendering a static page for each of the 474 blog posts is necessary! 🫣

Now I use one /opengraph/ page that client renders (the horror!) the appropriate metadata for the Open Graph image. Client rendering here is an appropriate tradeoff for build time because this page is still going through a Chromium-based screenshot service and the ultimate deliverable is a static image. This page isn’t intended to be consumed by human beings (unless they really want to, I dunno, I’m not your dad).

Note that the caching mechanism hasn’t changed: it still lives in the screenshot service and the image content isn’t being regenerated from scratch (with my old static pages method or this new client rendered method).

I now use this approach on a few places and it’s made implementing Open Graph support on websites much easier to build and manage:

• zachleat.com (this is the web site you’re on now)
• build.awesome.me
• speedlify.dev

Importantly, there is no freeform mechanism on these pages to modify the content of the images via URL parameter. There is no ?text=… to control the title text, it’s keyed off of the local page URL and that alone. I don’t want y’all to put whatever text you want next to my picture on my website (you have to do that on your website 😘).