ウェブパフォーマンス計測の落とし穴
•
0 likes•410 views
Delivered in Akamai Japan Tech Week 2020. Presented on pitfall when your performance measurement is not really measuring what you expect. Also comes with a guide on how you can do "real-device" measurement with Google Lighthouse, using various Android and Linux tools.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ウェブパフォーマンス計測の落とし穴
Similar to ウェブパフォーマンス計測の落とし穴 (20)
More from Taisuke Yamada
More from Taisuke Yamada (20)
ウェブパフォーマンス計測の落とし穴
- 1. © 2020 Akamai1 ウェブパフォーマンス計測の 落とし穴 Taisuke Yamada <tayamada@akamai.com> Global Consulting Services
- 2. © 2020 Akamai2 このセッションのゴール ざっくばらんな技術トークを通じて、アカマイの エンジニアはこんな人達ですよ～と知ってほしい ● ウェブ計測の楽しさを知ってほしい ● 計測ツールの落とし穴含め、色々な使い方を知ってほしい ● ついでに、アカマイの計測サービスにも目を向けてほしい
- 4. © 2020 Akamai4 2018 - ウェブサイト最適化101 「何か遅くない？」の一言でどれだけアカマイ エンジニアがドギマギジタバタするかの話
- 5. © 2020 Akamai5 2019 - DIY Akamai Globe in 50 Minutes 最近のAkamai APIを使って自分だけの「回る地球でア クセス可視化」をやってみよう！話
- 7. © 2020 Akamai7 今日のお題: Google Lighthouse ● OSS公開されている計測ツール ● 導入が容易で、使いやすい ● CLIでもGUIでも使える ● Chromeを駆動して計測 ● Chromeにも内蔵（Chrome DevTools） ● Google PageSpeed Insightsのエンジン ● Google web.dev計測のエンジン
- 8. © 2020 Akamai8 PageSpeed Insightsのレポート例 わかりやすくて便利！ この点数でじたばたしている人も いるのでは？
- 10. © 2020 Akamai10 計測ツール？シミュレータ？評価ツール？ ● Lighthouseは色々な側面を持っている ○ 計測ツールとしての側面 ○ シミュレータとしての側面 ○ 評価ツールとしての側面 ● PSI/web.devはLighthouseの結果を利用する形
- 12. © 2020 Akamai12 計測ツール？シミュレータ？評価ツール？ 計測 シミュレーション 結果 点数評価 ？
- 13. © 2020 Akamai13 計測ツール？シミュレータ？評価ツール？ 計測 シミュレーション 結果 点数評価 ？多くの方が「計測結果」だと思っている数字は、違うものです。 レポートでは本当の計測結果は一切、見えていません。
- 14. © 2020 Akamai14 ちょっと前はこうだった(2018/5に転換) 計測 通信・処理の エミュレーション 以前のレポート 計測 計測結果の 予想シミュレーション 現在のレポート 評価評価
- 15. © 2020 Akamai15 つまり・・・ ● 以前は、精度はともかくネットワーク通信やCPU処理の レイヤで遅延を入れるエミュレーション上での計測 （DevTools throttling） ● 現在は、全速で計測した上で、様々な環境でどういう計測 結果になり得たかというのを、内部モデルで予測して出力するシミュ レーション （Lantern simulation）
- 16. © 2020 Akamai16 当時はまった落とし穴 数百回以上lighthouseでデータを取った後の FMPタイミングの分布。 ほぼすべてのサンプルで 1000ms以下で起きていることになっている 問題のページの 既知のTTFB目安 (~2500ms) ある日、lighthouse計測を依頼された時の結果データで 問題発覚。SearchページのTTFBは2500ms程なので変！ 描画の発生タイミング（左側に寄るほど高速） 累 積 確 率 描画タイミングの累積分布（ FMP: First Meaningful Paint）
- 17. © 2020 Akamai17 ページロード過程の各種タイミング Time to First Byte (TTFB) （必ず先に発生） First Meaningful Paint (後続過程のどこかで発生)
- 18. © 2020 Akamai18 本当はこうだった シミュレータの予測 本当の内部計測値 FMPはほぼ全ての ケースで1000ms程だよ 80%は3000-5000msで、 一部は10000ms位かかる
- 19. © 2020 Akamai19 本当の計測値はどこにある？ Lighthouseの生成レポートならば、 JSONで埋め込まれるか、JSON出力 で得られる(*1)。 各種サービスでは取得不能。 (*1) DevTools画面では、(Copy|Save) to … メニューで取得可能
- 20. © 2020 Akamai20 教訓 ● エミュレーションの場合、計測時間は長く、速度制御の 精度も課題はあるが実測値ではあるので、ある程度結果の 妥当性は保たれる ● シミュレーションの場合、計測時間が短く、また、様々な 環境での結果予測ができる点が強力。が、モデルの想定から外 れると完全に予想外の結果になることが モデルは改良できるにしても、中間レイヤでの変換・解釈を挟んで モデルの出力を見るだけだと、しばしば現実とのギャップが生じる
- 22. © 2020 Akamai22 Score != Speed
- 23. © 2020 Akamai23 Score != Speed 誰もスコアを使うとは言っていません。 見ているのはあくまでスピードです。そして、これらのツールは「スピード 向上のチューニングに役に立つ」とされているだけです。
- 26. © 2020 Akamai26 スコアやスピードにとらわれないこと ● あくまで基本は「サイトでの快適な体験」 ● スピード指標「だけ」を追求してページ構成や操作性が おろそ かになるのは本末転倒 ● さらにスコア指標「だけ」を過度に気にして（実際の）スピード認 識までおろそかになるのは・・・ 「あなたのサイト」で「あなたのお客様」にとっての快適性とは何か。 これを一番知っているのは「あなた」です。 それを支える１要素にスピードがあり、参考としてスコアがあるだけ。
- 27. © 2020 Akamai27 まとめます ● 一番意識すべきは訪問者の体験。その体験をよりよくする要素 としてスピードがある。 ● クローラを意識するなら、クローラに見てほしいデータを迅速に 供給するという方向で意識しよう！ ● スコアは気づきにはなるが、大きく変換・解釈が入るため追跡指 標としてはお勧めできない。実測値を見ましょう！
- 30. © 2020 Akamai30 色々な lighthouse オプション --output HTML表示以外に、JSONやCSVデータで結果を保存 --max-wait-for-load 遅いページでもタイムアウトせずに計測するのに使用 --throttling-method どんな方式で帯域などを（絞って｜絞ったことにして）（計測 ｜推定）するか --emulated-form-factor どんな端末として対象ページを読み込むか --chrome-flags Chromeに渡すオプション（ヘッドレス稼働など） --port Chromeを制御するのに使うデバッグポート --config-path / --preset 上のオプション含め、内蔵のプリセットまたは外部のJSファ イルで詳細パラメータを指定するのに使用
- 32. © 2020 Akamai32 --throttling-method=providedとは？ ● 要するに、simulated方式もdevtools方式も限界がある ● なので、本当に特定条件のパフォーマンスを知りたいなら、 自分で外部にその環境を用意して測ったら？というオプション
- 34. © 2020 Akamai34 スマートフォン（Android）との接続 --port Chromeを制御するのに使うデバッグポート localabstract:chrome_devtools_remoteport:12345 Android Debug Bridge 実機のAndroid端末を接続し、端末内Chromeが 開いているアプリデバッグ用のソケットをADBでリレー することでlighthouseと連携可能になる。 計測用サーバ イラスト：いらすとや
- 35. © 2020 Akamai35 実際のコマンドライン $ adb -d -s <serial> forward --no-rebind tcp:9222 localabstract:chrome_devtools_remote $ lighthouse --port=9222 --output=json --output-path=out.json --emulated-form-factor=none --throttling-method=provided --only-categories=performance --max-wait-for-load 30000 <url> デバッグポートをリレー 実機ベースの計測実施 自動計測する場合は、ポートをmonitなどで監視しつつ、adbリレーが 落ちたら再確立や端末・ブラウザの再起動を行うといった工夫も必要
- 36. © 2020 Akamai36 外部でネットワークエミュレーション SSID: FAST SSID: FASTER Socket API TCP/IP Stack Netfilter Traffic Control Driver Interface SSID: SLOW 実機を様々な回線状況下で試験したい場合は、無線LANも利用できる。 Linuxベースで無線LAN AP/ルータ構成を作ると、SSIDをそれぞれ別の ブリッジに収容するなどして Traffic Control (tc) で様々な制御ができる Linuxベースの無線LAN AP/ルータ ここを制御 すると・・・ 回線品質を 制御できる！ SSID: IPV6 イラスト：いらすとや
- 37. © 2020 Akamai37 実際のコマンドライン # tc qdisc del dev br-slow root # tc qdisc add dev br-slow root handle 1: tbf rate 1Mbit burst 1600 limit 3000 # tc qdisc add dev br-slow parent 1:1 handle 10: netem delay 100ms 10ms 25% loss 1% 回線品質の制御例 上記でTraffic Control層に token bucket filter と network emulation フィルタを挿 入し、前者で帯域、後者でレイテンシとパケロスの制御を行っています。これによっ てDevToolsよりもより高度な制御が可能です。
- 39. © 2020 Akamai39 再び、まとめます • ウェブの計測は「ものさしを当てて、大小を比較するだけ」と いう世界か らは程遠い。まだまだ揺籃期 • 何を見たいのか • 構成はどうなっていて、それを見るためには何を対象にすべきか • そこを測る道具はどういうものがあるのか • その道具は本当は何を測っているのか • さらに測れるものそのものも、現在進行中で整備途上 このスライドから２年、ウェブでの計測には様々な発展がありました。 しかし、いまも上の話はまだまだ生きています。 本セッションが皆様のよりよい計測の一助となれば幸いです mOm
- 41. © 2020 Akamai41 おまけ: AndroidでのChrome制御例 $ adb shell am start -a android.intent.action.VIEW -d about:blank 空ページで起動しつつ前面に出す(*1) $ chrome-remote-interface -p <cdp-port> list 現在開かれているタブ一覧を調べる(*2) $ chrome-remote-interface -p <cdp-port> close <tabid> 開かれているタブを閉じる $ adb shell am force-stop com.android.chrome 強制終了する (*1) このIntentのハンドラがChromeである必要があります。 (*2) npm i -g chrome-report-interface でインストールが必要です。
- 42. © 2020 Akamai42 おまけ: Androidでの接続制御方法 $ adb shell svc wifi (enable|disable) WiFiの有効・無効化 $ adb shell svc data (enable|disable) データ通信（モバイル回線）の有効・無効化 $ adb shell dumpsys connectivity | grep -A1 'Current Networks:' Current Networks: NetworkAgentInfo{ ni{[type: WIFI[], state: CONNECTED/CONNECTED, ... 接続状態の確認(*1)(*2) (*1) LTE接続の場合、”WIFI” ではなく “MOBILE[LTE]” のようになります。 (*2)さらに厳密を期す場合は、 adb shell pingなどで疎通確認を取ります。
- 43. © 2020 Akamai43 おまけ: AndroidでのWiFi制御例（アプリ方式） $ adb shell am start -n com.magic.talh.wifimanager/com.magic.talh.wifimanager.MainActivity -e wifi (true|false) WiFiの有効・無効化 $ adb shell am start -n com.magic.talh.wifimanager/com.magic.talh.wifimanager.MainActivity -e wifi connect -e ssid <SSID> -e pass <PASSWORD> 指定SSIDへの接続 特定SSIDへの接続などは、アプリを介した制御が現状必要です。 上記は Wifi Tool ADB の場合ですが、未知アプリの導入を避ける場合は https://github.com/steinwurf/adb-join-wifi などを元に自作下さい。
- 44. © 2020 Akamai44 おまけ: Androidでの端末制御 $ adb reboot 端末の再起動 $ adb shell screencap -p <path> $ adb pull <path> $ adb shell rm <path> スクリーンショットの採取 $ adb shell wm size [(reset|<width>x<height>)] $ adb shell wm density [(reset|<ppi>)] 画面解像度の確認・変更
- 45. © 2020 Akamai45 おまけ: AndroidでのWebViewデバッグ有効化 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { WebView.setWebContentsDebuggingEnabled(true); } Lighthouseでの計測とはやや外れますが、WebViewベースのアプリでは 上記コードを含めることで同様にデバッグポートを介したアクセスが 可能となります。これは chrome://inspect などよりアプリ内WebViewの パフォーマンス解析を行う場合に有用です。