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