パフォーマンス・ウォーターフォール

SpeedIndex は算出する指標だったが、ここでは実測の指標を見て行く。

watagall view

これは WebPageTest というサービスでとった自分のサイトの測定結果。

シンプルなページなので結果もシンプルだ。

この辺のポイントまでとれれば現状十分かと思われる。

この場合、ばっと見ても TTFB(Time To First Byte) と SSL Negotiation が支配的に見える。

ちなみに図中上の表には SpeedIndex も出ている。

DNS の解決は、ホストの名前解決だ。解決結果がキャッシュされてればいいが、されてなければ必須となる。

initial connect は TCP の接続確立で、要するに 3 way handshake。

SSL Negotiation は、 HTTPS ページでの TLS セッション確立。

これだけでもそれなりに RTT があるため、無視は一切できない。

ブラウザはサーバに接続し、リクエストを投げて、レスポンスを受け取る。
TTFB は、そのレスポンスの最初のパケットを受け取った時間を現す。

つまり、サーバ内で解決する Response Time に、双方間でのネットワークが消費する時間が加えられたものになる。

つまり、クライアントから見た「サービスの速さ」は実際にはこっちの方がリアルに現されていると言えそうだ。どんなユーザもネットワーク環境が良好なところにいるとは限らないという点が加味できる。

コンテンツとして HTML を取得すれば、それを解析し DOM を構築し、必要なサブリソースを取ったりなんかして、画面に表示を始める。

解析を始めた瞬間が Start Rendering で、その結果画面に絵を表示し始める瞬間がこの First Paint になる。

例えば Start Rendering と First Paint の間に時間が空いたようであれば、レンダリングプロセスの途中、サブリソースの取得などでレンダリングがストップする問題などが見つかる。

SpeedIndex を向上するためには、 First Paint はなるべく速い方が良いという視点に立てば、このレンダリングがスムーズにペイントを始められるようなチューニングも見えてくるなど。

DOMContentLoaded は、ここに書かれている通り、HTML の取得と解析が終わった時点で発火する。

その後 HTML に付随する全てのサブリソースが取得されて、そのページを構成する全てが取得された時点で発火するのが onload となる。

つまり、 DOMContentLoaded の遅延がある場合、 HTML の解析をブロックする何かがある可能性を示唆し、DOMContentLoaded と onload の間にある時間は、サブリソースの取得でもたついている可能性を示唆する。

これは JS 書く時にどっちを取るかという話でもよく使われるが、実際にはブラウザの中で何がどこまで進んでいるのかを知るという意味で、結構重要な指標だったりする。