引き続きこちらの本を読んでます。
今回は第二章。
2.1ページロードの速度を左右するネットワーク処理
ページロード時間の理想は1秒以内
→ ただ全ての処理を1秒以内に収めるのは非常に困難
ネットワーク処理に影響を与える要素
- リソースの大きさ
- HTTPリクエストの数
- ネットワークの通信距離
ネットワーク処理の流れ
HTTP/2によるネットワーク処理の効率化
- HTTPリクエストとレスポンスのやりとりを多重化・並列化
- HPACKによるヘッダ圧縮
- 取得リソースの優先順位
- サーバプッシュによる高度なリソース配信
＊一応HTTP/1でもTCPコネクションを複数持つことで並列化は実現してたっちゃしてた。
2.2ネットワーク処理の基本
フロントエンドが鍵を握る
ユーザーの待ち時間の大半はブラウザのネットワーク処理
とはいえHTMLを返すのに2~3秒かかってるならそれはサーバサイドの致命的な遅延。論外。
ネットワーク処理最適化の基本3原則
- データの転送量を小さく
- データの転送回数を少なく
- データの転送距離を短く
クリティカルレンダリングパス
- HTMLドキュメントのダウンロードと評価
- サブリソースのダウンロードと評価
- レンダーツリーの構築とレンダリング
＊CSSとJSのロード中はレンダリングブロックされる。断片化したCSSやJSのプラグインをたくさん読み込んでいる時に問題が起きやすいフェーズ
2.3ネットワーク処理の調査と計測
DevToolのNetworkパネルを使うべし
基本的な対策を確認するツール
DevToolsのAuditsパネル
PageSpeed Insights
Webページロード速度のモニタリング
「早すぎる最適化は諸悪の根源」
→定常的にモニタリングできる仕組みづくりが重要。手探りで改修なんてするもんじゃない。
モニタリングの種類
- 合成モニタリング（計測用の仮想環境を作り定期的に計測する）
- リアルユーザモニタリング（Webページに実際にスクリプトをしこんでおく）
モニタリングサービス
- WebPagetest
- SpeedCurve
- New Relic
- Calibre
ブラウザの様々な処理時間を計測するTimingAPI
- UserTiming（任意の場所に設定可能）
- NavigationTiming（リンクをクリックしたタイミングとか）
- ResourceTiming（サブリソース取得時）
- PaintTiming（Webページのレンダリング状況）
- ServerTiming（サーバないで発生した処理時間）
2.4 プロダクトに応じた指標作り
表示速度に対する間接的な指標
- ページロードに関わるブラウザイベント（DOMContentLoadedとload）
- リクエスト数とファイルサイズ
ただこれらの指標だけだとビジュアルの表示量などユーザ体験に基づく表示速度を捉えきれない。なので次のような指標が生まれた。
ユーザー体験に基づいた表示速度の指標
- First Paint（ページが表示され始めたとき）
- First Contentful Paint（コンテンツが表示され始めたとき）
- First Meaningful Paint（ユーザに意味のある表示になったとき）
- Time To Interactive（ユーザーの操作に応答できるようになったとき）