Bytecode caching for Vercel Functions

We recently shipped a new for Vercel Functions to improve startup times.Rust-based core

Today, we are announcing a new experimental feature to further reduce startup latency for large applications, resulting in up to .27% faster cold starts

One of the slowest parts of a cold start is loading and compiling the JavaScript source code. Before executing the code, it needs to be parsed and compiled into , which is then directly executed by the V8 virtual machine or compiled into machine code by V8's just-in-time compiler (JIT).bytecode

This conversion to bytecode must happen when a JavaScript file is executed for the first time, but it introduces latency.

What if we could cache this step and re-use it later on subsequent cold starts?

That's exactly how bytecode caching works. The first execution will produce a bytecode cache, and successive executions and cold starts will re-use and optimize the cache. This can improve the cold start duration by transparently eliminating the compilation step.

We initially tested with three different Next.js applications which each load a different amount of JavaScript. Each application would get a cold start every 15 minutes. We compared the startup duration before and after bytecode caching.

These cold start improvements continue to improve as applications grow in size. With bytecode caching, your function both start faster and have a lower billed duration.

The npm package is widely known in the ecosystem, but can’t easily be used with serverless platforms like Vercel. The file system is ephemeral and fresh during a cold start. v8-compile-cache

We developed our own bytecode caching implementation that overcomes this limitation and allows all subsequent cold starts to use the produced bytecode cache. This system can continuously improve the cache as more traffic is sent to the function.

For example, assume you have two routes and . Your framework lazy-loads those routes from two JavaScript chunks. When a user hits for the first time, the bytecode generated by this first chunk is cached and re-used for future cold starts. But when a user then hits , it produces a separate bytecode cache (since this chunk was lazy-loaded)./home/blog/home/blog

Vercel Functions will intelligently merge together all bytecode chunks, regardless of when or where they were created. This results in faster cold starts as your application gets more traffic.

We’ve been using bytecode caching on our internal Vercel projects for the past month.

If you want to try experimental bytecode caching, you will need to use Node.js 20 and use a framework that compiles to CommonJS (for example, Next.js). We plan to use the new option to support ES Modules in the future.available in Node.js 22

You can opt-in by adding the following Environment Variable in your project's settings, then re-deploy your application: . This improve only applies to production deployments.USE_BYTECODE_CACHING=1

or get started .Learn more about Vercel Functionsbuilding your first application

Read more

Introducing bytecode caching

Technical details

Try bytecode caching

• The first application’s main page is . The average TTFB went from 873ms to 764ms () and the billed duration from 330ms to 137ms ()250 kB-12%-58%

• The second application’s main page is . The average TTFB went from 1017ms to 869ms () and the billed duration from 463ms to 214ms ()550 kB-15%-54%

• The third application’s main page is . The average TTFB went from 1548ms to 1130ms () and the billed duration from 866ms to 453ms ()800 kB-27%-48%