OJapp Petal を作り始めて 3か月。最初は GitHub Pages を使って開発していました。 「無料で使える」「簡単に公開できる」「静的サイトなら十分」──そう思っていたけど、Petal の機能が増えていくほど、GitHub Pages の限界に何度もぶつかるようになりました。
この記事では、実際に開発しながら感じた “GitHub Pages 卒業ポイント” と、 Worker + R2 に移行したことで得られた圧倒的な快適さをまとめます。
GitHub Pages で感じた限界
① 更新しても反映されない（反映まで数分〜数十分）
Petal の UI を直したり、テキストを微調整したりしても、GitHub Pages はすぐに反映されません。 反映されたとしても、ブラウザ側のキャッシュ・iOS の影キャッシュ・GitHub の反映遅延が重なって、 「直ってるのか直ってないのか」すらわからない時間が続く。
開発スピードが完全に止まる瞬間が多かったです。
② キャッシュの二重地獄（Safari × GitHub）
iOS Safari のキャッシュは強力で、WebClip（ホーム画面アイコン）だとさらに更新されにくい。 そこに GitHub Pages の “遅延更新” が重なると、 「本番が古いまま」「手元のコードは新しい」「どっちが本当？」 という混乱が生まれる。
Webツール開発者としては、致命的な開発ストレスでした。
③ 動的処理ができない
Petalでは、 ・ユーザー認証 ・画像アップロード ・公開/非公開の切り替え ・承認フロー などが必要になります。
これらは静的サイトの GitHub Pages では不可能。 API を別場所に作り、構成が複雑になるのも大きな理由でした。
Worker + R2 を使ってみたら、世界が変わった
① 更新が即時反映（0.1秒〜数秒）
Cloudflare Worker にコードをデプロイすると、 ほぼリアルタイムで世界中に反映されます。
GitHub の「更新されてるか謎」な時間が完全に消え、 一気に開発スピードが2〜3倍になりました。
② API がネイティブに作れる
Petal の ・ユーザー情報 ・Petal 投稿データ ・承認ステータス などはすべて Worker 上の API と D1 / R2 で処理しています。
「静的サイトに無理矢理 API を付ける」のではなく、 最初から API 前提で構築できるのが本当に楽。
③ 画像は R2 に置くだけで高速＆安定
Petal は “1人1投稿・画像必須” という仕組みなので、画像ストレージが重要です。
R2 に置いた瞬間、 ・読み込み高速 ・容量ほぼ気にしなくていい ・コストも激安 になり、GitHub のブロブ管理のストレスがゼロになりました。
④ iOS の影キャッシュ問題がほぼ解決
Worker を使うと、レスポンスヘッダでキャッシュ制御ができるため、 iOS 特有の “古いアイコンを読み続ける問題” が激減しました。
GitHub Pages ではどうにもならなかった部分なので、ここが最大のメリットかもしれません。
Petal の成長に合わせて、仕組みも成長していく
GitHub Pages は「静的ページを置く場所」としては最強ですが、 Petal のような ユーザー参加型・画像投稿型・承認管理型 のサービスには限界がありました。
Worker + R2 に移行したことで、 ・本番反映の速さ ・動的API ・キャッシュ制御 ・ストレージの拡張性 が揃い、Petal の開発は次のフェーズに進めるようになりました。
まとめ：GitHub Pages は卒業。Petal の未来のために Worker へ
GitHub Pages は本当に素晴らしいサービスです。 最初のOJappも、ここから始まりました。
でも、Petal の仕組みが成長するにつれて、 「静的サイト」から「サービス」へ進む必要が出てきた。
Worker + R2 への移行は、 そのタイミングが来たというだけの話です。
ここから Petal は、 もっと速く、もっと自由に進化できる。 そんな環境にやっと辿り着けました。
