本サイトは2021/06/01にWordPressからHugo + Cloudflare Pagesに移行した。まだ移行して数日に過ぎないが、良い面と悪い面が見えてきている。前回の記事ではHugoに関する話をメインにしていたので、この記事ではCloudflare Pagesやその開発周辺の、移行数日の所感を届けたいと思う。

良かったこと

まずは良かったことから触れよう。ただ、前回の記事でHugoの良い面の話をたくさんしているので、そちらも参照して欲しい。

とにかく速い

Hugo(Jamstack)のサイトは静的コンテンツだというのが、やっぱ速度面では驚異的だ。それを配信しているCloudflare Pagesもまた異常に速い。ローカルの開発環境である hugo server で提供されるサイトとCloudflare Pagesに配置したサイトで、体感に差がないくらいに速い。

WordPress + CloudflareでもDOM(HTML)キャッシュを組めば同様の速度を実現できてはいたのだが、サイトを回遊しているとやっぱりHugo + Cloudflareの方が常に安定的に速いという感触を受ける。私は仕事でFastlyを利用しているが、それに感じる速さと近しい。

加えて、最新技術の実装が速いCDNであるCloudflareに載せていることで、CDNの効果とHTTP/3やBrotliなどの恩恵を受けている。有料契約すればもっとできることは増えるが、無料でも既に素晴らしいレベルだ。

プレビュー機能がある

どうやら、Cloudflare PagesはPull Requestを作るとPreviewのURLが生成するようだ。と言っても、まだ使ったことはないのだけれど。

これは、例えばテーマを変えるときなどの、大規模な変更を掛けるときにとてもありがたい機能だ。WordPressのときは(ちゃんと開発環境を作っていないと)ぶっつけ本番になりがちで、実コンテンツと組み合わせてからミスに気付くってことを繰り返していた。それが、本番デプロイの事前に確認できるわけだ。

困ったこと

ここからは、数日使って遭遇した困ったことの共有だ。

Cloudflare Pagesのビルドでタイムアウトする

このサイトはコンテンツが重いという理由もあるだろうが、Hugoデフォルト値の10000(10s)では1記事のビルドに全く時間が足りないケースに陥った。今は config.toml に以下の設定値を乗り切っている。

timeout = 120000

Cloudflare Pagesのビルドは遅いという噂もある。実際、このサイトのこの記事の量で4分程度は掛かっている。

Cloudflare Pagesとモバイルでのエラー

未だに理由がよく分からないのだが、実際にデプロイしたあとで スマートフォン(SP)で見た時にCSSが効いていない という問題に陥った。どうやらSubresource Integrity(SRI)チェックに引っかかってるみたいだ。「SPで」と言うところからわかると思うが、PCでは問題がなかった。

たしかにCloudflareはエッジでコンテンツを最適化＝改変する仕組みを備えている。Rocket Loader、Auto Minifyなどだ。でも、これらの機能を無効化しても全く問題が解決しない。キャッシュも当然毎回飛ばしたけれど、だ。

最終的にはHugoの生成するコンテンツから、以下のようなSRI ( integrity=xxx )の記述を削除してSRIを無効化した。 layouts/partials/head.html あたりに記載があるはずだ。

<link rel="stylesheet" href="{{ $main.RelPermalink }}" integrity="{{ $main.Data.Integrity }}">

そうすると、ちゃんとSPでも表示されるようになった。セキュリティを犠牲にする形でちょっと納得がいかない。

これはCloudflare / Cloudflare Pagesの一種のバグかも知れないので、いつかサラッと直っていることを期待したい。

GitHubの転送量の問題

本サイトの写真はなかなかに大きなデータのため、git lfsで管理している。写真を差し替えた時なんかに差分が膨らむことを防ぐためだ。このリポジトリ、たったこれだけのコンテンツ数で 既に600MB強 となっている。1記事で187MBのものがあったりもする。高画質の写真を扱いたいとは言え、さすがにちょっと反省している。

ところでこのLFS、 GitHubでは容量と転送量に無料アカウントの場合1GBの制限 がある。これは $5/month 払うことで 50GBに拡張される が、頼りないのは変わらない。(なお、もっと課金すればもっと転送量枠は増える)

この大容量が問題になるのは、Cloudflare Pagesでデプロイするときだ。Cloudflare PagesでHugoコンテンツをビルドするとき、GitHubからの転送はpullじゃなくてclone = 常にフルサイズ である。CIあるあるではあるが。

なので、2021/06/01現在、このサイトは1回ビルドすると600MBのLFSの転送が必要である。CSSを1行変えただけでも。1文字追加しただけでも。 ビルドに失敗しても、成功しても、だ。 Cloudflare Pagesを利用開始した最初の日に何回もビルドに失敗したので、 初日だけでGitHubは5GB程度の転送量 となって、LFSのアクセスエラーに陥ってしまった。そのため、私はすぐにGitHubに課金をした。

課金したけれど、それでも月に80回ほどしかビルドはできないってことである。Cloudflare Pagesにビルドキャッシュがあれば解決のしようがあるのだが、そこまでの機能は現時点では存在しないようだ。

ということで、初期開発期である現在はガンガン転送量が増えている。 $5/month の課金で足りるかハラハラしながらの現在である。WordPressだった時代はホスティングサービスに金を払っていたが、今はGitHubに金を払う必要がある。 Cloudflare Pagesが無料枠が大きい太っ腹で良かった。

まとめ

Cloudflare Pagesはとにかく速い。そして無料枠が太っ腹で、無料部分だけでも高性能に仕上がる。有料化すれば更に便利な機能が使える。

一方、写真サイトにHugoという組み合わせは、デプロイをつらくする組み合わせだったかもしれない。いや、写真サイトの写真データをgitリポジトリに入れたことが間違いだったというべきか。写真データ部分だけ他のサービスと組み合わせられるのなら、その方が良い可能性は大いにある。もしもっと大規模にサイトを作るなら、そのような構成(imgixを利用するとか)も検討したいところだ。