静的サイトジェネレーターとは:このブログがAstroで動く理由
このブログの裏側を何度か話題にしてきましたが、本体の説明がまだでした。余白LABはWordPressではなく、Astroという道具で動いています。分類でいうと静的サイトジェネレーター。名前は堅いのですが、やっていることは台所の話に近い。今回は自分のサイトを教材に、この道具の正体を説明してみます。
静的サイトジェネレーターは、公開前に全ページのHTMLを「作り置き」しておく道具で、Astroはその代表格のひとつです。
「注文ごとに調理」か、「作り置き」か
Webサイトの作り方は、大きく2つの流儀に分かれます。
WordPressのような方式は、レストランの厨房です。訪問者がページを開くたびに、サーバーの中でプログラムがデータベースから材料を取り出し、その場でページを組み立てて出します。注文ごとの調理なので、訪問者に合わせて中身を変えられる代わりに、厨房(サーバー内のプログラムとデータベース)を常に動かし続け、守り続ける必要があります。
静的サイトジェネレーター(SSG)は、お弁当の作り置きです。MDNの定義によれば、SSGとは「静的ウェブサイトを生成するためのソフトウェア」で、MarkdownやHTMLで書いたコンテンツを、ブラウザでそのまま表示できる最適化された静的ファイルの束にコンパイルします※1。でき上がったサイトにはサーバー側の処理がなく、誰がどのURLを開いても同じものが返る。だから高速で、攻撃される面が少なく、CDN(世界中の配信網)からばらまきやすい※1。厨房ごと公開するのではなく、完成品だけを店頭に並べる方式です。
Astroという道具:コンテンツのための設計
SSGにはJekyll、Eleventy、Docusaurusなど多くの道具があり、Astroもその代表例のひとつとしてMDNに名を連ねています※1。では数ある中でAstroは何者なのか。
公式ドキュメントの自己紹介は明快で、「ブログやマーケティング、eコマースなど、コンテンツ駆動のウェブサイトを作成するためのウェブフレームワーク」と定義しています※2。設計原則の筆頭も「コンテンツ駆動」で、「サーバーファースト(HTMLはサーバー側で描画)」「デフォルトで高速」が続きます。特徴的なのは「デフォルトでJavaScriptゼロ」という思想で、飾りのプログラムを極力送らず、余計なものを削ることで「Astroで遅いウェブサイトを作成することは不可能であるべき」とまで書いています※2。
Webアプリを作るための道具がひしめく中で、「うちは読みものサイト専門です」と割り切っているわけです。記事を読んでもらうことがすべての当ブログにとって、この割り切りがちょうどよいサイズ感でした。
このブログでの実際の流れ
余白LABでの使われ方を具体的に示すと、こうなります。
① 記事を書く src/content/blog/記事名.md (Markdown+冒頭に題名や日付)
② ビルドする npm run build という命令ひとつ
③ 完成品が出る dist/フォルダに全ページのHTML(現在24ページ)
人間(とAI)が日常的に触るのは①だけです。Markdownファイルを1つ置いてビルドすると、記事ページだけでなく、トップの新着一覧、カテゴリー別ページ、目次、RSS、サイトマップ、検索エンジン向けの構造化データまで、テンプレートが全部作り直してくれます。公開後はGitHubと連携させるので、「書いて保存(push)すると、ホスティング側が勝手にビルドして公開する」ところまで自動になります。
そして、これは狙ったわけではなかったのですが、主要なAIクローラーはJavaScriptを実行せず、最初のHTMLに入っている本文しか読めないことが調査で報告されています※3。全ページを完成したHTMLとして作り置きするSSGの出力は、この条件をはじめから満たしています。コンテンツをMarkdownという素のテキストで持つことも含めて、AIと共同でサイトを運営するうえで、作り置き方式は結果的にかなり筋のよい選択でした。
苦手なことも、もちろんある
公平のために、作り置きの弱点も書いておきます。仕組み上、内容を変えるにはビルドのやり直しが必要です。1日に何百回も更新があるニュースサイトや、在庫が刻々と変わるECには向きません。また、コメント欄、サイト内検索、会員ページのように「訪問者ごとに中身が変わる」機能は、静的ファイルだけでは実現できず、外部サービスやJavaScriptで補うことになります。
つまりWordPressがWebの4割を支えているのには、それだけの理由があるということです。注文ごとに調理すべきサイトは世の中にたくさんあります。個人の読みものブログという、更新頻度が低く、全員に同じものを見せるサイトだからこそ、作り置きが最適解になる。道具の優劣ではなく、料理と客層の相性の話です。
調べても分からなかったこと
- 静的サイトジェネレーターで作られたサイトが全Webに占める割合。CMSのシェア統計(W3Techs)は確認できるのですが、SSG横断の利用率をまとめた信頼できる統計には今回たどり着けませんでした。
- Astro自体の利用サイト数の公式な数字。開発者アンケートでの人気は見かけるものの、実利用数の一次データは見つけられませんでした。
まとめ:弁当屋には弁当屋の合理性
静的サイトジェネレーターは、公開前に全ページを作り置きする道具です※1。速い・安全・配りやすいという利点はすべて「本番では何も調理しない」ことから来ていて、その代わりに更新のたびのビルドと、動的な機能の外注が必要になります。Astroはその中でも「コンテンツ駆動」に割り切った設計で※2、読みもの中心のサイトとは相性が良い。
このブログの場合は、そこにAI時代の偶然の追い風(クローラーは完成品のHTMLしか読めない※3)まで吹きました。次にどこかで「このサイト、何で作ろう」という話になったら、まず「注文調理が必要か、作り置きで足りるか」から考えてみてください。案外それだけで、答えは半分出ています。
参考文献・出典
※1 : 「Static site generator (静的サイトジェネレーター, SSG) - 用語集」 |MDN Web Docs https://developer.mozilla.org/ja/docs/Glossary/SSG
※2 : 「Astroを選ぶ理由」 |Astro公式ドキュメント https://docs.astro.build/ja/concepts/why-astro/
※3 : 「The rise of the AI crawler」 |Vercel https://vercel.com/blog/the-rise-of-the-ai-crawler
よくある質問
静的サイトジェネレーター(SSG)とは何ですか?
MarkdownやHTMLで書いたコンテンツを、ブラウザでそのまま表示できる静的ファイル(HTML・CSS・JavaScript)の束に変換するソフトウェアです。サーバー側で毎回ページを組み立てないため、高速で、セキュリティリスクが低く、CDNから配信しやすいのが特徴です。
WordPressと静的サイトジェネレーターはどちらがよいですか?
一長一短です。記事の公開が中心のブログやメディアなら、速さと安全性で静的型が有利です。一方、会員機能やコメント欄のように訪問者ごとに中身が変わる仕組みが必要なら、サーバー側で動的に処理する型が向きます。用途で選ぶのが正解です。
静的サイトでは記事を更新するたびに何が起きるのですか?
記事ファイルを追加・修正すると、ビルドという工程で全ページのHTMLが作り直され、その完成品がサーバーに置き換わります。GitHubと連携したホスティングなら、保存(push)をきっかけにこのビルドと公開が自動で走るため、書き手の作業は「書いて保存する」だけになります。