Catchpointによる表示速度検査を受けました

遅くなって申し訳ありませんでした。Webパフォーマンス Advent Calendar 2019 – Qiitaの記事です

AdventCarendarに参加するということで、Catchpointでの計測を行って頂きました。

計測して頂くのはどのページにしようかと考えたんですが、弊社内で、アプリの紹介ページが重いという意見があり、せっかくの機会なのでそのページをということになりました。

で、竹洞さんに連絡したら、「そのページまでの動線で計測したほうが良い」と言って頂き、動線の中で一番ボリュームが多い、ログイン→マイページ→アプリ紹介ページという動線で計測して頂きました。この導線で見るというのが、当初とは別の課題の発見につながったので、なるほど、流石だと感動しました。

Catchpointのありがたいところ

定時のチェックを行うのはPSIのスコアレベルなら行えますが（弊社は、定期的にPSIのAPIを利用してスコアを取得しています）この精度で見ることができないのでとてもありがたいです。

下は、First Contentful Paintの統計。実際の回線（今回はDoCoMo）やエミュレートした回線（ノイズが少ない）でのデータが見れています。

このようなウォーターフォールも15分ごとに見ることができます。

制作時にDevToolsでも確認できることはありますが、このように定期的に取れるのはこういうサービスでこそということですね。

竹洞さんにいろいろ指摘をいただく

ありがたいことに、ご意見頂きました。ざっとまとめると。

• DNS
  • Route53を利用することで出てくるレイテンシ
  • その場合のレイテンシは最低で約100ms以上
• サーバー返答時間（TTFB）
  • 改善の必要あり
  • プログラムのチューニングが主になる
• HTTP/2
  • 利用している
  • いわゆる「つまり」は確認できた
• サードパーティー
  • Googleタグマネージャー
  • Karte
  • 改善の要求をすべき

Catchpointでわかったこと

冒頭に書いたようにページに到達する導線で計測してもらって気づけた課題があります。

それは、ログイン→マイページの動線でのサーバー待機時間についてでした。

1. ログインの判定
2. リダイレクト
3. マイページのサーバー待機

という流れが1.5秒近くかかっていました。

言われてみれば確かにという問題ではあるんですが、改善ポイントとしてピックアップすべき事象ですね。

これからの改善ポイント

• サーバー返答時間
  • 現状、ページにより1000ms近く、またはそれ以上になっているので改善ポイントを探して対応していく
• サードパーティー
  • 改善の依頼を継続して行う
  • 使い方を確認していく
• フロントエンド
  • 効率的なHTML/CSS/JavaScriptの記述
  • 画像などのコンテンツの読み込み順を考えていく
• DNS/CDNなど
  • AWS以外の選択肢（Cloudflareなど）も「あと100ms」ぐらいになった段階で検討していく
  • CDNは静的ファイルだけでなく、コンテンツキャッシュでも利用しているので、そのあたりも含めた検討が必要
• スピード監視
  • 本気で検討したい
  • 社内の議論に改めて上げていく

最後に

普段から竹洞さんの情報を見ている立場ですが、このような形でやりとりさせて頂きありがとうございました。これからも参考にさせていただいて、少しずつでもサービスの改善に努めていきます。