「爆速Webサイト」の設計と実測結果

はじめに

本記事は、Webサイトを高速・軽量で、かつセキュアに運用するための構成についての実践メモです。

意識していたのは、次の3点を同時に満たすことでした。

回線品質や端末差に左右されにくく、軽快に表示できること
大量アクセス時にも、サービスを継続しやすい構造であること
Webサイト改竄が成立しにくく、運用者が守りやすいこと

「爆速」を狙ったというより、壊れにくく、守りやすい構造を突き詰めた結果として速くなったという位置づけになります。

本記事では、実際に採用した構成と、その判断理由、実測結果を紹介します。

採用したアーキテクチャ

今回構築したWebサイトでは、Jekyll による静的サイト生成と
Cloudflare Pages + GitHub による自動ビルド／デプロイを組み合わせた構成を採用しています。

コンテンツは Jekyll の Markdown 形式で作成し、GitHub リポジトリで履歴管理しています。
リポジトリへの更新をトリガーに Cloudflare Pages が Jekyll ビルドを実行し、静的HTMLを生成したうえで CDN へ自動デプロイします。

配信は Cloudflare の CDN エッジで完結し、ページ表示時にサーバサイドで実行される処理は存在しません。

この構成により、

配信が分散され、アクセス集中の影響を受けにくい
キャッシュが効きやすい
更新経路が限定され、改竄リスクを抑えやすい

といった特性が得られます。

なぜこの構成にしたのか

この構成を選んだ理由は、配信時はできるだけ単純に保ちつつ、更新や運用の手間は増やさないことを重視したためです。

アクセス時の処理負荷が特定のサーバやコンポーネントに集中しないよう、CDN を前提とし、ページ表示時にサーバサイドの処理を発生させない静的Webサイト構成を選びました。

一方で、完全な静的HTML運用では更新作業が煩雑になりやすいため、静的サイトとして完結しつつ、CMSに近い運用感を得る手段としてJekyll による静的Webサイト生成を採用しています。

JekyllによりMarkdown でコンテンツを管理し、レイアウトや共通パーツを分離することで、ページの追加や修正を比較的容易に行える構成としています。

また、Webコンテンツのバージョン管理のため GitHub を採用し、GitHub リポジトリと Cloudflare Pages を連携させることで、CDN へのコンテンツデプロイを自動化しています。

実測結果（PageSpeed Insights）

以下のURLで PageSpeed Insights による計測を行いました。

測定URL
https://pagespeed.web.dev/
対象ページ：https://humanhistories.org/ja/

本記事では、スコアそのものを最適化対象とするのではなく、

大きなボトルネックがないこと
構造上の判断（CDN完結・静的配信）が妥当であること

を確認する目的で、この結果を参照しています。

単発の数値ではなく、構造として安定した挙動になっているかを見る位置づけです。

本構成では、リクエスト時にサーバサイド処理が発生せず、配信の大部分がCDNキャッシュで完結するため、PageSpeed Insights 上でも安定した評価が得られています。

実際の構成と運用

設計方針

実運用では、以下の方針を軸に構成しています。

CDN前提：配信は Cloudflare CDN で完結
静的生成：Jekyll による事前ビルド
JS最小：ナビゲーション等の補助用途のみ
自動デプロイ：GitHub への push を起点に自動反映

特定の最適化テクニックに依存せず、構造そのものを単純に保つことを重視しています。

ディレクトリ構成

実際の構成を、再現しやすい形に簡略化すると以下のようになります。

/
├─ _includes/            # 共通パーツ
├─ _layouts/             # レイアウト
├─ _data/                # データ（必要に応じて）
├─ assets/               # 静的アセット（CSS/画像など）
│  ├─ css/
│  └─ images/
├─ pages/                # コンテンツ（言語別に管理）
│  ├─ en/
│  ├─ ja/
│  └─ ...（他言語）
└─ ビルド成果物ディレクトリ/ # ビルド成果物（配信対象）
   ├─ assets/
   ├─ en/
   ├─ ja/
   └─ ...（他言語）

pages/ 以下をソースとして管理し、jekyll build によりビルド成果物ディレクトリ以下に静的ファイルを生成します。

Cloudflare Pages 側の設定

Cloudflare Pages では、GitHub リポジトリを接続した上で、以下の設定のみを行っています。

ビルドコマンド
bundle exec jekyll build
ビルド出力ディレクトリ
ビルド成果物ディレクトリ

これにより、GitHub に push が行われるたびに、

Cloudflare Pages がリポジトリを取得
Jekyll によるビルドを実行
ビルド成果物ディレクトリ 以下に生成された静的ファイルをグローバルな CDN エッジへ自動デプロイ

という流れが自動で実行されます。

全体手順

本構成は、特別なインフラやサーバ運用を必要とせず、比較的シンプルな手順で再現できます。
以下は全体像を掴むための俯瞰です。

Cloudflareでドメイン取得
- Cloudflare Registrar でドメインを取得（または移管）
- DNS を Cloudflare に集約し、CDN 前提の構成にする
GitHubでリポジトリ作成
- 静的サイトのソース（Jekyll 等）を管理するリポジトリを作成
- 更新はすべて GitHub 経由に集約する
Cloudflare Pages連携
- GitHub リポジトリを Cloudflare Pages に接続
- push をトリガーに自動ビルドが走るよう設定する
push → 自動デプロイ → CDN反映
- 管理者が GitHub に push
- Cloudflare Pages がソースを取得してビルド
- 生成された静的ファイルがグローバル CDN エッジに反映される

成果物

サイトURL
https://humanhistories.org/
補足
非営利目的で運営しており、広告やトラッキングは最小限にしています。

謝辞

Jekyll 環境構築にあたっては、以前長らく一緒に仕事をさせていただいた技術者の方（現在は企業の代表を務めておられる方）に多大なご協力いただきました。
ここに感謝の意を表します。

まとめ

配信時は静的HTMLのみとすることで、
高速かつセキュアで、可用性を高めやすい構造を実現できた
Jekyll＋GitHub＋Cloudflare Pages により、
履歴管理・自動デプロイを備えた、CMSに近い運用が可能になった
PageSpeed Insights を用いることで、
構造設計が妥当かを客観的に検証できる