CLS不良ページを "0" にした パフォーマンス改善テクニック

フロントエンド パフォーマンス

こんにちは、Plex Job 開発チームの高岡です。
以前投稿した「Web パフォーマンス改善に向き合っていくお話」の記事の続編として、弊社のPlex Job サイトを対象に、Google Search Console で検知された CLS 不良ページの改善を行ったので、今回はその具体的な Tips をお話ししたいと思います。

product.plex.co.jp

対象読者

以下の項目に関心がある方におすすめの記事です 🙏

  • パフォーマンス改善が必要なページの検出方法
  • CLS スコアの改善方法

背景

普段の機能改修の影響で、Google Search Console で検知される CLS 不良ページが急激に増加したケースがありました。ただ既存の不良ページの修正が後回しになっていたため、どのページで発生したのかを突き止めるのが難しい課題がありました。
これらはユーザー体験の低下や SEO に良くない影響を与えるため、今後の改修で不良ページが検出された際に素早く対応できるように改善することにしました。

  1. Google Search Console でサイト全体のパフォーマンスの全体像を把握する
  2. より詳細な調査として Vercel Speed Insights でスコアが悪化しているページを絞り込む
  3. 該当ページで Google Chrome DevTools 上の Lighthouse を使用して具体的な原因を調査する
  4. 原因に合わせて最適な対応を行う

上記の流れで改善を行いましたので、順を追って説明していきたいと思います。

Google Search Console での不良ページの検出

パフォーマンス改善が必要なページの検出には、Google 検索結果におけるウェブサイトの掲載順位を監視、管理、改善するのに役立つ Google Search Console を使用しました。
その機能の一つであるウェブに関する主な指標レポートは、実際のユーザーデータに基づいてウェブページのパフォーマンスを評価し、「不良」「改善が必要」「良好」のステータスで示します。このレポートは、LCP（Largest Contentful Paint）、INP（Interaction to Next Paint）、CLS（Cumulative Layout Shift） という 3 つの主要な指標（Core Web Vitals）を用いており、モバイルとパソコンの両方で URL のグループごとのパフォーマンスを確認できます。

弊社では、CLS スコアに問題があるページが検出されました。

▼ 当時の不良ページ

ここで検出されたページは特定のページではなく、類似するユーザーエクスペリエンスを持つ URL がグループとして扱われます。上記の URL グループだけでは、動的ルートを使用していたり、近しいパスが多い場合などに、実際にどのページでスコアが悪化しているかを絞り込むことが難しい場合もあります。
その場合、次の節で説明する Vercel Speed Insights での絞り込みが有効です。

Vercel Speed Insights で特定のページを絞り込む

Plex Job サイトは Next.js のフレームワークを使用しており、クラウドプラットフォームである Vercel でホスティングしています。
Vercel には Speed Insights という機能があり、ダッシュボードでウェブサイトのパフォーマンスに関する詳細な情報を確認できます。

上記のダッシュボードのように、パフォーマンスの指標ごとにどのルート・パスのスコアが悪いのかを特定することができます。
また、特定の期間での絞り込みや実際のリリース日がカレンダーに表示されるなど多くの情報を得ることができます。
(補足) Speed Insights 機能では、データの種類・評価の粒度・スコアの算出方法などが Google Search Console とは異なります。
https://vercel.com/docs/speed-insights/metrics

今回は、解決したい指標である CLS での絞り込みと具体的なパスで絞り込みを行いました。
継続的なモニタリングの面で、スコアが悪化した時に、カレンダーでどのリリースが影響しているのかを確認できる点はとても便利です。

そして、ページの特定ができた後は、実際にそのページを対象に Lighthouse を実行します。

Lighthouse を使用したパフォーマンス計測

Lighthouse は、ウェブページの品質を改善するためのオープンソースの自動化ツールです。認証が必要なページを含むあらゆるページで実行可能で、パフォーマンス、アクセシビリティ、プログレッシブウェブアプリ（PWA）、SEO など、さまざまな側面を監査します。
Google Chrome DevTools 内での実行のみではなく、コマンドラインツール、Node.js モジュール、または Web UI（PageSpeed Insight）からも Lighthouse を実行できます。

Lighthouse での計測方法

Google Chrome DevTools 上の Lighthouse を使用する際は、ノイズが少なく精度の高い計測をするために以下のことに気をつけています。

  • ユーザー環境に合わせるために Network throttling を Slow 4G に設定する。
  • Chrome 拡張機能の影響を避けるため、シークレットモードで計測する。
  • 計測値は変動する可能性があるため、複数回計測する。

左上の+ボタンから新しいレポートを作成し、複数のレポート結果を比較することも可能です。

計測結果の解釈

Lighthouse レポートには、以下のセクションが含まれます。

  • パフォーマンススコア（Performance） : ページ全体のパフォーマンスを数値で示します。
  • メトリクス（Metrics） : FCP、LCP、TBT、CLS、SI などの指標が表示され、各指標の値を確認できます。
  • 改善提案（Diagnostics） : ページのパフォーマンスを向上させるための具体的なアクションが提示されます。

下記は当時の Plex Job サイト で実際に CLS が発生していたページを再現して、Lighthouse を実行した結果です。

特定のメトリクスのみを確認したい場合は、"Show audits relevant to:" の該当メトリクスをクリックすると絞り込めます。
改善提案には、具体的な修正方法が記載されています。CLS では原因となる要素（Element）部分のキャプチャを表示してくれます。
今回は 2 つレイアウトシフトが発生していることが分かりましたので、それぞれの改善提案の中身を確認していきます。

CLS の改善方法

CLS は、ウェブページの読み込み中に発生する予期しないレイアウトの変動を測定する指標で、視覚的な安定性を評価します。
前節で実行した Lighthouse の結果の詳細を確認して、それぞれの原因と改善方法の説明をしていきます。

1. CSR（クライアントサイドレンダリング）によるデータフェッチ

上記画像は、メインコンテンツ要素でレイアウトシフトが発生していることを示しています。
このページは CSR によるデータフェッチを行なっていたので、Header と Footer は先に表示されて、その 2 つの間にメインコンテンツ部分がデータフェッチ後に差し込まれることで、Footer が大きくずれてレイアウトシフトが発生していました。

対応策としては、

  • データが読み込まれるまでの間はスケルトンを使用する
  • データフェッチをクライアント側ではなく、サーバ側で行う
  • レイアウトシフトが発生しないような UI デザインに変更する

などがあるかと思います。
今回はクライアント側でデータフェッチを行う必要がなかったので、SSR （サーバサイドレンダリング）にすることで対応しました。
SPA（Single Page Application）や初期ロード時に必要なデータを最小限に抑えたいケースなど、CSR を選択せざるを得ない場合は、スケルトンを導入することをおすすめします。
画面全体や表示領域が決まっている要素にスケルトンを使用する場合は簡易に実装ができますが、データに依存して表示領域が決まる要素が複数ある場合は、実装とデザインを調整するなど慎重に設計する必要があります。

2. 画像タグのサイズ指定の不一致

こちらは<img>タグに設定した画像のwidthとheightが、実際にレンダリング後のサイズと異なっていたため、微小なレイアウトシフトが発生していました。
このような小さなズレでも CLS スコアに積み重なり、全体のスコア悪化につながる可能性があります。

対応策としては、正しいwidthとheightを設定することで解消できます。また、画像のアスペクト比を維持するためにaspect-ratioプロパティを活用することも有効です。
サイズの違いもありますが、そもそも指定し忘れていたケースなどもあります。Next.js の Image コンポーネントを使用している場合、widthとheightは必須項目なのでそういったミスを事前に防げます。
https://nextjs.org/docs/app/api-reference/components/image

Plex Job サイトでは、上記 2 種類が CLS 発生原因でしたが、一般的には Web フォントの遅延適用などもよくある原因の 1 つです。

Lighthouse を使用した上で原因がわからない場合は...

今回の CLS 改善では Lighthouse の結果のみで原因を特定できましたが、改善提案だけでは原因が不明なケースもあります。その場合は、Lighthouse に加え、Performance タブや Network タブを併用して原因を突き止めます。

特に Performance タブの Insights 項目では、読み込みフレームと合わせて Core Web Vitals のスコア悪化の原因を詳細に確認できます。Screenshots のチェックボックスをオンにすると画面キャプチャも同時に取得でき、非常に分かりやすいです。
https://developer.chrome.com/docs/devtools/performance/reference#insights

実際に今回のページを対象に Performance タブの Insights 項目を確認すると、画面キャプチャと一緒にどのようにズレが発生していたかを明確に確認することができました。

CLS のみではなく、その他の Core Web Vitals も確認することができるのでとても便利な機能です。

Google Chrome DevTools は多機能で、新しい機能も次々と追加されています。すべてを把握するのは難しいですが、解決したい課題に関連する機能がないか公式サイトを確認するのがおすすめです。
https://developer.chrome.com/

結果

上記で説明した流れで CLS 不良ページの改善を地道に続けた結果、なんと見事不良ページ数が 0 になりました 🎉

まとめ

今回はパフォーマンス改善に関する具体的な手法について説明しました。
パフォーマンス改善は、ユーザー体験を向上させるために重要な取り組みです。特に CLS の改善は、視覚的な安定性を高め、ユーザーが快適にウェブサイトを利用できるようにするための鍵となります。
今回の取り組みでは、Google Search Console や Vercel Speed Insight、Lighthouse を活用し、具体的な原因を特定して改善を行いました。

今後も継続的にモニタリングを行い、必要に応じて改善を続けていく予定です。また、lighthouse-ci を導入することで、開発プロセスにおけるパフォーマンスの監視を自動化し、さらなる効率化を目指していきます。

参照

support.google.com support.google.com vercel.com developer.chrome.com developer.chrome.com

おわりに

現在プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。 この記事を見て一緒にパフォーマンス改善をガンガン行いたい方がいればお気軽にご連絡をお願いいたします！

dev.plex.co.jp