この記事は Firebase Hosting エンジニア、Michael Bleigh による The Firebase Blog の記事 "Serving dynamic content with Cloud Functions on Firebase Hosting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


3 年前、Firebase Hosting がリリースされ、デベロッパーが高速で魅力的なウェブ コンテンツをより簡単に提供できるようになりました。2 か月前には、Cloud Functions for Firebase のベータ版がリリースされ、デベロッパーがサーバーやインフラについて心配せずに、カスタム バックエンド ロジックを記述できるようになりました。先日の Google I/O では、Firebase Hosting と Cloud Functions を組み合わせて、世界規模の拡張性とパフォーマンスを備えた Progressive Web Apps を作成できる柔軟なツールセットとして使う方法を紹介しました。

プロジェクトの firebase.json 設定ファイルに rewrite を追加すると、HTTPS Cloud Function を Firebase Hosting アプリに接続できます。

{
  "hosting": {
    "rewrites": [
      {"source": "/function/**", "function":"myFunction"}
    ]
  }
}

接続後は、一致するリクエストがスムーズに Cloud Function に渡されます（上記の例では、myFunction という名前の機能が呼ばれます）。このわずか 1 行の変更だけで、Firebase Hosting ユーザーは以下のようなすばらしい新機能を使えるようになります。

1. サーバーサイド レンダリング: 今までは、Firebase Hosting は静的なコンテンツしか提供できませんでしたが、Express などの業界標準ライブラリを使ってダイナミック コンテンツを提供できるようになります。超高速なグローバル CDN キャッシュが活用できる点は変わりません。
2. カスタム API: Cloud Functions と Firebase Hosting を組み合わせると、独自のドメインにカスタム API エンドポイントを作成して、クロスオリジン リクエストの負荷を避けることができます。さらに、数行のコードを追加すると、Firebase Auth でエンドポイントを認証することもできます。
3. ユーザー生成ウェブ コンテンツ: Firebase Hosting で初めてデプロイ不要で AMP、Twitter Cards などに対応したコンテンツを生成できるようになりました。これで、Firebase Hosting アプリはこれまで以上にコンテンツ共有や検索が容易になります。

Cloud Functions ユーザーは、SSL で保護されたカスタム ドメインで機能を実行できるようになり、不必要な実行を防ぐ強力なキャッシュも利用できます。

ご自分の Firebase プロジェクトの Firebase Hosting で Cloud Functions を使う方法については、ドキュメントをご覧ください。I/O セッション「Firebase Hosting で高速なウェブ体験を開発する」もご覧ください。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は Michael Bleigh による The Firebase Blog の記事 "The Firebase Blog: HTTP/2 comes to Firebase Hosting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

うれしいことに、本日（*原文公開当時）は Firebase Hosting で HTTP/2 が利用できるようになったことをお知らせできます。HTTP/2 は HTTP プロトコルの新版です。既に世界の 77% のブラウザでサポートされており、ウェブ デベロッパーにたいへん魅力的なメリットを提供しています。

• 1 回の接続で複数のリクエストを送信できます。HTTP/2 では、リソースを集約する必要性が少なくなります。
• バイナリ プロトコルであるため、ヘッダーを圧縮してデータを効率的に送信することができます。
• サーバーからクライアントに事前にコンテンツを「プッシュ」することができます。

これらを合わせて考えると、大幅なパフォーマンスの向上というメリットと、接続の遅いモバイル端末でもウェブアプリを早く読み込める可能性が増加します。

現在、HTTP/2 はすべての *.firebaseapp.com のトラフィックと新しくプロビジョニングされたカスタム ドメインのトラフィックで有効になっています。すでに Firebase のカスタム ドメインをお持ちの方は、後述のカスタム ドメインの移行をご覧ください。

Firebase Hosting での HTTP/2 の利用

Firebase Hosting で HTTP/2 を利用するために必要なことは何もありません。ユーザーのブラウザがサポートしていれば、自動的に HTTP/2 でコンテンツが提供されます。ただし、HTTP/2 向けに最適化を行いたい場合、覚えておくべきいくつかのベスト プラクティスがあります。

1. 1 回の接続で複数の同時リクエストが行われるため、多くのリソースを集約するメリットはなくなります。実際は、ブラウザは適切にリソースをキャッシュするため、あまり変更のないファイルをたくさん提供する方が効率的です。ただし、ここでたくさんのファイルというのは数十個のファイルであり、数百個のファイルになると依然として大きなオーバーヘッドが生じることに注意してください。
2. アセットを複数のドメインに「分割」する必要はなくなり、この方法は好ましいものでもなくなりました。Firebase Hosting は既に高速な CDN 経由で提供されており、HTTP/2 によって同じドメインからすべてのファイルを提供する方が有利になっています。
3. 必要なアセットのみ読み込むようにしてください。通信の往復を少なくし、App Shell を起動するために必要なファイルのみを読み込むよう、サイトを最適化します。その他のリソースは、ユーザーのインタラクションに応じてオンデマンドで読み込みます。

以上のガイドラインは絶対の決まりごとではありません。すべてのパフォーマンスの最適化に言えることですが、さまざまな最適化の組み合わせを実験し、どれがアプリ固有のニーズに適した最適な結果をもたらすかを見極める必要があります。

サーバー プッシュの実験

Firebase Hosting は、Link ヘッダーを用いた HTTP/2 サーバー プッシュを試験運用版としてサポートしています。サーバー プッシュによって、最初のリクエストが行われた際に、サーバーは自動的に追加リソース用のコンテンツを送信できるようになります。サーバー プッシュの最も一般的な利用方法は、ページが読み込まれた際に関連アセット（JavaScript や CSS ファイルなど）を送信することです。

Firebase Hosting でサーバー プッシュを設定するには、次の例のように firebase.json の設定に Link ヘッダーを追加します。

{
  "hosting": {
    "headers": [
      {
        "source": "/",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style"}]
      },
      {
         "source": "/users/*",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style;nopush,</css/users.css>;rel=preload;as=style"}]
      }
    ]
  }
}

ここでは、サーバー プッシュを使ってルートパス上にある /js/app.js と /css/app.css、さらに /users/* にマッチする任意のパスの /css/users.css をプリロードしています。既にブラウザのキャッシュに保存されている可能性が高いファイルについては、nopush ディレクティブ（2 番目の例の app.css など）を使用して HTTP/2 プッシュを使わずにアセットをプリロードすることもできます。

サーバー プッシュはまだ日が浅いため、いくつかの留意すべき点があります。

1. Link ヘッダーのワイルドカードには注意してください。自分自身をプリロードするようにリソースを設定してはいけません。
2. サーバー プッシュは、パフォーマンスと使用する帯域幅のトレードオフです。既にブラウザがキャッシュしているアセットをプッシュすると、余計なデータを送信することになります。プッシュするアセットはパフォーマンスに大きく影響する最低限のものにとどめます。ユーザーがモバイル端末に送られる余分なデータの料金を負担することになる可能性も考慮してください。
3. プッシュしなくても、プリロードするだけでパフォーマンスに十分貢献します。プリロード Link ヘッダーに ;nopush を追加すれば、サーバー プッシュを使わずにプリロードするようブラウザに指示できます。これは、既にブラウザがキャッシュしている可能性があるアセットには非常に有効です。

私たちは、HTTP/2 を使って読み込みを高速化できる可能性に期待しており、皆様のサイトでサーバー プッシュをさらにシンプルで信頼性が高く、効果的なものにする方法も模索しています。

カスタム ドメインの移行

HTTP/2 への移行に伴い、SSL 証明書の Server Name Indication（SNI）にも対応しています。SNI によって信頼性が高いインフラを継続的に拡張できるようになります。SNI は、世界の 98% 近くのブラウザがサポートしています。この変更はユーザー トラフィックに影響する可能性があるため、既存のカスタム ドメインは 2016 年 12 月まで自動切り替えを行いません。

2016 年 8 月 11 日以前に Firebase Hosting のカスタム ドメインを作成した方は、HTTP/2 のメリットを受けるために DNS レコードの更新が必要になります。dig <your-site>.firebaseapp.com を実行すると、既にサイトが SNI になっているかどうかを確認できます。結果に s-sni.firebaseapp.com と表示される場合、サイトは既に移行されています。

CNAME を使っている場合、DNS を s-sni.firebaseapp.com に向けるよう更新すると移行できます。A レコードを使っている場合、次のように更新してください。

151.101.1.195
151.101.65.195

DNS を変更してそれが反映されると、サイトが HTTP/2 で動作するようになります。年末までに、すべての Firebase Hosting のトラフィックが HTTP/2 と SNI に移行される予定です。そのため、SNI によってユーザーにどのような影響が出るか心配な方は、サポートまでご連絡ください。

Firebase Hosting が目指しているのは、プログレッシブ ウェブアプリ開発のベスト プラクティスを誰もが利用できるようにすることです。HTTP/2 はそれに向けた一歩です。みなさんが作成したコンテンツを見るのを楽しみにしています。

Posted by Khanh LeViet - Developer Relations Team

[この記事は Michael Bleigh、エンジニアによる The Firebase Blog の記事 "Deploy to multiple environments with Firebase Hosting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本番環境へのデプロイはいつも神経を使うものです。新しいバージョンのサイトに見つけられなかったバグがあったら何が起こるでしょうか。Firebase Hosting の 1 クリック ロールバックを使えば、動作していた最終バージョンに戻すことができますが、そもそもそれで問題が確実に起こらなくなると言えるでしょうか。

答えは簡単です。ミラーリングした本番環境でサイトのテストを行えばよいのです。うれしいことに、Firebase CLI を使うと複数環境のセットアップやデプロイを簡単に行うことができます。

新しい環境の追加

Firebase CLI では、firebase use というコマンド 1 つで環境を追加して切り替えることができます。

最初に firebase init で Firebase Hosting プロジェクトをセットアップするときに、アプリをどのプロジェクトにデプロイするかを指定します。これがデフォルトのプロジェクトになります。use コマンドを使うと、別のプロジェクトを追加できます。

$ firebase use --add

このコマンドを実行すると、既存のプロジェクトを 1 つ選ぶよう求められます。

$ firebase use --add
$ ? Which project do you want to add? (Use arrow keys)
  my-production-project
> my-staging-project
  my-dev-project

別の環境として使いたいプロジェクトを選択し、それに別名をつけます。この別名は何でも構いませんが、"development"、"staging"、"production" といった別名をつけるのが一般的です。

$ firebase use --add
$ ? Which project do you want to add? (Use arrow keys)
  my-production-project
> my-staging-project
  my-dev-project
? What alias do you want to use for this project? (e.g. staging) staging
Created alias staging my-staging-project.
Now using alias staging (my-staging-project)

新しく別名をつけたものが、デプロイの対象となるカレントの環境になります。firebase deploy を実行すると、アプリをその環境にデプロイできます。

環境の切り替え

別の環境に切り替えたい場合は、別名を指定して use コマンドを実行します。

$ firebase use default # sets environment to the default alias
$ firebase use staging # sets environment to the staging alias

コマンド内で -P フラグで環境を指定することもできます。

$ firebase deploy -P staging # deploy to staging alias

とても簡単

これだけで Firebase Hosting を使って環境を切り替えることができます。セットアップについてのガイドが必要な場合は、スクリーンキャストをご覧ください。フィードバックをお待ちしています。


Posted by Khanh LeViet - Developer Relations Team