「入門 監視」読書会レポート vol.6

読書会

株式会社リゾーム システム企画・開発部 第3グループの渡邉です。
読書会の第6回目のレポートです。 第5回目のレポートは、こちらになります。
tech.rhizome-e.com

読書会の題材

前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。

6回目レポート

今回は、「6章 フロントエンド監視」で、参加者は6名でした。

それぞれの感想・意見交換

フロントエンドのパフォーマンス・監視について
  • フロントエンドのパフォーマンスについては気にはしているが、監視をするという考えはなかった。
  • 「JavaScriptはbody閉じタグの直前で読み込め」とか、「CSSはheadで読み込ませるけど書く場所はなるべくまとめる」とか、「アセットパイプラインで全部ひとまとめにしてやる」とか、「なるべく圧縮した方がいや使用頻度が高いならCDNを使え」とか、そんな話もあったなどと懐古。
  • 以前はチャッチャとできるくらいは高速化に取り組んでたりしたけど、そっち専業ではないので、最近はあまりキャッチアップできてない。
    • PageSpeed Insightsを使ったりしていたくらい。
  • 去年やった社内ISUCONを思い出しつつ読んだ。当時はN+1の改善に注力していたが、画像サイズが大きいとかの問題もあったな。
  • ゴール＝動き続ける×＝素早くロードされる○
遅いアプリケーションのコスト
  • 早くすることでページビューやコンバージョンの改善につながるというのは、そうだろうなと思う。
    • やはり「遅いから使いたくない」とか言われたら負けだと思う。
  • フロントエンドのパフォーマンスチューニングは、沼なので、ずっとそればっかりやってもいられないのだが、頃合いを見ては取り組む、というのはやっていくべきだろう。
  • ECサイトはパフォーマンスの影響がかなり大きそう
    • 人によっては買い物でストレス発散したりするぐらいだから。(ECサイトが遅く)気分が良くないと買い物する気にならなそう
  • 担当サービスでも、ページ表示が遅いと言われることがある。
    • ほとんどはSQLが遅いので、改善できる箇所は積極的に改善していきたい。
  • 遅い事が悪いと直感的に理解している
    • 調べ物してて読込遅いサイトに行くと、すぐ別のサイトに切り替えるなあ
DOM
  • scriptタグがあると、そこでDOMのパースを停止してしまう。昨今は、async属性をつけて非同期にロードすればいい。
    • なるほど。やってたような。
  • 大量のscriptをロードせずに、少しにしたほうがよい、と書いてあるが、最近は多分事情が違って、HTTP2やHTTP3を使って小さいファイルを並列でロードしろっていう方向だと思う。
    • webpackでよく「JSのファイルサイズがデカすぎるよ！」て警告出てるし。1つのファイルにするのって、ファイルサイズが大きくなるため、初回ロードがかなり遅くなる。2回目以降はキャッシュが効くからいいんだけど。
    • 昔はJSをモジュールにできなかったのでバンドルせざるをえなかったが、モダンブラウザだとデフォルトでimportをサポートしているものもあるので、そろそろバンドルするなっていう流れになるんかなとか思う。
  • Reactの仮想DOMとjQueryのDOM操作のように、同じDOMでもライブラリによって仕組みが違うこともある。
パフォーマンスのメトリクス・監視/計測サービス
  • Google Analytics、名前はよく聞くけど、何かは分かっていない...
  • Google Analytics はアクセス解析などの目的で用いるものというイメージが強かったが、調べてみるとサイトの速度などフロントエンド側のデータ収集や可視化なども行ってくれているようなので、下手に自分であれこれするよりは任せてしまった方が良いと思われる。
  • Navigation Time API
    • 開発者ツールのネットワークタブに出てくるあれかな。
    • 使い方はあまり理解していないので確認する。
  • Speed Index
    • B-PARKのサイト作成の時に色々確認してた
      • 特にホーム画面のところが重かったからlazysizes導入してページ下部の写真は遅延読み込みさせたりした
  • PageSpeed Insightsなどの計測サイトは利用したことがあり、指標の部分にSpeed Indexも出てくるが、その程度の利用。
シンセティック監視
  • 単なる外形監視ではなく、サービスのロード時間とか表示時間とかをビジュアルで教えてくれるっぽい。WebpageTestを軽く動かしてみたら、そんな感じだった。
  • パフォーマンスへの影響をCIで計測できるのは便利
  • 自動テストで継続的にパフォーマンスを測定するのはありだと思う。

まとめ

フロントエンド側のパフォーマンスについては、過去に実施した手法や教訓の話、PageSpeed Insights等の計測サイトを用いたパフォーマンス計測の話が挙がりました。
継続的な監視・パフォーマンス計測については、あまり実施できていませんでしたが、Google AnalyticsやNew Relicを用いたログやメトリクスの取得・CIでの計測等、実践できそうな様々なヒントを得られることができました。
また、(主に私が)Google Analyticsについてあまり詳しく知らなかったのですが、実際にGoogle Analyticsを使用している例を見せてもらい、活用方法や取得できるメトリクス等について知ることができました。

次回は、「7章 アプリケーション監視」です。楽しみですね！