静的サイトジェネレーターについて考える座談会 第1回 「静的サイトジェネレーター」の変容の歴史
これまでフロントエンド開発に登場してきた「静的サイトジェネレーター」をキーにこれからのサイト制作の開発手法を展望する座談会です。第1回目は静的サイトジェネレーターの変容の歴史をざっくり話しました。
- カテゴリー
- 座談会 >
- 技術系座談会
- Jamstack >
- 静的サイトジェネレーター
発行
はじめに
CodeGridではこれまで、複数の「静的サイトジェネレーター」と呼ばれたり、あるいはそのような機能をもったフレームワークやツールを紹介してきました。
この座談会ではこれまでフロントエンド開発に登場してきた主なフレームワークやツールを振り返りながら、現代の開発現場では、どのようなサイトのニーズに応えようとしているのか、またその理想的なサイトをどのような手法で構築しようとしているのかを考えます。
第1回目はCodeGridの中にも登場した主要なフレームワークやツールの発展の歴史を、開発者なりの視点から語り合っています。
参加者はピクセルグリッドの以下のメンバーです。
静的サイトジェネレーターとは
ーー今日は静的サイトジェネレーターについて、お話できればと思います。昨今、たくさんの静的サイトジェネレーター、または静的サイトジェネレーターの機能を持ったツールがありますよね。まず最初に「静的サイトジェネレーターって何？ どういう定義？」ということがあるかと思うので、そこを確認できればと思います。
中野：僕は、作るときにはプログラム的なコードで書けて、ビルド時には静的なアセットとしてできるだけ吐き出す。配信するものとしては静的なHTML/CSSと、クライアントサイドのJavaScriptという状態にできるツールが静的サイトジェネレーター、という定義だと思っています。
ただ、Gatsbyは吐き出すものがSPAに近い挙動をするとか、Next.jsはSSRでレンダリングできる機能が揃っていたり、APIを構築できたりだとかしますよね。ツールによっては、静的サイトジェネレーターというよりもっと大きな枠という気がするのですよね。
中村：そうですね、僕は静的サイトジェネレーターは「何らかのソースファイルから、Webサイト的なものを生成するツール」なのかなと思いますね。
「1ページのSPAのようなものを生成する」というよりは「複数ページからなるWebサイトを生成する」というツールを、静的サイトジェネレーターと呼ぶのかなっていう印象ですかね。僕の中では。合っています？
矢倉：多分、正解はないと思います。
中村：ないと思いますね（笑）。どう説明したら、一言で説明できるんだろう。
矢倉：それこそ、Jamstackのサイトに静的サイトジェネレーターの説明って何て書いてあるんでしたっけ。えーと……
A tool which can be run as part of a build to transform content, data, and templates into files which can be deployed to a hosting environment as a ready-to-serve web site.
（Static site generator | Jamstack）
「そのままWebサイトとしてホスティング環境にデプロイできるように、コンテンツ、データ、テンプレートをファイルに変換する、ビルド時に使うツール」となってますね。
だからまあ、意味合いとしては広いですよね。
中村：ファイルに書き出すっていうのは、静的サイトジェネレーターの必須条件かな。たとえばWordPressってサーバーを起動してサーバーからHTMLを含めたデータを返しますけど、ファイルとして吐き出すわけではないじゃないですか。そういうものは静的サイトジェネレーターではないっていうことですよね。まずはそのあたりのことを考えるためにも、静的サイトジェネレーターを、昔のところから今までの理解を整理することから始めてみましょう。
静的サイトジェネレーターの登場前夜
ーー静的サイトジェネレーターがツールとして登場する前、というのはどういう状況だったのでしょうか？
中村：大昔のWebサイトの作り方は、「みんな手で書いてたよね」っていうのがありますよね。その後に、手で書くのが大変なので、サーバーに作らせようとかそういう流れがまず出てきたはずです。
僕が最初に触ったものでいくとMovable Typeの2.6ですかね。それはCGIを使ってサーバーで、あらかじめHTMLを生成しておくっていうPerl製ツールで。静的サイトジェネレーターに近い動きをしてたと思うんですよね。
高津戸：確かに。
矢倉：Movable Typeでは、「再構築」っていっていましたもんね。
中村：そうそう。「再構築」っていうボタンを押すのが「全サイトを生成する」ことで、普段は更新した記事と関連するインデックスだけを生成する「インクリメンタルビルド」ですよ。記事とその関連ページを更新するんだけど、過去の記事は更新しないっていうのがMovable Typeの動きだったので、まあやっていることはサーバーで動く静的サイトジェネレーターだよねっていうイメージですね。
でも、それだと「再構築が時間かかるよね」という流れが出てきました。それで、WordPressなどのように、毎回データベースに問い合わせて生成するみたいなもののほうが主流になっていったな、という印象ですかね。
高津戸：そもそも、静的サイトジェネレーターっていう言葉がその頃ないですしね。
中村：そうですね、静的サイトジェネレーターとは呼んでいない。ただ、すごくアクセス数が多い場合とか、やっぱり静的サイトじゃないと運用が難しいことはありましたよね。僕が昔やっていたときは、静的サイトジェネレーターツールがあまりなかったので、ローカルでPHPを動かしてHTMLを大量に生成するみたいなことはやっていましたね。
中野：今の感じに近いですよね。
中村：そう。なんらかのプログラム言語で静的サイト生成するみたいなことはしていたと思います。
静的サイトジェネレーターの2つの流れ
ーーツールとして、静的サイトジェネレーターが登場してきたのはどのあたりからでしょう？
中村：静的サイトジェネレーターって言葉が出てきたなというのは、Jekyll*とかあのへんのツールが出てきたあたりかな。
*注：Jekyll
2013年6月にv1.0.0がリリースされています。CodeGridでは2013年にJekyll（ジキル）を取り上げています。
- 「Jekyllで作るシンプルWebサイト」シリーズ
矢倉：やっぱり、JekyllやHugoがクラシックな静的サイトジェネレーターとして出てくるじゃないですかね。Markdownで書いたものを、別途用意したテンプレートに流し込んでコマンドラインでエンターを押せば、ばばっと一連のHTMLファイルができてくれる。
中村：そうですね。そのへんのJekyll系みたいなツールが、歴史的にはいわゆる静的サイトジェネレーターっていうものですよね。
その流れを汲んでるのが、今でいうとEleventy*かな。Eleventyで採用された、Front matterのついたMarkdownファイルで生成できるとか、そういうのはJekyllから来ているみたいですね。Eleventyは、Jekyllをかなり参考にして作られていたと思います。
*注：Eleventy
2017年12月頃にv0.1.0がリリースされています。CodeGridでは2019年11月からシリーズが開始されていました。2022年1月にメジャーバージョンアップしたv1.0.0がリリースされ、現在も開発が続いています。
- 「静的サイトジェネレーターEleventy」シリーズ
Node.jsで作られたJekyll。Eleventyはそんな印象ですかね。
高津戸：僕は、当時Jekyllが流行ったけど、それは開発の人らがブログとかを書くのに「え、これイケてんじゃん！」みたいな感じで使うぐらいだったんじゃないかなって思って。CodeGridの記事にも書きましたけど。
GitHubもすごくJekyllを推していて、サーバーとか準備しなくてもGitHub Pagesに、ちょろっとビルドした結果を公開して「ほら、ブログができちゃいまっせ」みたいのが、当時は流行ったんですよね。開発的には「ちょっとクールに見える！」みたいな（笑）。
中村：そうそう。「ブログとか日記の公開ごときでサーバーのメンテなんかしたくないよね」という、静的に生成してそれを公開するだけで十分では？ みたいな流れがあったんですよね。
高津戸：ただ、コーポレートサイトとかをそれで作るかっていわれると、Markdownで全部作れるようなことはあまりないので。ドキュメントとかブログとか、そういうので主に使われていたぐらいかなーっていう感じでしたけど。その頃は。
ーーエンジニア個人が楽しんで使う範疇で、まだ本格的に案件に使うというわけではなかったんですね。
SPA由来の静的サイトジェネレーター
中村：そういうJekyllみたいな昔ながらのツールの流れをくむ静的サイトジェネレーターとは別に、SPAからきた静的ジェネレーション機能の流れがあると思っています。
Webの世界ではGoogle Mapとか、Ajax*でWebでアプリ的なものを作るみたいな流れが別にありましたよね。
*注：Ajax
みなさんお馴染みの言葉なので、用語解説というより、歴史を語る上で注釈をつけておきます。Ajax（エイジャックス）はAsynchronous JavaScript And XMLの略で、2005年2月18日に情報アーキテクトであるジェシー・ジェームズ・ギャレット氏によって提唱された造語です。
フロントエンド的には、JavaScriptでできることが増えていって、Gruntなどのタスクランナーや、Backbone.jsなどのいろんなライブラリが出てきて、SPAを気軽に作ることが増えてきました。
*注：Grunt、Backbone.js
Gruntは初期バージョン0.4.0が2013年2月にリリース、Backbone.jsの0.1.0は2010年10月にリリースされています。CodeGridではGruntが2013年3月、Backbone.jsは2012年11月に連載されています。
今だとReactやSvelte、VueなどのUIフレームワークを採用したツールなどですね。
そういうSPAを作るツールが、ここ数年、静的ジェネレーション機能を搭載し始めてるんですよね。具体的にはNext.js、SvelteKit、NuxtJSとかがそうだと思います。
静的ジェネレーション機能を使えば、静的サイトジェネレーターのようなことができるので、今は、そういうSPAの流れからの静的サイトを作るというのと、昔ながらのJekyllみたいな流れのものというのが混ざり始めていているかなと。
ーーSPAを作るツールが、静的ジェネレーション機能を搭載し始めたのはどうしてでしょう？
中村：主にパフォーマンスの問題かな？
中野：そうですね。SPAはユーザーがアクセスしてきてから、いったんHTMLを読んで、必要なデータがあればクライアントサイドのJavaScriptがAPI経由でアクセスします。それらのデータを使ってJavaScriptがHTMLを生成するので、アクセスしてから表示されるまでが遅いんですよね。
中村：要は、Flashみたいに最初にローディングが走ってるのでよければいいんだろうけど、そうじゃなくてアクセスしたらすぐに速く表示させられるようにしたい、という流れがあったんですよね。
そのためにはサーバーサイドでHTMLを事前に作る、いわゆるSSRみたいな流れが出てきた。でも、それだとサーバーの制限とか厳しいから、じゃあ静的に先に生成しておいたらどうだろうというのが静的サイトジェネレーターに至るまでの道なのかなと思っていますね。
高津戸：SPAが流行ったときは「静的にサイトを作ろうぜ！」みたいには盛り上がっていたわけじゃないという印象でしたね。巷で流行ってんのは「SPAでイケてるUI作ろうぜ！」みたいな（笑）。ピクセルグリッドの仕事としても多かったんじゃないかな。
ただ、HTMLをちまちま手書きで作っていた我々みたいな人間からすると、PugとかHandlebarsとか、そういうテンプレートエンジンをうまく使ってなんかできないかなーって思いつつ、別に何か仕事には、大してつながらないというか、そういう感じでした。その頃は。
中村：そうですね。その頃はそうだったかも。
世の中でも流行り始めたのは、静的なサイトがいろんなSPAのツールでも出せるようになったところあたりかな。
Jamstackが出てきて、静的サイトジェネレーターでサイトを作るという手法が広まり、各種SPAツールが機能を搭載していったという印象ですね。
Gatsbyと静的サイトジェネレーター
中村：Gatsbyはその流れとは違って、SPAのようなサイトを吐き出すんだけど、Eleventyとかの静的サイトジェネレーターよりですね。
中野：Gatsbyが最初に静的サイトジェネレーターというか、SSGみたいなことをいっていたと思いますけど、Next.jsに静的サイトジェネレーター機能がつくのってそれよりちょっとあとですね。
補足：Next.jsのSSG機能
Gatsbyが2017年にv1をリリースした当初は「モダンな静的サイト生成」を可能にするツールとして自らを定義していたようです。Next.jsがSSG機能をサポートしたのは、2020年3月にリリースされたNext.js9.3からです。
中村：そうですね。
中野：Next.jsは、もともとはSSRのフレームワークだったのが、バージョンアップによってそういう機能が搭載された、という感じだったと思います。
中村：Next.jsは、以前は完全にSSRのライブラリだったんですよね。Gatsbyは、静的サイトジェネレーターに少しSPA的な要素を取り入れて、「静的とは呼べない動的なサイトを生成するジェネレーター」っていう感じかなと思っていて。多分、静的サイトジェネレーターの流れとそのSPAの流れと、両方取り込んだものだと思うんですよね。
高津戸：そうといえばそうですね。動的っていう言葉が、こうサーバーサイドで生成する動的って意味と、その画面上でダイナミックにUIが遷移するみたいな動的っていう意味があって、その意味でいうと、Gatsbyは静的。
中村：静的なファイルで、動的なサイトを構成するというイメージですよね。
高津戸：ページ間の遷移を、History APIなんかを駆使して画面上で済ませてしまい、パフォーマンスをマックスにするみたいな、そういう思想みたいな感じですね。その機能についていえば。
Gatsbyのドキュメントを見てもらうと、左のナビゲーションとかぼちぼちするとダイナミックにこうページが切り替わるんですよね。これはSPAみたいな設計、実装上はまあ、ひとつひとつHTMLを書くのに近いんだけど、それだけでこうダイナミックなSPA的な挙動を実現できるみたいになってんすよ。
中野：たとえば、top.htmlからabout.htmlへの遷移だとしたら、実際にabout.htmlという違うファイルを見に行っているのではなくて、クライアントサイドのJavaScriptがtop.htmlとabout.htmlの内容の差分を書き換えているという感じですね。
ーーいわゆる、SPA的意味での動的って意味ですよね。
高津戸：そうです。ダイナミックな挙動をしているけど、使うファイルっていうのは、あらかじめビルド時にJSONとかHTMLとか静的に生成されたもの使っていると。
でもややこしいのが、そこでサーバーサイドで動的に処理したい部分もあるってことですよね。だから、今のフレームワーク、Next.jsとかGatsbyとかは、そういう部分もカバーした存在になっているんですよ。
ーーなるほど、機能としてはありますよ、ということですね。
高津戸：そう、やろうと思えばできますよと。だから昔のJekyllとかそういうのと比べると、かなり包括的に広い範囲をカバーするような存在になって。もはやそれ自体のことはフレームワークと呼ぶようになっていて、静的サイトジェネレーターとあえて彼らは名乗らない。Gatsbyも、以前は「静的サイトジェネレーター」といってた気がしたんだけど。
補足：静的サイトジェネレーターとしてのGatsby
v1をリリースした当初のブログを参照してください。
中野：最近はいっていませんよね。
高津戸：ちょっと前までトップページに「フルスタックのフロントエンドフレームワーク」というようなことが書かれていた記憶があります。
AstroとEleventy
ーー最近の話でいうと、Astroはどうでしょうか。Eleventyとも、GatsbyやNext.jsともアプローチが違うのかな？
中村：Astroは、もともと静的サイトジェネレーターとして作られていて、最近はまたSSRの機能が付いたりしていますね。もうすぐ1.0が出る、新しい静的サイトジェネレーターですね。
Astro 1.0のリリース
この座談会は2022年7月に行われましたが、Astroは8月に1.0がリリースされています。Astroの詳細は、次のシリーズを参照してください。
AstroはSPAへの開発のフロー的なもの、コンポーネントだとかいいところは全部取り込んでるんだけど、吐き出したときにデフォルトではJavaScriptなしになるんですよね。Astroが目指してるのは「JavaScriptを減らして速いサイトにしよう」というところがあるのかなと。
最近Reactなどを使うのが当たり前になってきて、なんでもない、ただの静的サイトでもReactが読み込まれたりするじゃないですか。「静的なサイトだったらJavaScriptは必要ないのではないか？ それのせいでパフォーマンスが悪くなっているんじゃないのだろうか？」として解決しようとしてるのが、Astroですかね。
中野：GatsbyとかNext.jsで、JavaScriptを使ってたくさんの機能を持ったサイトを作るようになったのに対する、なにかアンチテーゼ的なポジションだなって僕は思っていて。
そもそも、そういう大きいことをするのにそういうJavaScriptを使ったりするのはいいにしろ、静的サイトにはいらないよねってことかなと。
Eleventyがその仕組み自体は似たようなことしていて、JavaScriptがあまりないファイルを吐き出せるようなものでしたよね。でも、Eleventyは書き味が、モダンなReactやらVue.jsに備わる「コンポーネント化」っていう感じではない。Jekyllから来たHTMLのテンプレート言語で書くようなものだったので、それがやっぱりデベロッパー的にはつらい部分ではあったんです。
Astroはそういう部分がモダンなので「Astroが使いやすいな！」って、僕はなるんですね（笑）。
中村：僕は古い人なのでテンプレートベースの書き味は悪くないんですけど（笑）。でもEleventyを使ってて困るのが、現代のWebサイトで「JavaScriptは、やっぱりちょっと入れたいよね」っていうポイントはいっぱいあるところなんですよね。
たとえば、なんでもないサイトでも、モバイル時はハンバーガーのメニューでちょっとメニューが出せるとか、ちょっと検索の窓がついてるとかそういうことってあると思うんですね。
そういった場合にJavaScriptを使いたくてもEleventyは何もサポートしてくれないので、自分でどうJavaScriptを入れるかを考えないといけない。何かビルドするものを作るんだとしたら、全部自分でビルドプロセス組んでなんか考えなきゃいけない。そういうところが、Eleventyのちょっとつらいところだなと思っていますね。
そういう点からいうと、Astroのほかにも、Next.jsやGatsbyもReact限定になりますけどJavaScriptが前提になってるんでやりやすいのかなと思ってはいますね。
高津戸：担当した案件でもEleventyを使っていますけど、ビルドが結構めんどくさいんですよね。小さなパッケージみたいのを組み合わせたりしていて。
中村：JavaScriptの部分はSvelteでちょっとしたツールを作って自分でビルドして、ってなっていますよね。
それって、自由にできるっちゃあできるんですけど、組み合わせとかを自分で考えないといけないのはちょっとめんどくさいポイントですね。
高津戸：うん、そのめんどくささはあると思います。
ーーピクセルグリッドのコーポレートサイトは、EleventyからAstroに置き換えたんでしたよね。次回はそのあたりの実作業から得られたことをうかがいます。
現在、ピクセルグリッドで採用を検討する静的サイトジェネレーター（中村）
今回の座談会では古いものも含めて多くのツールの名前が挙がりました。中には現時点では古すぎたり、開発が継続されていなかったりするものもあり、今から採用はしないだろうなというツールもあります。
そこで、さまざまなツール名でいっぱいになっている頭をちょっとクールダウンしてもらうために、今、Webフレームワークや静的サイトジェネレーター（以下ツール）を選ぶとしたら、という視点で、今回出てきたツールの中からいくつかピックアップしてみます（記事公開時2022年9月の状況です）。
Next.js
SPAを作ろうとするなら、現在のトレンドからいくと、まず選択肢として挙がるツールです。現在も活発に開発がされています。
SvelteKit
もうすぐ1.0になる予定で現在RCが公開されています。1.0になっていないため「安定しているツール」とはいえません。しかし、パフォーマンスが重要なら採用を検討するツールです。
Eleventy
HTMLをテキストとして扱い完全にコントロールしながら生成するツールとして、採用を検討します。また、本文ではJavaScriptを追加しづらいという話になっていますが、2022年6月に<is-land>という仕組みができ、Svelte、Vue、PreactなどのコンポーネントをAstroのように追加できるようになったようです。
（社内プロジェクトはAstroに移行済みのため、社内ではまだ試せていません）
Astro
Astroは1.0になり、いわゆるWebアプリケーションよりはWebサイトに近いものを作るのであれば、社内にノウハウも溜まっていますし、利用する可能性の高いツールです。
Gatsby
Gatsbyが用意した範囲で構築でき、初回アクセス速度ではなく、ページ遷移の速度が最重要ということであれば採用するかもしれません。