Firebase Hosting が HTTP/2 に対応
2016年10月5日水曜日
Michael Bleigh
エンジニアうれしいことに、本日（*原文公開当時）は 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 回の接続で複数の同時リクエストが行われるため、多くのリソースを集約するメリットはなくなります。実際は、ブラウザは適切にリソースをキャッシュするため、あまり変更のないファイルをたくさん提供する方が効率的です。ただし、ここでたくさんのファイルというのは数十個のファイルであり、数百個のファイルになると依然として大きなオーバーヘッドが生じることに注意してください。
- アセットを複数のドメインに「分割」する必要はなくなり、この方法は好ましいものでもなくなりました。Firebase Hosting は既に高速な CDN 経由で提供されており、HTTP/2 によって同じドメインからすべてのファイルを提供する方が有利になっています。
- 必要なアセットのみ読み込むようにしてください。通信の往復を少なくし、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 プッシュを使わずにアセットをプリロードすることもできます。 サーバー プッシュはまだ日が浅いため、いくつかの留意すべき点があります。
- Link ヘッダーのワイルドカードには注意してください。自分自身をプリロードするようにリソースを設定してはいけません。
- サーバー プッシュは、パフォーマンスと使用する帯域幅のトレードオフです。既にブラウザがキャッシュしているアセットをプッシュすると、余計なデータを送信することになります。プッシュするアセットはパフォーマンスに大きく影響する最低限のものにとどめます。ユーザーがモバイル端末に送られる余分なデータの料金を負担することになる可能性も考慮してください。
- プッシュしなくても、プリロードするだけでパフォーマンスに十分貢献します。プリロード 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
