英国の大手ニュース ウェブサイトでは、数か月以内に 75 パーセンタイル CLS を 250% 改善し、0.25 から 0.1 に改善しました。
視覚的な安定性に関する課題
レイアウトの変化は非常に混乱を招く可能性があります。Telegraph Media Group（TMG）では、読者が主にアプリケーションを使用してニュースを閲覧するため、視覚的な安定性が特に重要です。記事の読み込み中にレイアウトが変更されると、読者はどこを読んでいたか分からなくなる可能性があります。そのため、イライラしたり、気を散らしたりする可能性があります。
エンジニアリングの観点から、ページが移動して読者の操作を中断しないようにすることは、特にアプリケーションの領域が非同期で読み込まれ、ページに動的に追加される場合は難しい場合があります。
TMG には、クライアントサイドのコードに貢献する複数のチームがあります。
- コア エンジニアリング。サードパーティ ソリューションを実装して、コンテンツのおすすめやコメントなどの領域を強化する。
- マーケティング。A/B テストを実施して、読者が新しい機能や変更にどのように反応するかを評価する。
- 広告: 広告リクエストと広告の事前入札の管理。
- 編集。記事（ツイートや動画など）内にコードを埋め込むこと、およびカスタム ウィジェット（新型コロナウイルス感染症のケース トラッカーなど）を埋め込むこと。
これらの各チームがページのレイアウトを乱さないようにすることは困難です。チームは、累積レイアウト シフト指標を使用して、読者に発生する頻度を測定し、実際のユーザー エクスペリエンスに関するより多くの分析情報を得て、達成すべき明確な目標を設定しました。その結果、75 パーセンタイル CLS は 0.25 から 0.1 に改善し、合格バケットは 57% から 72% に増加しました。
250%
75 パーセンタイルの CLS の改善
15%
CLS スコアが高いユーザーが増える
最初
CrUX ダッシュボードを使用して、ページが望ましくないほど移動していることを確認できました。
理想的には、少なくとも 75% の読者に「良好」なエクスペリエンスを提供したいと考え、レイアウトの不安定性の原因の特定を開始しました。
レイアウトのずれの測定方法
レイアウトがずれる原因を特定するために、Chrome DevTools と WebPageTest を組み合わせて使用しました。DevTools では、[パフォーマンス] タブの [エクスペリエンス] セクションを使用して、レイアウトのずれの個々のインスタンスと、それらが総合スコアにどのように影響したかをハイライト表示しました。
WebPageTest では、[レイアウト シフトをハイライト表示] を選択すると、タイムライン ビューでレイアウト シフトが発生した場所がハイライト表示されます。
最もアクセス数の多いテンプレートの各シフトを確認した結果、改善方法に関するアイデアのリストが作成されました。
レイアウト シフトの軽減
レイアウトのずれを減らすことができる 4 つの領域に重点を置きました。 - 広告 - 画像 - ヘッダー - 埋め込み
広告
広告は、JavaScript を介して最初のペイントの後に読み込まれます。読み込まれたコンテナの一部に、予約済みの高さが設定されていませんでした。
正確な高さは不明ですが、スロットに読み込まれた最も一般的な広告サイズを使用してスペースを確保できます。
広告の平均高さを誤って判断していたケースがありました。タブレット リーダーの場合、スロットが閉じていました。
スロットを見直し、最も一般的なサイズを使用できるように高さを調整しました。
画像
ウェブサイト上の多くの画像は遅延読み込みされ、画像用にスペースが予約されています。
ただし、記事の上部にあるインライン画像には、コンテナに予約されたスペースがなく、タグに幅と高さの属性も関連付けられていませんでした。その結果、読み込み時にレイアウトがずれる問題が発生していました。
画像に幅と高さの属性を追加するだけで、レイアウトがずれないようにしました。
ヘッダー
ヘッダーはマークアップ内のコンテンツの下に配置され、CSS を使用して上部に配置されていました。当初は、ナビゲーションよりもコンテンツの読み込みを優先する予定でしたが、この方法ではページが短時間移動する問題が発生しました。
ヘッダーをマークアップの上部に移動すると、このシフトなしでページをレンダリングできるようになりました。
埋め込み
よく使用される埋め込みには、定義されたアスペクト比があります。たとえば、YouTube 動画などです。プレーヤーの読み込み中に、YouTube からサムネイルを取得し、動画の読み込み中にプレースホルダとして使用します。
効果の測定
この記事の冒頭で説明したツールを使用して、機能レベルで影響を確認できました。ただし、CLS はテンプレート単位とサイト単位の両方で測定したいと考えていました。合成テストでは、SpeedCurve を使用して、本番前環境と本番環境の両方で変更を検証しました。
コードが本番環境に到達したら、RUM データ（mPulse 提供）で結果を検証できます。
RUM データを確認することで、実施した変更が読者に好影響を与えていることを高い信頼度で把握できます。
最後に確認した数値は、Google が収集する RUM データに関するものです。まもなくページのランキングに影響するため、特に重要です。まず、Chrome UX レポートを使用しました。CrUX ダッシュボードで利用可能な月次オリジンレベルのデータと、BigQuery のクエリを使用して過去の p75 データを取得しました。これにより、CrUX で測定されたすべてのトラフィックで、75 パーセンタイル CLS が 250% 改善され（0.25 から 0.1 に）、合格バケットが 57% から 72%に増加したことを簡単に確認できました。
また、Chrome UX Report API を使用して、テンプレートに分割された内部ダッシュボードを作成することもできました。
CLS の回帰を回避する
パフォーマンスを改善するうえで重要なのは、回帰を回避することです。主要指標の基本的なパフォーマンス予算を設定し、CLS をその中に含めました。
テストで予算を超えた場合は、Slack チャンネルにメッセージが送信され、原因を調査できます。また、週次レポートも設定されているため、テンプレートが予算内に収まっている場合でも、悪影響を及ぼす変更を把握できます。
また、予算を拡大して RUM データと合成データの両方を使用する予定です。mPulse を使用して静的アラートと異常検出の両方を設定し、異常な変化を検出できるようにします。
新機能を開発する際は、CLS を念頭に置くことが重要です。これまでお話しした変更の多くは、読者に公開した後に修正を加えたものです。今後、新しい機能のソリューション設計では、レイアウトの安定性を考慮し、最初から予期しないレイアウト シフトを回避できるようにします。
まとめ
これまでに実施した改善は、実装が非常に簡単で、大きな効果がありました。この記事で説明した変更の多くは、実装にそれほど時間がかからず、最もよく使用されるテンプレートにすべて適用されました。つまり、読者に広範囲にわたってプラスの影響を与えています。
サイトには改善すべき点がまだあります。Google は、CLS をさらに改善するために、クライアントサイド ロジックをサーバーサイドで実行する方法の検討を進めています。Google は、指標を継続的に改善し、読者に最適なユーザー エクスペリエンスを提供することを目標に、指標の追跡とモニタリングを継続します。