POSTD以外は、サンプルとして捉えて下さい。

前書き

ニジボックスがPOSTDを引き取って運用再開してから、そろそろ2年が経とうとしています。

上記リンクにもある通り、POSTDは移管のタイミングでGatsbyに書き直していました。
それに起因してとまでは言わないですが、案件などでGatsbyを使うサイトの制作を受託するケースが発生しています。

今回のこの記事では、POSTD運用をベースにGatsbyを使っていた案件をちょっと離れた位置から見た立場として、SSG(Static Site Generation)を採用することの良し悪しについて、改めて文にしてみました。

サイト自体の概要

今回出てくるサイトの構成要素を少しだけ記載します。（どれもGatsby製）¹

サイト	スタイル	コンテンツ管理
POSTD	ブログ	GitHubリポジトリ内にMarkdownで管理
ある案件のサイト	Webサイト	HeadlessCMS上で管理

いずれも、Gatsby製の静的サイトとして管理しており、更新のたびにビルドが必要な点については共通しています。

ありがたい点

サーバーサイドが複雑にならない

gatsby buildでの静的サイト化は、当たり前ですが動的サイトと単純比較すると、レスポンス速度の優位性が高いです。
Gatsbyはサイト内でのページ間遷移はHTMLではなくコンテンツを保持したJSONを利用するため、初回アクセスだけでなくページ巡回においてもかなりの速さを期待できるでしょう。

また、「静的サイトである」ことからデプロイ場所を選ばないという点も大きいです。
個人的に管理している自身のサイトもSphinxを利用していますが、以前はレンタルサーバーにそのままPUTするだけの運用をしていました。
動的要素を考慮しないで良いというのはそれだけで気楽さを提供してくれます。

developモードにおける表示確認の気楽さ

Gatsbyの表示確認時はgatsby developコマンドでローカルサーバーが立ち上がるため、エンジニアにとっては馴染み深いです。
また、POSTDではリポジトリ内に記事ソースをまとめて管理しているのもあり、編集がホットリロードで即時反映されていくのも、記事自体の扱いやすさに一役買っています。

困りがちなこと

とはいえ、上記の点とのトレードオフになりやすい領域で困ったことも起きます。
場合によっては、この点が要件上クリティカルにもなりうるのが重要です。

記事などの要素数が多いほどビルドがしんどくなる

この記事の投稿時点で、POSTDの中でページソースとして管理しているMarkdownファイルは全部で820個あります。さらにカテゴリー・タグもかなりあるため、最終的に gatby build における生成は1250ページにまで膨れ上がります。²

ここまで生成量が多いと、時間そのものもかなり必要とします。
現在、POSTDの記事更新は、 1回あたり7分程度必要 です。ちょっと長いですね。

とはいえ、実際のところはあまり問題になっていません。これは、チーム内の合意として「予定日通りに公開できるように心掛けるが、難しい場合は延期を含めて柔軟に対応する」となっているためです。

ビルド時間がかかる = 決まった時間にリリースできない

前述の通りPOSTDはビルド時間に関するしんどさは「許容する」方針で進行させています。
そのため、リリースのタイミングがずれてもそこまで問題になりません。

逆にフレキシブルな動き出しをするわけにはいかないケースも存在します。案件サイトがそのようなパターンでした。

この案件では、スタイル欄に記載したWebサイトの内容をライブ配信などのタイミングと可能な限り足並みを揃えて公開する必要が出てきていました。
つまり要件として「記事要素の更新・公開がリアルタイムに近い状態で提供できること」といういものが含まれています。
さて、こうなってくると以下のような要素が運用を困難にしてきます。

ビルド環境が遅延して、公開が遅延する
記事のデータ取り込みが遅延して、公開が遅延する
記事データetc起因でビルドに失敗して、公開が大遅延する
ビルド自体の時間が気づかないうちにかなり増えて、公開が遅延する

このような「記事更新→即反映」が必要な場合だと、やはりWordPressのような動的サイトを構成するほうが楽なことがあります。

構成要素すべてがボトルネックになるリスク

Gatsbyでのサイト管理+公開を考えると次のような要素分割が可能です。

デザイン等のソースを管理する場所
記事データを管理する場所（上記のリポジトリと同一でも可）
公開用サイトをビルドする場所
公開するための場所

サイトの公開状態を維持するだけならば、(4)さえ生きていれば問題ありません。
しかし、更新のタイミングで(1)-(3)のいずれかが死んでいると、もう更新が不可能になります。

POSTDの場合では(1)=(2)のために構成要素が1個少なくなりますが、案件サイトのようにCMSが別になると事故率が上がるケースも有りえます。

逆に動的サイトの場合は(2)-(4)が同一基盤としての動作が期待できます。
もちろん基盤の死=サイトの死ではあるもの、ボトルネックとしては逆に少ないと捉えることもできます。

まとめ

SSGを利用したサイト制作は、得られる恩恵は十分にあるものの、万能ではありません（当たり前ですが）。
時にWordPressなどでの提案を含めて「選択肢の1つ」であることを留意する必要があるでしょう。

どちらも基盤情報等はもうちょっと複雑ですが、記事に必要なごくごく最低限の要素のみ記載しています ↩
カテゴリー類が164個あり、さらにビルド時には全記事版や特定タグ版のページネーションされたアーカイブまで登場します。 ↩