フロントエンド監視
- フロントエンド
  - ブラウザあるいはネイティブなモバイルアプリケーションによってパースされて実行されるすべて
  - HTML, CSS, JS, 画像、もろもろ
- 見過ごされやすい
SPA: Single Page Applicationの普及により、HTTP 200 OKでも実行時エラーが起きたりする時代
- 伝統的なやり方では死活監視できない
フロントエンド監視のゴール: 素早くロードされること
- 元気に動き続けることではない
- 静的アセットの容量に影響される
継続的に改善していく戦略も提示する

6.1 遅いアプリケーションのコスト

6.2 フロントエンド監視の2つのアプローチ

リアルユーザ監視(RUM: Real User Monitoring)
- ホンモノのユーザートラフィックを使い、サーバーにメトリクス送信
- サイト自体にgaとかを仕込む
- ホワイトボックス監視といえる
シンセティック監視(synthetic monitoring)
- 作りものの(syntheticな)リクエストで測定
- curlコマンドとか
- WebpageTest.orgとか
- ブラックボックス監視といえる

監視対象の仕組みを理解することは有用(著者見解)
DOMのお勉強
- HTML: 静的なHTMLファイル。タグの階層構造
- DOM: ブラウザがHTMLやJSをパース・実行して構築される。ノードの階層構造
- 静的なサイトならHTMLとDOMは1対1対応
- 動的なサイトならHTMLとDOMは1対1対応にならない
  - JSによって動的にノードが生成・挿入されたりするから
- <script>はデフォルトで同期的に実行される
  - *.jsのロード～パース～実行完了まで、DOMのパースをブロック
- async属性をつけると非同期実行になる
  - DOMのパースの裏で呼んでくれる
  - 実行タイミングが保証されなくなる、とも
- 【補】deferってのもあるわね
  - DOMのパースをブロックせず、
    DOMContentLoaded直前に実行されるようになる
    - deferなスクリプトの全実行をもってDOMContentLoadedが発火する、というのが正しい気がする
要するにasyncじゃないスクリプトがたくさんあるとパフォーマンス劣化
- 【補】HTTPハンドシェイクに時間がかかるので、同じ容量・同じ処理負荷ならファイル数は少ないほうが良いでしょうね

Speed Index
実際に描画して、ページのロード完了を判断
- Speed Indexアルゴリズムにより数値化
視覚的なアプローチ
- ユーザーの体感の判断基準としては、ブラウザのメトリクスより正確
- ブラウザのメトリクスの含まれる詳細情報のいっさいを欠いているため、過度に依存しないこと

どう活用したらいいの？という意味かな
メトリクスを加工する
- 時刻を時間に変換
  - domComplete - navigationStart ... ページの総ロード時間
  - domInteractive - navigationStart ... ページがロードされたとユーザが体感する時間
サーバーに送信する
- 既存のツールを使う
  - StatsD, Graphite等
  - 面倒
- SaaS使う
  - GAとか
  - らく

JavaScript自体に蓄積用途のログ機構はない
- console.logはデバッグには使えるがログには使えない
- ユーザが見ようと思ったら見れちゃう(F12 -> console)
SaaS使うといい
- exception tracking serviceで検索

WebpageTest.org など(再掲)
CIと連携せよ
- 継続的にパフォーマンス改善
WebpageTestプライベートインスタンスが役立つ
- GitHub
- 【補】DockerHub
  - CI上でこのコンテナを動かしてパフォーマンス測定し、
    Artifactsに貯めたりSlackに通知したりできる

バックエンドが遅いとフロントエンドも遅くなる。 => 次章、バックエンド