PageSpeedスコアを調べる中で、ドキュメントTTFBとスコアの関係に疑問がありました。

ドキュメントTTFBが遅いとその後のプロセスがすべて一様に遅れるので、最もスコアへの相関性が高いはずと思いきや、そうはなりませんでした。

PageSpeed Insightsの改善にはまずJavaScriptのダイエットを
https://qiita.com/miyanaga/items/b3d955a6fd70ef7d89ec

2020/6/3 追記

本家レポートよりPageSpeed Insightsのスコア改善が捗る裏レポートツールを公開しました。合わせてご参考ください。
https://simulate.site/cheatspeed-insights/

検証

シンプルなHTMLを出力するPHPを用意し、waitパラメータの分sleepさせてドキュメントTTFBを偽装します。

index.php

<?php sleep($_GET['wait'] ?? 0) ?>
<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>TTFB Test</title>
</head>
<body>
  <p>PageSpeedスコアとドキュメントTTFBのテスト</p>
</body>
</html>

TTFB≒0秒の場合

waitパラメータに0を指定した場合です。予想通りというか当然100点になります。

ラボデータの各タイミングが0.7秒=700msというのは謎ですが…

TTFB≒3秒の場合

waitパラメータに3を指定します。

スコアが91に下がりましたが、ラボデータは速度インデックス(SpeedIndex)しか変化していません(TTIの0.8秒は誤差ということにします…)。

延長したTTFBは3秒ですが、速度インデックスは4.8-0.7=4.1秒伸びています。

※ 速度インデックスの単位が秒というのはちょっと変なんですが、ここではスルーします。

TTFB≒5秒の場合

waitパラメータに5を指定します。

スコアは80に下がりましたが、こちらもラボデータは速度インデックスのみが長くなりました。また同じくTTFB5秒延長に対し、7.4-0.7=6.7秒伸びています。

以上の結果から、次のことが確認できました。

ドキュメントTTFBが遅くなってもSpeedIndexしか遅延しない
SpeedIndex以外の指標はドキュメントTTFB以後のタイミングを起点に計測される

SpeedIndexにしか影響しないのでスコアとの相関は低い

総合スコアは、コンテンツの初回ペイントFCP、意味のあるコンテンツの初回ペイントFMP、速度インデックスSpeedIndex、CPUの初回アイドルFID、インタラクティブになるまでの時間TTIを元に計算されます。

PageSpeed Insightsの点数はどのように計算されているか。100点をとるための条件
https://qiita.com/miyanaga/items/d38124cdd64a1999fed9

SpeedIndexの総合スコアに対する影響力は4/15です。仮にSpeedIndexが0点評価でもほかが100点なら73点を獲得できます。

Chrome DeveloperツールのAuditsタブはまた挙動が異なる

Auditsタブで、TTFB≒5(wait=5)を試してみたところ、次の結果になりました。

FCP、FMPなどのタイミングが軒並み5秒強となっています。当初予想した「TTFBが遅れるとその後の処理が一様に遅れる」状態です。

全体の指標が伸びてしまったのでスコアも大きく悪化しています。

ちなみにnpm版のLighthouseを単体で試したところ、前述のPageSpeed Insightsと同じくSpeedIndexにしか影響しませんでした。

ChromeのAuditタブは実はLighthouseと違うという新たな謎を残してしまいました…

PageSpeed InsightsでドキュメントTTFBはSpeedIndexにしか影響しない