D.Horiyama's output

入門監視ch6 フロントエンド監視

勉強メモ監視

出典: 

  • フロントエンド監視

    • フロントエンド

      • ブラウザあるいはネイティブなモバイルアプリケーションによってパースされて実行されるすべて
      • HTML, CSS, JS, 画像、もろもろ
    • 見過ごされやすい

  • SPA: Single Page Applicationの普及により、HTTP 200 OKでも実行時エラーが起きたりする時代

    • 伝統的なやり方では死活監視できない

  • フロントエンド監視のゴール: 素早くロードされること

    • 元気に動き続けることではない
    • 静的アセットの容量に影響される
  • 継続的に改善していく戦略も提示する

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

  • 表示が早いと売り上げ上がるよ、という話

    • 定量的な調査報告多数
    • オンラインで何か売るなら、サイトのパフォーマンスが良いことは必須

  • ページロード時間は4秒以下を目指せ

    • Amazon様のPrime Dayですらロード時間2.4秒以下。やれ

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

  • リアルユーザ監視(RUM: Real User Monitoring)

    • ホンモノのユーザートラフィックを使い、サーバーにメトリクス送信
    • サイト自体にgaとかを仕込む
    • ホワイトボックス監視といえる

  • シンセティック監視(synthetic monitoring)

    • 作りものの(syntheticな)リクエストで測定
    • curlコマンドとか
    • WebpageTest.orgとか
    • ブラックボックス監視といえる

6.3 DOM

  • 監視対象の仕組みを理解することは有用(著者見解)

  • 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ハンドシェイクに時間がかかるので、同じ容量・同じ処理負荷ならファイル数は少ないほうが良いでしょうね

6.3.1 フロントエンドパフォーマンスのメトリクス

  • ブラウザがAPIとして提供するメトリクス
  • MDN
  • window.performanceを通じていろいろ取得できる

  • 特に有益なもの:

    • navigationStart

      • ブラウザによってページリクエスト開始

    • domLoading

      • DOMがコンパイルされロードが始まった

    • domInteractive

      • ページが利用可能になった
      • ロードが終わっているとは限らない
      • 「ページがロードされた」とユーザーが感じるのはこの時点

    • domContentLoaded

      • すべてのスクリプトが実行された

    • domComplete

      • すべてのロードを終えた

        • HTML
        • CSS
        • JavaScript
        • 【補】画像

Speed Index

  • Speed Index

  • 実際に描画して、ページのロード完了を判断

    • Speed Indexアルゴリズムにより数値化

  • 視覚的なアプローチ

    • ユーザーの体感の判断基準としては、ブラウザのメトリクスより正確
    • ブラウザのメトリクスの含まれる詳細情報のいっさいを欠いているため、過度に依存しないこと

6.3.2 素晴らしい！でもどうやったらいいの？

  • どう活用したらいいの？という意味かな

  • メトリクスを加工する

    • 時刻を時間に変換

      • domComplete - navigationStart … ページの総ロード時間
      • domInteractive - navigationStart … ページがロードされたとユーザが体感する時間

  • サーバーに送信する

    • 既存のツールを使う

      • StatsD, Graphite等
      • 面倒

    • SaaS使う

      • GAとか
      • らく

6.4 ロギング

  • JavaScript自体に蓄積用途のログ機構はない

    • console.logはデバッグには使えるがログには使えない
    • ユーザが見ようと思ったら見れちゃう(F12 -> console)

  • SaaS使うといい

    • exception tracking serviceで検索

6.5 シンセティック監視

  • WebpageTest.org など(再掲)

  • CIと連携せよ

    • 継続的にパフォーマンス改善

  • WebpageTestプライベートインスタンスが役立つ

    • GitHub

    • 【補】DockerHub

      • CI上でこのコンテナを動かしてパフォーマンス測定し、
        Artifactsに貯めたりSlackに通知したりできる

6.6 まとめ

  • 実際のユーザが見ているページのロード時間を監視しましょう。

  • JavaScriptの例外を監視しましょう。

    • 【補】「動いている」かの監視にHTTP 200 OKで十分な時代は終わった
  • ページのロード時間をCIシステムから計測し続け、ロード時間が許容時間内に収まるようにしましょう。

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