Cloudflare Pagesで公開したサイト、その後どうなっているか
以前、Cloudflare Pagesで静的サイトを無料で公開するという記事を書きました。公開するまでの手順はあの記事でひと通り書いたのですが、正直に言うと「公開してから半年後、実際どうなっているか」の方が気になる方が多いのではないかと思っています。私自身、他人のブログを読むときはそっちが気になるタイプです。
私が作っているChrome拡張「QR Send」の紹介ページ(qrsend.app)は、公開初日からずっとCloudflare Pagesで運用しています。今回はその後の運用フロー、無料枠の実際の使用感、独自ドメインまわりでハマったこと、Search Console登録までを、実際にやっている手順そのままで書きます。前回記事が「建てる」話だとすると、今回は「住み続ける」話です。
今の運用フローはこれだけです
結論から言うと、日々の更新作業はコマンド一発です。qrsend.appの実体である静的ファイル一式を編集したら、ターミナルで以下を打つだけで反映されます。
npx wrangler pages deploy pages-site --project-name=qrsend --branch=mainpages-siteのところはリポジトリ内の公開対象ディレクトリ名です。ダッシュボードを一切開かずに、ローカルで内容を確認してからこのコマンドを叩くだけで本番に反映されます。GitHub連携で自動デプロイする方法も用意されているのですが、個人開発の小さなサイトくらいの規模だと、手元で確認してからコマンド一発で反映するこのやり方のほうが、むしろシンプルで気に入っています。
デプロイにかかる時間は体感で数十秒です。差分だけがアップロードされるので、ファイル数が増えてきても極端に遅くなった実感はありません。瞬殺ですね。
デプロイのたびにプレビューURLが残るのが地味に便利
wranglerでデプロイすると、コマンドの実行結果に本番URLとは別に、そのデプロイ専用のプレビューURLも出力されます。これがhttps://<ランダムな文字列>.qrsend.pages.devのような形式で、デプロイ1回ごとに個別のURLとして残ります。
初めて使うときは気付きにくい機能なので、デプロイ後のコマンド出力は一度じっくり眺めてみてください。最初はこの仕組みをあまり意識していなかったのですが、使ってみると地味に便利です。「さっき直した表示、本番に出す前にスマホの実機で確認したい」というときに、このプレビューURLをそのままスマホで開けば、本番ドメインを汚さずに確認できます。ダッシュボードにもデプロイ履歴が一覧で残っているので、過去のデプロイに戻したくなったら該当のデプロイを選んで「本番に昇格」させることもできます。これ、意外と使えます。
無料枠、実際どうなのか
「無料枠でどこまでいけるのか」は公開前に一番気になっていたところです。Cloudflareの公式ドキュメント(執筆時点)で確認できた無料プランの上限は以下の通りです。
- ビルド回数: 月500回まで
- カスタムドメイン: 1プロジェクトあたり100件まで
- ファイル数: 1サイトあたり最大2万ファイル
- ファイルサイズ: 1ファイルあたり最大25MiB
- ビルドのタイムアウト: 20分
- 同時ビルド数: 1
qrsend.appのような紹介ページ＋コラムを何本か抱える程度の規模だと、この上限に触れそうになったことは一度もありません。ビルド回数で言えば、コラムを増やすたびに1日1〜2回デプロイする運用をしていますが、月500回にはまったく届きません。ファイル数も2万は個人サイトにはかなり余裕のある枠だと思います。
ただ、帯域幅(転送量)やリクエスト数についての明記は公式ドキュメントの中に見つけられませんでした(調べ方が悪いだけかもしれません)。Cloudflareの静的アセット配信自体はCDN経由で無制限に近い扱いだという理解で運用していますが、これは執筆時点で私が確認できた範囲の話として書いておきます。もし正確な仕様をご存知の方がいたらコメントで教えていただけると助かります。
独自ドメインへの切り替えでハマったこと
公開直後はqrsend.pages.devのようなサブドメインでアクセスできる状態でした。ここから独自ドメインのqrsend.appに切り替えたのですが、この作業で一度だけ「あれ、反映されないな」という時間を過ごしました。
手順自体はダッシュボードの「カスタムドメイン」から追加するだけのシンプルなものです。ただ、DNSレコードが自動で追加されてから実際にhttpsでアクセスできるようになるまで、体感で数分から小一時間くらいの幅がありました。私はこの待ち時間の間に「設定が間違っているのでは」と疑って何度もダッシュボードを開き直してしまったのですが、結局は待てば解決する話でした。反映まで少し待つものだと知っていれば、何も焦る必要はありません。
ドメインをすでにCloudflareでDNS管理しているなら、この待ち時間はかなり短めに済む印象です。逆に他社のレジストラでネームサーバーだけCloudflareに向けている状態だと、ネームサーバーの伝播待ちも重なるので、余裕を持ってドメイン移行のスケジュールを組んだほうがいいと思います。
デプロイで一度やらかった話
その時の失敗談です。コマンドの--project-nameを打ち間違えたまま実行してしまい、既存の別プロジェクトが新規プロジェクトとして作られかけたことが一度ありました。エンターを押した直後に「あれ、見慣れないプロジェクト名が出てきたぞ」と気付いて、慌ててCtrl+Cで止めたのですが、幸い実害はありませんでした。
この経験から、今は--project-nameを含むデプロイコマンドをシェルのエイリアスかスクリプトに登録して、毎回手打ちしないようにしています。手打ちしている限り、いつかまた同じミスをする気がしています(これは私の注意力の問題かもしれません)。個人開発でひとりで作業していると、こういう単純ミスに気付くレビュアーがいないので、コマンドを固定化しておくのは地味に効くやり方だと思います。
Search Consoleへの登録も一緒にやっておく
独自ドメインに切り替えたら、そのタイミングでSearch Console(GSC)にも登録しておくことをおすすめします。独自ドメインへの切り替えと同じタイミングでやってしまいましょう。私は以下の流れでやりました。
- Search Consoleで新しいプロパティを「URLプレフィックス」で追加(
https://qrsend.appのように) - 所有権の確認は、HTMLタグ埋め込みかDNSレコード追加のどちらかを選択。すでにCloudflareでDNS管理しているならDNSレコード追加のほうが早いです
- sitemap.xmlのURLを登録して、インデックス登録をリクエスト
ここで一つ触れておくと、インデックス登録リクエストを出してもすぐに検索結果に出るわけではありません。私の体感では数日から1〜2週間ほど待つことが多く、焦って何度もリクエストし直しても速くはならないようです(このあたりの正確な仕組みはGoogle側の話なので私も詳しくはわかりません)。気長に構えるのがいちばんです。
アクセス解析はどうしているか
Cloudflare自体にもWeb Analyticsという解析機能があるのですが、私はGoogle Analytics 4(GA4)のタグを埋め込む形で計測しています。Cloudflare Pagesは配信先が静的ファイルなので、HTMLに計測タグを1行足してデプロイするだけで済みます。サーバー側の設定変更が要らないぶん、この手軽さは地味にありがたいです。
アクセスが増えてきたときにCPUやメモリを気にする必要がないのも、静的サイトならではの気楽さだと思います。ここは動的なアプリケーションのホスティングとは根本的に違うところで、サーバーの死活監視やスケーリングを考えなくていい分、個人開発では圧倒的に運用の手間が少なくて済みます。
運用してみて感じている限界
ここまで良いことばかり書いてきましたが、限界も書いておきます。Cloudflare Pagesはあくまで静的ファイルの配信に特化したサービスです。サーバーサイドでの動的処理(フォームの受け取り、DBへの書き込みなど)が必要になったら、Pages Functionsか、別のバックエンドを組み合わせる必要が出てきます。qrsend.appのような紹介ページ程度なら気にならないのですが、会員登録やお問い合わせフォームを持つサイトだと、そのあたりの設計は別途考える必要があります。
あとはビルド・デプロイがCLIかGit連携に寄っているぶん、非エンジニアの方が単独で更新するにはハードルがあります。私は業務でクライアントのコーポレートサイトを作ることもあるのですが、更新を担当者にお任せしたいケースでは、Cloudflare Pagesよりも普通のCMS(WordPressなど)を勧めることのほうが多いです。適材適所ですね。
費用の話
半年以上運用していますが、qrsend.appにかかっているホスティング費用は今のところゼロ円です。ドメインの年間更新料は別途かかりますが、それはどのサービスを使っても発生する費用なので、Cloudflare Pages固有のコストではありません。別の案件でVPSを借りてNginxを自分で設定していたことがあるのですが、そのときは月額費用に加えてOSのアップデートや証明書の更新も自分の作業として発生していました。qrsend.appではその手間がまるごとなくなっていて、想像以上に大きい変化だと感じています。
もちろんアクセスが極端に増えたり、Pages Functionsを使ってサーバーサイド処理を増やしたりすれば、どこかで有料プランを検討することになるはずです。ただ、個人開発の紹介ページやコラムサイト程度の規模であれば、無料のまま運用を続けられる可能性が高いと感じています。
迷っているなら一度試してみる価値はある
個人開発のサイトをどこで公開しようか迷っている方がいたら、一度試してみてください。前回の基本セットアップ手順はこちらの記事にまとめてあるので、公開までの流れはそちらも参考にしてもらえればと思います。作っているChrome拡張の話はこちらの記事にも書いているので、興味があれば覗いてみてください。
コメント