PageSpeed Insightsの改善にはまずJavaScriptのダイエットを

# 2020/6/3 追記

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

# PageSpeed Insightsのスコアを最も左右する要因は何か

先日、[PageSpeed Insightsの点数はどのように計算されているか。100点を取るための条件](https://qiita.com/miyanaga/items/d38124cdd64a1999fed9)という記事を書きました。

要約すると、PageSpeed Insightsの点数(以下PSIスコア)は**指摘を減らして技術点を競うものではありません**。シンプルに**スタートダッシュの速さだけ**を見ています。

そこで気になった仮説を検証してみました。

# 仮説: TTFBとJavaScriptの量で点数が決まる

理論的にページ表示の初期段階では、TTFB(≒サーバーの応答時間)の長さ、HTML、CSS、JavaScriptのデータ量や複雑さがタイムを左右します。

次のように予想しました。

* TTFBが長いとその後のすべてが遅れるので、TTFBが最も重要だろう。
* 次にJavaScriptとCSSが多いとレンダリングブロックで足を引っ張るだろう。特にJavaScriptは重いしヤバい。

# 結論: JavaScriptの転送量が最重要

約300件のサンプルについて検証した結果、次の傾向を確認しました。

* JavaScriptの転送量が多いページほどPSIスコアは低い。
* 次にCSSのデータ量が影響し、全体のリクエスト数が多いページもPSIスコアが低くなりがち。
* TTFBはPSIスコアにあまり関係無い。

## 通販300サイトのデータで検証

以前、[通販サイトについて調査したこちらのデータ](https://qiita.com/miyanaga/items/b38c33fa3d8e5e575a22)を利用します。約300サイト分のPageSpeed Insightsの結果について、**次の数値とPSIスコアの相関係数**を調べました。

* TTFB
* リソースタイプ(Document/Stylesheet/Script/Image/XHRなど)ごとのリクエスト数・サイズ・転送量

**サイズは元々のバイト数**で、**転送量は通信経路においてGZIPなどで圧縮されたバイト数**です。

## PSIスコアと相関性が最も高いのはJavaScriptの転送量

相関係数は二つの値の因果関係を示す数値です。絶対値が0.4以上だと相関性があり、0.7以上だと相関性が強いとみなされます。

集計の結果、相関性の強い変数は次の通りです。ほぼ予想通り、**JavaScriptとCSSが多いサイトはPSIスコアが低い**という統計が得られました。

<table>
	<tr>
		<th>リソース</th>
		<th>指標</th>
		<th>相関係数</th>
	</tr>
	<tr>
		<td>JavaScript</td>
		<td>転送データサイズ</td>
		<td>-0.605</td>
	</tr>
	<tr>
		<td>JavaScript</td>
		<td>リクエスト数</td>
		<td>-0.536</td>
	</tr>
	<tr>
		<td>ページ全体</td>
		<td>リクエスト数</td>
		<td>-0.526</td>
	</tr>
	<tr>
		<td>JavaScript</td>
		<td>リソースサイズ</td>
		<td>-0.489</td>
	</tr>
	<tr>
		<td>Stylesheet</td>
		<td>リソースサイズ</td>
		<td>-0.485</td>
	</tr>
	<tr>
		<td>Stylesheet</td>
		<td>転送データサイズ</td>
		<td>-0.418</td>
	</tr>
	<tr>
		<td>画像</td>
		<td>リクエスト数</td>
		<td>-0.407</td>
	</tr>
</table>

PageSpeed Insightsでも`ブロッキング要素を減らせ`という改善項目があります。これが最も重要でありそうです。

画像などを含む**ページ全体のリクエスト数が多い**ページもPSIスコアが低いという統計も興味深いです。ブロッキングの回数が増えるからか、トラフィック渋滞を引き起こすからか…次回調べてみたいと思います。

## JavaScriptの転送量で点数の上限が決まる

JavaScriptのデータ転送量とPSIスコアの実際の散布図がこちらです。ばらつきはありますが、**JavaScriptの転送量が多くなるほどPSIスコアの上限が下がる**ことが一目瞭然です。

極論ですが、**JavaScriptが重いサイトは他で何を頑張っても無駄**ということが起こり得ます。

<img width="594" alt="リソースとスコアの関係.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35178/b29f3f72-d388-9e1c-77e2-71c9b2d98dd6.png">

[通販サイトのPSIスコアを偏差値で表す](https://qiita.com/miyanaga/items/b38c33fa3d8e5e575a22)と、PSI80点で偏差値70(上位2%)、PSI55点で偏差値60(上位16%)でした。

JavaScriptは**偏差値70クラスを目指すなら250KB以下、偏差値60クラスを目指すなら500KB以下**をひとつの目安としてはどうでしょうか。

## TTFBはPSIスコアにほとんど関係無い

さて、当初はTTFBが最も重要ではないかと予想しましたが、これは大ハズレでした。TTFBは0.07秒から7.6秒まで大きなばらつきがありましたが、PSIスコアの相関係数は`-0.11`でした。

理由はまた次回調べてみたいと思いますが、サーバー応答時間がユーザーの離脱率に大きく影響するのは言うまでもありません。

# JavaScriptのダイエットを

JavaScriptは**追加するより後で影響範囲を見極めて除去する方が難しい**ため、ゾンビスクリプトが残りがちです。

でも今回、使われていなくても残しておくだけでパフォーマンスに悪影響ということがわかりました。地道にダイエットしましょう！

* 昔使われてたけど今は使われていないJavaScriptライブラリはありませんか。
* トラッキングタグが多すぎませんか。
* head要素内にscript要素で外部参照していませんか。body要素の下の方に移動しましょう。
* 非同期にしても大丈夫なスクリプトはありませんか(script要素にasync属性をつけるとブロッキングしません)。
* コンテンツや見せ方、機能自体を見直しませんか。

特にファーストビューのカルーセルスライダーは、多くのサイトで見かけますがPSIスコア的には**猛毒**です。パフォーマンス意識の高いサイトではもうほとんど使われていないでしょう…