wanwangaogao

← Blog 一覧

個人開発の小さなサイトに Cloudflare Pages を選んだ理由

by wanwangaogao 読了 6 分

個人開発の作品ページや小さなブログを置く場所として、選択肢はいくつもあります。Vercel、Netlify、 GitHub Pages、Render、Fly.io、自前 VPS、いっそ S3 + CloudFront、AWS Amplify、Firebase Hosting。 どれも動きますが、「自分にとってのデフォルト」を 1 つ決めておくと、新しい小さな実験をはじめるたびに 場所を悩まなくて済むようになります。今回その「デフォルト」を Cloudflare Pages に決めました。 理由を整理しておきます。

1. 静的ホスティングの料金が実質ゼロ

Cloudflare Pages の Free プランは、静的サイトについて帯域無制限・リクエスト数無制限です。 月のビルド回数 500 まで、同時ビルド 1 という縛りはあるものの、個人サイト規模なら踏むことはまずない。 Vercel の Hobby プランは「商用利用は不可」という条項があり、AdSense を貼った瞬間グレー寄りになる という議論があるため、商用判定で悩まずに済む点でも Cloudflare は気が楽です。

2. Functions が同じプロジェクトに同居できる

静的サイトに「お問い合わせフォーム」のような少しだけサーバーが要る部品を足したいとき、 別プロジェクトを立てなくていいのが効きます。functions/api/contact.ts を置けば、 /api/contact に POST が来た時だけ Cloudflare Workers 上で実行される、それだけです。 

// functions/api/contact.ts (抜粋)
export const onRequestPost = async (context) => {
  const form = await context.request.formData();
  // …MailChannels で送信
  return Response.redirect('/contact/thanks.html', 303);
};

ビルド設定も None でよく、Output directory に public を指定するだけ。 フレームワークなしの素の HTML プロジェクトと相性が良いです。

3. メール送信に MailChannels がそのまま使える

Cloudflare Workers / Pages Functions から https://api.mailchannels.net/tx/v1/send へ POST すると、追加のサインアップなしでメールが送れます。アクセスキーは不要で、SPF / DKIM を ドメイン側で設定しておけば「自前ドメインから自分のメールアドレスへ転送」がほぼゼロ円で完成します。 小さなお問い合わせフォーム 1 つのためだけに SendGrid アカウントを発行する手間が省けるのは大きい。

4. デプロイ速度・地理分布

Cloudflare のエッジ網は世界 300 都市超に分散しています。日本国内からアクセスしても、東京・大阪の エッジから即時に応答が返るので、TTFB が他のホスティングと比べて体感で明らかに速い。 Lighthouse の Performance スコアが何もしなくても 95 以上になりやすく、AdSense 審査の「サイトの操作性」 という観点でも有利に働きます。

5. プレビューデプロイが PR ごとに勝手にできる

GitHub と連携しておくと、PR を作るたびに固有 URL の Preview Deploy が自動で生成されます。 codex にレビューを依頼するとき、コメント欄に Preview URL を貼っておけば、「コード」と「実際の見た目」を 両方確認した上で指摘してもらえるので、修正のサイクルが短くなります。

6. 制約も正直に書いておく

Cloudflare Pages を選ぶ上で頭に入れておくべき制約もあります。

  • Pages Functions は Cloudflare Workers ランタイム上で動くので、Node.js API がすべて使えるわけではない。 Web 標準（fetch、Request、Response、FormData）で書く。
  • 長時間のレスポンス（30 秒超）は向かない。お問い合わせフォーム程度なら問題なし。
  • 環境変数の「Production / Preview」が別管理。Production にだけ Secret を入れ忘れる事故が起きやすい。
  • カスタムドメインの DNS が Cloudflare 上にない場合、CNAME を手動で *.pages.dev に向ける手順が増える。

7. AdSense 審査との相性

Cloudflare Pages はデフォルトで HTTPS、独自ドメインも HTTPS 化が自動。AdSense 審査要件の 「HTTPS で配信されていること」をクリアするのに何も追加作業が要りません。 広告タグを貼った後の表示速度低下も、エッジ配信のおかげで比較的緩やかです。

結論: 個人開発のデフォルトとしては十分すぎる

フレームワーク必須のフロントエンドで Server Components や ISR を多用する大きめプロジェクトなら Vercel の方が嬉しい場面もあります。ただ、個人開発の「ちょっとした作品集」「ちょっとしたブログ」「ちょっとしたフォーム」 の三点セットを置くだけなら、Cloudflare Pages は今のところいちばん引っかかりが少ない選択肢でした。 このサイト自体がその実証実験です。

次回は、お問い合わせフォームの functions/api/contact.ts の中身、MailChannels の SPF / DKIM 設定、 Cloudflare Turnstile による軽量スパム対策のあたりを書く予定です。