ウェブに関わる人なら知っておきたい

パフォーマンスの基礎とこれからby ふろしき

2015.03.20GREE MiniTechTalk

エンジニアをやっています川田です。Webのパフォーマンス関連のことで、いろいろと活動しています

ウェブエンジニア

・Software Design(技術評論社) 　2014年5-7月号 　「Web標準技術ではじめる 　Webパフォーマンス改善」 他

・html5j パフォーマンス部 ・日本Cordovaユーザー会 ・Microsoft MVP (Internet Explorer) ・W3C Web-perf WG 他

ふろしき (川田 寛)

Published Community

4年前、とある開発プロジェクトで フロントエンドの性能劣化にかなり苦しめられ 以来、Webのパフォーマンス技術を追っています

2.パフォーマンスの計測

3.パフォーマンスの改善

4. 最後に

アジェンダ

ギクッ

Webパフォーマンスの計測とちょっとした統計学、改善手法、最近の標準化の動向の話をします

1.ウェブの仕組み

パフォーマンスは企画段階から検討が必要で、運用時にも仕込みが必要です。しかし、今日はそんな話はしません

お話しないこと

1. 多重化と設計(見積もり)みたいなこと 2. 負荷テストとその手法みたいなこと 3. キャパシティプランニング(運用)みたいなこと

お伝えしたい人

・Webインフラエンジニア ・Webアプリ開発者 ・フロントエンドエンジニア ・技術的なことに興味があるWebデザイナ

今日は、Web標準なお話をします!!!

1. ウェブの仕組み

インターネットはなぜ遅いのか？

インターネットは、信頼性や効率を犠牲に、拡張性の高さを優先した、”IP”という技術を利用しています

R

R

R

R

Rクライアント (ブラウザ)

サーバ (Webサーバ)

健全な ネットワーク

悪い ネットワーク

新品な ネットワーク

オンボロな ネットワーク

赤ん坊

ツギハギな ネットワーク

おーい、おまえら… ちゃんとパケット 送ってくれよ(怒)

まだ？

捨てられたパケットポイッ

ばぶー

来ないね

もう限界や…

知ッテイル モウ少シマテ

偽物なら あるで？

ここ ほんと暇だな

インターネットはなぜ遅いのか？

IPのデメリットを埋める仕組み”TCP”は、信頼性を上げるために”ack”と呼ばれるパケットを返答します

クライアント サーバ

ネットワークA

R

ネットワークB

TCPデータ

TCPデータ

ack

ack

TCPデータ

TCPデータ

きたぞー

送ったぞー

TCPデータ

インターネットはなぜ遅いのか？

クライアント サーバ

ネットワークA

R R R

ネットワークB ネットワークC ネットワークD

2点間の距離が遠い場合は、ackの応答に時間がかかり、ネットワークリソースを十分に活かしきれません

TCPデータ

TCPデータ

TCPデータ

使い切れていない ネットワークリソース

ack

ack

ack

ack

きたぞー

送ったぞー

インターネットはなぜ遅いのか？

海外にアクセスしようものなら、ackの応答時間(Round Trip Time)に10倍以上もの差が出ることもしばしば

US カリフォルニア州166ミリ秒15ミリ秒

yahoo.co.jpさくら

インターネット

RTT= RTT=大阪 東京

KDDI

Softbank Telecom

yahoo.com

海底ケーブル (恐らくJapan-US経由)

R

RR

R R

R

R

RR R

R

R

R

R R

R

R

RR

R

R

R

RR

35ミリ秒

100ミリ秒

6ミリ秒 6ミリ秒

6ミリ秒 3ミリ秒

一定タイミングごと(一様乱数で少しズラした)にtracerouteを実行し、1週間分のRTTの平均値。 ※各ノードについて、L2トンネリングは配慮しないものとする。

25ミリ秒

インターネットはなぜ遅いのか？

今回、海底の光ケーブルは、2,100kmを 約100ミリ秒でRound Tripしていたが…

真空での光の速さが約30万km/秒なのに対して、今回の海底ケーブルは4.2万km/秒。もはや、人類は限界なのです

真空空間の光は、約30,0000kmを 100ミリ秒で進む。つまり…

１ 7：

通信技術が革新しても桁は上がらない時代 上位レイヤーは無駄を排除する努力をすべきだ!!

TCPデータ

インターネットはなぜ遅いのか？

クライアント サーバ

ネットワークA

R R R

ネットワークB ネットワークC ネットワークD

RTの問題を緩和しようと、輻輳制御の煩雑化を犠牲に、ウィンドウサイズや遅延ackなどいろいろ改善を進めましたが

TCPデータ

TCPデータ

TCPデータ

ack

ack

ack

まとめて 送ったぞー

全部 きたぞー

ウィンドウ サイズ

TCPデータ

もう次 いくからな？

つかおい! 待てって…

TCPデータTCPデータ

インターネットはなぜ遅いのか？

クライアント サーバ

ネットワークA

R R R

ネットワークB ネットワークC ネットワークD

TCP接続開始時はいまのところ、RTTがそのままクリティカルパスとなり改善されていません

いいよーTCP接続 するよ？

じゃ 開始して!

synsyn

synsyn

ackack

ack

ack

ackack

ackack

TCPデータTCPデータ

※注:APPENDIX-1も参考のこと

ウェブはなぜ遅いのか？

Webページの表示には、名前解決にSSL証明書取得など、様々なRT的処理がクリティカルパスになっていますが

公開鍵証明書

名前解決

リダイレクト

HTMLファイル本体

ブラウザ

CA

DNS

リダイレクトサーバ

HTTPサーバ

ウェブはなぜ遅いのか？

多くはチェーンが可能であり、実態としては2つ以上のサーバが関わることも少なくありません

公開鍵証明書

名前解決

リダイレクト

HTMLファイル本体

ブラウザ

CAチェーン

DNSのチェーン

リダイレクトサーバのチェーン

HTTPサーバ

ウェブはなぜ遅いのか？

ブラウザ

アドネットワーク など

CDN などJS/CSS

画像ファイル

広告関連 リソース

ソーシャル などソーシャル ボタン

HTMLの解釈と描画の段階に入ると、色んなサーバにあの非効率なサーバ接続処理を大量に開始するのですが

ウェブはなぜ遅いのか？

ブラウザ

アドネットワーク など

CDN など

当然、リソースの全てに、SSLや名前解決、リダイレクトが絡むわけで

JS/CSS 画像ファイル

広告関連 リソース

ソーシャル などソーシャル ボタン

ウェブはなぜ遅いのか？

ブラウザ

アドネットワーク など

CDN など

さらにチェーンできるとなると、潜在的には相当な数のサーバ接続が関わっているわけです

JS/CSS 画像ファイル

広告関連 リソース

ソーシャル などソーシャル ボタン

ウェブはなぜ遅いのか？

どれぐらいのサーバ接続があるのか？サーバとの接続だけでも40オーバーが普通なので、100超えは割とよくあること

http://www.atmarkit.co.jp/

82本 44本

＠ITのトップページ Qiitaの記事http://qiita.com/nhiroki/

items/eb16b802101153352bba

First Viewアクセスで特徴的なWebページを3つほどご紹介 (2015年3月18日現在)

Pixivのイラストページhttp://www.pixiv.net/member_illust.php?

mode=medium&illust_id=49316209

108本2回目のアクセス

17本2回目のアクセス

11本2回目のアクセス

127本

モバイルはなぜ遅いのか？

さらに、モバイルにおいては帯域の小ささがWebの様々な手続きを全体的に遅くし

通信リソース小さいモバイル(3G回線)において、 最初の600msは手出しできない遅延

有線と比較すると圧倒的なリソース不足、帯域が小さい

HTTP+TCP+IP

モバイルはなぜ遅いのか？

あげく、通信は全機能の中で2番目にバッテリー消費が大きいため、通常は節電のために非アクティブ化されます

Power On

モバイルの場合、ネットワークインタフェースは普段OFFになる! 接続前にONにしなくてはいけない…

※ここで言うネットワーク・インタフェースは 　Push Notificationで利用されるものとは別のもの!!

OMG :(

HTTP+TCP+IPレイヤー物理レイヤー

これでは遅くなって当然!!

Webのパフォーマンスは悪くなる宿命にあるわけですが

これでは遅くなって当然!!なのに…なのに!!

そんなこと、利用者からしてみれば、知ったこっちゃありません

2. パフォーマンスの計測

どういう状態を遅いというのか？

平均は約700ミリ秒？？ …言うほど、遅くないように見えるけど?

計測するのはいいのですが、ほんの数件だけでは特徴がさっぱり見えません

・１回目：534ミリ秒 ・２回目：812ミリ秒 ・３回目：742ミリ秒

さっそく、計測してみた

？？

どういう状態を遅いというのか？

では10件程度でしょうか？これでもまだ、全体が見えません

10PVほど収集。件数(件)

読込時間(ミリ秒)

10回やると平均800ミリ秒超えた？ けど、そんなに遅い？

本当にこんな分布？

？？

どういう状態を遅いというのか？

1,000PVほど収集すると…

ん？これ、よく見たら対数正規分布…

多くの値を使うと状況は変わります。Webの速さが、対数正規分布っぽいということに気がつきませんか？

件数(件)

読込時間(ミリ秒)

どういう状態を遅いというのか？

この分布だと少数の異常値が含まれる…

先ほどの図では見えませんでしたが、対数正規分布の場合は、少数の異常な値が交じることになります

Webページ表示時間の順位(位)

読込時間(ミリ秒)

少数の異常値速すぎ。恐らく何かエラーがある

異常に遅すぎ。恐らく何かエラーがある

どういう状態を遅いというのか？

平均値で評価するとσ(信頼性)の大きさやμ(遅さ)が見えません。ここはパーセンタイルで評価するのが一般的です

Webページ表示時間の順位(位)

50パーセンタイル → 832ミリ秒

70パーセンタイル → 1,310ミリ秒

90パーセンタイル → 3,428ミリ秒

(※50%のアクセスが832ミリ秒以下になる)

(※70%のアクセスが1,310ミリ秒以下になる)

(※90%のアクセスが3,428ミリ秒以下になる)

30パーセンタイル → 531ミリ秒(※30%のアクセスが531ミリ秒以下になる)

パーセンタイルで遅さを評価。こ、これはッ!!!!!

30回に1度は10秒超え!? 50回に1度は30秒超え!?これが原因?

読込時間(ミリ秒)

？？

…普通に速くね？

9割が3秒台だし!!

ただ、考えてみて下さい

このグラフの軸 こいつらは一体、ナニモノ？

…グラフで使っていた軸、本当に大丈夫ですか？

欲しい情報(母集団)に含まれる値を”標本”を呼びますが、それの質が低いと母集団は推測できません

↓この人はなぜ、遅いと感じたのか？

標本がなければ推測できない

仮説1) 100回に1度のとても悪いタイミングにあたり、 　　　 その瞬間だけは確かに遅かった。 仮説2) アクセス数が多くてサーバ負荷が高いため、 　　　 その時間帯は常に全ユーザが読み込みが遅かった。 仮説3) CSSの読み込みが遅く描画をブロックするため、 　　　 常に遅く描画された。

特定の時間に 偏りのあるサンプルは

使い物にならない

HTML読込時間は 使いものにならない

サーバサイド・モニタリング

確実に値が取れる、環境の制約を受けにくい ブラウザ上のイベントが見えない

トータルの速さ、JSの実行結果を含めた計測ができる 値をドロップすることがある、環境の差異が大きい

良 悪

良 悪

質の高い標本を得る手段は増えています。最近では、サーバサイドだけでなく、クライアント上でも計測ができます

サーバ上でHTTPリクエストなどをモニタリングして計測。

ブラウザ上で様々な処理をモニタリングして計測。

リアルユーザ・モニタリング

標本がなければ推測できない

リアルエンドユーザによる計測

シミュレーションによる計測

実際のユーザの置かれている状況を丸裸にできる 標本として正しいのか見極めが難しい値がある

ブラウザの機能にないところまで計測できる 単位時間あたりのPV数など、得られない値がある

良 悪

良 悪

データに乗っているノイズから解放してくれる、シミュレーションによる計測からも目が話せません

実際に運用しているサーバやユーザのブラウザ上で計測。

ブラウザの動きをシミュレートして運用中のサーバにアクセスし計測。

標本がなければ推測できない

サービスがゴマンとあるわけですが、私はオープンソースの人なのでよくわかりません！オススメ、教えてください

私が知っている範囲(知人レベル)で有償系：

無料系：

オープンソース系 Make the Web Faster

PageSpeed Insights modern.ie Site Scan

→モバイル系 　@massieさんのところが 　もいちょっとしたら…多分

→Webサイト系 　@takehoraさんが 　代理店で販売

Yahoo! Boomerang 　→恐らく停滞

→よく目にする…

標本がなければ推測できない

よくわからないけど 対策のきっかけが欲しい!!

何から始めたらいいのかわからないようでしたら、まずは手頃なサイトスキャンに検査を委ねてみましょう

→ とりあえずのサイトスキャン

modern.ie Site Scan①

②

Web制作者、アプリ開発者向け制約こそあるがMicrosoftらしい親切さがある

特徴

1. 検査項目がかなり豊富2. 日本語対応、説明が親切3. MS製品と相性がいい4. モバイルとデスクトップは 　 同じWebページが前提

modern.ie Site Scan

計測とかよくわからない！そういう人は、とりあえずこのサービスに頼ってみてください

Webpagetestアプリ開発者、インフラエンジニア向けオープンソースでGoogleのアイデアが入っている

特徴

1. 指標値がかなり豊富2. 自前のサーバで使える3. OSS系ブラウザが使える

ガッチガチに数値と睨めっこしたいひとは、このOSS製品がかなりオススメです

4. モバイルとデスクトップは 　 別々に対応してOK

ブラウザ上でのパフォーマンス計測は Web標準の力を必要としている!!

何から始めたらいいのかわからないようでしたら、まずは手頃なサイトスキャンに検査を委ねてみましょう本章の最後に、ブラウザのパフォーマンス計測で得られる値、指標値の標準化について説明します

ブラウザごとに値の意味が違っていたら、役に立たない!

ブラウザ上での計測

Webは、サーバ環境の統一はできてもブラウザはバラバラ。標本用途には、標準化された値が必要なケースがあります

Web標準として、計測方法や値の意味を定義

ブラウザ上での計測

例えば、Webページ読み込み時に発生する様々な事象がいつ起きたのか？これはもう標準で定義されています

ハイパーリンクのクリック。 ナビゲーションの手続き開始。

ビュー内が白くなり、 DOMの読み込みを開始。

全てのコンテンツの読み込みが完了し、JSイベントを実行。

Navigation Start

DOM Loading

Load Event Start

ex.1427014713416

1427014719823

+ 6,407 ms

1427014803940

+ 84,117 ms

ブラウザ上での計測

JavaScript API

開発者ツール

Web標準

”開発者ツール”と”JavaScritp API”の2箇所から、その値を確認することができます

その場で 確認したい!!

どこかに 蓄積したい!!

デバッグ用途

分析用途

旧時代的かつもっとも実用的な仕様：

Navigation Timing

2010年、IE9に実装すべくかなりの早さで仕様を固めたのがNavigation Timingです。実用的ですが、まもなく消えます

ブラウザ上での計測

Webページ遷移時のパフォーマンス 計測方法と値の定義

JavaScript APIの仕様

W3C勧告で安定しているけど 数年後には人々の記憶から失われることになる

ちなみに、雑誌でもWebでも、日本語の詳しい解説はだいたい私が頑張りました。…か、買ってくださいね(汗)

ブラウザ上での計測

仕様の詳しい説明はこちら↓ Webだとこちら↓

https://html5experts.jp/furoshiki/6242/

旧時代的かつもっとも実用的な仕様：

Navigation Timing

これからのパフォーマンス計測の標準と言えば：

Performance Timelineと…

次世代は、Performance Timelineという仕組みを通じて、様々な計測値が高精度で取得できるようになります

ブラウザ上での計測

＋Navigation Timing 2 ＋Resource Timing ＋Frame Timing ＋User Timing ＋Server Timing

計測対象とその仕様 精度に関する仕様＋High Resolution 　Time ＋High Resolution 　Time 2※注:APPENDIX-2も参考のこと

ここは以前まで Navigation Timing だった!!

ブラウザ上での計測Chrome 41では、ちゃんとお引っ越し済みなので 少しだけ遊べる状態。

ちなみに、Chromeは41から体験できるようになりました

仕様はほとんど 固まってないけど(汗)

目玉の一つがネットワークの状態の可視化で、今もなお更に詳細化しようと検討しています

ブラウザ上での計測1. ネットワーク周りの計測が強化された!!

ブラウザ

チェーンされたサーバたち

↑これができるように、今まさに検討中

計測

計測

計測

計測

計測

Server Timing

この仕様が発展すると、TCPのおかげで海底ケーブルをいっぱい往復するパケットたちを、妄想して楽しめるわけです

ブラウザ上での計測1. ネットワーク周りの計測が強化された!! ↓ここを往復してる!!

Server Timing

画像ファイルやCSS/JSの読み込みも、計測値を拾えるようになりました。つい最近、実用フェーズに入ってます

ブラウザ上での計測2. HTMLファイル以外のリソースのパフォーマンスを可視化

昨年末、ようやくFirefoxが 35で実装したので

これで使い物になりそう!!ブラウザ

JS/CSS 画像ファイル

広告関連 リソース

ソーシャル ボタン

計測

計測

計測

Resource Timing

画面遷移だけでなく、アニメーション的な振る舞いに対して、フレームレートを計測できるようにする予定です

ブラウザ上での計測3. アニメーション/フレームレートも可視化する!(これから)

Frame Timing

また、速さの計測だけでなく、エラーもロギングして取得できるようにする予定です

ブラウザ上での計測4. エラーも探れるようにする!(これから)

少数の異常値速すぎ。恐らく何かエラーがある

異常に遅すぎ。恐らく何かエラーがある

Network Error Logging

巨大なファイルのアップロードやダウンロードも、ユースケースに含めていく方針です

ブラウザ上での計測5. 巨大ファイルのダウン/アップロードも計測する!(これから)

ブラウザ サーバ

ZIP

動画 画像

Resource Timing

Power On

モバイル固有の問題にだって、対応していく予定です

ブラウザ上での計測6. モバイルをしっかりと捉える!(これから)

ネットワーク インタフェースの 活性化の時間も可視化

Navigation Timing 2

ブラウザ上での計測http://www.w3.org/wiki/Web_Performance/Publications

3. パフォーマンスの改善

HTTP1.x

HTTP1.xの時代、通信効率を上げることについて、TCP接続がネックになっていました

HTTP1.xのインフラ戦略

通信時間を短縮したい!! ・TCP接続のオーバヘッドを減らす → KeepAlive ・接続後の通信量を減らす → gzip ・既にロードしたことある場合は読み込まない → Expires

通信効率を上げたい!! ・JS/CSSファイル数を減らす → Concat ・画像ファイル数を減らす → CSS Sprite ・ファイル読込の並列性を上げる → ドメインシャーディング

TCP接続を減らそうとしつつも、一方では増やして並列性を高めようとする矛盾

ブラウザ サーバ

HTTP1.xのインフラ戦略

並列性が足りないから増やすぞ!!

オーバヘッド減らすためにまとめるぞ!!

ファイル数分、TCP接続や!!

▼

▼

▼

どうなる!?

SPDY?

HTTP/2

HTTP/2になると、接続数はもちろん減ります。時代の流れからして、必然の傾向です

ブラウザ サーバ

HTTP/2のインフラ戦略

並列性が足りないから増やすぞ!!

オーバヘッド減らすためにまとめるぞ!!

ファイル数分、TCP接続や!!

▼

▼

▼オーバヘッドを減らすためにまとめるぞ!!

通信周りに対する問題は、HTTP/2の登場である程度解決してくれるらしいです。らしい？何が言いたいかと言うと

通信時間を短縮したい!! ・TCP接続のオーバヘッドを減らす → HTTP/2 !? ・接続後の通信量を減らす → HTTP/2 !? ・既にロードしたことある場合は読み込まない → HTTP/2 !?

通信効率を上げたい!! ・JS/CSSファイル数を減らす → HTTP/2 !? ・画像ファイル数を減らす → HTTP/2 !? ・ファイル読込の並列性を上げる → HTTP/2 !?

HTTP/2世代のインフラ戦略

…ええ、怖いですよ。

定石が変わってしまったので、1.xのインフラを2にそのまま移すのいうのは難しく、何も考えなかったら悪化します

HTTP/2世代のインフラ戦略

HTTP1.xインフラ≠HTTP/2インフラ

えっ、今SPDY/3!? あ、はい。頑張って下さい…

もうやることなくなるの？

アプリ開発者はやることはもうなくなったのでしょうか？いえ、それがまだ残っています

アプリの特性に合わせた、パフォーマンスの改善技術というのが作られています

インフラ

アプリ

ビジネス

HTTP/2という 汎用的な

手段で解決

HTML5による アプリ特化な

手段で解決

やること まだ あります。

画面を描画する過程、読み込むファイルの中の作りにまで踏み込んで見えるのは、アプリ開発者だけです

HTML5世代のアプリケーション戦略Navigation Start

Unload

First Paint

DOMContentLoaded

Above to fold(ATF)

Loaded

→ クリック or サブミット

→ 画面を白くする

→ 描画を開始する

→ DOMの読み込みを完了する

→ 最初に見えるスクリーン内の描画を完了する

HTML

JS/CSSJS/CSSJS/CSS

ImageImageImage

First Viewの最適化 ・Resource Priorities 　ファイル(リソース)の読み込み優先度の制御 ・Resource Hints 　別ページで使われるファイルやページ全体を先読み Repeat Viewの最適化 ・Service Worker 　 オンライン時の振る舞い・キャッシュの細かい制御

作りを把握した上で、アプローチする方法も日々生み出されています

HTML5世代のアプリケーション戦略

ATFの最適化 ・CSS/JSのインライン化 　CSS/JSをHTML内に展開しておく モバイルでのGPU活用 ・CSS3 Animation 　GPUを有効活用してスムーズな動きを作る 通信量の最適化 ・画像ファイルの変換、Webフォントのサブセット化 　インフラ化しようと思えばできるか…

そして相変わらず、泥臭い方法が残っていて、それもWeb標準側でカバーしようとはしています

HTML5世代のアプリケーション戦略

4. 最後に

・HTTP1.x系からHTTP/2への移る時期、つらい。 　クラウドの普及で若干圧されがちだった、 　インフラエンジニアが再び脚光を浴びる！？

・モバイルだと、Webがユースケースに合わない、つらい。 　オフライン強化、リッチアプリ風の作りが要求されたり、 　市場価値を取り戻すまでしばらく耐える時期かも！？

・Googleがモバイル中心主義になりつつあり、 　Web標準側もモバイル特化の改善に舵を切っている感じ。 　※Microsoftは、モバイルとデスクトップをくっつけたい派っぽい。

一言だけコメント

インフラ屋さんもアプリ屋さんも、しんどい時期が続きそうですね

・Google - Ilya Grigorik一派 　→実装最速 ・Microsoft - Tobin Titus一派 　→実装速度は2番手ぐらい。かなり速い方。 ・Mozilla 　→少し後ろを走りつつも追っている。 ・Apple

　→ ＼(^o^)／

肝心のアダプションについて

しかも残念なことに、Appleは全くもってパフォーマンス系の機能をサポートしてくれません

モバイル…無理なのか!?

ところが…

喜ぶ人々。

・Google - Ilya Grigorik一派 　→実装最速 ・Microsoft - Tobin Titus一派 　→実装速度は2番手ぐらい。かなり速い方。 ・Mozilla 　→少し後ろを走りつつも追っている。 ・Apple - Ryosuke Niwa一派!? 　→ 2015年は本気出す…!?

2015年も パフォーマンスの技術はもっと良くなる!!

肝心のアダプションについて

これからAppleもパフォーマンス系の機能に力を入れてくれそうで、2015年もますます発展が期待できそうです

Thank You!!@kawada_hiroshi

速いは楽しい!!

APPENDIX-1

TCP Fast Open(TFO)

→

クライアント サーバ

…こんなの、私の知っているTCPじゃない けど、なんかわくわくする!!

syn + HttpRequest

ack + HttpResponse

TCPデータ

APPENDIX-2

Performance Timelineと他の仕様との関係 JavaScript APIの仕様

Performance Navigation Timing 2

Resource Timing

Frame Timing

User Timing

+ getEntries() + getEntriesByType() + getEntriesByName()

Performance Entry

+ name + entryType + startTime + duration

Written by UML 2.5 Class Diagram

Performance Timeline

<<interface>>

http://www.w3.org/TR/performance-timeline/

https://w3c.github.io/navigation-timing/

https://w3c.github.io/resource-timing/

https://w3c.github.io/user-timing/

https://w3c.github.io/frame-timing/

Webページ読込時間の計測

リソース読込時間の計測

リフレッシュレートの計測

任意時点の計測

<<interface>>Server Timing https://w3c.github.io/server-

timing/

サーバ接続時間の計測

1

0..*

implements

Navigation Timing→Performance Timeline JavaScript記述方法の変化

APPENDIX-3

performance && performance.timing && (function() { var timing = performance.timing; var loadTime = timing.loadEventEnd - timing.navigationStart; console.log( loadTime );

})();

performance && performance.getEntriesByType && (function() { var timing = performance.getEntriesByType(“navigation”)[0]; if( timing ) {

var loadTime = timing.loadEventEnd - timing.navigationStart; console.log( loadTime );

} })();

▼ Navigation Timing

▼ Navigation Timing 2

1. High Performance Browser Networking - Ilya Grigorik (O’Reilly Media) 　 http://chimera.labs.oreilly.com/books/1230000000545 2. Mobile Analysis in PageSpeed Insights (Google Developers) 　 https://developers.google.com/speed/docs/insights/mobile 3. Kokusai Cable Ship Co.,Ltd 　 http://www.k-kcs.co.jp/english/topic_unity.html 4. WebPagetest.org 　 http://www.webpagetest.org/ 5. modern.IE Site Scan 　 http://modern.ie/ja-jp/ 6. W3C WEB PERFORMANCE WORKING GROUP 　 http://www.w3.org/2010/webperf/ 7. Evaluating network performance 　 https://developer.chrome.com/devtools/docs/network 8. Hello HTTP/2, Goodbye SPDY 　 http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html 9. rniwa from Apple just joined the Web Performance WG 　 https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0055.html

Reference