静的サイトジェネレータによる Web サイト構築

用語がわからないから分解していく。
随分前から色々な Web サイトやサービス、スマホアプリだったりは、Web サーバの向こう側で働いているアプリケーションが、ユーザからのリクエストを元に色々と処理をし、その結果を画面に出力（表示）している。
企業のサイトだったりも、大部分は WordPress なんかを代表とする CMS でコンテンツを管理（データベースに保存）して配信していたりするので、下図のように応答を得るまでに色々処理が行われて時間がかかる。（リクエストに対して生成する応答 = 動的）

それに対して静的サイトジェネレータを使用する構成は、コンテンツの作成に CMS を使ったりするのは同様だが、それは前段の作業で、あらかじめ応答内容を作成して Web ホスティング環境に配置しておくため、レスポンスの出力は HTML を応答するのみとなり高速になる。（リクエストに対して予め用意された応答 = 静的）

静的な応答なので、何かの状態に応じて提供するコンテンツを変化させることはできないが、企業サイトや LP、読み物系コンテンツなどは、そもそも状態に応じて変化させることが必要ないことが多いため、静的サイトジェネレータによるサイト構築の恩恵を大きく受けられるのだと思う。

続いて静的サイトジェネレータを使用する構成について考える。

Jamstack ってなに

公式サイトによれば

Jamstackは、Webエクスペリエンス層をデータやビジネスロジックから切り離し、柔軟性、拡張性、パフォーマンス、保守性を向上させるアーキテクチャアプローチである。
Jamstackは、ビジネスロジックがWebエクスペリエンスを決定する必要性を排除します。
カスタムロジックやサードパーティーのサービスがAPIを通じて利用される、Webのためのコンポーザブルアーキテクチャを実現します。

ということで、いわゆるユーザ体験を提供する部分をサーバサイドから切り離して管理する構成ということなのかな。

で、名前にある通りこれを実現するための道具が

• J（Javascript）
• A（API）
• M（Markup）

で、Markup 言語で作成された静的なコンテンツ（予め準備された HTML）と、Javascript で API を介して情報を入力することで動的な機能の提供を行う。

ユーザ体験って言葉、粒度がデカくて好きになれないんだけど、画面デザインだったり、ユーザインタフェースだったり、操作を行った際の反応や速度だったり、提供するコンテンツを構成しているアレコレを Jamstack 構成ではサーバサイドで提供しない = 静的な HTML がベースのため高速な応答が実現でき、必要な動的部分は Javascript を介して API を利用すること実現する。これにより本構成で作られた Web サイトには Web サーバやアプリケーションは必要なく、コンテンツは静的ホスティングによる配信で行うことができると理解。
副産物として複雑？なアーキテクチャからの解放により、開発や保守・運用が楽チンになるのかな。

具体的な構成

ここまでの内容を踏まえて具体的な構成を考えてみる。

• 静的サイトジェネレータ: Eleventy（11ty）
• ヘッドレス CMS: Strapi
• CSS フレームワーク: tailwindcss

コンテンツを作成するための情報が入力できれば入力元はなんだって構わないので、ヘッドレス CMS は必須じゃないけれど、コンテンツを構成する情報を管理するものとして便利なので使用する。ヘッドレスというのは画面の生成部分を担当しない（コンテンツの情報管理のみを行う）ということで、要はコンテンツを管理する画面のついたデータベース。
完全分業されていてとても良いと思う。

今回は Strapi というヘッドレス CMS を選択。サービス化されているものではなく、自分で環境作って使うんだけど、丁度使ってなかった VPS もあるのでそこで構築してみる。
サービスとして提供されているものだと裏の仕組みがわからないけど、自分で管理するとテーブル構成とか色々覗けて勉強になる。

11ty は Node 環境で JS でゴリゴリやれるっぽくシンプルで良さげ。プラグインも色々用意されてるけど、11ty が用意している Shortcode や Filter といった機構に、自前で機能追加できるのが楽しそう。
あと、テンプレートを記述するために使用可能な Markup 言語がとても豊富なので自分の好きな言語が選びやすいというのが良い。（対応している Markup 言語）
ざざっと眺めてみたけど、説明とサンプルみてとっつきやすそうだった Nunjucks を選択。
レイアウトファイルでヘッダ部分などの要素ごとに分割して管理でき、組み合わせてページを構成するといったことが可能なのと、HTML が基本で、その中に分岐や繰り返し、データの展開などが簡単にできるようになっていて習得コストはかなり低そうなのが良さげ。

あとは苦手な画面レイアウトだけど、評判が良くて使ってみたかった tailwindcss を使ってみる。なんか色々便利で凄そうという印象。

静的サイトジェネレータを使うことのメリット・デメリット

色々あると思うけど、画面を構成するテンプレート作成、テンプレートに食わせるデータ管理、それらを便利に使えるようにするためのプログラムなどが独立して管理できるのはとても好みだし、保守するのが楽そう。
静的なサイトなので、レスポンスが高速な上、ログインのような認証処理が表にでないことによるセキュリティリスクの低減もポイント高い。
あとは静的ホスティングで配信できるので、無料枠が大きい（サーバの CPU を使用しない）サービスが選択肢として豊富にあるところも良さげ。
今回は CloudFlare を使ってみてるけど、AWS と違い通信に課金されないのでデプロイに関する処理を別でやれば完全に無料で公開できる。

逆にデメリットは、図にあるように、ビルドしてアップロードという手順を踏まないとコンテンツが更新できない点。
動的なサイトであれば DB に入っている情報を更新すれば連動して表示されるコンテンツにも反映されるけど、静的サイトジェネレータの場合は必ずビルドからのアップロードという作業が必要になる。
静的サイトジェネレータで良いと判断したコンテンツを扱う Web サイトであれば、この部分はあまり気にならないと思うけど、CMS に手を入れて記事更新からデプロイできちゃうような機構を用意したら解決できるよね。

その他として、動的なことをやろうとすると、セキュリティ的に色々考慮しないといけないところが出てきて悩ましくなる。まぁそういうところは動的な機構をいれて分業したらいいわけだけど。

そういえばメリットについて、コスト面の低減をあげているのを良くみるけど、触ってみた感じ、それなりの規模感で便利にやろうとすると静的サイトジェネレータの構成全部を外部に任せる（あれこれ比較して乗り換えたりすると移行コストもばかにならなそう）とか、ジェネレータ部分をカスタマイズしていくとかが前提になりそうな気がするので、単純にコストダウン・・・というわけにはいかないんじゃないかという印象。

比較対象として色々問題点も囁かれる WordPress などの既存環境だけど、自分の用途に応じて上手くチョイスできなければどっちの環境でもダメだよね。

まとめ

• Jamstack によるアーキテクチャの簡略化
• 静的サイトジェネレータが、というか単純に昔ながらの静的なサイトってやっぱり速い
• 静的、動的についてはメリット・デメリットをよく考えてチョイスしないと後悔も？
• 無料でつかえるホスティングサービスに感謝
• Node 環境から何から、ちゃんと使うのが初めてだと学習コストはそれなりにありそう（今回の構成はフロント専門の人にはきつそう）

ということで構築に関するアレコレは、備忘として引き続き記事化していこう。