ハクソク

世界を動かす技術を、日本語で。

Cloudflare WorkersのCPUパフォーマンスベンチマークの解析

223日前原文(blog.cloudflare.com)

概要

  • 2025年10月4日、Theo BrowneによるCloudflare WorkersとVercel（AWS Lambdaベース）のベンチマーク公開
  • 初期結果ではCloudflare WorkersがVercelより最大3.5倍遅いと判明
  • 原因調査でインフラ設定やライブラリ、ベンチマーク手法の問題を発見
  • Cloudflareはプラットフォーム改善を実施し、ほぼ全てのケースでVercelと同等性能を達成
  • Next.js関連の課題は継続中だが、さらなる改善予定

Cloudflare Workers vs Vercel：JavaScript実行速度ベンチマークの詳細

  • Theo Browne によるベンチマークで、 Cloudflare Workers のパフォーマンス問題が浮き彫り
  • 両プラットフォームとも V8 JavaScriptエンジン を採用しているにも関わらず、3.5倍の性能差が発生
  • 原因は インフラのチューニング不備、 ライブラリの違い、 ベンチマーク手法の偏り など複合的要因
  • Cloudflareは問題点を修正し、 全ユーザーのパフォーマンス向上 を実現
  • 特に 三角関数の遅延 など、他社プラットフォームにも影響する問題も発見・修正

ベンチマーク手法と再現性

  • Theoのテストは Webpass回線のラップトップ からVercel SFO1リージョンで実施
  • Cloudflare側では AWS us-east-1データセンター でクライアントを稼働し、Vercel IAD1リージョンと比較
  • 1 vCPUインスタンス を選択し、シングルスレッド性能にフォーカス
  • CPU時間課金 の観点からも公平性を確保（Vercel $0.128/hr、Cloudflare $0.072/hr）
  • バグ修正のため プルリクエスト も提出

Cloudflare Workersプラットフォームの改善

  • Workers Runtime 自体のチューニングに注力
  • シャーディングとウォームアイソレートルーティング のアルゴリズムを改良
    • CPUバウンドワークロード時のリクエスト待機時間を削減
    • 自動スケール の最適化により、I/OバウンドとCPUバウンドを適切に分離
    • この変更は 全ユーザーに自動適用
  • V8ガベージコレクタのチューニング も実施
    • 若世代領域のサイズ設定を見直し、 GC頻度を低減
    • 約25%のベンチマーク性能向上を達成し、メモリ消費増加は最小限
    • 2017年当時の設定を現代仕様に合わせて調整

Next.js/OpenNextにおける最適化

  • OpenNext プロジェクトのコードに複数の非効率的処理を発見
    • 不要なバッファコピーやアロケーション の多発
    • 例えば、 pipeThrough() 操作で未使用のバッファが大量生成
    • ストリーミング出力データ の不要なコピーも発覚（5MBデータで顕著）
    • Buffer.concat による無意味な全結合も修正
  • OpenNextへのプルリクエスト で以下の改善を推進
    • ストリーミングレスポンス性能向上
    • ストリームのアロケーション削減
    • 計算結果のキャッシュ
    • 頻繁にアクセスされるオブジェクトの最適化
    • レスポンス時のバッファコピー回避
    • 正規表現のキャッシュによるGC負荷低減
  • これらの改善は 他プラットフォーム利用者にも恩恵

ストリームアダプタの非効率性

  • Next.js はNode.js標準APIのバイトストリームを利用
  • Workers はWeb標準のStreams APIを採用
  • この違いによる アダプタ変換処理の非効率性 がパフォーマンス低下の一因

今後の展望と総括

  • Cloudflare は今後もOpenNextやNext.js関連の最適化を継続
  • Theo Browneの指摘により、多くのユーザーが恩恵を受ける結果に
  • ベンチマークの手法が現実の課金や実利用と異なることを強調
  • 全体として、Cloudflare Workersの性能と信頼性が大幅に向上

Hackerたちの意見

記事のトーンが競争相手を批判するんじゃなくて、改善できる点に焦点を当ててるのがすごく良かった！これが大事なんだよね！追伸：OpenNextの実装が改善されてるのを見るのは最高だし、他のプロバイダーも再利用できるのがいいね。

パフォーマンスに大きな差が出るJSON関数の話だけど、V8ブログで最近、replacer関数を渡さないときのJSON.stringifyのパフォーマンス改善についての記事があったよ。よく使われる関数の中で、パフォーマンスの落とし穴にハマりやすいものが紹介されてる。0: https://v8.dev/blog/json-stringify

負けを受け入れて、建設的な行動を取るのは素晴らしいね。

だからこそ、競争と独立したベンチマークが必要なんだよね。パフォーマンスが悪い製品やサービスを行動に駆り立てるから。

└

彼らが気にしてくれればね…

└

もう独立したベンチマークはあるよ。

この記事からの私の感想は、SvelteKitはめちゃくちゃ速いけど、Next.jsはカメみたいだってこと。

└

確かに、それは間違ってない結論だね。

└

SvelteKitやAstro、TanStackみたいな実用的なフレームワークが、NextJSの複雑さを早く置き換えてくれるといいな。

これは素晴らしいPRだね。あの記事を仕切った人、よくやった！

└

ありがとう！これは100%ワーカーズチームのエンジニアたち（私も含めて）が制作したものだよ。

これが公開されて、分解されて、議論されたことに絶対的な感謝！Cloudflareのワーカーズチームへの信頼がすごく高まった。

これを読んでると、Chromeがv8を動かしているたくさんのデバイスに対してどうやって最適化してるのか気になる。パフォーマンスを良くするために難しい決断が必要なんだろうな。

今、NextJSをVercelからCloudflareのAstro/Reactに移行中なんだけど、特に驚いたのは「エッジ」で毎回リクエストに応じてウェブアプリをレンダリングできて、レスポンスタイムが100〜200msってこと。ほぼ完全に静的なページと同じくらい速いよ。ここ数週間でCloudflare Workerも確実に改善されてるのを感じてる。コールドスタートがほぼなくなったし、レスポンスタイムもかなり安定してる。

CFが他を責めるんじゃなくて、自分たちのプラットフォームを改善しようとしてるのはいいことだね。でも、急速な変化は一長一短だな。変化が早すぎてついていくのが大変だし、リリースが仕上げを追い越すことも多い。R2データカタログはまだIceberg v3のサポートがないし、Wranglerは数ヶ月で劇的に変わった。Pagesは廃れそうな感じで、Workers Assetsの移行が痛い。Wrangler 3で動いてた設定がWrangler 4にうまく引き継がれなかったし、Wrangler 5ではまた別のインタラクションモデルが導入されそうだ。

└

どこで「pagesが廃れそう」って見たの？いくつかのプロジェクトでページ使ってるんだけど…