HTTP2 for front-end web developers
CreditThis article is translated with permission of Matt Wilcox.
You can find original article at HTTP2 for front-end web developers.
本記事はMatt Wilcox氏の了承を得て翻訳された記事です。
原文はHTTP2 for front-end web developersにて掲載されています。
HTTP2は我々開発者のWebサイト作成の常識を変えるだろう。HTTP1におけるベストプラクティスはHTTP2の世界では害になってしまう。
HTTP1は今日におけるWebの大半において遅く非効率である
HTTP1.xは私達が最も慣れ親しんでいるHTTPのバージョンだ。HTTP1.xは、ワールドワイドウェブがどのようになるか予想できなかったときに設計された古いプロトコルである。そして、設計以上に複雑なことを我々が求めている以上、その振る舞いは現在のWebにとってももはや充分なものではない。
HTTP1において、Webを閲覧者が許容できるロード時間で提供するために、この古いプロトコルに対しいくつかのハックとも言えるテクニックをパフォーマンスのために施してきた。
- Spriting: 複数の画像を扱う場合はそれらを1つに結合し、CSSによって画像の特定の位置を表示する
- Concatenating: 複数のCSSやJSファイルは、結合して1つの大きなファイルにする
- クッキーを利用しないドメインからアセットを配信する
- Sharding: 画像のようなアセットを複数のドメイン・サブドメインでホストする
はじめの2つのテクニックはHTTPリクエストを削減するためのものだ。HTTP1において、リクエストは高価である上に時間を要する。それぞれのリクエストは、リクエストの一部にクッキーが付与され、圧縮もされない。そのため、リクエストを1つにまとめてしまうほうが、異なるリソースを要求する上でより高速になる。
3つ目のテクニックは要求されたアセットを取得するための時間を短縮するためのものだ。クッキーが設定されていると、そのドメインへのリクエスト全てに付与されるので、貴重とも言えるネットワーク経路において無駄なスペースを占めてしまう。もしクッキーが使われないドメインでアセットを配信すれば、それらへのリクエストへクッキーが付与されず、少し高速になるということだ。
最後のシャーディングは、ブラウザがひとつのドメインに対しHTTPリクエストを2つしか実行できないという制限に対するテクニックだ。もし新しくドメインを作ってそこからも配信すれば、ブラウザがアセットを取得するときのコネクションは倍になる。そのため、コンテンツをより早く送り届けることが可能になるのだ。実際には、ブラウザがドメインにつき2コネクションという制限を捨てたため、ここ2年間でシャーディングは非常に有効な手段となった。
HTTP2で配信されるWebサイトに、HTTP1におけるベストプラクティスは使ってはならない
HTTP2はもうすぐそこだ。HTTP2はSPDYがベースとなっていて、全てがより効率的になったプロトコルである。また、これはHTTP1において有効であったパフォーマンスのためのテクニックが害になることも意味している。それらのテクニックはHTTP2向けのWebサイトを遅くすることはあっても、速くすることにはならない。だから、HTTP2においては使わないことだ。
HTTP2は複数リクエストをプロトコルレベルで最適化し、発生するコストを小さなものにする。
- HTTP2では開いたコネクションを再利用のために長い期間維持することが出来るため、HTTP1においてリクエストの度に必要だったハンドシェイクはなくなる
- HTTP1とは異なり圧縮を使うので、リクエストのサイズがかなり小さくなる。結果、高速になる
- HTTP2の多重送信では1つのコネクションで複数の送受信を行う
これらの意味するところはHTTP1におけるテクニックは必要なくなるということであり、むしろ遅くしてしまうということだ。（ファイルの結合やスプライトによって）閲覧中のページには不要なアセットをロードし、シャーディングはDNSルックアップを引き起こす（シャーディングもHTTP2ならその必要がないのにも関わらず、だ）。
これからWebサイトを構築する際にはHTTP2で配信していくことも検討しよう。そしてその時は、HTTP2においては害となってしまうHTTP1のパフォーマンスのテクニックは使わないようにしなければならない。