Gatsby vs Next.js 徹底比較──あなたのプロジェクトに最適なReactフレームワークはどちら?

Gatsby.jsとNext.jsは、現在のWeb開発において最も注目されている2大トピックです。掲示板やYouTubeのコメント欄では「どちらを選べばいいのか?」という質問を頻繁に見かけます。筆者はここ1年間、Next.jsとGatsby.jsの世界にどっぷり浸かってきた経験があり、この議論に加わる資格は十分にあると自負しています。

プロジェクトにNext.jsを使うかGatsbyを使うかという問題になると、「適材適所」という言葉が思い浮かびます。しかし安心してください。そんな曖昧な答えで終わらせるつもりはありません。

要点まとめ(TL;DR)

• GatsbyもNext.jsもどちらもReactフレームワークであり、SSR(サーバーサイドレンダリング)が標準で備わっている(SEOに強い)。
• Next.jsは2つのうち自由度が高い反面、学習曲線が急で、「バッテリー同梱」が少ないため、自分で組み立てる部分が多い。
• 大量のデータを頻繁に更新する必要があるサイトには、Next.jsの方が有利といえる。

Next.jsとGatsby.jsの共通点

GatsbyとNext.jsが比較されるのには理由があります。実は両者は異なる点よりも共通点の方がはるかに多いのです。まずは共通点を見てから、違いについて掘り下げていきましょう。

GatsbyとNext.jsの共通点:

• どちらも標準状態で高いパフォーマンスを発揮する。
• どちらもJavaScriptフレームワークであり、Reactベースである。
• SSR(サーバーサイドレンダリング)とCSR(クライアントサイドレンダリング)が標準で使える。
• SSG(静的サイト生成)とDSG(動的サイト生成)の両方に対応している。
• コード分割(code-splitting)と優れたキャッシュ機構が標準搭載されている。
• ページデータのプリフェッチに対応。Gatsbyは自動で行い、Next.jsはルーティング用のLinkコンポーネントでprefetchプロップを使うことで実現できる。
• それぞれ独自のルーターによる自動ルーティングを提供している(GatsbyはReach Router、Next.jsはNext.js Routerを採用)。
• REST APIからのデータ取得に対応しており、WordPress、Contentful、PrismicなどをCMSバックエンドとして利用できる。

標準状態のままでも、GatsbyとNext.jsはSSRとCSRの「両方の良いところ」を提供してくれます。SSRはSEOに強く、CSRはネイティブモバイルアプリのような滑らかで瞬時なページ遷移(ページ再読み込みなし)を実現できます。

Next.jsとGatsby.jsの違い

以下の内容は、カスタマイズによって変化しうるポテンシャルではなく、各フレームワークの「標準状態」に基づいた話であることを先にお伝えしておきます。とはいえ、Next.jsもGatsbyも非常に柔軟性の高いフレームワークです。

GatsbyとNext.jsはどちらも「無限に」カスタマイズ可能だと主張します。「万人のすべてに応える」 classicなフレーズを思い浮かべてしまうほどです。潜在的なユーザーを排除したくないのは当然で、優れたビジネスとして弱点ではなく強みを前面に出すのは自然なことです。

嘘をついているわけではありません。しかし両者とも非常に柔軟で(莫大な資金調達を背景に)絶えず進化しているため、長期的な視点で見ると「特定のユースケースにどちらが優れている」と断言するのは難しいのが実情です。

筆者はどちらにも利害関係がないので、偏りのない視点でお伝えします。Next.jsとGatsbyを分ける主なポイントは以下の通りです:

• GatsbyはGraphQLの使用を強制する(意見が強い/opinionated)。Next.jsでは任意。
• Gatsbyは画像変換機能を標準搭載している(やや強制的だが、使わない選択も可能)。
• Gatsbyは画像への遅延読み込み(lazy loading)を自動で追加する(opinionated)。
• Gatsbyサイトは小さなプラグインをインストールするだけでPWA(プログレッシブウェブアプリ)化できる。Next.jsで同じことを簡単に行う方法は筆者は見たことがない。
• Next.jsは動的ルーティングと静的ルーティングの両方を提供。筆者の知る限りGatsbyは静的(ハードコードされた)ルーティングのみ。この点については明確な情報が見つけにくいため確信度は高くない(詳細がわかり次第更新予定)。
• GatsbyのSSRはサイトビルド(SSG)フェーズで実行される。
• Next.jsのSSRはページリクエスト時に動的に実行される。ただし静的エクスポート機能によるSSGも提供されている。

カスタマイズについては、Gatsbyにはコメント機能から検索用のAlgoliaまで、導入が比較的簡単な便利プラグインが豊富にあります。一方Next.jsにはGitHubリポジトリに/examplesディレクトリがあり、さまざまなライブラリ(「プラグイン」)の使用例を紹介しています。ただし筆者の経験上、Next.jsのサンプルを設定する方がGatsbyのプラグインを使うより手間がかかる印象です。

動的なデータ取得

Gatsbyは標準で静的生成されますが、さまざまなサーバーAPIに問い合わせてデータを動的に取得することも可能です。

Next.jsも同様の方法で動的なデータ取得ができます。

SSRが必要な場合は、Gatsbyの内蔵GraphQL APIを使ってWordPressやContentfulなどの(ヘッドレス)CMSからデータを取得し、CMS側のWebhookを設定すれば、コンテンツ公開のたびに自動デプロイさせることができます。

規約(Customization)対 設定(Configuration)

一般的に、Gatsbyの方が意見の強い(opinionated)フレームワークです。そのメリットは、決めることが減ることです。逆にNext.jsは立ち上げまでにより多くの設定が必要ですが、何も強制されない自由さがあります。

Next.jsは「アプリをゼロから組み立てる」タイプのプロダクトです。ただし、いくつかの便利な機能(SSR、ルーティング、プリフェッチ、コード分割)は最初から入っています。

Gatsbyは「スタート時点に、おそらく必要となるものがすでに入っている」タイプのプロダクトです。多くの機能(GraphQL、プリフェッチ、SSR、コード分割、遅延読み込み、画像変換)がバンドルされています。

製品の隅々まで細かくカスタマイズしたいなら、Next.jsの方が適しています。理由はシンプルで、標準状態がより「素朴(barebone)」だからです(やってくれることが少ない)。

プロジェクト開始時にフレームワークの機能を削除する作業は決して楽しいものではありません。何らかの理由でGraphQLが好きでないなら、Gatsbyは向いていないでしょう。

GraphQLは今や(それなりの理由があって)大きな注目を集めており、Gatsbyがこれをフレームワークの一部としたことを否定するのは難しいところです。筆者はむしろプラス要素だと考えていますが、人それぞれ好みはあるでしょう。なお、Apollo(GraphQLエンジン)はNext.jsアプリで最も人気のある追加ライブラリのひとつであることも付記しておきます。

Gatsbyが画像変換や遅延読み込みを勝手に処理してくれる点についても、意見が強いと言えばその通りですが、得られるパフォーマンス向上は非常に大きく、その決定を許容できる人がほとんどでしょう。ただし、画像処理を独自のやり方で行いたい場合は、やはりNext.jsの方が適しています。

SEOにおけるGatsby vs Next.js

GatsbyもNext.jsも標準でサーバーサイドレンダリングされるため、SEO(検索エンジン最適化)を重視するWebサイトにとっては、どちらも優秀な選択肢です。現代の公開WebサイトのほぼすべてがSEOを必要とすることを考えれば、これは大きなポイントです。

しかし、Next.jsがGatsbyに対して輝きを放つ特定のSEOユースケースが存在します:

TwitterやRedditのような、絶え間なくコンテンツを更新し続けるプラットフォームを構築していて、しかもすべてのコンテンツに最適なSEOが必要な場合、Next.jsがベストな選択肢となります。

なぜでしょうか?Next.jsは、変更が発生したその瞬間に、自サーバーからコンテンツの更新を動的にサーバーサイドレンダリングできるからです。

一方Gatsbyで新しいコンテンツを表示するには、コンテンツに変更があるたびにアプリを再ビルドして再デプロイする必要があります。ブログやECサイトなど、1日1回、あるいは1時間に1回程度の更新で済むWebサイトのほとんどにとっては、これで十分でしょう。

ただし、Gatsbyサイトが外部APIから動的にデータを取得して更新を表示している場合(Disqusのようなコメントサービス経由など)、リアルタイムのコンテンツ更新は可能です。しかしこの場合、更新はクライアントサイドレンダリングされるため、SEOのメリットは得られません(SEOで効果があるのはあくまでサーバーサイドレンダリングです)。

実際の世界での観察

規模の大きい企業や大型サイトほど、GatsbyよりもNext.jsを採用する傾向があります。とはいえ誤解しないでください。ReactJSの公式ドキュメントページはGatsbyを使用しています。あくまで筆者の観察に基づく話です。

Next.jsを使用している大手サイト:

• Marvel.com
• Netflix
• Uber Marketplace
• Invisionapp
• Material UI

Gatsbyを使用している大手サイト:

• ReactJS
• MarvelApp.com

そう、興味深いことにMarvelは両方を使っています。メインサイトにはNext.js、デザインプラットフォームのMarvelAppにはGatsbyを採用しているのです。

ブログについては、優れたNext.jsブログの事例はあまり多く見かけませんが、質の高いGatsbyブログの事例はかなり目にします。Tania Rascia氏のブログは筆者のお気に入りのひとつです。

Gatsby自身は「ブロガー向けのもうひとつの静的サイトジェネレーター」(Jekyllのような)と思われたくない姿勢を明確に示していますが、それでもブログ用途での人気は非常に高く、多くのWordPressユーザーがその理由でGatsbyへ移行しています(前述のTania氏もその一人です)。

GatsbyまたはNext.jsとヘッドレスCMS

近年話題の「ヘッドレスCMS」や「分離型CMS」について語る開発者が増えています。WordPressなどをバックエンドとして使い、React(Angular/Vue)でREST API/GraphQL経由でデータを取得する構成です。Next.jsとGatsbyはどちらもヘッドレスCMSのフロントエンドとして利用できます。理論上は非常に有望に聞こえますが、筆者が見つけられた良質な事例はまだ少数です:

• Kata.aiによるNext.js + WordPress
• Chase McCoyによるGatsby + WordPress
• Indigo TreeによるGatsby + WordPress
• Adam RasheedによるGatsby + WordPress

Adam氏とChase氏のGatsby + WordPressの事例はどちらも非常に高速です。一方Kata氏のNext.jsの事例は、サイトは美しいものの、やや動作が遅めです。ハイパフォーマンスこそがNext.jsの主要なセリングポイントである以上、Kataの事例は「Next.jsとWordPressを併用すべき理由」としては最も説得力のある例とは言えません。

ヘッドレスCMSはまだ比較的新しい概念です。今後もヘッドレスCMS全般(ヘッドレスWordPressに限らず)がホットな話題であり続けることは間違いありません。そしてGatsbyもNext.jsもSSRを処理してくれるため、どちらもヘッドレスフロントエンドとして堅実な選択肢となっています。

GatsbyとNext.jsのデプロイ/ホスティング

Gatsbyはデプロイ前に静的に生成(プリビルド)されるため、専用サーバーなしでどこでも稼働できます。一般的にNext.jsはNode.jsサーバーを必要としますが、Gatsbyのようにアプリ全体を静的サイトとしてエクスポートすれば別です(ええ、それも可能です)。ホスティングサービスの中には、どちらかに特化したものもあります。

Gatsby + Netlify

GatsbyとNetlifyは天国で出会ったような相性です。サーバーレスなサイトであれば、GatsbyサイトをNetlifyにデプロイする設定は文字通り30秒足らずで完了します。

gatsby-plugin-netlifyプラグインを使えば、以後の継続的デプロイはターミナルでgit push origin masterという1コマンドを実行するだけになります。

Next.js + Now

Next.jsはNowホスティングサービスと相性が抜群です。その理由は明白で、Now(ホスティングサービス)とNext.js(フレームワーク)の背後には同じZeit社がいるからです。

Netlifyと同様に、Nowへのデプロイも数秒で完了します。ただし、デプロイするアプリの種類によります。

注意:GatsbyとNext.jsはそれぞれ特定のホスティングサービスと相性が良いものの、静的/フロントエンドのNext.jsアプリをNetlifyでホストすることもできますし(事例あり)、GatsbyをNowでホストすることも可能です(事例あり)。

どちらのフレームワークもDigitalOceanやHerokuなどでホストできます。

サーバーレスではなく、Next.jsまたはGatsbyアプリ用に自前のバックエンドサーバー/APIをホストしたい場合は、DigitalOcean、Heroku、Nowあたりを検討するとよいでしょう。ただし注意点として、Zeit社のNow v2.0ではDockerがサポートされなくなりました。これは多くの開発者にとって致命的な変更点です。

Next.js vs Gatsby デプロイ時間の比較

Gatsbyは再ビルド&再デプロイの際に更新までのタイムラグが発生します。その遅延の大きさはサイトの規模によります。サイトが大きくなるほど、再ビルドと再デプロイにかかる時間は長くなります。筆者は最近このサイトをGatsbyで構築しましたが、比較的小規模なサイトでも再ビルドから再デプロイ完了まで約2分かかります。

Next.jsにはこの「再ビルド → 再デプロイ → ダウンタイム」という問題がありません。自前のバックエンドサーバーを運用していれば、新しいコンテンツは即座に反映されます。

Gatsbyがダウンタイムなしのインクリメンタル更新を簡単に扱えるようになれば問題ではなくなるかもしれませんが、現時点ではWebSocketなどを使って自分で回避策を見つける必要があります。

参考リソース

• Postlight.comがGitHubで公開しているWordPress + Next.jsスターターキットは非常に興味深いです。
• ヘッドレスCMSとしては、WordPressの有力な代替としてPrismic、Contentful、Sanity、Ghost、ButterCMSなどがあります。