WEBパフォーマンス改善とは何か
パフォーマンスとは「性能」です。
つまりWEBパフォーマンスとは「WEBの性能」です。
- 読み込み時間が長い、コンテンツが表示されない
- スクロールできない、操作できない
- アクションに対して反応がない、待たされる
このようなWEBサイトよりも
- コンテンツがすぐ表示される
- すぐ操作可能
- アクションを起こすと反応があり、状態がわかる
こちらのほうがWEBサイトを使う上で快適です。
後者はWEBパフォーマンスがいいといえますね。
ユーザーにとってWEBサイトを使いやすいものにすること、これがWEBパフォーマンス改善です。
WEBパフォーマンス改善の2つの目標
- コンテンツがすぐ表示される
- すぐ操作可能
- アクションを起こすと反応があり、状態がわかる
これらを達成するには
- WEBサイトを実際に速くすること
- WEBサイトを遅いと感じさせないこと
この2つの方針でパフォーマンス改善が可能です。
計測できる指標にだけこだわらず、ユーザーにとって遅いと感じさせない工夫も大事だということですね。
ユーザーが感じるパフォーマンスを知覚的パフォーマンスといいます。
WEBパフォーマンス指標
WEBパフォーマンスには計測可能な指標があります。
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 秒以下にする必要があります。
クリティカルレンダリングパス
Webサイトのリソースのダウンロード、処理、最初のピクセルの表示、までの一連の流れをクリティカルレンダリングパスと呼びます。
クリティカルレンダリングパスを分析し、レンダリングの妨げになっているリソースを特定することもWEBパフォーマンス改善には重要な要素です。
First Input Delay (FID)
- ユーザーが最初に操作した時の反応速度
画面は表示されたがスクロールできない、ボタンが反応しないといった遅延が起こる度合いです。
画面が素早く表示されたとしても、操作できなければユーザーは遅いと感じます。
サイトで優れたユーザー エクスペリエンスを提供するには、初回入力遅延を 100 ミリ秒以下にする必要があります。
Cumulative Layout Shift (CLS)
- ページ コンテンツの予期しない移動が起こる頻度
記事を読んでいる最中に画像がレンダリングされ文章が下方向に移動して見失う、ボタンをクリックしようとした際に広告が表示され広告をクリックしてしまうなど、画面のカクツキや予期しない動作はユーザーを不満にさせます。
優れたユーザー エクスペリエンスを提供するには、サイトの CLS スコアを 0.1 以下にする必要があります。
また測定すべき重要な指標には以下の指標もありますが、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 スコアの良さは？
-
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
このツールを使用して様々なWEBサイトのCore Web Vitalsを計測できます。
また改善策を提案してくれる優れものです。
- スマホ、デスクトップ環境でスコアを計測できる
- 実際のユーザーの環境で評価する
- WEBサイトが公開されていて、利用ユーザーがある程度いる場合、Chromeユーザーの実際のデータが反映されスコア化される
- パフォーマンスの問題を診断する
- こちらはラボデータという特定の環境下で測定されたスコアが示されます。公開して間もないWEBサイト等は「実際のユーザーの環境で評価する」が表示されず、このラボデータのみ表示されます。
試しにQiitaのTOPページを診断してみた結果がこちらです。
Qiitaは速度的にはWEBパフォーマンスが良いといえそうです。
具体的な対策について（参考リンク一覧）
- WEBサイトを実際に速くすること
- WEBサイトを遅いと感じさせないこと
ここまでで、上記の2つの目標を達成するために、Core Web Vitalsという3つの指標が役に立つこと、Google PageSpeed Insightsなどのツールを使用して計測できることを確認しました。
具体策はすでにいろいろなサイトで紹介されているので、ここではリンクの共有にとどめます。
勉強系
指標と対応策
- Core Web Vitalsとは？Googleのランキング要因となる指標
- LCPとは？表示速度を遅くするLCPの改善方法6つ
- FID(First Input Delay)とは？調べ方と改善方法
- CLSとは？レイアウトシフトのスコア計算と改善方法
より細かな対応策
- Webフロントエンドパフォーマンスチューニング80選
- PageSpeed Insightsで100点満点の爆速サイト🚀にした話
- source要素にwidth/height属性を指定して各画像のアスペクト比の維持とCLSの改善を図る
- script タグに async / defer を付けた場合のタイミング
最後に
個人開発では徹底的に突き詰めてWEBパフォーマンス改善に取り組めますが、案件となるとスケジュールや納期との兼ね合いで対応範囲も限られます。
Google PageSpeed Insightsで100を目指すことはできないにしても、目標値の設定や、どこまで対応するかの指標にはできます。
またデザインや実装の段階で積極的にWEBパフォーマンスを考慮した設計がされるとより望ましいと思います。
WEBパフォーマンスを念頭によいプロダクトを作っていきましょう。