Webサイトホスティングで使うCloudflare Workers 第1回 Workersでサイトを配信する仕組み
Cloudflareは、新規に構築するサイトのホスティングにCloudflare Workersを推奨しています。このシリーズでは、AstroやNext.jsで構築したサイトをWorkersにデプロイし、運用するまでを解説します。第1回は、PagesとWorkersの違いと、Workersでサイトを配信する全体像を整理します。
- カテゴリー
- Webサービス >
- Cloudflare Workers
発行
はじめに
Cloudflareが提供するホスティングサービスというと、まずCloudflare Pagesが思い浮かぶ方は多いのではないでしょうか。CodeGridにも、2021年に公開された「ホスティングサービスCloudflare Pages」というシリーズがあります。
Cloudflare PagesがWebサイトのホスティングサービスであり、GitHubと連携して手軽にサイトを公開できる……というのは2026年現在も変わりないのですが、Cloudflareはこれから新規のサイトをホスティングするのであれば、Cloudflare Workersを選ぶことを推奨しています。
このシリーズでは、まずPagesとWorkersの現状や特徴を押さえ、AstroやNext.jsで作ったサイトをCloudflare Workersにデプロイし、運用していくまでを扱います。第1回となる今回は、PagesとWorkersでできること、「どこに何を置いて配信するのか」というサービスの全体像を整理していきます。
WorkersとPages、どちらを選ぶか
これから新しくWebサイト（Webアプリケーション）を公開するのであれば、基本的にはCloudflare Workersを選んでください。Cloudflare自身が、新規プロジェクトにはWorkersを使うことを推奨しています。公式ドキュメントにはPagesからWorkersへの移行ガイドも用意されています。
現在Pagesでホスティングしている場合は？
すでにPagesでサイトを運用している場合は、急いでWorkersに移行する必要はありません。Cloudflareから、Pagesのサービスを終了するというアナウンスはされていませんし、数多くのサイトで利用されていることを踏まえると、当面はサービスは維持されると考えるのが自然です。
ただし、新しい機能の追加はWorkersが中心になるということは公表されています。現時点でも、ログの確認や、Cloudflareのほかのサービスとの連携機能などはWorkersのほうが充実していますので、移行コストとメリットを比較し検討してみるのもよいかもしれません。
Workersが推奨されるようになった経緯
Pagesは、静的ホスティングのサービスとして登場しました。後からPages Functionsが加わってサーバー処理も書けるようになりましたが、出発点はあくまで静的サイトの配信です。また、Pagesには、Gitリポジトリと連携した自動ビルドやブランチごとのプレビューURLといった機能があります。
一方のWorkersは「リクエストに応答するコードを置く場所」でしかなく、サイト丸ごとというよりは、APIや認証ゲートなどの用途が出発点でした。CodeGridにも「サーバーレス実行環境Cloudflare Workers」という2021年公開のシリーズがあります。
その後、Workers側にPagesの機能が追加されていきました。静的ファイルを配信するStatic Assets、Gitリポジトリと連携してビルド・デプロイを行うWorkers Builds、そしてプレビューURLも発行できるようになりました。内部ではPagesはWorkersの上で動いているそうで、ユーザーの要望やフレームワークの進歩などを踏まえて、Workersに機能を集約する選択をしたのかもしれません。
Workersでできること
現在のWorkersでできることは、大まかに、コードの実行と静的なファイルの配信の2つです。この2つのどちらか、あるいは組み合わせでWebサイトを配信します。
コードを実行する
前節でも触れましたが、Workersはもともと「リクエストに応答するコードを置く場所」で、つまりはJavaScriptを実行することでリクエストを処理してレスポンスを返します。ということは、リクエストに応じてレスポンスを変えることもできるわけで、これによってSSRでのサイト配信が可能になります。
ただし、JavaScriptの実行ランタイムはNode.jsではありません。Workersのコードを実行しているのは、workerdという、Cloudflareが開発しているオープンソースのJavaScriptランタイムです。
補足：workerdの読み方と名前の由来
workerdは「ワーカーディー」と読みます。末尾の「d」は、Unixで常駐してリクエストを待ち受けるプログラム（デーモン）の名前を「d」で終わらせる慣習にならったものです。プログラム名を小文字で書くのもUnix系の慣習で、workerdの先頭を大文字にしないのはそのためです。
このランタイム自体の詳しい説明は省きますが、実行環境が軽量で、起動が非常に速いという特徴があります。
注意：Node.jsではないということ
Node.jsではないということは、JavaScriptの標準的な機能は使えますが、npmパッケージが何でも使えるというわけではないので、注意が必要です。nodejs_compatというフラグを有効にすると、Node.js APIの多くも使えるようになりますが、すべてをカバーしているわけではありません。
静的ファイルをWorkersで配信する
コードの実行環境からスタートしたCloudflare Workersですが、静的なファイルの配信もサポートするようになりました。Static Assetsという機能です。
静的アセットとして指定したファイルは、内容がそのまま返され、実行環境であるworkerdが起動することはありません。SSGでのサイト配信はこの機能を使って行われます。
つまり、Cloudflare Workersでサイトを配信する場合、SSRもSSGも可能ということです。詳細は後述しますが、AstroやNext.jsなど、SSRをサポートするフレームワークで構築したサイトを、PagesだけではなくWorkersにもデプロイできるのはこういった背景があるためです。
フレームワークとアダプター
さて、このシリーズではAstroやNext.jsといったフレームワークで構築したサイトを、Cloudflare Workersにデプロイ・運用するまでを解説していきます。これらのフレームワークはSSGもSSRもサポートしますが、前節でお話ししたworkerdやStatic Assetsとの関係は次のようになります。
SSGのみのサイト
workerdを起動する必要はなく、すべてStatic Assetsということになります。ビルドしたHTMLやCSSがどのディレクトリにあるかを指定するだけでサイトが配信できるので、もっともシンプルです。
SSRを含むサイト
SSRのみ、あるいはSSGとのハイブリッド構成の場合、「アダプター」と呼ばれるライブラリが必要です。詳しいことは次回以降に取り上げますが、フレームワーク側あるいはCloudflare側がアダプターを開発・提供しています。このアダプターがworkerd上で動くコードを生成し、リクエストに応じてページをレンダリングして返してくれるわけです。アダプターのなかには、Cloudflare Pagesのサポートを打ち切ったものもあり、この点からも、やはり新規にサイトをデプロイするのであれば、Workersを選ぶのがよいです。
補足：その他のレンダリング方式
Cloudflare Workersでは、Next.jsのISR（Incremental Static Regeneration：インクリメンタル静的再生成）もアダプターがサポートしています。ただし、個々の機能についてのアダプターの対応状況、キャッシュの取り扱いなど、Vercel環境に比べると考慮しなければいけない点が増えてしまいます。
パフォーマンスと料金
Cloudflare Workersはサーバーサイドのなかでもユーザーのアクセス元に近いエッジで動作しています。SSRでのページ生成や、SSGの静的リソースの配信もエッジで行われるわけですから、レスポンスが速いという特徴をもちます。
料金面では、Cloudflareの無料プランから利用可能です。1日10万件のリクエストと、リクエストごとに10msのCPU時間が無料枠に含まれますので、個人サイトや小規模なプロジェクトであれば、無料枠に十分収まるでしょう。なお、この制限はworkerdが起動する場合のもので、Static Assetsのみ、つまりすべてSSGのサイトであれば、どんなにアクセスが増えても料金はかかりません。
ここまでのまとめ
今回は、Cloudflare Workersの概要や、Pagesとの違いについてお話ししました。次回は、フレームワークで構築したサイトを公開するまでの手順を追いながら、運用上のポイントなども紹介していきます。