2x faster with SatoriOptions.fonts as a global variable about satori

[jakeinflab]

TL;DR: Declaring SatoriOptions.fonts as a global variable doubled the performance

Upon closer inspection of the code, I discovered a global variable named fontCache that utilizes WeakMap. I added console.log to satori.ts#L57-L62 to check if the cache was indeed being utilized.

satori.ts#L57-L62

  let font: FontLoader
  if (fontCache.has(options.fonts)) {
    font = fontCache.get(options.fonts)
  } else {
    fontCache.set(options.fonts, (font = new FontLoader(options.fonts)))
  }

It turned out, in satori.ts, the cache key was being assigned to the memory address of the SatoriOptions.fonts object.

We had been declaring SatoriOptions.fonts as a local variable, just as the example in README.md suggests.

This made me realize that changing the address of options.fonts with every invocation prevented us from ever utilizing the cache effectively, as it just kept accumulating.

Therefore, I declared SatoriOptions.fonts as a global variable as follows:

AS-IS

export default async function handler(
  request: NextApiRequest,
  response: NextApiResponse
) {
  try {
    const svg = await satori(JSX,
      {
        width: 1200,
        height: 630,
        embedFont: true,
        fonts: [
          // ...
        ]
    );

TO-BE

const options: SatoriOptions = {
  width: 1200,
  height: 630,
  embedFont: true,
  fonts: [
    // ...
  ],
};

export default async function handler(
  request: NextApiRequest,
  response: NextApiResponse
) {
  try {
    const svg = await satori(JSX, options);
    // ...

As a result, the same code was able to handle approximately double the number of requests.

wrk -t10 -c 30 -d30s http://localhost:3000/og/review/41854\?updatedAt\=2024-01-29T14:30:22
Running 30s test @ http://localhost:3000/og/review/41854?updatedAt=2024-01-29T14:30:22
  10 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   992.55ms  273.04ms   1.87s    66.67%
    Req/Sec     4.43      3.97    20.00     70.93%
  891 requests in 30.07s, 318.15MB read
Requests/sec:     29.63
Transfer/sec:     10.58MB

• AS-IS: 15.95 Requests/sec
• TO-BE: 29.63 Requests/sec

Performance improvement by roughly 1.86 times

As you can see, this changes no longer make unnecessary calls to addFonts() in the profiling graph.

Now, we can see that the sendData() function, used when returning a response, occupies most of the flame graph.

Required

• Modify satori.ts#L57-L62 to use serialized value as key of the map instead of the memory address value of the object
• ImageResponse provided by @next/og might also have similar issues.

I hope this helps those experiencing performance issues. Thank you.

Regarding this, I'd like to inform @shuding , the author of this code, about the matter. If it's not too much trouble, may I go ahead and make the improvements, then submit them as a Pull Request? @shuding