GitHub PagesとCloudflare Pages比較 — 静的サイト配信の選び方

静的サイトの公開先を選ぶときは、単純な表示速度だけでなく、デプロイ方法・プレビュー環境・配信制御・将来の動的機能・運用の複雑さを比較します。

数値やプランは変更されることがあります。本稿の制限値は2026年9月時点の公式ドキュメントを基準にしています。導入時には必ず最新情報を確認してください。

最初に整理する3つの構成

「Cloudflareを使う」という表現には、異なる構成が含まれます。

1. GitHub Pagesだけで配信

Browser
  └─ GitHub Pages edge
       └─ Static HTML / CSS / JavaScript / Images

Gitのbranchから静的ファイルを公開する、最も単純な構成です。GitHub Pagesはcustom domainとHTTPS enforcementに対応しています。

2. Cloudflare Pagesへ移行

Browser
  └─ Cloudflare Pages
       └─ Static assets
       └─ Pages Functions（必要な場合だけ）

hosting先そのものをCloudflareへ変更します。Git連携、preview deployment、CloudflareのDNS・Rules・Workers ecosystemをまとめて使えます。

3. GitHub Pagesの前段にCloudflareを追加

Browser
  └─ Cloudflare proxy / CDN
       └─ GitHub Pages edge
            └─ Static assets

hostingはGitHub Pagesのまま、Cloudflareをreverse proxyとして追加する構成です。WAFやcache ruleを利用できますが、CDNが二重になるため、cache・TLS・障害の切り分けは複雑になります。

機能比較

主な制限を比較する

GitHub Pages

GitHub Pagesの公式制限では、主に次の基準が示されています。

• 公開サイトは最大1 GB
• 月100 GBのsoft bandwidth limit
• deploymentは10分でtimeout
• buildはsoft limitとして1時間あたり10回。ただしcustom GitHub Actions workflowによるbuildには適用されない

通常のportfolioや技術文書では十分大きな枠です。上限に近づいた場合、GitHubは第三者CDNや別hostingへの移行も選択肢として案内しています。

Cloudflare Pages

Cloudflare Pagesの公式制限では、Free planに次の基準があります。

• 月500 builds
• build timeoutは20分
• 1 siteあたり20,000 files
• 1 assetあたり最大25 MiB
• 1 projectあたり100 custom domains

Pages Functionsの料金説明では、Functionsを通らないstatic asset requestはFree・Paidとも無料かつ無制限です。Functionsを使うrequestはWorkersのquota・料金体系で計算されます。

Cloudflare Pagesが強いところ

Preview deployment

Git連携したCloudflare Pagesでは、branchやpull requestごとにproductionへ影響しないURLを作れます。previewには既定でX-Robots-Tag: noindexが付与され、検索結果の重複も抑えられます。

• Git integration
• Preview deployments

デザイン確認や記事レビューをproduction公開前に行いたい場合に有効です。

Edge機能への発展

Pages Functionsを利用すると、専用serverを管理せずに次の機能を追加できます。

• form受付
• authentication
• middleware
• API endpoint
• Workers KV・D1・R2等との連携

ただし、静的サイトに必要のないFunctionsを追加すると、security boundary、料金、障害点も増えます。必要になった機能だけを追加します。

DNSとRulesの統合

Cloudflare Pagesをapex domainで利用する場合、そのdomainをCloudflare zoneへ追加し、authoritative nameserverをCloudflareへ向けます。subdomainだけなら外部DNSからCNAMEで接続できます。詳しくはCustom domainsを確認してください。

DNSを移管すると、redirect、WAF、cache、DNSSECなどを同じ管理画面で扱いやすくなります。一方、DNS変更の影響範囲が大きくなるため、mail用recordやdomain verification recordまで事前に棚卸しする必要があります。

GitHub Pagesが強いところ

構成が単純

静的ファイルをGitで管理して公開するだけなら、GitHub Pagesは部品が少なく、障害調査も容易です。

Source / generated files
  └─ Git push
       └─ GitHub Pages deployment
            └─ Public site

DB、authentication、form、server-side APIがないサイトでは、この単純さ自体がsecurityと保守性の利点になります。

GitHub中心の運用と相性がよい

repository、Actions、Pages deployment、rollback対象のcommitをGitHub内で確認できます。公開物をGitのcommitとして固定したいdocumentationやportfolioに向いています。

選定フロー

次の順番で判断します。

完全な静的サイトか？
  ├─ Yes
  │   ├─ PR previewやCloudflare Rulesが必要か？
  │   │   ├─ No  → GitHub Pages
  │   │   └─ Yes → Cloudflare Pagesを検討
  │   └─ bandwidthやfile limitに近いか？
  │       ├─ No  → 現状維持
  │       └─ Yes → CDN追加またはhosting移行を比較
  └─ No
      ├─ 小規模なedge functionで足りる → Cloudflare Pages / Workers
      └─ 常駐serverや複雑なbackendが必要 → 別のapplication hostingも比較

ケーススタディ：小規模なAstro学習サイト

AstroでbuildしたHTML・CSS・画像を配信し、login、DB、form、server-side APIを持たない学習サイトを考えます。

この段階ではGitHub Pagesを選ぶ合理性があります。

• build後は静的ファイルだけ
• attack surfaceが小さい
• Git commitをそのままrelease単位にできる
• CDN、custom domain、HTTPSがすでに利用できる
• Cloudflareを重ねても体感速度の改善が小さい可能性がある

一方、次の要件が生まれたらCloudflare Pagesへの移行を再評価します。

• 学習進捗を複数端末で同期する
• 教材検索APIを提供する
• 問い合わせや回答送信を受け付ける
• PRごとのpreviewを共有する
• WAF、rate limiting、redirect ruleを細かく制御する

移行前のチェックリスト

hostingを変更するときは、機能比較だけでなくrollbackまで設計します。

• 現在のDNS recordをすべて保存した
• custom domainの所有確認方法を理解した
• wwwとapex domainのredirect先を決めた
• canonical URLとsitemapが変わらないことを確認した
• CAA recordが新しい証明書発行元を許可している
• preview URLへnoindexが付くことを確認した
• cache purgeと更新反映の手順を決めた
• 旧hostingへ戻すDNS・deployment手順を用意した
• production切替前に一時URLで全ページを検証した

まとめ

• GitHub Pagesは、静的サイトを少ない構成要素で公開したい場合に強い
• Cloudflare Pagesは、preview、Rules、Workers ecosystemへ発展させたい場合に強い
• GitHub Pagesの前段へCloudflareを置く構成は、WAF等の目的が明確な場合に限って検討する
• 「CDNを追加すれば必ず速くなる」ではなく、現在の配信経路と必要な機能から選ぶ

まず最小の構成で公開し、実測した課題が生まれてから構成を増やすことが、静的サイト運用では重要です。