Speed Indexは表示されたページの見える部分、つまりATF/ファーストビューの平均時間です。それはビューポートサイズに依存し、ミリ秒で表わされます。
Speed Indexの指標がWebPagetestに追加されたのは2012年の4月で、いかに速くページの見える部分がレンダリングされたのか計測します（数値が低いほうが良いです）。これはUXを比較（改善前後、自社サイトと競合サイトなど）するのに大いに役立ちますし、他の指標（読み込み時間、Start Renderなど）と合わせて見るべきでWebパフォーマンスを理解するのに良いでしょう。
これまで私達はWebページが速かったのか、遅かったのか決めるためにある種の段階的なタイミングに頼らざるをえませんでした。これのタイミングの中で最も一般的なのは、ブラウザがメインのドキュメントのloadイベントに達するまでの時間、つまりonloadでしょう。loadイベントはラボ環境や実際のネット環境であろうとも計測自体は簡単です。しかし、不幸にもこれは実際のエンドユーザー体験を理解するための良い指標とは言えません。ページのコンテンツが増えていけば、当然、ユーザーには見えない部分やスクリーン外（below the fold）のコンテンツを読み込まなければならず、たとえユーザーに見る部分がはるか昔にレンダリングされていたとしても、読み込み時間は長くなってしまいます。私達は他のより良いタイミング（first paintまでの時間や、DOM content readyの時間など）についても検討してきましたが、結局それらはひとつのポイントでしかなく、実際のエンドユーザーの体験を理解することはできないのです。
Speed Indexは、読み込むページの見える部分のVisual Progress(ビジュアル的進捗状況)を必要とし、ページのコンテンツがいかに速くレンダリングされたのか総合的なスコアが算出されます。このため、まずページの読み込み中のさまざまなタイミングの中で、どの時点を『完了』と見なすのか判断する必要があります。WebPagetestにおいては、ページの読み込みをビデオキャプチャーし、毎フレームの画像をチェックすることでこれを可能にしています（現在の実装では1秒間に10フレーム記録していて、ビデオキャプチャーが有効になってるテストの時だけレポートされます）。各フレームの進捗率を計算するアルゴリズムは以降で説明しますが、とりあえず今は各フレームの進捗率を%で表しています（各フレームの下にある数字）。
完了になるまでページの進捗率をプロットしてみると、以下のようなグラフができました。
この曲線下部の進捗率を数値として扱うことも可能です。
これは非常に素晴らしい指標となりうるかもしれませんが、1点弱点を挙げるとすれば際限がないことです。もし、Visually Complete後にも10秒間読み込みのスピナーが回っていたとすればこのスコアは増加し続けます。代わりに、『グラフ曲線上部』を使用し、ページのレンダリングされてない部分を計算します。そうればページが100%レンダリングが完了したなら終了ですし、ページが速いほど0に近づく有限なエリアとなります。
Speed Indexとはミリ秒で計算された『グラフ曲線上部』であり、進捗率は0.0から1.0の範囲で算出されます。この計算方法は、0.1秒のインターバルに設定し、次の公式で計算します。IntervalScore = Interval * (1.0 - (Completeness/100))この時のCompletenessはそのフレームの進捗率で%が単位です。また、Intervalはビデオフレームの経過時間(ミリ秒)で、この場合は100msです。総合スコアは個々のインターバルの合計なので、つまりSUM(IntervalScore)です。
比較のために、2つのページのビデオフレームが次です（Aが上、Bが下）。
各ビデオフレームのVisual Progressというのは波打ったような曲線になり、Speed Indexの計算と進捗率を決定する技術とは独立したものとなります（進捗率の計算は異なる計算方法が使用される可能性があります）。私達は2つのメソッドを現在、提供しています。
単純なアプローチとして画像の各ピクセルを最終的なイメージと比較し、各フレームがどれだけマッチしてるのか%を算出します（おそらく最初と最後のフレームのいくつかのマッチしているピクセルは無視されます）。このアプローチの問題としてはリキッドデザインや広告の読み込みなどで、コンテンツが移動してしまう可能性を含んでいることです。ピクセル比較モードにおいては、実際のコンテンツが単一のピクセルにシフトダウンしたとしても、スクリーン上のすべてのピクセルの変化を見ます。
私達が決めたこのテクニックはキャプチャーした画像の（赤、緑、青といった具合の）各色のヒストグラムを作成し、全体の色分布を見ているだけでした。最初のビデオフレームから抽出したヒストグラムと最後のビデオフレームから抽出したヒストグラムを差異を計算し、それを差異のベースラインとして使用します。各ビデオフレームのヒストグラムと最初のフレームのヒストグラムとの差異は、ベースラインと比較され、そのビデオフレームがどれだけ完了しているのか決定されます。たまに正確な状態を表していないこともありますが、私達がテストしてきた結果、多くのページで有意義な結果出ているので安心してください。
これはSpeed Indexが作られたときにできたVisual Progressを計算する独自のメカニズムで、まだうまく機能しますが、いくつかのケースで問題があります。ケースというのは、動画を再生するページや、スライドショーなどの大きな要素を含むページです。終了の状態と最終イメージを基準としたVisual Progressの計算というのはデリケートなものです。またラボでしか計測できず、ビデオキャプチャーが有効の場合のみです。
最近では、私達は（リモートデバッグプロトコルや拡張機能を利用できる）デベロッパーツールのタイムラインを通して、Webkitのペイントイベントを使用する試みをしていて概ねうまくいっています。最近のWebkitベースのブラウザであれば、モバイル・デスクトップ両方のプラットフォームで使用することが可能で、非常に軽量なうえにビデオキャプチャーを必要としません。また、ブラウザのレンダラーに依存するため異なるブラウザでのパフォーマンス比較には適していません。
有益なデータを得るために、いろいろフィルタリングや重みつけをしています。
DevToolsの描画矩形（paint rects）からSpeed Indexを計算するためのアルゴリズムは以下のとおりです。
- Webkitベースのブラウザにおいて、ほかの有用なイベント同様に描画矩形データをタイムラインから収集します。
- 最初のレイアウトが実行する前と、最初のレスポンスデータを受信した後に発生した描画イベントを除外します
- ResourceReceiveResponse -> Layout -> Paint events.
- これはブラウザが実際のデータを処理する前に描画イベントが発生させてしまうためです。
- frame ID, x, y, width, heightなどの情報がアップデートされる、すべての描画矩形イベントを収集します。
- もっとも大きな描画矩形はフルスクリーン矩形としてみなします。
- 各矩形は総合スコアに加算されます。つまり矩形ポイントというのは矩形の面積のことです（width x height）。
- フルスクリーン描画（もっとも大きな矩形の描画イベント）のポイントは50%としてカウントするため、それがプロセスを占めることはありません。
- 総合スコアは各矩形ポイントの合計です。
- 矩形ポイントはその矩形内の描画イベントの回数によって平均化されます。
- 単一の描画イベントで出来た矩形はそのまますべてスコアに加算されます。
- 4回の描画イベントを伴う矩形は25%づつスコアに加算されます。
- 描画イベントの終了時間はその描画イベントの時間に使用されます。
- Visual Progressはその時点までのポイントよって（総合スコアの何%か）計算されます。
HTTP AchiveによればAlexaの上位300,000のテスト結果は以下。
HTTP AchiveによればAlexaの上位100,000のテスト結果は以下。
