これだけで「静的サイトジェネレーター」のすべてがわかります

Jamstackと静的サイトジェネレーター

「これだけ読めばOK！ Jamstackのすべてがわかります」で紹介したように、近年急速に採用が広がるJamstackですが、このコアには静的サイトジェネレーター（Static Site Generator/SSG）というテクノロジーがあります。

代表的な静的サイトジェネレーター、Next.js、Gatsby、Nuxt.jsで作られているウェブサイトやアプリは次の記事で一覧紹介しています。

静的サイトジェネレーターが現れるまでの歴史

こちらの記事でも説明したように、90年代始めのインターネット黎明期のウェブサイトは、すべてが静的サイトでした。

当時は通信速度も遅く、またやり取りされるデータも文字ベースの軽いものだったため、静的サイトの「アクセスされた時にデータを表示する」というシンプルな機能で十分だったのです。

下の画像は世界最初のウェブサイトで、これも静的サイトでした。

http://info.cern.ch/hypertext/WWW/TheProject.html

---

当時ウェブサイトは、エディターでHTMLを1枚1枚書くというマニュアルワークで作られていましたが、90年代も後半になってくると、ページ数の多いウェブサイトが現れ、マニュアルワークでページを作成、更新、そしてサーバーにアップロードする作業が大変になってきました。

このようなページ数の増加と合わせて、ウェブサイト自体に求められる役割や機能も増えてきたので、CGI（Common Graphic Interface）とPHPを活用したLAMPという手法による「動的サイト」が現れます。

このLAMPについては「Jamstackが現れるまでの歴史 ― LAMPからMEAN、そしてJamstackへ」でくわしく解説しており、LAMPを使った代表的な動的サイトがあのWordPressです。

静的サイトと動的サイトの最大の違いはユーザーとのやりとりが「一方通行」か「双方向」かの点にあり、静的サイトの場合、誰がアクセスをしても表示されるページは同じであるのに対し、動的サイトはユーザーごとに異なるページを表示することができます。

そのため「双方向」の動的サイトはおのずとその仕組みが複雑になり、「表示スピードが遅い」、「パフォーマンスが悪い」、「セキュリティが低い」といった課題を抱えていましたが、これらはWordPressが広く使われている今も存在している現在進行形の問題です。

	静的サイト	動的サイト
ユーザーとのやりとり	一方通行	双方向
表示されるページ	全員に同じページを表示する	ユーザーに応じて表示するページを変更できる
スピード	速い	遅い
機能	少ない	多い

WordPressのような動的サイトを使い続ける限りこれらの問題は解決されないため、2015年頃から再び注目を集めるようになったのがウェブ黎明期のあの静的サイトです。

とはいえ当時と同じ静的サイトではなく、90年代から20年あまりの間に進化・発展したテクノロジーを取り込んだ「現代版静的サイト」です。

この現代版静的サイトは、ウェブ黎明期の静的サイトとは比較にならないほど高性能で、かつ高機能となっていますが、その分作るプロセスも複雑になりました。

そこで開発されたのが静的サイトジェネレーター（SSG）で、これによって高機能な現代版静的サイトを簡単に作れるようになったのです。

ページが生成される時と場所

動的サイトではユーザーからのアクセスが発生した時にページが生成されます。

プロセスとしては、アクセスを受けたサーバーがまずデータベースにデータを取りに行き、次にそのデータを元にページを生成してユーザーに送る流れとなります。

このようなページ生成のプロセスは、アクセスするユーザーによって表示するページを変える（ログインユーザーによってページが異なるなど）ケースでは有効ですが、ページ生成を毎回行うのでページの表示には時間がかかることになります。

一方静的サイトの場合、ページはアクセスを受ける前にすでに生成されています。

上でも触れたように、静的サイトの場合は表示されるページが誰に対しても同じなので、ユーザーに応じてページ内容をカスタマイズする必要がありません。

そのためページを事前に生成しておくことが可能で、その分速く表示できるのです。

この「ページ生成」というプロセスこそが静的サイトジェネレーターの担当範囲なのですが、それではいつ、どこでページ生成はされているのでしょうか？

buildとは何か？

例えば新しいブログ記事を書いたとします。

これを現代版静的サイトとしてアップするには、まずページ生成をする必要があるので、記事データを静的サイトジェネレーターに取り込みます。

このページ生成プロセスはbuildと呼ばれ、buildによって記事データがページのひな形であるテンプレートと一体化されて、ページ（HTML）が生成されるのです。

buildは通常手元のコンピューター内で行われますが、ここで注目したいのは、ページ生成がユーザーからのアクセスを受けるよりもはるか前に行われていることで、ページ生成をアクセスされた時にサーバーで行う動的サイトとはプロセスが異なっています。

build時にはコードの圧縮・軽量化や画像最適化なども行われ、次節で紹介するような静的サイトジェネレーターのメリットにつながっていきます。

	サーバー	静的サイトジェネレーター
ページが生成される時	アクセスされた時 （Request time / Real time）	build時
ページが生成される場所	サーバー	ローカル環境、その他Netlify、Gatsby Cloudなど

静的サイトジェネレーターのメリット

静的サイトジェネレーターが現れた当初は「コンテンツ管理が難しい」という意見がよく聞かれましたが、その点はあとで触れるように、すでに解決されています。

ここでは静的サイトジェネレーターの代表的なメリットを紹介します。

スピード

上で説明したように、ページはアクセスを受けるよりも前に生成されており、アクセス時には生成済みのページをユーザーに送るだけなので、ユーザーに素早くページを表示できます。

50パーセント以上のユーザーが3秒以上待たされるとページを離脱するという調査データが示すように、ウェブサイトを高速表示する必要性は年々高まっており、動的サイトとは比較にならない程のスピードが実現できる静的サイトジェネレーターは、このニーズを満たすことができます。

---

下記のウェブサイトは、1つ目は静的サイトジェネレーター（Gatsby + ヘッドレスWordPress）で、2つ目は普通のWordPressで作ってあります。

スピードやパフォーマンスを比較、体感してみてください。

• monotein-demo.site（静的サイトジェネレーター / Jamstack）

• monotein-demo-wordpress.site（普通のWordPressサイト）（*2022年1月追記：昨年7月よりこのドメインでWordPress版を公開していましたが、現在メンテナンス中で公開を停止しています）

セキュリティ

静的サイトジェネレーターの場合、データベースやAPI、CMS（ヘッドレスCMS）との通信はbuild時（ページ生成時）に行われます。

そのため、ネットワーク（CDN）上にパブリックになっているのはその生成済みのページだけなので、サイバーアタックの標的となりうるデータベースやサーバーへの「入り口」が存在せず、高いセキュリティを維持できます。

柔軟性（フレキシビリティー）

ウェブ黎明期の静的サイトは、文字や画像を表示するだけのシンプルなものでした。

そこではコメント機能やショッピング機能といったユーザーと双方向のやりとりが発生する機能は実現不可能でした。

一方でさまざまなテクノロジーを取り込み、今も日夜進化を続ける静的サイトジェネレーターによる現代版静的サイトは、双方向の機能も一部実現できるようになっており、こちらの記事でも触れたように、フォームやコメント、決済といった動的要素はAPIを使って広く実装されています。

この静的サイトジェネレーターをコアテクノロジーとするJamstackをより深く知りたい方は、無料ダウンロードできる下記資料を参考にしてください。

コンテンツ管理の方法

ここまでやや技術的な面から静的サイトジェネレーターを紹介してきましたが、プログラマーやエンジニア以外の人は静的サイトジェネレーターで作ったサイトを使えないのでしょうか？

静的サイトジェネレーターが開発された当初はそうでした。

しかし今ではさまざまなコンテンツ管理の手法が生み出され、専門知識のないユーザーでも簡単にコンテンツを制作・編集することができるようになっています。

そこで使われるのがヘッドレスCMSというものです。

ヘッドレスCMSは上の記事でくわしく紹介していますが、これによってより多くの人が静的サイトジェネレーターのウェブサイトのメリットを享受できるようになっています。

これまでWordPressを使ってきたユーザーでも、フロント部分を静的サイトジェネレーターに置き換え、ヘッドレスCMS化することで、高パフォーマンスで高セキュリティのサイトに進化させることができます。

• monotein-demo.site

上記デモサイトにおいても、CMSとしてヘッドレス化したWordPressが接続されているので、下のスクリーンショットのように、使い慣れたWordPressの管理画面でコンテンツの制作作業を行い、そのままプレビューも行うことができます。

プレビュー画面は下のように表示されます。

「ヘッドレスのWordPress」と「普通のWordPress」のくわしい比較は、次の記事をご覧ください。

有名な静的サイトジェネレーター

最後に有名な静的サイトジェネレーターを簡単に紹介します。

jamstack.orgではGitHubのスターの多い順に静的サイトジェネレーターが列挙されているので、よりくわしく知りたい方はそちらを参考にしてください。

Gatsby

当サイトでも使っている、高速のウェブサイトを制作できる静的サイトジェネレーターです。

JavaScriptフレームワークのReact、そしてGraphQLを採用しており、豊富なプラグインによってさまざまな機能を簡単に追加できます。

• monotein-demo.site

上記のデモサイトでもGatsbyを使っています。

Gatsbyに興味のある人は次の記事も参考にしてください。

Next.js

Vercelという企業によって開発されているReactベースの静的サイトジェネレーターです。

当初はサーバーサイドレンダリング（SSR）で注目を集めましたが、今では静的サイトの書き出しにも対応しています。

静的サイトだけでなく本格的なウェブアプリケーションやSPAなどにも対応可能なので、日本の企業でも採用しているところが多くあります。

Next.jsを静的サイトとして使ってブログを作る方法は、下の記事を参考にしてください。

Jekyll

最古の静的サイトジェネレーターといわれており、開発言語にはRubyが使われています。

今でも新しいバージョンがリリースされていますが、GatsbyやNext.jsといった高機能な静的サイトジェネレーターの登場で、近年は個人のブログや小規模サイトでの利用が主になっています。

Hugo

静的サイトジェネレーターはフロントエンド寄りのテクノロジーなので、言語にはJavaScriptを使うものが多いですが、このHugoにはGoが使われています。

オフィシャルサイトには「The world’s fastest framework for building websites」とあります。これはbuild時間が短いという意味のようで、こちらの調査でもbuild時間は最短になっています。

Nuxt.js

上で紹介したNext.jsに影響を受けた静的サイトジェネレーターで、こちらではJavaScriptフレームワークとしてVueを使っています。

静的サイトジェネレーターの全体的な傾向として、Reactベースのもの（GatsbyやNext.js）の方が世界的に採用件数が多いように個人的に感じます。

React、Vueと来て最後に残されたAngularですが、Angularを使ったScullyという静的サイトジェネレーターも最近ようやく現れたようです。

monoteinは、Next.jsやGatsbyを使ったJamstackサイト制作を専門としています。

ストレスフリーでサクサク動き、高いCV率を実現するJamstackサイトに興味のある方は、コチラより遠慮なくお問い合わせください。