3章ネットワーク処理の調査と改善

3.1 サイズの大きいリソースの調査と改善

まずサイズが大きいリソースをブラウザの開発者ツールで特定する。サイズが大きいリソースは以下の理由により速度を悪化させる

リソースのサイズを小さくするには以下の方法がある

テキストリソース（HTML, CSS, JS）の最小化
- uglify-esなどのツールを利用して、不要な空白を削ったり変数名を置き換えることでサイズを小さくする
- gulp, webpackなどのタスクランナーを使うと良い
配信時の圧縮
- 配信サーバで動的にgzip形式に圧縮して配信する
- gzip以外にも、圧縮率を高めたzopfli, brotliなどの圧縮アルゴリズムがある
- brotliは新しく圧縮効率が高い。IE, Android Browser以外の最新ブラウザは対応している
- css, jsなどの静的コンテンツは、あらかじめ圧縮してサーバに配置すると良い
画像の最適化
- 適切な解像度で画像をダウンロードする
  - 小さい領域に高解像度の画像を表示しても意味がない
- 詳しくは8章
JSのサイズ削減
- 不要なライブラリを削除する
- ページごとなどの粒度でファイルを分割する

リクエストを送信してからレスポンスが返ってくるまでの待機時間が長いリクエストを特定する。開発者ツールでWaitingやTTFB(Time To First Byte)の時間を見れば良い。

改善方法は以下の通り。

リクエスト数が多いと速度に悪影響がある。特にHTTP/1ではリクエストのオーバーヘッドが大きく、同時接続数の上限もある。

リクエスト数が多い場合、不要なリクエストを削る。以下が典型的なパターンである

また、静的リソースは結合することでリクエスト数を減らすことができる。ただし、HTTP/2ではリソースを結合しすぎないほうが良い場合がある。リソースのサイズが小さいほうが早く評価を始められるため。

クリティカルレンダリングパスを最適化するため、レンダーツリーの構築を早くする。すなわちブラウザのDOMContentLoadedイベントを早くする。

前提

ほとんどの場合（scriptタグがある場合）、ブラウザはCSSOMツリーの構築を待ってレンダーツリーを構築する。
スクリプトを実行している間、DOMツリーの構築はブロックされる。
- スクリプトによりDOMが変えられる可能性があるため
CSSを非同期でロードすると、スタイルが適用されていないコンテンツが表示される可能性がある。
- FOUC(Flash of Unstyled Content)とゆう。
- Webフォントのロードを伴う場合や、body要素でcssを読み込む場合などに起きる

以上の前提に基づく改善方法

CSSは最も優先してダウンロードし、JSのロードは遅らせる。
- ATFに関わるCSSのみ<link rel="stylesheet">でロードし、それ以外は遅延ロードするのも良い
メインコンテンツに影響しないスクリプトは非同期で実行する
- <script defer>や<script async>を利用する
- 以下のようにjsからscriptタグを生成する方法もあるが、プリロードスキャンの対象にならないため<script async>の方が望ましい。

const script = document.createElement('script');
script.src = 'hoge.js';
document.head.appendChild(script);

興味がないので省略