相変わらず自分の肩書がキモい（死語）事になりますね…
プログラマミング業界のマルチタレント、と言えば意図は伝わりそうな気がしました。
（厳密に言えば違います）
システムの専門家だけど、特定の言語や専門分野としてプログラマーをやっているのではなく、システムのなンでも屋です、としか表現できないのが悩みです。

さて、今日は何でもやります、のうち速度計測の話を。
フロントエンドエンジニアが好きな（いずれ壁にぶち当たるであろう）言葉ですね。
JAMStackなブログを作ろうと思っている人は必ず一度は悩むホスティングサーバーをどこにするか問題について、私なりに取り組んだ結果をお話します。
この記録は執筆時点のものですので、実際に使われる時には結果が変わっている事が考えられます。

結論

敢えて選ぶとしたらNetlify？
ですが、慣れたサービスでいいと思います。

ソースファイル

• Firebase
• Github Pages
• Netlify

速度比較

Netlifyは遅いとかFirebaseが圧倒的だとか言われますが、実測値では大した違いはないです。
イエローゾーン内で65±15を行ったり来たりしてるので、数字はガチャ運です。
せっかくだから頑張れるぐらい高い数値を狙って３つ全部で同じ数値になるようガチャを引いたら案外簡単にできたのでパシャりました。

敢えてNetlifyを推す理由

MicroCMSでWebhookを設定する時に明示的に指定ができるからです。

Webhookを指定することで、記事を更新するたびに新着記事を各ホスティングサービスに通知する事ができます。
これがあると、WordPressと同じような感覚でブログの更新ができるようになる（当然、更新も表示も爆速を維持したまま）ので、
「静的サイト？WordPress？何が違うの？」みたいな状況にできるわけです。とても素晴らしい！
ここを見ている人でJAMStackが分からない人なんていないと思って話してますが、要はWordPressみたいな動的サイトでやってくれてたアレコレを静的サイトでも同じような感覚で使うのは結構骨が折れるものです。
裏で色々と頑張ってくれているサービスに感謝しましょう。

IT人事・採用担当さんに向けて意訳すると「ReactフレームワークをAPI連携して出来たサイトをGithubにCIツール使ってWordPressよりも早くて使いやすいアプリ作りました」と言えるようになります。
脱・メルカリクローンではなく、メルカリクローンをJAMStackで作れば、今なら評価も高いんじゃないでしょうか？
私の感覚ですが、データベースのメンテナンスコストも考えるとAPIを叩いて取ってきたデータをいい感じに使えるようにサービスを構築する方がモダンな気がします。
インターネット老人おじさんなのに若者アピールに余念がないです。褒めてください。

GithubPagesのいいところ

普段Gitを使い慣れている人にとって最も教育コストが低い事が挙げられます。

ローカルでgatsby build してpublicを公開用リポジトリにpushすればページを公開できるので、難しそうな事は考えなくていいのが強みです。
GithubPagesをdocsディレクトリに指定してpublic->docsにリネームして丸ごとアップすればソース管理もできます。
ただし、無料プランだとプライベートリポジトリでGithubPagesを公開できないので、公開用のリポジトリとソース管理用のリポジトリを分ける等の工夫が必要です。
たとえば、developリポジトリにソースコードをおいて、gatsby buildで生成したpublicディレクトをopenリポジトリに置く事でAPIキーを秘匿できるのでセキュリティ面でも安心です。

Firebaseのいいところ

GithubPagesのようにリポジトリで分けず、サービスで分けたのがFirebaseやNetlifyのイメージです。
FirebaseはGoogleが作った、と一言だけ言えばアフィリエイターなら全員納得してくれますよね？
他のサービスよりGoogleアナリティクスやGoogleアドセンスといった、めちゃくちゃ重いスクリプトが最も最適化された状態で使用する事ができるのです。
元々はホスティングサービスではなくBaasとして使えるサービスだったので、その機能の一つにホスティングがある、という位置づけです。
今回使ったのもFirebaseホスティングだけですが、Firebaseは他にも機能が豊富にあるのでエンジニアとしてスキルアップしたいなら使ってみるのも悪くないでしょう。

技術要件

なるほど、こりゃいい！となってくる頃だと思うので、就職活動のポートフォリオにしようと考えもよぎるかと思いますので、この辺りで一応心を折っておく事にします。
今回の要件を実装するために必要なエンジニアリングスキルは、

• サイト作成のためのReactスキル：Reactである必要はありませんが、今回はReactを採用しています
  • フロントエンド、特に表示制御に集中できます
  • バックエンド、今回はGatsby-config.js やGatsby-code.js 辺りが該当します。ここだけで完結できます。
• API構築：今回はMicroCMSに丸投げしているので繋ぎの部分とMicroCMSの仕様だけ知っておけばいいです
• ライティングスキル：記事を書く、というのは実は結構度胸が要ります。発信しようと思っている人が多いので軽視されがちですが、書けない人は本当に書けないです。
• Githubを使うためのGitコマンド：プロジェクトによってはGitの運用プラクティスも求められます
• 静的サイトの使い方：GithubPagesとかFirebaseとかNetlifyなど、今回のメインテーマです
• ページを更新したら画面に反映する仕組み：これがビルドです。次のページでより詳細に解説します。

ざっくりいうと

• J: Javascript／ReactやらVueやら
• A: API／
• M: Markup

Stackは一語で「つながり・積み重ね」です。

記事を更新しても反映されない

次の問題です。
MicroCMSを更新してもサイトに新しい記事は反映されません。
これを反映させるためにビルドを行う必要があります。
手動で行うなら、

1. 記事を更新
2. gatsby build
3. デプロイコマンドを実施
   1. （GithubPagesのみ）publicディレクトリをpushする

とはいえ、記事を更新するたびにビルドしてデプロイするのは面倒です。
これを簡略化・自動化する仕組みがCMS側に必要です。
GithubPagesの場合も同様です。