2019年の10月ごろに Firebase Hosting に乗り換えて以来2年半ほど使ってきたが、先日 Cloudflare Pages に乗り換えた。

Firebase Hosting でもそこまで不満があったわけではないのだが、GitHub Actions を使うにせよ Cloud Build を使うにせよ、自分でビルドやデプロイのための設定を行う必要があるのが若干面倒だった。Cloudflare Pages であれば、Netlify 同様にビルドして特定ディレクトリに出力されたものを配信する程度ならほぼ何も設定しなくてもできる。

Netlify の Starter (無料) プランでネックだった CDN のエッジが日本にないために遅い問題もない。体感としては Firebase Hosting で配信していたときと比べて遜色ないパフォーマンスが出ている。加えて、Firebase Hosting ではサポートされていなかったIPv6 や HTTP/3 もサポートされている。

自分のドメインを使うときには Cloudflare の DNS や CDN と連携される。これは簡単に設定できて便利な面があるのは間違いないものの、Cloudflare Pages のサーバをオリジンとして Cloudflare の CDN 機能を使っている、というような状況になるため、そっちの設定がわかっていないために生じる混乱はあった。特に CDN はこれまでまったく使っていなかったため、SSL/TLS 周りの設定がオフになっていることに気づかず、HTTP のページにリダイレクトされて HSTS で HTTPS に戻されるリダイレクトループになって困った。

ビルドやデプロイに掛かる時間は、直近まで使っていた Cloud Build と比べると大幅に改善された。このブログで6分から7分程度掛かっていたのが、3分を切るほどになっている。自分で試してはいないが、軽く調べたところ Netlify や Vercel と比べると遅めのようだ。今後の改善に期待。

カスタム HTTP ヘッダやリダイレクトについては、Netlify 互換っぽい雰囲気の _headers や _redirects が使える。どちらも表現力が低く、それによって特に_headers は手書きで思ったような挙動にするのが難しかったため、GatsbyJS のプラグインである gatsby-plugin-netlify で生成するようにした。プラグインで生成したファイルを Cloudflare Pages で使う分には特に問題なさそうだった。

ちなみに、互換ではなく互換っぽい雰囲気と書いたのは、どこにも互換とは謳われていないというのもあるし、Cloudflare Pages のドキュメントでもクローラー避けとして紹介されている以下のような記述が Netlify’s playground で正しくパースできなかったというのもある。

https://:project.pages.dev/*
  X-Robots-Tag: noindex

さらに付け加えておくと、Netlify は解釈してくれなさそうだが gatsby-plugin-netlify でこのような記述を含んだファイルを生成することは問題なくできる。

module.exports = {
  // ...
  plugins: [
    // ...
    {
      resolve: `gatsby-plugin-netlify`,
      options: {
        headers: {
          "https://:project.pages.dev/*": ["X-Robots-Tag: noindex"],
        },
      },
    },
  ],
}

全体としては、不満らしい不満は今のところ特になく、これまで試してきた中ではもっともよいと感じる。本格的に業務で使う場合については定かではないが、ちょっとした静的 Web サイトをシンプルに置いておく場所としてはかなり魅力的だと感じた。