フロントエンドの配信の分かれ目は、たいてい請求が動き出してから見えてくる。サイトが増え、流量が増えれば、帯域と構築の回数が新しい変数になる。Cloudflare Pages は無料の境目を別の場所に置いた。サイトと席と要求と帯域はいったん脇に置き、割当の表が本当に見張るのは構築の回数と案件の数と一つのファイルの大きさだ。

構築と配信を同じ網に載せる

Cloudflare は Pages を、チームがアプリを早く作り、共に手を入れ、試し、配備まで進められるサーバー不要の基盤と位置づける。製品のページの一言はもっと直接的で、全体のアプリは作り終えたらそのまま Cloudflare の世界の網に載る、という。配信は自社の網が担い、製品のページによればこの仕組みはインターネットの二割の流量を支える系の上で走る。企業向けの信頼性と安全性と速さは既定の設定で、HTTP/3 と QUIC と画像の圧縮と SSL は最初から使える範囲に入る。公開までの道は三つ。コードの保管の基盤につなぐか、Direct Upload で作り終えた産物をそのまま上げるか、コマンド行の道具で手元から送るかだ。静的サイトと全体のアプリは同じ配備の型を共有し、Pages Functions がサーバー側のコードを走らせる。

構築の設定は既定の一覧に任せる

コードの保管の基盤をつなぐと、押し出すたびに構築と配備が一度ずつ走る。Cloudflare はよく使う枠組みのために既定の一覧を用意しており、React、Gatsby、Next.js の静的出力、Nuxt、Qwik、Remix、Svelte、SvelteKit、Vue、Angular、Docusaurus、Hugo、Jekyll、Eleventy、VitePress、Zola が並ぶ。どの既定にも構築の命令と産物の置き場が付く。成否は終了の値で決まる。零でない値を返せば失敗の印が付き、零なら成功とみなして産物を上げる。標準の誤りの側に記録が書かれても、この判断は変わらない。根の置き場は既定で倉庫の根になり、一つの中に複数の案件を抱える倉庫のときだけ自分で指定する。産物の置き場は構築の命令が作るもので、多くの枠組みは慣例どおり public の下に落ちる。

コードの保管を経ないなら、Direct Upload が作り終えた産物をまとめて上げられる。構築の手順を自社の基盤や手元の機械に置いている場面に向く。コマンド行では一度に一つのフォルダを上げ、公式の上限は二万のファイル。画面に圧縮の束か一つのフォルダを落とす方式は一千まで。どちらも一つのファイルは 25 MiB で頭打ちになる。関数のフォルダはコマンド行と一緒に上げる必要があり、独立した worker の記述はどちらの方式でも見分けられる。

割当の表が本当に見張るもの

無料の境目は公式の表に一行ずつ書かれている。同時の構築は分かりやすい。無料は一度に一つだけ走り、Professional は五つ、Business は二十。同時の数は口座ごとに数え、一度の構築が二十分を超えると打ち切られる。月の構築の回数は順に五百、五千、二万。独自のドメインは案件ごとに百、二百五十、五百。ファイルの数では、無料は一つのサイトに二万まで置け、上の段は十万まで広がる。案件の設定で対応する環境の変数を入れておく必要がある。一つの資源のファイルは 25 MiB が上限。予備の配信と協力する利用者はどちらも無制限で、口座あたりの案件の数は百が上限となり、公式はこの枠は慣例として上げないと記す。

要求の層は二つの小さなファイルが受ける

静的の資源の応答の頭と転送の規則は、二つの素のテキストのファイルが受け持つ。どちらも資源として公開されることはなく、産物の置き場の中で基盤に読まれるだけだ。応答の頭のファイルは規則が百件まで、一行は空白も名前も値も合わせて二千字で頭打ちになり、一つの要求が複数の規則に当たると、それぞれが告げる頭をまとめて引き継ぐ。転送のファイルは一行に一つの宣言だけを書き、順番が結果を左右する。同じ元の道に複数の宣言があると、上にあるものが先に効き、静的な規則は動的な規則より前に置くべきだ。容量は静的な転送が二千、動的な転送が百で合わせて二千百、一つの宣言は千字で頭打ちになる。二つのファイルが同じ要求に当たると、転送が応答の頭より先に走る。

予備の配信、巻き戻し、配備の鉤

倉庫に新しい統合の求めを一つ立てるたび、その変更のために独立した予備のリンクが作られ、中身は枝に積まれる後の提出に合わせて更新され続ける。新しい枝を作るたび、案件の下のドメインの前に無作為に作ったハッシュが付いて、新しい予備の宛先になる。基盤はさらに枝の名前の別名を作り、その別名は枝の提出に合わせて進む。本番のドメインも案件に付けた独自のドメインも、予備の配信の影響を受けない。こうした一時の写しが検索の結果に影響しないよう、公式は予備の配信のすべてに検索の仕組みに拾わせない印を既定で付ける。巻き戻しの対象は、構築に成功した本番の配備ならどれでもよく、巻き戻した後でもより新しい版に切り替えられる。予備の配信は巻き戻しの対象にならない。ドメインの接続は二通りに分かれる。根のドメインはまずサイトを Cloudflare につなぎ、ネームサーバーを変えて、基盤に記録を作ってもらう。下のドメインは今の解析の事業者に CNAME の記録を一つ足し、案件の下のドメインを指せばよい。

配備の鉤は、始まりの場所を提出から別のところへ移す。鉤ごとに固有の宛先を持ち、HTTP POST を一回受け取れば構築が一度走る。設定のときに入れるのは鉤の名前と構築する枝の二つだけだ。公式は、宛先を呼ばれれば誰でも走らせられると注意し、機密として扱い、使われた疑いがあれば消して作り直すよう求める。この仕組みは、中身を外部の管理の仕組みで保ち、サイトもそれに合わせて更新したい場面に向く。自前の統合の流れに組み込むことも、決めた時刻に作り直すこともできる。

Cloudflare Pages はフロントエンドの配信を三つに分けた。構築は既定の中で終わり、配信は自社の世界の網に載り、割当は公開の表に書かれる。目を引くのは、無料の枠が開いている項目の多さだ。サイトと席と要求と帯域は脇に置かれ、見積もるべきは月の構築の回数と案件の数と一つのファイルの大きさになる。流量の起伏が大きく、帯域の費用を見積もりにくい静的サイトや全体のアプリにとって、この組み合わせは請求の不確かさを きわめて小さく抑える。