超速！ Webページ速度改善ガイド 第三章
引き続きこちらの本を読んでます。
第3章 ネットワーク処理の調査と改善
3.1 サイズの大きいリソースの調査と改善
- 当たり前っちゃ当たり前だが、サイトが遅い原因の一つ。
- NetworkパネルのSizeカラムをクリックして降順で並び替えるとよい。
- ダウンロードに時間がかかっているリソースはtotal duration
- 適切な最小化が行われていないテキストリソースに対してはgZip圧縮しろ
-
gzip以外にもgunzip、zopfli、brotliなどがある。
JavaScriptの圧縮に関して、webpackであればCodeSplittingという機能を使えばビルドするファイルを分割できる。
3.2待機時間が長いリクエストの調査と改善
TTFBを確認すべし。
TTFB（Time To First Byte）とは、ブラウザがWebサーバーにリクエストを送信してから、Webサーバーが最初の1バイトの応答をブラウザに返すまでの時間のこと。
- リソースへの事前接続
非表示の<img>要素を入れて事前リクエストを送るとか。結構力技だな…
他にはResourceHintsという仕様の策定が進められているらしい
- キャッシュによるリクエスト結果の再利用
Web StorageとかIndexedDBに保存しておく。
ETagやCache-Controlを適切に設定すべし。
Etagってのはリソース自体は返さないから送信コストが抑えられるぽい
CacheAPIとやらもあるらしい。ServiceWorkerを利用するらしい。
- CDNからの配信
通信経路の問題を解決
3.3 リクエスト数の調査と改善
- 不必要なリクエストの削減
- 画像の遅延読み込み
- 静的リソースの結合
ただし結合するとフィイルサイズがでかくなるので、なんでもかんでも結合すればいいというわけではない。
【参考】
簡単にいうと、複数の画像を一個にまとめて必要なものだけ参照できる？→リクエスト数の削減？
3.4 クリティカルレンダリングパスの調査と改善
スクリプト処理によるブロッキング
ファイルのダウンロード後からDomContentLoadedまで時間がかかってる場合はスクリプトの実行によって遅延が発生してるかも。
スタイリングされずに表示されるコンテンツ
FOUG（Flash of Unstyled Content スタイルが適用されていないコンテンツが表示されること）はできるだけ避けるべし。
DomContentLoadedイベントより前に読み込んでいるJSがあったらDOMツリーの構築をブロッキングしている可能性が高い。FOUGの原因。遅延読み込みが可能ならそうしたほうがいい。
コンテンツに影響しないスクリプトの非同期実行
<script async>・・・DL完了後スクリプト実行までする
<script defer>・・・DL完了後スクリプト実行はDOMツリー構築まで。（つまりDOMツリー構築のブロッキングをしない）
3.5 Webフォントに関わるリソース調査と改善
Webフォントのファイルサイズが大きければそれだけ表示に時間がかかる。
- Webフォントは
- 圧縮すべし
- キャッシュすべし
- サブセット化すべし
Font Loading APIを使えばJavaScriptにより任意のタイミングでWebフォントのリクエストを行える。ちらつきを抑えるために有効な場合がある。
font-displayというプロパティも仕様策定中らしい。
