2021 年のこと、ロンドンを拠点とするファッション e コマース スタートアップのクライアントが、「とにかく Vercel に乗せてくれ。みんな使ってるし」というブリーフを持ってきました。危うくそうするところでした。その後、彼らの予想トラフィックパターン、チームのワークフロー、そして莫大なコストをかけずにスケールできるサーバーレス関数を使ったフォームが必要という事実を確認しました。私たちは Netlify を選びました。6 か月後、彼らは問題なくスケールしていました。しかし別のクライアント、ベルリンのフィンテック企業向けに構築した SaaS ダッシュボードには Vercel が必要でした。ブランドロイヤリティのせいではなく、各プラットフォームで Next.js App Router がどのように動作するかという理由によってです。needed Vercel. Not because of brand loyalty. Because of how Next.js App Router behaved on each platform.
これが本当の議論なんです。どちらが「優れているか」ではなく、あなたの特定の Next.js プロジェクトにはどちらが優れているかということです。では、適切に説明しましょう。for your specific Next.js project. So let me break this down properly.
---
Vercel のアドバンテージ: 彼らのフレームワークだから
人々が言わないことが 1 つあります: Vercel は Next.js を作りました。Vercel は Next.js フレームワークを創造し維持管理していており、新しい Next.js 機能がリリースされるとき、Vercel はそれを初日からサポートします。30 日目ではなく。初日です。Vercel created and maintains the Next.js framework, which means when a new Next.js feature ships, Vercel supports it on day one. Not day thirty. Day one.
App RouterがNext.js 13でリリースされた時、NetlifyはVercelについていくのに必死でした。React Server Components、ストリーミングSSR、新しいfetchキャッシング動作、すべてがVercelではすぐにそのままの状態で動きました。Netlifyも対応しましたが、コミュニティフォーラムのスレッドと回避策が何週間も続いた後に、ようやく安定しました。fetch caching behaviour, all of it worked out of the box on Vercel immediately. Netlify got there, but it took weeks of community forum threads and workarounds before things stabilised.
昨年、Next.js 14でServer Actionsを多用したクライアントポータルを再構築しました。DNS伝播を含めて約40分でVercelにデプロイできました。Netlifyだと同じ結果を得るのに丸一日かかったでしょう。ほぼ全時間をサポートされていることとサポートされていないことを把握するため、彼らのNext.js互換性ドキュメントを読むのに費やしていたはずです。Next.js compatibility docs trying to figure out what was and wasn't supported yet.
Edge FunctionsとISRの問題
VercelのIncremental Static Regenerationは、彼らのプラットフォーム上で本当にファーストクラスです。ページにrevalidate: 60を設定すれば、ドキュメントに記載されている通りに正確に動きます。Netlifyでは、ISRはNethify Next.js Runtimeという彼ら独自の適応層を通じて処理されます。動きます。しかし、あなたが求めなかった抽象化層が追加されるため、何かが間違った時のデバッグは本当に厄介です。Incremental Static Regeneration is genuinely first-class on their platform. You set revalidate: 60 in your page and it works exactly as documented. On Netlify, ISR is handled through their own adaptation layer called the Netlify Next.js Runtime. It works. But it adds an abstraction you didn't ask for, and debugging it when something goes wrong is genuinely painful.
ISRに大きく依存するプロジェクト、コンテンツが多いサイト、ニュースプラットフォーム、プロダクトカタログの場合、Vercelはシンプルな選択肢です。
---
Netlifyが実際に勝つ場面
Netlifyは代替案ではありません。過去5年間で400以上のサイトをNetlifyで構築してきましたが、特定のプロジェクトタイプについては、はるかに優れています。
フォーム、Identity、そして組み込みの機能
Netlifyは組み込みのフォーム処理（サーバーレス関数は不要）、認証フローのためのNetlify Identity、そしてボックスから分割テストが付属しています。クライアントがFormspreeアカウントを設定したり、Lambdaを書いたりすることなく、動作するコンタクトフォームを必要とするエージェンシープロジェクトの場合、Netlifyは本当に時間の節約になります。works without me wiring up a Formspree account or writing a Lambda, Netlify is a genuine time-saver.
昨年、Seahawk Mediaで手がけたプロジェクトの一つに、マンチェスターの不動産仲介業者向けの物件掲載サイトがありました。バックエンドは何も凝った作りにしていません。ほぼ静的ページ、お問い合わせフォーム、物件問い合わせ用のサーバーレス関数が少し。1日半で本番環境に上げられました。Netlifyのデプロイプレビュー、フォーム送信通知をクライアントのメールに送る機能、Sanityとの連携は本当に簡単でした。
スケーリング時の料金
ここからが本当の話になります。Vercelの料金は上昇が急です。Proプランは月額メンバーあたり20ドルですが、4人の代理店だと月80ドルになり、帯域幅や関数の実行回数を考える前の段階で既に膨らんでいます。
NetlifyのProプランも月額メンバーあたり19ドルなので、表面上は似ています。ですがNetlifyの寛大な無料枠とビルド分数のの余裕は、複数の小規模クライアントサイトを運用する代理店にとって歴史的に優しい設定になっています。僕も何度か、一つのNetlifyチームアカウント経由で15個のマイクロサイトをクライアント向けにデプロイした月がありますが、請求額は管理できるレベルでした。Vercelの関数実行に対する従量課金は、注視していないと痛い目に遭います。
---
Next.js App Router：今のところの本当の差別化要因
まだPages Routerを使っているなら、このセクションはほぼ関係ありません。両プラットフォームともPages Routerの Next.js は問題なく対応しています。ですが新しいプロジェクトをApp Routerで構築しているなら（正直なところ、そうすべきです）、その差は意味を持つようになります。
VercelはApp Router機能をネイティブで実行します。Next.js 15で本格的に来るPartial Prerenderingは、Vercelのインフラを念頭に設計されています。彼らのEdge Runtime、CDN、関数リージョン、全てがフレームワークと共設計されています。
NetlifyのランタイムへのAdaptationは本当に素晴らしいエンジニアリングです。彼らのチームはApp Routerを自分たちのプラットフォームで動かすために大変な仕事をしました。でもそれは常に一歩遅れることになります。なぜなら彼らは他人のフレームワークを自分たちのインフラに合わせている訳で、その逆ではないからです。
具体的なシナリオを紹介します。ネストされたレイアウト、動的ルートセグメント、Prismaでデータベース呼び出しをする何個かのServer Componentsを持つNext.js 14アプリをテストしました。Vercelではコールドスタートが約280ミリ秒。Netlifyでは類似の関数サイズで420～480ミリ秒のコールドスタートを見ていました。破滅的ではありません。ですがSaaS製品でユーザーがローディング画面に座っているシチュエーションでは、その差は感じられます。
---
開発者体験：日々の現実
両方について正直に話そう。
Vercelの開発者体験は、意見を反映させるほどまでに磨き抜かれている。ダッシュボードは美しい。デプロイログは明確だ。プレビューURLは自動生成される。CLI（vercel dev）はエッジミドルウェアを含む本番環境に近い環境でプロジェクトをローカル実行する。使っていて気持ちいい。 Their dashboard is beautiful. Deploy logs are clear. Preview URLs are automatic. The CLI (vercel dev) runs your project locally with an environment that closely mirrors production, including edge middleware. It's a joy to use.
Netlifyの開発者体験は、設定の自由度が高く、やや混沌としている。netlify.tomlファイルは、リダイレクト、ヘッダー、ビルドプラグイン、関数設定に対する細粒度な制御を提供する。Vercelはそこまでのレベルで露出していない。特定のルートにカスタムヘッダーが必要な場合、Netlifyの設定はより明示的で読みやすい。Vercelはこれをnext.config.jsで処理するが、悪くはないものの、インフラストラクチャレベルの制御としては同じではない。 Their netlify.toml file gives you fine-grained control over redirects, headers, build plugins, and function configurations that Vercel simply doesn't expose at the same level. If you need custom headers on specific routes, Netlify's config is more explicit and readable. Vercel handles this through next.config.js which is fine, but it's not the same level of infrastructure control.
個人的なワークフロー：クライアントサイトで素早くライブにしたく、インフラをそれ以上考えたくない場合はVercelが勝つ。デプロイ設定を調整し、複数の環境を実行し、クライアントのチームがダッシュボード自体を操作することを知っているプロジェクトの場合はNetlifyが勝つ。UIは非技術系ユーザーにとってより威圧的でない。
---
ビルドパフォーマンス
曖昧な主張は無用だから、数字を出そう。
中規模のNext.jsプロジェクト、例えば80ページ、TypeScript、Tailwind、いくつかのAPIルート、GitHubプッシュからのビルド：
- Vercel のビルド時間：標準的なプロジェクトでは通常 90～120 秒
- Netlify のビルド時間：同等のプロジェクトで 130～180 秒
Vercel のビルドインフラストラクチャはより高速です。彼らは大きく投資しています。Netlify は有料のビルド並行実行アップグレードを提供していますが、同等の性能を得るために余分に支払うことになります。
もう 1 つ：Turborepo 経由の Vercel のリモートキャッシング機能は、モノレポのセットアップを使っている場合、本当に革新的です。去年、Seahawk のプロジェクトをバニラビルドから Vercel 上の Turborepo セットアップに移行し、ビルド時間を 4 分から 90 秒未満に短縮しました。Netlify には同等の機能がありませんが、自分でキャッシング設定を構築することはできます。
---
どちらを選ぶか：実際の推奨事項
「状況による」という中立的な答えではなく、実際にどのように判断しているかを説明します。
Vercel を選ぶべき場合：
- Next.js App Router、Server Components、Server Actions、または ISR を使用している
- パフォーマンスの一貫性が重要な SaaS 製品を構築している
- モノレポを使用している、または Turborepo のリモートキャッシングを必要としている
- コールドスタート時間があなたの製品のパフォーマンス認識の一部である
以下の場合は Netlify を選択してください：
- コンテンツサイト、マーケティングサイト、またはエージェンシークライアント案件を構築している
- サードパーティの統合なしに、組み込みのフォーム、Identity、またはスプリットテストが必要である
- 予算が限られており、1つのアカウントで複数の小規模サイトを管理している
- 技術者以外のステークホルダーがデプロイメントダッシュボードにアクセスする
付け加えるなら、既に大規模な既存プロジェクトで Netlify を使用している場合、Vercel への移行コストは、特定のフレームワーク互換性の問題に直面していない限り、ほぼ価値がありません。逆も同様です。理論的なゲインのためにプラットフォームを切り替えないでください。
---
FAQ
VercelはNext.jsに対して常にNetlifyより高速ですか？
必ずしもそうではありません。Vercelのコールドスタートは一般的により高速で、エッジネットワークはNext.jsに特に最適化されています。ただし、サーバーレス関数がクリティカルパスにない静的サイトの場合、両プラットフォームともCDN経由でアセットを配信するため、パフォーマンスの差は無視できるレベルです。SSRルートと関数が多いページで差が出ます。
NetlifyはNext.js App Routerに完全に対応していますか？
はい、ただし注意点があります。NetlifyのNext.js RuntimeはApp Routerに対応していますが、Partial Prerenderingのような特定機能はVercelのサポートタイムラインより遅れる可能性があります。ほとんどの本番App RouterプロジェクトではNetlifyは問題なく機能します。最先端のNext.js機能に依存するプロジェクトを始める前に、互換性に関する注記を確認してください。Next.js Runtime supports App Router, but specific features like Partial Prerendering may lag behind Vercel's support timeline. For most production App Router projects, Netlify works fine. Just check their compatibility notes before starting a project that relies on bleeding-edge Next.js features.
VercelはエージェンシーでのEOD利用には高すぎませんか？
アカウント構成方法によります。Vercelのメンバー単位の価格設定はチームの場合すぐに積み重なります。多くのエージェンシーはチームアカウント1つではなく、クライアントプロジェクトごとにVercelアカウント1つを使用しており、これでコスト計算が大きく変わります。Netlifyのモデルは一般的に複数のクライアントサイトを1つの請求でまとめて管理する場合、エージェンシーに優しいです。
Next.jsを自分でホストする方法はどうですか？
完全に妥当な選択肢です。特にインフラストラクチャの完全なコントロールが必要なプロジェクトの場合に有効です。DigitalOcean dropletやfly.io上のデプロイメント、NodeサーバーやDockerコンテナは完全なコントロールを得られます。デプロイプレビューの自動化とDXのポーランドの一部は失いますが、価格予測可能性が得られます。私はコンプライアンス上の理由でサードパーティのPaaSを使用しない企業クライアント向けに何度か実装したことがあります。ただし、ほとんどのチームが望むよりも運用負荷が大きいです。
後で切り替える可能性がある場合、どのプラットフォームから始めるかは重要ですか？
VercelからNetlify（またはその逆）への移行は、ほとんどのNext.jsプロジェクトでは本当に難しくありません。コードは変わりません。主に環境変数を更新し、設定ファイル1～2つをアップデートするだけです。移行が大変な点は、カスタムNetlifyプラグイン、Netlify Identityの実装、およびNetlifyの独自フォームハンドリングを使用したものです。これらが対象範囲に含まれる場合は事前に計画してください。is painful to migrate: custom Netlify plugins, Netlify Identity implementations, and anything using Netlify's proprietary form handling. Plan ahead if those are in scope.
ウェブ構築に9年間取り組み、想像できるあらゆる種類のプロジェクトにおいて12,000件を超えるデプロイメントを経験した正直な答えは、両方のプラットフォームとも優れているということです。ただし、互換性があるわけではありません。Vercelはフレームワークの最新機能が本質的に必要な本格的なNext.jsアプリケーションに最適です。Netlifyはそれ以外のすべてに最適です。今月のTwitterのコンセンサスが何を言おうとも、今日のプロジェクトが実際に必要としているものに基づいて選択してください。
ウェブ構築に9年間取り組み、想像できるあらゆる種類のプロジェクトにおいて12,000件を超えるデプロイメントを経験した正直な答えは、両方のプラットフォームとも優れているということです。ただし、互換性があるわけではありません。Vercelはフレームワークの最新機能が本質的に必要な本格的なNext.jsアプリケーションに最適です。Netlifyはそれ以外のすべてに最適です。今月のTwitterのコンセンサスが何を言おうとも、今日のプロジェクトが実際に必要としているものに基づいて選択してください。