How to 速度改善 ー計測・知識編ー

## 前提
速度改善にこれから取り組もうと思っている方向けに書きました。
すでに速度改善に取り組んでいる方からするとちょっと基礎すぎるかもしれませんが、自分の勉強メモとしてアウトプットして残そうと思った次第です。

## 速度改善のために必要なこと

テクニックや考え方は色々とあると思うのですが

* まずは計測しよう（Page Speed Insightsなどで）
* 問題を切り分けて考えよう
* 影響が小さいところから取り組んでみよう

ということが大事かと思います。

なので、まずは計測をしてみましょう。

とあるWebサイトのデータを[Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=ja)で計測してみます。

Page Speed Insightsとは、ものすごい簡単にいうと、サイトのいいところ、ダメなところを診断してくれるツールですね。無料です。（ほとんどの方は知っていると思いますが、念のため。）

<img width="638" alt="スクリーンショット 2019-02-22 14.44.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/76779/def516ed-b1df-454a-9979-7351ee2fe8ab.png">

スコア、39ですね。低い・・・

さて、どこがいけないのでしょうか？

内容を確認してみましょう。

<img width="848" alt="スクリーンショット 2019-02-22 14.49.23.png" src="https://qiita-image-store.s3.amazonaws.com/0/76779/ee6a5ff7-fb4a-f0b9-9fe5-3ba544657789.png">

注意されているポイントは6つ
1. コンテンツの初回ペイント
2. 意味のあるコンテンツの初回ペイント
3. 速度インデックス
4. CPUの初回アイドル
5. インタラクティブになるまでの時間
6. 入力の推定待ち時間

とのことです。それぞれ詳細をみてみます。

#### 1. コンテンツの初回ペイント
Googleさんによると

```
First Contentful Paint (FCP) measures the time from navigation to the time when the browser renders the first bit of content from the DOM. 
This is an important milestone for users because it provides feedback that the page is actually loading.
```
FCP（First Contentful Paint）というのはブラウザがDOMのコンテンツの最初の部分をレンダリングするまでの時間ということで、それが遅いと必然的に評価スコアも下がる、ということですね。

#### 2. 意味のあるコンテンツの初回ペイント
First Meaningful Paintという用語が[こちら](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint)では使われていますが、これは
ページの主要コンテンツが画面に表示されたタイミングを指すようです。当たり前ですが、これも遅いと評価スコアが下がるということですね。

#### 3. 速度インデックス
これはページの読み込みパフォーマンスにおける指標で、ページのコンテンツが見える状態になるまでの時間を表します。

#### 4. CPUの初回アイドル
これはページのメインスレッド処理が静止し、初めて入力の処理が可能になるまでにかかった時間です。

#### 5. インタラクティブになるまでの時間
これはページが表示され、ユーザー操作が可能になるまでの時間を指しています。

#### 6. 入力の推定待ち時間
このスコアは、ページ読み込みの最もビジーな5秒間における、ユーザーの入力に対するアプリの応答時間（ミリ秒）を指します。待ち時間が50ミリ秒より長い場合、アプリの反応が悪いと思われる可能性があります。
[（Googleのページを参照）](https://developers.google.com/web/tools/lighthouse/audits/estimated-input-latency)

このように、様々な視点から評価され、スコアが決まっています。

##  RAIL
Googleが2015年の開発者向けのイベントGoogleI/Oにて発表したモバイル時代のパフォーマンス計測に対しての考え方です。

Response,Animation,Idle,Load

この4つの頭文字をとってRAILと呼ばれています。

[こちら](https://developers.google.com/web/fundamentals/performance/rail?hl=ja)を参考に簡単に説明します。

##### Response
ユーザーによるボタンのクリック、フォーム上のコントロールの切り替え、アニメーションの開始などのユーザーの操作に対して100ミリ秒以内にレスポンスを返しましょう、という考え方です。

##### Animation
現在ある端末のほとんどは、1秒間に60回リフレッシュします。
（スクロールなどを含めて）アニメーションなどを実行している時はブラウザ側で端末のリフレッシュレートに合わせて、画面がリフレッシュされるたびに新しい画像またはフレームを表示する必要があります。
なので、1つのフレームに対して割り当てられる時間は1秒/60回 = 16ミリ秒くらいとなります。
（短い。。）

##### Idle
Idleはユーザー操作が行われるまでの待機時間(つまり、処理が何も行われていない）状態のことです。
WebページでJavascriptを使って何かをする場合にはメインスレッドにも処理が行えるように余裕を持たせることが推奨されています。Javascriptの処理が重すぎるとメインスレッドが詰まってしまうので、それを避けましょう、ということですね。

##### Load
Webページの読み込みについては、ユーザーがアクションを起こしてから1000ミリ秒（つまり1秒）以内にDOM生成を行う必要があります。


## クリティカルレンダリングパス
Webサイトのリソース（HTML,CSS,Javascript）のダウンロードと処理、そしてページの一番最初のピクセルまでのレンダリングを行うまでの流れのことを指します。
ここの中でちょこちょこ下記の用語が出てくるので、それについても触れておきます。

##### DOM
今更感ありますが、簡単に説明します。
Document Object Modelの略で、ドキュメントをオブジェクト（モノ）のように扱うためのモデルのことです。
DOMは階層構造を持っており、それぞれの階層にある要素はノードと呼ばれます。また、DOMがあることでJavascriptを使ってHTMLやCSSの操作ができるようになっていると言っても過言ではありません。

##### CSSOM
DOMに関連づけられたスタイルのオブジェクトを表現したものです。
これによって各要素にスタイルが当たるようになります。

また、レンダリングが行われるまでの流れは大まかに下記のようになります。


<img width="668" alt="スクリーンショット 2019-02-22 18.11.17.png" src="https://qiita-image-store.s3.amazonaws.com/0/76779/5aebc86f-b2ff-341a-3191-4dfce2770b6f.png">


この間での処理を最適化することで、ページの表示速度を上げ、Page Speed Insightsの評価を高くすることができます。

次回は

How to 速度改善 ー原因調査編ーと題して、先ほど分析結果が出てきたサイトの問題点を抽出し、どういった手段を取ることができるかなどを検討していきます。