なうびるどいんぐ

脳みそ常時-3dB

Hugo+Firebase雑感

      2019/12/11    HimaJyun

先日Hugo+Firebase Hostingでサイト作るって趣旨の記事を見かけたので、それを実際にやってる人間が感想をダラダラと書いておきます。

スポンサーリンク

この記事の中で出てくる話は、まだ作ったばかりで月5000PVくらいのサイトで得た知見の話です。PV数変わると事情が変わって感想も変わるかもしれないが、とりあえず現時点での感想。

俺個人の感想なので、まぁ鵜呑みにしないくらいで読んでください。

運用関連

Firebase Hostingを選んでるのは自分で運用するのがめんどくさいからです。

ゼロ運用アーキテクチャ目指しましょう。人間は忙しいのです。

コスト

Firebase Hostingには無料プランがあるので、ドメイン代とか除くと1円も掛かってないです。

ドメイン代も払いたくない人はサブドメインでやりましょう。

アクセス数が伸びてきて無料プランの枠で賄えなくなってきたらS3+CloudFrontな感じにでもしようかな、と考えている。

ソースコードの管理

GitHubで管理してます。

画像は.gitattributesbinary指定してそのまま突っ込んでる。LFSは使ってません。

GitHubで管理しているので出先でも記事が書ける。俺は出先で記事を書くほど熱心な人間ではありませんが。

個人的にはやってませんが、GitHub Actionsでデプロイするようにしても良いかもしれない。

Firebase関連

Firebaseはまだあまりメジャーでないのか、情報が少ない(あっても「試しに使ってみました~」みたいな奴とか)

特にFirebase Hostingに限った細かい話とかだと情報皆無なので、個人的に気になったところとか書いておく。

CDN

Firebase HostingはFastly経由で配信されている。なにも設定しなくてもCDNを経由する。

デプロイすると自動でキャッシュパージも行われるので、「最新版表示されねぇ!」みたいな問題はない。

というか、ここ最近の静的サイトに限ったホスティングサービスは大抵がデフォルトでCDN入ってる。(GitHub PagesもFastly経由だし)

Zone Apexの利用

運営しているサイトはZone Apexで動かしている。

CDNが云々とかになると気になるのがZone Apexに対応しているかどうかという話。

最近はZone Apexでも使えるサービス増えてるので気にすることは減ったが、一応注意しておかないとたまに対応してないサービスとかある。

FirebaseのDNS設定はAレコードを使用するので、Zone Apexでも利用できます。DNSに設定しろと提示されるIPアドレスもFastlyのもの。

CDNでありがちな「CNAMEがZone Apexで使えないからCDN使えない」問題もFastlyには関係ない。

この辺はFirebaseの仕様というよりFastlyの仕様。機会があったらFastly単体でも使ってみたい。

応答速度

「Firebase Hostingは早い」みたいな話を聞いて使おうと思ったのだが、ここは少し罠がある。

Fastly経由で配信されているので、CDNのキャッシュに載っているなら早い。つまり、キャッシュに載ってなかったら普通に遅い。

ChromeのDevToolsでざっと計った感じでは、キャッシュに載っている→15ms前後、載っていない→300~500msという感じ。

気になるほど遅い訳ではない(へたくそが作るWPサイトの方がよっぽど遅い)のだが、せっかく爆速にしたのにそこで遅くなるのはちょっとなぁ、という気持ち。

キャッシュに載っていないページ=アクセスが少ないページなので気にしないことにしているが……

ちなみに、Netlifyで運営されているサイトを見てみると100msくらいなので、それに比べると15msは圧倒的だと思う。キャッシュに載っていればの話だけどね。

Cloud Functionsが外向き通信できない

FirebaseのCloud Functionsは無料プランだとGoogleサービス以外への通信ができない。要するにHTTPで外部のAPIを呼び出したりできない。

お問い合わせ機能を実装しようとなると外向きの通信がほぼ必須だろうから、その辺は不便だなぁ、と。

どうしても外向けAPIが呼び出したいならBlaze(従量課金)プランを利用しましょう。

Spark(無料)プランの無料使用量を含むので、Blazeでも無料枠に収まってる内は課金されません。

この場合のコストは$0.12/GBですが、5GBまではGCPそのものの無料枠が適用されて無料です。

俺はうっかり無料枠超えて課金されたりすると嫌なので、外向き通信が必要なAPIだけAWS Lambdaで実装している。

デフォルトのドメインは無効に出来ない

Firebaseはデフォルトで<プロジェクト名>.web.app<プロジェクト名>.firebaseapp.comのドメインが利用可能になっている。

もちろん独自ドメインを追加することも可能なのだが、そうした時に少し気になるのがこの2つのデフォルトドメインを無効に出来ない事。

複数のドメインを追加してリダイレクトしたり出来るのに、デフォルトドメインだけはリダイレクトも削除も出来ない。

結果的に1つのサイトに複数のドメインでアクセスできるようになってしまうので、少し気になる。

一応meta canonicalは設定しているのだが、ちょっと気持ち悪いよね。気にしすぎだろうか?

IPv6は非対応

Firebase Hostingは今のところIPv6には対応していない。

……という事なのだが、実はFastlyのIPv6アドレスをAAAAに指定するとIPv6で接続できるらしい。

公式の手法ではないのでやらない方が良いと思うが……

IPv6しか使えないプロバイダは珍しいと思うが、IPv6対応が要件として求められる時には注意が必要。

(ちなみにiOS用のFirebase SDKはIPv6で動作するので、iOSアプリの審査がどうのこうのには問題ないらしい……俺はiOSアプリ作らないので知りませんが)

firebaseとfirebase-toolsに注意

Firebaseのデプロイ用コマンドはnpmでインストールするのだが、firebasefirebase-toolsの2種類のパッケージがあるので注意。

firebaseは開発時に利用するSDKで、firebase-toolsがデプロイなどに使用するツール。デプロイに必要なのはfirebase-toolsの方。

ドキュメントをちゃんと読まずに「npmでfirebaseをインストールすれば良いんだな」なんて事をやるとハマるので注意。(実際ハマった)

Hugo関連

次はHugo関連の感想。

俺はHugoを結構気に入っていて、高く評価しているのでプラス補正掛かってるかもしれない。

静的サイトジェネレーターを使う事自体が初めてだったので、Hugo関係ない感想もちょっと混ざってる。

インストール楽ちん

HugoはGoで出来ており、バイナリで提供されている。

GitHubからダウンロードしてきてPATHを通せば動くのでとっても楽ちん。

というかスクリプト言語にありがちな依存関係までゴチャゴチャインストールしなきゃいけないアレあんまり好きじゃないんで……

minifyしてからdeployしよう

Hugoでビルドする際に--minifyという引数を与えてやるとHTML、CSS、JSなどがminifyされます。

minifyなんて気休めにしかならないでしょうが、一応やっておくと良いでしょう。

これ感想じゃないな……

自動変換を停止する

Hugoには二連ハイフンをなんか繋がった奴(名前忘れた)に変換する機能が付いてます。WordPressにも同じお節介機能あるよね。

アレ、多分邪魔になる人がほとんどだと思うので停止しちゃいましょう。config.tomlに以下のように設定すれば止まります。

[blackfriday]
    smartypants = false
[markup.goldmark.extensions]
    typographer = false

これも感想じゃないな……

マークダウンで書けるのは良い

別にブログエンジンにエディターが付いてる必要はないですよね?

Markdownで記事を書くので、好きなエディターを使えるのはとってもよい。

WordPressのビジュアルエディターとかぶっちゃけ使い勝手よろしくないので俺はあんまり好きじゃないです……

Markdown=テキストファイルなので、Gitのような高機能なバージョン管理システムでバージョン管理できるのも非常に良い。

ちなみにエディターにはVSCodeを使ってます。

ライブリロード機能が良い

これはWordPressしか使ったことない人に言いたい事なんですけど、ライブリロード機能めっちゃ良いです。

Hugoのプレビュー機能にはライブリロードが付いているので、プレビュー画面を開いたまま記事を更新すると自動でリロードされます。

俺は4画面のPCを使ってるんですが、1つの画面でプレビューを開いたままもう一つの画面で記事を書く、という事をやると効率が何倍にも跳ね上がります。

むしろWordPressみたいに、プレビューするたびにボタンポチポチしなきゃいけないのがつらい。

静的で良いということに気付く

WordPressをディスる意図があるわけじゃないんですが、静的サイトジェネレーターに入門すると今までWordPressでやってた事が実は必要ないと気付きます。

コメントとか、問い合わせとか、そういうものは「必要な時だけJSで呼び出せば良いじゃん」と気付く。

最近はfetchとかあってブラウザJSの機能も強力になってるんだし、サーバーレスとかでAPIサーバーを用意してそれを呼び出せばいいよね、という気持ち。

サーバーサイドじゃないと出来ないような動的な機能をゴリゴリ使いまくってるとかならともかく、おそらく世の中の殆どのサイトは大した事やってないと思うんですよね。

それこそ、fastcgi_cacheが使えるサイトなら静的サイトジェネレーターで十分だと思う。

いや、WordPressは素晴らしいんですよ?素晴らしいソフトウェアなんですけど……その"素晴らしい機能"、普通のサイトには要らなくない?みたいな。

サイトに動的な要素があるからって、サイトそのものまで動的である必要はないですよね?

あ、でも、そういう仕組みをしっかり作れるくらいの技術力がないなら黙ってWordPress使ってる方が良いと思います。セキュリティ的な理由で。

(じゃあなんでこのブログはWordPressなんだ?って、そりゃ、移行作業をするまとまった時間が取れないからだよ、いずれはやめるつもり)

まとめ

という感じで、Firebase Hosting + Hugoなサイトを動かしてます。

今あるサイトをHugoで置き換えろとまでは言いませんが、新規にサイトを作るなら試してみてほしい。

(まぁ、普通はそんないくつもサイト作ったりしないだろうけど)

俺はこの組み合わせ、結構気に入ってます。

 - Web制作