フロントエンドのパフォーマンスチューニング
今回は、フロントエンドのパフォーマンスチューニングについて解説していきます。
そもそもパフォーマンスとは、ユーザーの行動に対しての反応速度のことです。
例えば、ユーザーがクリックしたりスクロールしたりしてから、画面が反応するまで何秒もかかるとストレスになりますよね？
ストレスを感じたユーザーは、ページを離れる確率が上がりますし、もう一生このサイトに訪れないと思うかもしれません。
つまり、パフォーマンスとはそのくらい大事な要素なのです。
今回は、基本的なことに絞ってパフォーマンスチューニングについて解説していくので、初心者でもとっつきやすいかと思います。
ぜひ、参考にしてみてください。
レンダリングの仕組み
まず、パフォーマンス改善をするためには、ブラウザの仕組みを知る必要があります。
なので、どのような仕組みでWebページが画面にレンダリングされるのか、を解説して行きます。
まず大前提として、ブラウザごとにレンダリングの仕組みは異なります。
ですが、大枠は変わらないので、まずは基本的なことを抑えていきましょう。
結論から言うと、次の順番で処理が行われます。
- Loading
- Scripting
- Rendering
- Painting
これをそれぞれ解説していきます。
Loading
Loadingでは、HTMLやCSSなどをダウンロードして、ブラウザで扱える形に変換させます。
つまり、対象のサイトからコンテンツを取得して、DOMやCSSOMなどを作成するフェーズになります。
もちろん、JavaScriptなどもレンダリングエンジンで使用する形にparseされます。
さらに、HTMLなどの中で別のコンテンツを参照していたら、そのファイルもダウンロードしにいきます。
Scripting
このフェーズでは、JavaScriptの実行を行います。
具体的には、コンパイルとJSエンジンによる実行が行われます。
このコンパイルのされ方はブラウザごとに異なりますし、JSエンジンも異なります。
Rendering
このフェーズでは、どのDOM要素にどのCSSルールが当たるかを計算します。
具体的には、CSSセレクタとDOM要素のマッチング、詳細度を元にどのルールを適用させるかの決定などが行われます。
また、それを基に要素の大きさやmarginなど、layoutの計算も実行されます。
Painting(paint,rasterize,comite layers)
このフェーズはさらに次の3つに分けれます。
- Paint
- Rasterize
- Composite
それぞれ説明していきます。
まずPaintで2Dの画面をレイヤーごとに生成します。
Paintで作成した2Dの画面をz-indexなどを元に重ね合わせます。
そして、Compositeのフェーズでそれらを良い感じに合成します。
これで、最終的な画面が完成します。
チューニングの判断
パフォーマンスチューニングは、闇雲にやれば良いというものではありません。
チューニングするには、開発者のリソースが割かれますし、コードが複雑なものになってしまう可能性があります。
なので、闇雲にパフォーマンスチューニングをやって、結局効果がありませんでしたとなってしまうと良くないです。
そのためコストパフォーマンスを考えて、チューニングするかを決める必要があります。
具体的には、実際にパフォーマンスを計測した上でチューニングするか決める、といったことが大事になります。
RAIL
パフォーマンスの指標としてRAILという有名なものがあります。
RAILとは、Response,Animation,Idle,Loadの頭文字を取ったものです。
これらは次のような速度を目指すと良いと言われています。
| 処理 | 目標 |
|---|---|
| Response | 100m秒 |
| Animation | 16m秒 |
| Idle | 50m秒 |
| Load | 1000m秒 |
Responseとはその名の通り、ユーザーがクリックなどを実行して反応するまでの時間です。
Animationは1フレームごとの秒数を差しています、要は60fpsくらいを目指せばOKです。
Idleは少し複雑ですが、ユーザーが何も操作していない時の処理のことです。
例えば、プリフェッチやプリロードなどです。
この処理を50m秒で区切ることで、突然ユーザーが操作を開始したときに、その操作にすぐに応答できるようになります。
Loadはコンテンツの読み込みにかかる時間を表します。
もちろんこれらは飽くまで指標なので、チーム内でどのくらいのパフォーマンスを目指すか決めるのも大事です。
パフォーマンス計測
また、ツールを用いてパフォーマンスを計測するのも効果的です。
まずchromeの開発者ツールが最も手軽です。
network,perfomance,momeryタブあたりを見ると、パフォーマンスの詳細をすることができます。
また、JavaScriptを使って、パフォーマンスを計測することもできます。
なので、詳細に処理の時間を知りたいときは、こちらの方を使う必要があります。
また、PageSpeed InsightsやLighthouseも便利です。
継続的にパフォーマンスのモニタリングを行なってくれるツールを導入するのも良いでしょう。
Web Vitals
Web VitalsはGoogleが定義したUX指標です。
Web Vitalsで重要視されているものは以下の3点です。
- Largest Contentful Paint
- First Input Delay
- Cumulative Layout Shift
それぞれ解説していきます。
Largest Contentful Paint
ページの表示速度を測る指標になります。
具体的には、最大コンテンツ（ページのメイン部分）の描画、それを読み込み表示する時間を示す指標です。
2.5秒以内が良評価となります。
First Input Delay
ユーザーの応答性を測る指標になります。
コンテンツが表示され、操作できるようになるまでの時間が1秒以内が良評価となります。
Cumulative Layout Shift
視覚の安定性を測る指標です。
ロードしたあとに表示がずれたり、最初に画像が表示されず少ししてから表示され、その分レイアウトがずれるなど予期せぬレイアウトの崩れを定量化します。
0.1以下が良評価となります。
パフォーマンスのチューニング方法
最後にどのようにすれば、パフォーマンスを改善できるのかを解説していきます。
その時々によって、ベストプラクティスは変わってきますので、適宜改善したい項目を元に検索してみてください。
Loading時のチューニング
まず、このフェーズでは読み込みに時間をかけないようにすることが大切です。
具体的な対策としては、以下のようなものが挙げられます。
- ファイルサイズを最小化する
- 遅延読み込みの導入
- 適切な画像形式を選択する
写真はJPEG、 アニメーションはGIF、 それ以外はPNGを使用 - 画像サイズを下げる
- JavaScriptを非同期で読み込む
- imgタグのsrcsetを使用して、デバイスごとに画像の大きさを最適化する
- メディアクエリを使用する
- リソースの事前読み込み
- CDNの活用
- キャッシュの活用
Scripting時のチューニング
このフェーズでできることは、JavaScriptを効率的に実行させることのみです。
具体的な対策としては、以下のようなものが挙げられます。
- メモリリークに気をつける
- 時間のかかっている処理をリファクタする
- webworkerを活用する
- scrollイベントをなるべく使わない
- 非同期で良いものは非同期で処理する
- SSGを導入する
Layout時のチューニング
ここでは、CSSを効率的に書くことが大事になってきます。
具体的な例としては次の通りです。
- 子孫セレクタ、間接セレクタ、全称セレクタはなるべく使わない
- セレクタをシンプルにする
BEMはこの面だと優秀 - 使用していないルールセットを削除する
- Classではなく直接Styleを書き換える
可読性が下がる可能性があるので、必要な時のみ。 - メディアクエリを使用する
その他
最後に、細かいTipsをいくつか紹介します。
以下のような対策も、ユーザーのストレスとを減らすことができます。
- 無限スクロール
- インジケーター
- 仮のコンテンツを表示しておく
- Prefetchをしておく
- 処理が終わったように振る舞う
これらのテクニックも上手く活用することで、ストレスレスなサイトを作成することができます。
まとめ
今回は、フロントエンドのパフォーマンスチューニングについて解説してきました。
ぜひ、これ参考にして、パフォーマンスチューニングを進めていってください。
宣伝
0からエンジニアになるためのノウハウをブログで発信しています。
また、YouTubeでの動画解説も始めました。
インスタの発信も細々とやっています。
興味がある方は、ぜひリンクをクリックして確認してみてください！
Discussion