Lighthouseのパフォーマンス改善を試みた
はじめに
最近リリースしたサイトのスコアがかなり低いことに気がついたので、どうやったら改善できるか調べてみたことをまとめました。
環境
- デプロイ環境 Amplify
- フレームワーク Next.js 12.0.8
結果
今回いろいろ調べて試してみたんですが、結果としてパフォーマンスを改善することはできませんでした。（パッと思いつくところ取り組んでみましたが、改善できなかったので、引き続き改善策を思いついたら取り組んでいきたい）
なので後述する内容はあまり参考になりませんが、取り組んだことを忘れないようにする & 再チャレンジする際、今回やったことを忘れないようにするため、やったことをまとめました。
取り組んだこと
- next/image を使うようにした
- 不要なモジュールを使ってないか調べた
- 初期描画を早くするように試みた
next/image を使うようにした
Lighthouseのスコアで、改善できる項目に「次世代フォーマットでの画像の配信」があったのと、当初 next/imageを使えていなかったので、まずは画像最適化のため next/imageを試すところからはじめました。
結果は「次世代フォーマットでの画像の配信」の短縮時間が55秒から0.45秒に変わるも、Lighthouseのパフォーマンスのスコアに大きな変化はないという結果でした。
next/image の詳細はドキュメント
next/image 使ってみての感想メモ
普段、Static HTML ExportでNextをデプロイすることが多く、その場合 デフォルトのローダーではサポートされてない ので、next/imageを使ったことがなかったのですが、今回実際に試してみた感じ
- webpに変換
- 画像のサイズが縮小
- 遅延読み込み
などの挙動を確認することができて、next/image すごいと思ったので、今後もっと使っていきたいと思いました。
不要なモジュールを使ってないか調べた
next-bundle-analyzerを導入、生成されたJSファイルのバンドル情報を可視化して確認してみました。
結果は以下の通りです。Dialogコンポーネントのファイルのサイズがかなり大きいとわかったのですが、よく調べてみると単純に対象のファイルの中で容量の大きいSVGファイルを使われてただけでした。
こちらを適切な画像に差し替え、あらためてスコアを確認してみたのですが、結果は大きく変わらずでした。
next-bundle-analyzer 使ってみての感想メモ
今回はじめて next-bundle-analyzer を使ったのですがビジュアライズ化されるのは、わかりやすいと感じた。
初期描画を早くするように試みた
今回の構成として、各ページに必要なデータを毎回クライアントサイドでフェッチしていたのですが、getStaticPropsを使いビルド時にデータをフェッチするようにすると、スコアが改善されるのではないかと思い試してみました。
スコアが改善されるイメージとしては、ビルド時にデータを取得するので、クライアントサイドで初回のフェッチでのローディングの表示がなくなり、Cumulative Layout Shift のスコアが向上するのではないかと思い試してみました。（スケルトン的なローディングじゃなくて、画面真ん中でくるくるするやつ使ってたので、フェッチ中のローディングの表示がなくなれば、視覚的な安定性が高まりそう？というイメージ）
Cumulative Layout Shift (累積レイアウト シフト数、CLS) は、視覚的な安定性を測定するための重要なユーザーを中心とした指標です。これは、ユーザーが予期しないレイアウト シフトに遭遇する頻度の数値化に役立つ指標であり、CLS が低ければ低いほど、そのページが快適であることが保証されます。
こちらも結果としては、スコアに影響ありませんでした。このあたりの記事も参考になりそうなのでもう少し調べてみます。
Cumulative Layout Shift を最適化する
以上、今回取り組んだことでした。
Lighthouseの指標
Lighthouseのパフォーマンスの指標についてについて調べたことまとめ。調べた順にリンクを並べてます。（https://web.dev/ の記事わかりやすい）
パフォーマンスの指標は、Lighthouseで見れるこちらの値
Largest Contentful Paint (LCP)
ビューポート内に表示される最も大きな要素のレンダリングタイミング、秒を指標としていて、数値は引くほど良い。
Largest Contentful Paint (LCP)
Largest Contentful Paint を最適化する
First Contentful Paint (FCP)
First Contentful Paint (視覚コンテンツの初期表示時間、FCP) は、知覚される読み込み速度を測定するための重要なユーザーを中心とした指標です
Time to Interactive（TTI）
TTIは、ページが完全にインタラクティブになるまでにかかる時間を測定します。次の場合、ページは完全にインタラクティブであると見なされます。
Total Blocking Time（TBT）
TBTは、マウスのクリック、画面のタップ、キーボードの押下といったユーザー入力への応答がブロックされている合計時間を測定します。合計は、First Contentful Paint (最初のコンテンツ描画にかかるまでの時間) と Time to Interactive (インタラクティブになるまでの時間) の間に実行されるすべての長いタスクのブロック部分を加算することで算出されます。
Web Vitals
Googleが推奨してるUXの指標
- Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP)
- First Input Delay (初回入力までの遅延時間、FID)
- Cumulative Layout Shift (累積レイアウト シフト数、CLS)
おわりに
- 今回、結果としてパフォーマンス改善できなかったが、どういう指標でパフォーマンスが測定されているのか知れてよかった
- 改善できる項目の「使用していない JavaScript の削減」について、まだまだ改善できそうな気がするが、使用していないJavaScriptを見つける方法が難しくいったん諦めた。また再チャレンジする際はこの辺りから試みたい
- Lighthouse 測定の対象デバイスがモバイル or パソコンかでスコアがかなり違っていた。モバイルの場合通信環境が悪いことを想定したシミュレーションのスコアになる？など気になったのでこのあたりも調べたい
Discussion