Utilize OG Edge Functions Reduced 90% OG Build Time

@ Web Performance

Introduction

As the number of articles on this blog increases, the pressure on static generation also escalates. For instance, in daily development, it takes about nearly 10 minutes🔗 to build all content on the website:

This problem will continue to worsen as the website scales, especially the generation of preview images, which amounts to: (language x number of articles).

Problem Discovery

WebDong🔗 is a static-generated blog with hundreds of articles.

07:31:30   ├─ /post/build-product-from-scratch-tokens/og.png (+691ms)

If you look at the build log, you’ll discover that the previously established OG image static generation endpoint🔗 takes up the most build time, and rendering images for just one article in three languages can take nearly 2 seconds. With hundreds of articles, it’s clear that the website is becoming too large to wait for image rendering.

Problem Solution

Due to the increasingly high cost of SSG🔗 rendering for the entire site, it may be worthwhile to consider switching to server-side rendering, such as SSR🔗 or a hybrid of ISR🔗. Given that the blog content does not change often and considering cost, maintaining the maximum static rendering is a reasonable choice. For OG image rendering, it can be packaged into a Serverless Function for on-demand calls.

The considerations are:

  1. It can solve the problem without major changes to the existing structure
  2. A clean solution that elegantly addresses scaling issues
  3. Low operating costs, minimizing the need to set up servers

How Serverless Functions Help

Serverless Functions are cloud computing models where you write the program logic without managing server infrastructure. Edge Functions are a type of serverless function running on edge nodes closest to users. In simple terms, the code isn’t deployed on a single server; it’s distributed to multiple data centers worldwide, allowing users to receive responses faster.

PlatformEdge Function Service Name
CloudflareWorkers / Pages Functions
VercelEdge Functions
NetlifyEdge Functions
AWSLambda@Edge
DenoDeno Deploy

Since the static website was originally deployed using Cloudflare Pages🔗, it is natural to use their full suite of services: Pages Functions🔗.

Getting Started with Cloudflare Functions

The documentation for Cloudflare Functions🔗 is quite comprehensive and well-integrated. They even provide multiple pre-written packages for common use cases that you can use right away, such as the @cloudflare/pages-plugin-vercel-og🔗 which utilizes @vercel/og🔗 to generate images:

import React from "react";
import { ImageResponse } from "@cloudflare/pages-plugin-vercel-og/api";


export const onRequest: PagesFunction = async () => {
  return new ImageResponse(
    <div style={{ display: "flex" }}>Hello, world!</div>,
    {
      width: 1200,
      height: 630,
    }
  );
};
  1. Create Routes: You’ll need to understand the routing rules🔗 to create a new endpoint.
  2. Types: If using TypeScript, you’ll need to configure and generate corresponding types🔗 according to the documentation.
  3. Deploy and Test Locally: Learn how Wrangler CLI manages Cloudflare services.
  4. Automated Deployment: Various platforms also provide detailed support🔗 for automating Cloudflare service deployments.

Thanks to the groundwork laid by others, migrating a generated image endpoint to the cloud for on-demand rendering and scaling can be done quickly. If you’re curious about the specific process I followed to enhance the blog, you can refer to this PR: feat: og-page-function-api🔗. Special thanks to the og-image-generator-cloudflare-worker🔗 repository for providing excellent examples of advanced setups, such as loading fonts in the Edge environment, loading images, caching, etc.

Conclusion

When making technical choices, it is also essential to consider the limits of the service. For example, the free version of Pages Functions provides a maximum of 10ms CPU processing per request (source🔗), and complex image generation can easily exceed this, causing timeouts. Upgrading may be necessary to increase processing time settings🔗 for it to work correctly…

After removing the task of pre-rendering local OG images during website construction, the continuous deployment build time has improved from nearly 10 minutes🔗 to just over 1 minute🔗. With a well-planned architecture, we achieved nearly a 10-fold performance improvement while retaining the same functionality.

Above is the new OG image, below is the old OG image
Above is the new OG image, below is the old OG image

Further Reading