WEBパフォーマンス改善に取り組む前に知っておきたいこと

## WEBパフォーマンス改善とは何か

パフォーマンスとは「性能」です。
つまりWEBパフォーマンスとは「WEBの性能」です。

- 読み込み時間が長い、コンテンツが表示されない
- スクロールできない、操作できない
- アクションに対して反応がない、待たされる

このようなWEBサイトよりも

- コンテンツがすぐ表示される
- すぐ操作可能
- アクションを起こすと反応があり、状態がわかる

こちらのほうがWEBサイトを使う上で快適です。
後者はWEBパフォーマンスがいいといえますね。

:::note info
ユーザーにとってWEBサイトを使いやすいものにすること、これがWEBパフォーマンス改善です。
:::

## WEBパフォーマンス改善の2つの目標

> - コンテンツがすぐ表示される
> - すぐ操作可能
> - アクションを起こすと反応があり、状態がわかる

これらを達成するには

- **WEBサイトを実際に速くすること**
- **WEBサイトを遅いと感じさせないこと**

この2つの方針でパフォーマンス改善が可能です。
計測できる指標にだけこだわらず、**ユーザーにとって遅いと感じさせない工夫も大事**だということですね。

:::note info
ユーザーが感じるパフォーマンスを[**知覚的パフォーマンス**](https://developer.mozilla.org/ja/docs/Learn/Performance/Perceived_performance)といいます。
:::

## WEBパフォーマンス指標

WEBパフォーマンスには計測可能な指標があります。
[**Core Web Vitals**](https://web.dev/articles/vitals?hl=ja#core_web_vitals)という3つの指標が用意されています。

- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)

### Largest Contentful Paint (LCP)

- ウェブページのメイン コンテンツが読み込まれてユーザーに表示されるまでの時間

WEBサイト全体の読み込みが遅くとも、ファーストビューがすぐ表示されるWEBサイトはユーザーからしてみれば速く感じます。

> 優れたユーザー エクスペリエンスを提供するには、Largest Contentful Paint を 2.5 秒以下にする必要があります。
> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218989/641d11de-4181-350a-624e-11b855cf8575.png)

引用元：[良い LCP スコアとは何ですか？](https://web.dev/articles/lcp?hl=ja#what_is_a_good_lcp_score)

:::note info
クリティカルレンダリングパス
Webサイトのリソースのダウンロード、処理、最初のピクセルの表示、までの一連の流れをクリティカルレンダリングパスと呼びます。
クリティカルレンダリングパスを分析し、レンダリングの妨げになっているリソースを特定することもWEBパフォーマンス改善には重要な要素です。
- [MDN:クリティカルレンダリングパス(en)](https://developer.mozilla.org/en-US/docs/Web/Performance/Critical_rendering_path)
- [web.dev:クリティカル パスの把握](https://web.dev/learn/performance/understanding-the-critical-path?hl=ja)
- [Webパフォーマンス入門: クリティカルレンダリングパス](https://perfdata.jp/blog/blog-2017-09-15.html)
:::

### First Input Delay (FID)
- ユーザーが最初に操作した時の反応速度

画面は表示されたがスクロールできない、ボタンが反応しないといった遅延が起こる度合いです。
画面が素早く表示されたとしても、操作できなければユーザーは遅いと感じます。

> サイトで優れたユーザー エクスペリエンスを提供するには、初回入力遅延を 100 ミリ秒以下にする必要があります。
> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218989/5caffefb-1282-e552-c871-c388d8e151c2.png)

引用元：[良い FID スコアとは何ですか？](https://web.dev/articles/fid?hl=ja#what_is_a_good_fid_score)

### Cumulative Layout Shift (CLS)

- ページ コンテンツの予期しない移動が起こる頻度

記事を読んでいる最中に画像がレンダリングされ文章が下方向に移動して見失う、ボタンをクリックしようとした際に広告が表示され広告をクリックしてしまうなど、画面のカクツキや予期しない動作はユーザーを不満にさせます。

> 優れたユーザー エクスペリエンスを提供するには、サイトの CLS スコアを 0.1 以下にする必要があります。
> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218989/3b3bfbee-7d75-7e34-5a17-14cf745a4102.png)

引用元：[良い CLS スコアとは何ですか？](https://web.dev/articles/cls?hl=ja#what_is_a_good_cls_score)

また[測定すべき重要な指標](https://web.dev/articles/user-centric-performance-metrics?hl=ja#important_metrics_to_measure)には以下の指標もありますが、Core Web Vitalsよりは優先度が低そうです。
それぞれ整理しておきます。

- First Contentful Paint (FCP)
    - ページの読み込みを開始してから、ページのコンテンツのいずれかの部分が画面にレンダリングされるまでの時間
    - Core Web Vitalsの指標には前提としてこのFCPが良好であることが必要そうです
    - https://web.dev/articles/fcp?hl=ja
- Interaction to Next Paint (INP)
    - 保留中の Core Web Vitals 指標で、2024 年 3 月に初回入力遅延（FID）に置き換わる予定とのこと
    - https://web.dev/articles/inp?hl=ja
- Time to First Byte (TTFB)
    - > TTFB は Core Web Vitals 指標ではありません。そのため、重要な指標でスコアを上げるのに支障がなければ、サイトが「良好」な TTFB 基準を満たしている必要はありません。
    - [TTFB スコアの良さは？](https://web.dev/articles/ttfb?hl=ja#what_is_a_good_ttfb_score)

:::note info
**Core Web Vitals**を良好な状態に持っていくことがWEBパフォーマンス改善につながります。
- Largest Contentful Paint (LCP)：2.5 秒以下
- First Input Delay (FID)：100 ミリ秒以下
- Cumulative Layout Shift (CLS)：0.1 以下
:::

## CoreWebVitalsを計測するツール

### Google PageSpeed Insights

https://pagespeed.web.dev/?hl=ja

このツールを使用して様々なWEBサイトのCore Web Vitalsを計測できます。
また改善策を提案してくれる優れものです。
- スマホ、デスクトップ環境でスコアを計測できる
- 実際のユーザーの環境で評価する
    - WEBサイトが公開されていて、利用ユーザーがある程度いる場合、Chromeユーザーの実際のデータが反映されスコア化される
- パフォーマンスの問題を診断する
    - こちらはラボデータという特定の環境下で測定されたスコアが示されます。公開して間もないWEBサイト等は「実際のユーザーの環境で評価する」が表示されず、このラボデータのみ表示されます。

試しにQiitaのTOPページを診断してみた結果がこちらです。
Qiitaは速度的にはWEBパフォーマンスが良いといえそうです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218989/f7fa3d44-9ced-9a7e-70bb-08256ae82c03.png)


## 具体的な対策について（参考リンク一覧）

> - **WEBサイトを実際に速くすること**
> - **WEBサイトを遅いと感じさせないこと**

ここまでで、上記の2つの目標を達成するために、[**Core Web Vitals**](https://web.dev/articles/vitals?hl=ja#core_web_vitals)という3つの指標が役に立つこと、Google PageSpeed Insightsなどのツールを使用して計測できることを確認しました。

具体策はすでにいろいろなサイトで紹介されているので、ここではリンクの共有にとどめます。

### 勉強系

- [web.dev: パフォーマンスの学習へようこそ！](https://web.dev/learn/performance/welcome?hl=ja)
- [MDN: ウェブパフォーマンスとは](https://developer.mozilla.org/ja/docs/Learn/Performance/What_is_web_performance)

### 指標と対応策

- [Core Web Vitalsとは？Googleのランキング要因となる指標](https://digital-marketing.jp/seo/what-is-core-web-vitals/)
- [LCPとは？表示速度を遅くするLCPの改善方法6つ](https://digital-marketing.jp/seo/optimize-lcp/)
- [FID(First Input Delay)とは？調べ方と改善方法](https://digital-marketing.jp/seo/first-input-delay/)
- [CLSとは？レイアウトシフトのスコア計算と改善方法](https://digital-marketing.jp/seo/what-is-cls/)

### より細かな対応策

- [Webフロントエンドパフォーマンスチューニング80選](https://qiita.com/nuko-suke/items/50ba4e35289e98d95753)
- [PageSpeed Insightsで100点満点の爆速サイト🚀にした話](https://qiita.com/nuko-suke/items/22702472543bfd3e585f)
- [source要素にwidth/height属性を指定して各画像のアスペクト比の維持とCLSの改善を図る](https://www.mitsue.co.jp/knowledge/blog/frontend/202105/31_1512.html)
- [script タグに async / defer を付けた場合のタイミング](https://qiita.com/phanect/items/82c85ea4b8f9c373d684)

## 最後に

個人開発では徹底的に突き詰めてWEBパフォーマンス改善に取り組めますが、案件となるとスケジュールや納期との兼ね合いで対応範囲も限られます。
Google PageSpeed Insightsで100を目指すことはできないにしても、目標値の設定や、どこまで対応するかの指標にはできます。
またデザインや実装の段階で積極的にWEBパフォーマンスを考慮した設計がされるとより望ましいと思います。
WEBパフォーマンスを念頭によいプロダクトを作っていきましょう。