フロントエンドの

パフォーマンスチューニング

〜ネットワーク編〜

2018-04-26

Monthly Hygge #3 at Kurashicom Inc.

Ryuta Hamasaki

@avosalmon

今日話すこと

1. 表示速度におけるフロントエンドの重要性
2. ネットワーク処理速度の計測
3. ネットワーク処理の改善手法

1. 表示速度における

フロントエンドの重要性

Webページの速度は

フロントエンドが一番重要

• サーバーは最初のHTMLを配信しているだけ
• HTMLを起点としたサブリソースへのリクエストがほとんどを占める

Webコンテンツのリッチ化

• ページ当たりの画像ファイル数の増加
• 動画も増えてきている
• JSのロジックも増える
• 放っておくだけで表示速度は確実に遅くなる

Webフロントエンド上の3要因

• ネットワーク処理 ← 今日はここ
  • 各種リソースのダウンロード
• レンダリング処理
  • HTML, CSSに基いて要素を表示
• スクリプト処理
  • JSによる処理

2. ネットワーク処理速度の計測

高速化への取り組み方

• Measure, Don’t Guess
• 当てずっぽうでシステムに手を入れても効果があるか分からない
• 計測した事実に基づいて改善する

計測ツール

• Chrome DevTools
  • Network / Performance / Audits
• 継続的なモニタリング
  • SpeedCurve
  • NewRelic
  • Calibre

ネットワーク処理の流れ

• DNS Lookup
• TCP Handshake
• SSL/TLS Handshake
• HTTP Request/Response

DevToolsの重要な指標

• DOMContentLoaded
  • DOMツリーの構築完了
• Load
  • サブリソースのダウンロードと評価
• TTFB (Time To First Byte)

3. ネットワーク処理の改善手法

HTTP/1

• 1つのTCPコネクションにつき1組のHTTP Request/Responseしか扱えない
• 複数のTCPコネクションにより並行性を確保（1ドメインあたり最大6つのTCPコネクション）

HTTP/2

• 1つのTCPコネクションで並列のHTTP Request/Responseを扱える
• HPACKによるヘッダー圧縮
• 取得リソースの優先度をコントロールできる
• サーバープッシュ

ALB with HTTP/2

• クライアントとALBの間はHTTP/2
• ALBとEC2の間はHTTP/1.1
• サーバープッシュは非対応

Amazon CloudFront now supports HTTP/2

CloudFront

• HTTP/2に対応
• S3単体はHTTP/2非対応

プロトコルの確認方法

ファイルサイズの削減

• 画像の圧縮
• テキストのgzip圧縮
• ビルドされたJSファイルの分割
  • Code splitting with Laravel Mix

不必要なリクエストの削減

• 全てのページで使っているわけではないCSSやJS
• 使っていないソーシャルプラグイン関連のスクリプト
• スクロールしないと見えない位置にある画像 → Lazy Load

Resource Hints

• 次のページで必要になるリソースを事前に取得しておく
• 未対応のブラウザでは無視されるだけなので、デメリットはない

Resource Hints

• DNS Prefetch
• Preconnect
• Prefetch
• Prerender

Service Worker

• バックグラウンドで動くJSファイル
• HTTPSのサイトにのみインストール可能
• Request/Responseへの割り込み
• サーバープッシュの受信
• バックグラウンド同期

Thank You!