はじめに

Webページの読込パフォーマンスについて，前回，単純なWebページの読込時間（PLT）から，その過程を含めた評価方法（Speed Index），コンテンツのメインとなる巨大な画像リソース（Hero Image）といった，さまざまなメトリクスについて紹介しました。Webページ読込のパフォーマンスは，JSやCSS，画像などのリソースが互いに干渉しあい，ブロッキングを起こすことで劣化するのです。

後篇では，Webが扱うリソースをより低いレイヤーから考えてみましょう。前篇はあくまでHTMLというレベルでの制約（ブロッキング）と最適化の話でしたが，本記事ではHTTP以下の制約とその最適化に目を向けます。その対策は，通信時に使われるTCPコネクションをいかに効率化するのかという点と，キャッシュをいかに有効活用するのかという点の，2つの観点から整理できます。

1. TCPコネクションの有効活用
   1. リソースの結合
   2. シャーディング
   3. SPDYとHTTP/2
2. キャッシュの有効活用
   1. HTTP Cache(RFC2616)
   2. PreloadとResource Hints
   3. AppCacheとService Worker

これらについて，掘り下げてみてみましょう。

1. TCPコネクションの有効活用

Webでは，サーバとクライアントの間をTCPと呼ばれるプロトコルを通じて接続します。

TCPは決して効率のよいプロトコルとは言えません。接続が開始されるまでに，DNSによる名前解決，TLSの鍵交換，そしてTCPのスリーウェイハンドシェイクと，様々な前処理を行い，多くの時間を要します。また一般的なデフォルト設定のOSは，TCPはスロースタートと呼ばれるアルゴリズムを採用しています。接続直後は，ネットワークのポテンシャルを充分には発揮できません。

サイズが小さなリソースを大量にサーバから取得するようなケースでは，TCPのオーバヘッドが大きく，読み込み速度が問題となります。1つのTCPコネクションで同時にダウンロードできるリソースは1つだけですが，先に挙げたブロッキングの制約も踏まえると，これが問題とはならなかったりもします。こうした経緯から，HTTP/1.1の時代，小さなリソースは極力結合され，今では慣習として行われるような状況です。

1-a. リソースの結合

リソースの結合では，Webの仕様を活用して出来る限り多くのリソースをつなぎ合わせることで，Webページが含むリソースの数を減らします。何をつなげるかによって，その呼び名も手法も大きく異なってきます。

JavaScriptやCSSは，メンテナビリティを配慮し複数のファイルに分割されることがあります。しかしながら，これらはサイズが小さいことが多く，読み込み順序が制限されていることもあります。ファイルを結合させることで，パフォーマンスを改善させることを「Concat」と呼びます。

ファイルサイズが小さくなるのはJSやCSSだけではありません。アイコンなどに活用されるような画像ファイルもまた，小さく大量になりがちです。これらを1つのファイルに結合し，CSSを使ってブラウザ上で切り取って使おうというアプローチもあります。それを「CSSスプライト」と呼びます。

これらの同じ種類のリソースを結合するというアプローチは，TCPのオーバヘッドを削減するうえで非常に有益です。ただ，最も効果的なものは，そもそも新しいTCPコネクションを作らないということです。HTMLドキュメント自体にJSやCSSを埋め込むことで，ブロッキングの時間を最小化するこのアプローチを「インライン化」と呼び，ATFの最適化においては非常によく活用されます。

リソースの結合によるパフォーマンスの最適化は，ブラウザから見れば少々無理をしたやり方であり，けっして正攻法とは言えません。真面目に扱おうとすれば，非常に煩雑なものになります。開発や運用の現場では，ツールを使って補うことが必須になります。

代表的なものだと，「Grunt」や「Gulp」といったタスクランナーが挙げられます。これらとプラグインを組み合わせ，開発などのワークフローに組み込んでいくとよいでしょう。