超速! Webページ速度改善ガイド 第二章

超速! Webページ速度改善ガイド 第二章

引き続きこちらの本を読んでます。

 

今回は第二章。

 

2.1ページロードの速度を左右するネットワーク処理

ページロード時間の理想は1秒以内

→ ただ全ての処理を1秒以内に収めるのは非常に困難

ネットワーク処理に影響を与える要素

  • リソースの大きさ
  • HTTPリクエストの数
  • ネットワークの通信距離

ネットワーク処理の流れ

  1. DNS解決
  2. TCP接続
  3. HTTPリクエス

HTTP/2によるネットワーク処理の効率化

  • HTTPリクエストとレスポンスのやりとりを多重化・並列化
  • HPACKによるヘッダ圧縮
  • 取得リソースの優先順位
  • サーバプッシュによる高度なリソース配信

*一応HTTP/1でもTCPコネクションを複数持つことで並列化は実現してたっちゃしてた。

 

2.2ネットワーク処理の基本

フロントエンドが鍵を握る

ユーザーの待ち時間の大半はブラウザのネットワーク処理

とはいえHTMLを返すのに2~3秒かかってるならそれはサーバサイドの致命的な遅延。論外。

ネットワーク処理最適化の基本3原則

  • データの転送量を小さく
  • データの転送回数を少なく
  • データの転送距離を短く

クリティカルレンダリングパス

  • HTMLドキュメントのダウンロードと評価
  • サブリソースのダウンロードと評価
  • レンダーツリーの構築とレンダリング

CSSJSのロード中はレンダリングブロックされる。断片化した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 プロダクトに応じた指標作り

表示速度に対する間接的な指標

  • ページロードに関わるブラウザイベント(DOMContentLoadedload
  • リクエスト数とファイルサイズ

ただこれらの指標だけだとビジュアルの表示量などユーザ体験に基づく表示速度を捉えきれない。なので次のような指標が生まれた。

ユーザー体験に基づいた表示速度の指標

  • First Paint(ページが表示され始めたとき)
  • First Contentful Paint(コンテンツが表示され始めたとき)
  • First Meaningful Paint(ユーザに意味のある表示になったとき)
  • Time To Interactive(ユーザーの操作に応答できるようになったとき)
2019-02-11T09:40:55+00:00

About the Author:

齋藤大地
取締役。大手Sler出身。三度の飯よりコーディングが好きな人間。得意じゃないイラレやフォトショなどの仕事をしている時は目が死んでいる。使用言語は、Swift、Ruby(Ruby on Rails)、PHP、Javascript、Kotlin(ちょっとだけ)。

Leave A Comment

TWITTER

ご相談ください

 確認ページはございません。内容をご確認の上チェックを入れてください