Speed Indexを使ったWebパフォーマンス改善の振り返り

2017年 Sep 28日 (Thu)

こんにちは。制作部の苅部です。

今回は、サービス横断でのWebパフォーマンス改善を1年間続けた中で指標としてSpeed Indexを採用した振り返りを書き残しておこうと思います。

Speed Indexとは

時間ごとの描画面積で算出される値で、体感速度の指標として参考にすることができます。 UX向上としてのWebパフォーマンス改善を考える時に、他の指標よりも役に立ちます。 DOMContentLoadedやwindow.onload、First Paintといったいくつもの指標はあくまで説明変数で、Speed Indexが目的変数になると考えています。

体感速度における目的変数が明確になることで、実施すべき施策(クリティカルレンダリングパスなど)にフォーカスすることができるようになります。

※Speed Indexの詳しい算出方法については以下ページが参考になります。

改善の進め方

1. 数値を定量化する

Speed Indexを統計的な定量データにした上で、時系列の軸で他のデータと比較できるようにします。
これによって「数値」を「ファクト」として扱えるようになります。
数値の妥当性を計るためにもヒストグラムも合わせて確認できるようにすると良いと思います。

2. 比較のためのベンチマークをとる

速度とは相対的な値ですので、比較のために同じ条件でベンチマークを複数取り相対評価をできるようにします。
これで速い・遅いの判断ができるようになります。

3. 改善して効果を測る

ベンチマークと比較した結果遅ければ、ファーストビューにフォーカスして描画をブロックする要因がないかを調べ、そのボトルネックに対して改善を行います。
その後、定量データ(統計量)を前後比較して施策の評価を行います。

この繰り返しでPDCAサイクルを回していきます。

Speed Indexの理想値

計測条件や計測対象のUIあるいは計測時のネットワーク影響によって差が出てしまうため厳密な絶対値は出せませんが、いくつか参考になる値はあります。

・HTTP Archive

Big QueryのPublicなデータセットにHTTP Archiveのデータが保存されているため、数十万件の計測データから任意の統計量を取得することができます。
例えば以下のようなクエリを叩くことで、Speed Indexの中央値が取得できます。

クエリ

SELECT
  NTH(501, quantiles(SpeedIndex,1001)) pages_mobile_speedindex_median,
FROM [httparchive:runs.2017_09_01_pages_mobile]

SELECT
  NTH(501, quantiles(SpeedIndex,1001)) pages_speed_index_median,
FROM [httparchive:runs.2017_09_01_pages]

実行結果

2017年9月1日の計測(46万件)におけるSpeed Indexの中央値はモバイルサイトで8,025、デスクトップサイトで3,800となりました。
モバイルサイトの方がSpeed Indexが高くなる傾向にあるので、目標とする値はViewportで分けて考える必要がありそうです。

※ HTTP Archiveは世界中のサイトを計測しているため、ネットワーク(RTT)の影響を受けて数値が高い状態になっていると思います。

参考URL：HTTP Archive + BigQuery = Web Performance Answers - igvita.com

・Google Adsense, Double Click by Google

AdsenseのブログやDouble Clickの資料ではSpeed Indexへの言及があり、目指すべき数値として3,000以下と記載されています。

Webpagetest provides a Speed Index that indicates the average time at which visible parts of the page are displayed. Aim for a Speed Index of 3,000 or less and load time of 3 seconds or less — ideally 1-3 seconds.2
5 steps to improve Page Speed and boost page performance

・モバイルサイト認定資格

Google Partnersのモバイルサイト認定資格には Speed Indexのスコアの目標値に関する問題が出てきます。
試験対策ガイドには

私たちの目標は、スコアが 3,000を下回ることです。
2.1.3 目標値の設定 - Google Partners ヘルプ

と記載されていて解答欄にも 5,000未満という選択項目が用意されていたので、最低でも5,000未満、理想は3,000未満という解釈ができそうです。

・書籍：パフォーマンス向上のためのデザイン設計

オライリー・ジャパンから出版されている"パフォーマンス向上のためのデザイン設計(Designing for Performance)“では、Speed Indexの数値について言及があります。

Table 5-1. Example responsive web design budget
Measure Goal
Speed Index 1,000
Designing for Performance

Measure	Goal
Speed Index	1,000

"Example"となっているので、数値に根拠はないと思いたいです・・。

・NCC Groupのベンチマーク

セキュリティ企業のNCC Groupの記事によれば、英国の小売店(上位50位)のベンチマークは中央値が3,106(帯域:8Mbps)だったとのことです。

in a recent test of top 50 UK retailer home pages (tested in Performance Analyser with Internet Explorer 11 at 8Mbps), the best Speed Index score was 819. The average was 3,658 (median 3,106), while the poorest had a score of 8,582
Speed Index – how it works and what it means

・Lighthouse

Chrome Developer ToolsのAuditsにてパフォーマンス診断をするとLighthouseを使った分析が可能です。
実行結果としてSpeed Indexの値が表示されますが、目標の数値としては [< 1,250] となっています。

Chromeのソースコードには以下のようなコメントアウトの記述もあり、中央値を5,500と想定している模様です。

  // 10th Percentile = 2,240
  // 25th Percentile = 3,430
  // Median = 5,500
  // 75th Percentile = 8,820
  // 95th Percentile = 17,400

参考URL：https://github.com/GoogleChrome/lighthouse/blob/v2.4.0/lighthouse-core/audits/speed-index-metric.js#L62

・mediba運営のサービス

私たちが計測している複数のモバイルサイトのベンチマークは以下のようになりました。(2016年12月〜2017年8月)

計測概要

項目	内容
ツール	WebpageTest
地点	EC2 north-west1
Viewport	iPhone5c
帯域/RTT	Mobile3GFast(1.6Mbps/768Kbps 150msRTT)
数値の算出方法	1日12回計測した上で月単位での中央値を取得

計測結果

計測対象	毎月の中央値の平均
A	3,452
B	4,276
C	4,808
D	5,330
E	5,756
F	6,098

※D・Eは同期的なA/Bテストツールの読み込み(HTMLパースのブロッキング)があり、FはファーストビューにカルーセルUIが存在しているため、それを反映して数値が高くなっています。

感覚的にもレンダリングをブロックする要素がなければ(ボトルネックがなければ)、5,000以下の数値が出せるという印象です。
そしてLighthouseの5,500という中央値も肌感覚としては妥当に感じます。

そのため、medibaでは5,000を閾値としてパフォーマンス改善に取り組んでいます。
6,000を超えているような状況では「体感速度が遅く、改善の余地がある」といったざっくり判断をしています。

Speed Indexを取り入れるポイント

1. ざっくり捉える

Speed Indexは描画の面積で算出するため、ファーストビューに自動送りのカルーセルが存在していたりバナー広告があったりする場合は不利になる事があります。
逆に画像の少ないテキストベースのデザインであれば有利になります。

ただ体感速度という意味ではある意味妥当ですし、他のベンチマークと比較はできないとしても同一計測対象での比較としては有用だと思います。
そのため、厳密さを求めずある程度の「ざっくり感」をもって取り入れると良いと思います。

2. 他の指標を使って改善する

Speed Indexはあくまで結果としての数値(目的変数)なので、何かアクションを起こすためには、TTFBやfirstPaint、DOMContentLoadedなどの他の指標(説明変数)が必要になります。

またonLoadは古い指標と言われたりする事もありますが、onLoadが遅い場合はブラウザのインジケータの表示時間が増えるため、体感速度へのマイナス影響もあります。
そのため投機的な読み込みや不要なサードパーティ絡みのリクエストの削除など、onLoadの最適化も必要だと思います。

Speed Indexは他の指標を代替するわけではなく、相互的に補完していくイメージです。

3. ビジュアライズする

Speed Indexの改善幅を数値で共有しても、なかなか相手に意図が伝わりづらいと思います。
そのため、数値(中央値)が近いもの同士の比較動画をWebPagetest上で作成し、数字と合わせて展開すると視覚的にもわかりやすく、コミュニケーションもスムーズになると思います。

速度改善のベネフィット

パフォーマンス改善にかかるコストに対して、どういったベネフィットが期待できるかの説明に悩むことは常にあると思います。

「速い方がいい」のは間違いないですが、それだけでは協力を得る事が難しいです。
多くの人が納得できる説明が必要になるのですが、その一つとして「パフォーマンス改善は帯域の品質が低いほど効果が大きい」ということが挙げられると思っています。

最近のデータ契約は容量に上限（と超えた場合の通信制限）があることがほとんどです。
MVNOの市場シェアも伸びてきていますし、事業者によっては節約モード(下り制限)のスイッチを用意しているケースもあります。
つまり国内の通信環境にも多様性があり、ナローバンドも珍しくないので「通信速度が速いから大丈夫」というわけでもなさそうです。

というわけで、ナローバンドを考慮したときに、UXとしてのエンゲージメント貢献や事業指標への期待ができると思っています。

※ rtt attributeがモバイルのChromeにも実装されたら、RUMとして収集するのも面白そうです。

おわりに

Speed Indexを使ってボトルネックにフォーカスすることで、パフォーマンス改善をシンプルに考えることができると思います。
例えば、ボトルネックには以下のようなものが挙げられます。

CSSファイルの肥大化
同期的なScript読み込みによるHTMLパースのブロック
圧縮が有効になっていない
巨大なCSS Sprite画像の読み込み
HTTP/1.1での同時接続数制限
キャッシュの設計の問題

どれも難しいことではなく解決のためのコストも低いですが、サードパーティのリソースも含めて、このいずれかが課題として見つかる事が多いです。
そしてどれもネットワーク(RTT)影響を大きく受けるため、RTT的に不利なモバイルネットワークではわかりやすく体感速度を上げることができました。

Speed Indexは精度が高くないかもしれませんが、[体感速度が遅いかどうか]を把握し次のアクションに繋げる事ができるため、より良いモバイルUXを提供できる指標だと思っています。