こんにちは。エンジニアの鈴木（@yamotuki）です。
サイトの速度改善のとっかかりとして定期的に速度を計測するために SpeedCurve というSaaS を導入しました。
この記事では「SpeedCurve で何をやれるのか？」「どういう数値を見ているのか？」ということを共有したいと思います。
実際にそのデータを使って改善をどのようにやるか、というのは後続の記事で書いていければと考えています。
SpeedCurve とは
speedcurve.com
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を中心に使っていきます。
以下では Synthetic でできることの一部を紹介します。
Site
一番ベーシックなところは ”Site” の項目。
以下の項目を設定しておくと、選択して見れる。グラフの大きさは個人的にはMediam Chartsくらいが直感的でおすすめ。
Syntheticの一番ベーシックなところ
Responsive
スマホ で見た場合とPC Chrome で見た場合との違いを出している。
Responsiveのところでスマホ の方がかなり遅くなっていたら要注意。
このスクショは改善前のもの。
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 また違う料金体系です。ここでは説明を端折ります。
SpeedCurve | Pricing
料金表のうちSYNTHETIC MONITORING ONLYの方を確認します。この中でもプランはいくつかあります
Starter でも年額 $3600 => 月額日本円で３万円とかかかります
Pay-As-You-Go という使った分だけプランだと、最低 $20/month で始められます
Pay-As-You-Goだと 1チェック $0.01 なので、以下のような設定だと料金は $20 で収まります。
iPhone と PC Chrome の2端末1回のチェックで3回叩いて平均をとる
region は一つだけ
自社サイトと競合サイト2つでそれぞれ 3 url
これにより 2端末 * 3回 * 1region * 3url * 3サイト = 54 checks/day = 1620 checks/month = $16.2/month
同じ設定で自社のだけ 1url増やすと6checks/回 * 30日 = 180 checks 増えるので、自社サイト 5 url くらいまでは $20範囲内。
終わりに
SpeedCurveの導入により以下の効果がありました。
いつでもサイト速度に関する推移が見れるので、何か変更が有った時にカジュアルに見れる。また、バジェットを設定しておくと定期的にメールが来る。それによりエンジニアが改善する意欲が湧きやすい
アクセサビリティやベストプラク ティスの項目で、DOMの数や画像サイズや非同期読み込みについて可視化されるので、マークアップ するデザイナさんともコミュニケーションが取りやすい
同業他社との比較で弊社サイトが早くなっていることが可視化されると、社内のモティベーション が上がる（気がする）
