静的サイト

原稿と部品から公開ファイルを作り、閲覧時は完成品を配る生成する時点と配信する時点を分けて考える

公開までと閲覧時では処理が違う

1. 原稿を管理するMarkdown、CMS、表計算、画像など、編集しやすい形で内容を持つ。
2. ビルドするテンプレートへ原稿を流し込み、HTML、CSS、JavaScript、画像を生成・最適化する。
3. 検査するリンク、画像、文字化け、画面幅、アクセシビリティ、不要ファイルの混入を確かめる。
4. 配備する完成した公開用ファイルだけを文書ルートやオブジェクトストレージへ配置する。
5. そのまま配信する要求されたパスに対応するファイルをWebサーバーやCDNが返す。

静的でも画面は動かせる

CSSのアニメーション、menuの開閉、検索、入力確認などは、配信後にブラウザーで動きます。JavaScriptがAPIからデータを取得し、表示を書き換えることもできます。配信されたHTMLがあらかじめ完成していることと、画面が動かないことは別です。

ただしJavaScriptで毎回APIを呼び、利用者別データを表示する部分は動的です。一つのサイトの中に、静的に配る部分と動的に取得する部分が共存します。

ソースと公開成果物を分ける

テンプレート、原稿、ビルドスクリプト、設計の元データはソースです。公開するHTML、CSS、JavaScript、WebPなどはartifact（アーティファクト、成果物）です。ソースに秘密鍵、接続パスワード、非公開原稿があれば、公開フォルダーへ複製しない構成にします。

この区別があると、同じソースから何度でも成果物を作れます。公開中のファイルを直接手直しすると、次回ビルドで消えたり、修正の由来が分からなくなったりします。

URLは配置パスと一緒に設計する

/glossary/term-192/のようなURLへ、glossary/term-192/index.htmlを対応させる構成があります。どのURLをどのファイルへ結び付けるかはWebサーバーの索引設定や書き換えにも左右されます。

/assets/site.cssのようにスラッシュから始まるルート相対URLは、ドメインのルートを基準にします。file://でHTMLを直接開いた場合はWebサーバーのルートがないため、見つからないことがあります。ローカル確認ではHTTPサーバーを使うと公開時のパス解決に近づきます。

キャッシュとCDNを利用しやすい

同じURLへ同じ内容を返しやすいため、ブラウザーキャッシュやCDNへ保存しやすい方式です。画像やCSSのファイル名へ内容ハッシュを付ければ、変更時は新しいURLになり、古いキャッシュとの混在を避けられます。

HTMLまで長期間キャッシュすると、更新しても古い入口が残ることがあります。HTMLは短め、ハッシュ付き資産は長めなど、役割でCache-Controlを分けます。

問い合わせやログインは別の処理へ渡す

フォームの送信先、検索API、決済、認証などは、serverless機能や外部サービスへ任せられます。静的サイト自体にアプリケーションサーバーがなくても機能は追加できます。

ブラウザーへ届くJavaScriptやAPI鍵は利用者から見えます。公開してよい識別子と、サーバーだけが保持すべき秘密情報を分け、重要な認可をブラウザー任せにしません。

更新は一組として切り替える

HTMLだけ先に更新し、参照先のCSSや画像がまだないと表示が崩れます。リリースごとに一式を作り、検査済みバージョンへまとめて切り替えるatomic deployment（アトミック・デプロイメント）が安全です。

戻すときも過去の一式へ切り替えます。問い合わせAPIやCMSのスキーマを同時変更する場合は、前後バージョンの双方から扱える移行順を設計します。

攻撃面は減るが、無条件に安全ではない

閲覧ごとにサーバーコードやデータベースを動かさないため、SQL注入やサーバー側コード実行の入口は減らせます。一方、第三者スクリプト、古いJavaScript依存先、改ざんされたビルド環境、公開フォルダーへの不要ファイル混入は残ります。

静的サイトの強みは「内容が単純」ではなく、重い生成処理を公開前へ移し、閲覧時に配るものを明確なファイル一式へ絞れることです。

静的file配信とHTTP cacheの確認資料：Apache HTTP Server「Getting Started」、RFC 9111「HTTP Caching」