こんにちは。エンジニアの鈴木（@yamotuki）です。
サイトの速度改善のとっかかりとして定期的に速度を計測するために SpeedCurve というSaaSを導入しました。 この記事では「SpeedCurve で何をやれるのか？」「どういう数値を見ているのか？」ということを共有したいと思います。
実際にそのデータを使って改善をどのようにやるか、というのは後続の記事で書いていければと考えています。
SpeedCurve とは
At SpeedCurve, we focus on measuring the interplay between design & performance to help you deliver a great, enjoyable and fast experience to your users.
機械翻訳すると ⬇️
SpeedCurveでは、デザインとパフォーマンスの相互作用を測定することに重点を置いており、ユーザーに優れた、楽しくて速い体験を提供するのに役立ちます。
SpeedCurveは単なるサーバレスポンス速度だけでなく、画像のサイズやアクセサビリティの改善ポイントなども見ることができます。
具体的に何ができるの？
以下の二つの導入方法があります
- Synthetic Monitoring : 特定の環境からアクセスして測定する（Syntheticは「人造」や「人工」）
- Real User Monitoring: 実際のユーザ行動をモニタリングする。LUXと表記されているパターンもある
弊社の最初の導入としては一つ目のSyntheticを中心に使っていきます。
Real User Monitoring は便利そうですがお金が結構かかりそうなのと、まずは理想的な環境でのチューニングからということで導入していません。
以下では Synthetic でできることの一部を紹介します。
Site
一番ベーシックなところは ”Site” の項目。 以下の項目を設定しておくと、選択して見れる。グラフの大きさは個人的にはMediam Chartsくらいが直感的でおすすめ。
- Site
- Url
- Browser
- Region
Responsive
スマホで見た場合とPC Chromeで見た場合との違いを出している。 Responsiveのところでスマホの方がかなり遅くなっていたら要注意。 このスクショは改善前のもの。
Benchmark
他社サイトとの比較。
ページ名を同名で（例えば TOP や main_contents_list）とつけておくと比較できる。
見るときに全て大文字にされてしまうので、名前はsnake_case でつけた方が見やすい。
最初の測定対象は以下のページとしました。
- topページ(top) vs 競合
- 募集一覧（main_contents_list）vs 競合
- 募集詳細（main_contents_detail）vs 競合
どのような指標をサイト改善に使うか？
以下は弊社サイトTOPページのリニューアルの時に使用した数値です。
- SPとPCが同等の速度を実現（Responsive の項目で判断）
- コンテンツサイズを同等にする
- リクエストブレイクダウンを同等にする
- PCでTTFB (backend)
- before 1.59s => 目標1.0s以内 => 実際 0.7sくらい
- speedindex
- before 2.99s => 目標1.5s以内 => リニューアル直後は 1.6sくらい。その後ファーストビューだけでなくUX考えてやや下のコンテンツも同期的に取るようにして1.9sほど。鋭意調整中です。
- Lighthouse performance score について（レンダリング過程のキャプチャ画像をタップすると詳細が見れるものです）
- SEO, Best Practice, Accessibility, Performance にそれぞれ目標を立てて作業しましたが、細かいので略
- Perfomance以外は満足のいく結果が取れたので良いのですが、Permanceについてはまだ頑張っているところです。
- リニューアルしたページについて benchmarkで speedIndex で同業他社サイトよりspeedIndexで勝るようにする
speedIndex 以外にも指標となるデータは沢山あります。今後、弊社のユーザ体験としてこうあるべきでは？という議論が深まっていくと他の指標を使うこともありえるかと思います。speedIndexはユーザの体感と近いと言われているので、とっかかりとしてまずこれを見て最低限の改善をしていくことにしました。（speedIndexの詳細については後述）
speedIndexとは何か
https://developers.google.com/web/tools/lighthouse/audits/speed-index?hl=ja
ページのコンテンツが目に見える状態になるまでの時間
というわけでユーザ体感に近いと言われている数値。
もっと詳細の計算ロジックとかはこちら。 https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
要するに、数字と表示領域をパーセントのグラフをとった、上側の領域の積算のようです。
お高いのでしょう？
高いイメージがあって弊社でも導入が進んでいませんでした。
先に以下の二つの測定方法があることを紹介しました（再掲）。
- Synthetic Monitoring : 特定の環境からアクセスして測定する（Syntheticは「人造」や「人工」）
- Real User Monitoring: 実際のユーザ行動をモニタリングする。LUXと表記されているパターンもある
実際にはSyntheticについてはそこまで高くなく導入できます。 Real User Monitoring また違う料金体系です。ここでは説明を端折ります。
料金表のうちSYNTHETIC MONITORING ONLYの方を確認します。この中でもプランはいくつかあります
- Starter でも年額 $3600 => 月額日本円で３万円とかかかります
- Pay-As-You-Go という使った分だけプランだと、最低 $20/month で始められます
Pay-As-You-Goだと 1チェック $0.01 なので、以下のような設定だと料金は $20 で収まります。
これにより 2端末 * 3回 * 1region * 3url * 3サイト = 54 checks/day = 1620 checks/month = $16.2/month
同じ設定で自社のだけ 1url増やすと6checks/回 * 30日 = 180 checks 増えるので、自社サイト 5 url くらいまでは $20範囲内。
終わりに
SpeedCurveの導入により以下の効果がありました。
