Firebase Hosting VS GitHub Pages

はじめに

もともとスマホアプリのランディングページをGitHub Pagesで運用していましたが、アプリにFirebaseを導入したのを機に、Firebase Hostingに移行してみました。

両方使ってみた感想・比較をアプリのランディングページを運用するならどちらが良いかという観点から行っていきたいと思います。

基本情報

使い方に関しては、すでに詳しく解説している記事が多くあるためここでは省略しますが、2つのサービスの基本的な情報に関しては記載しておきます。

Firebase Hosting

Googleが運用しているモバイル向けバックエンドサービス(mBaas)である、Firebaseの機能の一つです。
静的Webページのホスティングサービスで、公開するページを指定してCLIツールを使用することで、簡単にWebページをデプロイすることができます。

GitHub Pages

みんな大好きGitHubの静的Webページのホスティングサービスです。
バージョン管理サービスであるGitHubのサービスなので、コンテンツをgit管理しつつpushしたらすぐにデプロイすることが可能です。

公開方法の比較

非エンジニアが管理する場合もあるため、公開が容易に行えるかどうかは大事なポイントです。
そこでまずは、公開をする際の方法を比較してみました。

サービス名	公開方法	難易度
Firebase Hosting	CLIでinit・deploy	易
GitHub Pages	専用ブランチにpush	中

Firebase HostingはCLIをPCにインストールした後に、公開するディレクトリを選択して、init・deployするとすぐに公開されます。
ただし、FirebaseのCLIをインストールしなくてはいけないため、全く手間がかからないわけではありません。

GitHub Pagesは公開に使用するリポジトリにgh-pagesブランチを作成し、そこに公開するページをpushするとすぐに公開されます。

どちらもデプロイ・公開は簡単ですが、GitHub Pagesの方がgitの基礎知識を必要とするため、若干難易度が高いです。

ロールバック方法の比較

次に、Webページを公開したけれど、不具合が見つかったために以前のものに戻したい(ロールバック)場合にどうするかを比較してみました。

サービス名	ロールバック方法	難易度
Firebase Hosting	ConsoleからGUIで過去にデプロイしたものを選択	易
GitHub Pages	公開中のgh-pagesブランチを新しくpush	易

Firebase Hostingは管理用ConsoleからGUI上で過去にデプロイしたものを選択し、すぐにロールバックすることが可能です。
過去にデプロイしたものを一覧で残しておいてくれるため、いつデプロイしたものかを確認しながらロールバックすることが可能です。

GitHub Pagesはgh-pagesのブランチがそのまま公開されるため、このブランチをそのまま公開したいコミットにチェックアウトすれば、ロールバックすることが可能です。
注意しなければいけないのは、マージされたブランチを消す癖がある人はロールバックした際に、する前のコミットにブランチを残しておかないとコミットが消えてしまうことがあることですね。

どちらもロールバックは簡単です。
ただ、GUIからロールバックを行えるという点でFirebase Hostingは使いやすいですね。

コストの比較

次に、Webページを公開する上で切り離せないのがランニングコストです。

サービス名	料金	備考
Firebase Hosting	1GBまで無料	転送量は10GBまで
GitHub Pages	publicなら無料・privateは$7/月

Firebase Hostingは1ヶ月に1GBまでの容量・10GBまでの転送量は無料で公開することができます。
それ以上になると課金する必要があります。
ただ、アプリのランディングページでそこまで容量を消費することはないかと思います。

GitHub PagesはGitHubの料金体系がそのまま適用されるため、容量の制限等はありません。
ただ、公開しているページに直接関係がないものをgit管理したい場合、privateにしないと他人に見られてしまう危険性があるため、注意したいところですね。

ドメイン（＋URL)の比較

また、アプリのランディングページを運用する際、そのアプリ名でドメインを取得して運用する場合もあると思います。

サービス名	デフォルトURL	ドメイン接続	備考
Firebase Hosting	https://{プロジェクトID}.firebaseapp.com/	無料で接続可	SSL対応
GitHub Pages	https://{ユーザ名}.github.io/{リポジトリ名}	無料で接続可	SSL対応

どちらも独自ドメインを無料で接続可能なこと、デフォルトでSSL化されていること、独自ドメインを接続しない場合はそれぞれのデフォルトURLが振られるという点は共通しています。
ただ、デフォルトURLが異なるパターンで与えられており、SEO対策という点では単一ユーザであれば、サブドメインも含めて同一ドメインで複数のページを公開できるGitHub Pagesに軍配があがりそうです。

それぞれのメリット

ここからは、それぞれのサービスにしかないメリットを見ていきます。
これがどちらのサービスを利用するかの分かれ目かもしれません。

Firebase Hosting

• firebase.jsonを設定することでアクセスの振り分けが行える

一般的なホスティングサービスの場合、htaccessなどのファイルを設定することはできないため、特定のパスに対して3xx系・4xx系のエラーなどを設定することができないことがほとんどです。
しかし、Firebase　Hostingはfirebase.jsonというFirebase全体の設定を行うファイルにルーティング周りの設定などを記述することができます。

• 他のFirebaseの機能と一緒に使用することができる

アプリなどで他の機能を使っていたりする場合、改めてプロジェクトの作成などを行う必要がありません。

GitHub Pages

• gitでバージョン管理を行いつつ公開することができる

ページを作成したら、そのページがいつ作成されたものなのかを管理している人がほとんどだと思います。
GitHub Pagesはバージョン管理を行うGitHubのサービスの一部なので、特に設定することなくバージョン管理を行うことができます。

• Jekyllに対応しているため、手軽にマークダウンでページを作成することができる

JekyllはRuby製の静的サイト構築用のGemライブラリで、マークダウンなどで書いたページを静的ページにビルドできたり、テンプレート化して使いまわしたりできます。
普通なら元のファイルを手元でビルドしなくてはいけませんが、GitHubPagesはビルドをする必要がなく、そのままpushすればGitHub側でビルドして公開してくれるため、バージョン管理もしやすくなります。

さいごに

Firebase HostingとGitHub Pagesを比較してみてきましたが、どちらもメリットがあります。

Firebaseの他のサービスを使っていたり、Gitlabなどの自前のバージョン管理環境がある場合などはFirebase Hostingを、既にGitHubでバージョン管理を行っていたり、マークダウンで気軽に書きたい場合などはGitHub Pagesを使うのが良さそうですね。

指摘等ありましたらコメント欄までお願いします。