Vercel Functions 바이트코드 캐싱 — 콜드 스타트 TTFB 최대 27% 개선

Vercel Functions에 바이트코드 캐싱 실험적 기능이 추가됐다. JS 소스 코드를 V8 바이트코드로 컴파일하는 과정을 콜드 스타트마다 반복하는 대신 첫 실행 시 캐싱해 이후 로드에서 재사용한다. 250KB~800KB 규모 Next.js 앱에서 TTFB 12~27% 개선, 과금 실행 시간 48~58% 단축이 확인됐다.

핵심 포인트

JS 소스를 V8 바이트코드로 컴파일하는 과정을 최초 1회만 수행하고 이후 콜드 스타트에서 캐시를 재사용해 컴파일 비용을 제거한다
생태계의 v8-compile-cache 패키지가 아닌 커스텀 구현으로, 여러 콜드 스타트에 걸쳐 지연 로드된 라우트의 바이트코드 청크를 점진적으로 합산·캐싱한다
트래픽이 쌓일수록 캐시 커버리지가 늘어 성능이 점진적으로 개선된다
현재 Node.js 20 + CommonJS 프레임워크만 지원하며, ES Module 지원은 Node.js 22 기반으로 계획 중이다
USE_BYTECODE_CACHING=1 환경변수 설정 후 재배포만으로 활성화 가능(프로덕션 한정)

상세 정리

문제 배경: JS 함수는 콜드 스타트마다 소스 파싱 → AST 생성 → V8 바이트코드 컴파일 전 과정을 반복해야 해 TTFB 지연이 발생한다.
핵심 메커니즘: 첫 번째 콜드 스타트에서 컴파일된 바이트코드를 캐싱하고, 이후 호출에서는 소스 대신 바이트코드를 V8에 직접 로드해 파싱·컴파일 단계를 건너뛴다.
커스텀 구현 이유: 기존 v8-compile-cache는 단일 실행에서만 동작하지만, Vercel 구현은 여러 콜드 스타트에 걸쳐 지연 로드된 경로의 바이트코드를 점진적으로 병합·축적한다.
점진적 개선: 초기에는 자주 사용되는 경로만 캐싱되고, 트래픽이 쌓일수록 더 많은 경로의 바이트코드가 캐싱돼 성능이 향상된다.
250KB 앱 결과: 평균 TTFB 873ms → 764ms (-12%), 과금 실행 시간 -58%.
550KB 앱 결과: 평균 TTFB 1017ms → 869ms (-15%), 과금 실행 시간 -54%.
800KB 앱 결과: 평균 TTFB 1548ms → 1130ms (-27%), 과금 실행 시간 -48%. 앱 규모가 클수록 개선 폭이 더 크다.
제약: Node.js 20 + CommonJS만 지원. ES Module은 Node.js 22의 기능을 활용한 지원 예정.
활성화 방법: 프로덕션 환경변수에 USE_BYTECODE_CACHING=1 추가 후 재배포. 미리보기 환경 미지원.

왜 읽나Vercel에서 Next.js 서버 함수를 운영하며 콜드 스타트 지연 개선이 필요한 백엔드·인프라 엔지니어.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

Vercel Functions 바이트코드 캐싱 — 콜드 스타트 TTFB 최대 27% 개선

이 글과 비슷한

대규모 도그푸딩: cdnjs를 Cloudflare 개발자 플랫폼으로 이전하다

Dependabot 길들이기: 업데이트 묶고, 주기 늦추고, 보안은 빠르게

Cloudflare, 프라이버시 프로토콜 디버깅 CLI pvcli 오픈소스 공개