星評価ウィジェットが引き起こすCLSの問題

CLSとは何か、なぜ星評価ウィジェットがCLSを悪化させるのか

Cumulative Layout Shift（CLS）は、ページが読み込まれる際に可視コンテンツがどれほど動いたかを測る指標です。画面上にすでに表示されている要素が、ユーザーの操作なしに別の位置へ移動するたびにスコアが加算されます。CLSが高いページとは、読んでいた場所を見失ったり、ボタンがずれてタップミスをしたりするページです。

星評価は典型的なCLSの原因の一つです。多くのレビューアプリは、最初のHTMLが届いた後にスクリプトで星評価を挿入します。ページが表示された瞬間は星評価がなく、タイトルと価格が上の方に表示されています。その後ウィジェットが読み込まれ、下にあるすべての要素が押し下げられます。この押し下げがレイアウトシフトです。

レビューウィジェットは実際にどれほどページをずらすのか

見た目より大きい影響があります。星評価の一行は小さく見えますが、単体で挿入されることはほとんどありません。同じスクリプトが評価の数字、レビュー件数、「○件のレビュー」へのリンク、場合によってはサマリーバーも一緒に挿入し、それまでゼロピクセルだったブロックが一度に出現します。

さらに悪いことに、このブロックは通常、商品ページの上部、ファーストビュー内に配置されます。まだスクロールされていないページ下部でのシフトはスコアへの影響が小さい。しかし顧客が商品タイトルを読みながら「カートに入れる」ボタンに手を伸ばしているまさにその瞬間に、ヒーロー部分でシフトが起きると、体験を損ねるうえにCLSスコアへの影響も最大になります。

CLSがページ体験と検索順位に影響する理由

CLSはCore Web Vitalsの一つであり、Core Web VitalsはGoogleの検索順位への入力シグナルです。Googleはページ体験、CLSを含む各指標が検索結果の並び順に実際に影響すると明言しています。コンテンツやリンクほど強力なレバーではありませんが、競合商品のキーワードで争うときに無用な不利を抱えるべきではありません。

ユーザーへのコストも軽視しがちです。ページが目の前でがたがたと再配置される様子は安っぽさや不具合の印象を与えます。そしてその印象は、顧客がカード情報を入力して信頼を置くかどうかを判断する数秒に訪れます。

• 検索順位: CLSはGoogleが使用するページ体験シグナルの一部です。
• コンバージョン: 購入判断の瞬間にレイアウトがずれると信頼が損なわれます。
• タップミス: レイアウトのシフトにより顧客が誤ったボタンを押すことがあります。
• 体感速度: 安定したページは、同じ読み込み時間でも動きのあるページより速く感じられます。

星評価によるレイアウトシフトを防ぐには

二つの対策があり、それぞれ難易度が異なります。

一つ目はスペースの事前確保です。星評価ブロックの高さが例えば28ピクセルになるとわかっているなら、ウィジェットが届く前にCSSでそのコンテナに同じ高さを与えておきます。遅れて読み込まれる星評価はすでに用意されたスロットに収まり、その下にある要素は動きません。この方法はほぼどのウィジェットでも使えます。ただし確保する高さが実際に読み込まれる高さと一致していることが前提です。

二つ目はサーバーレンダリングです。星評価を最初のレスポンスのHTMLに含めて返すことで、スクリプトが何かを挿入する必要がなくなります。これは本質的な解決策です。コンテンツは最初から存在するため、競合状態が生じません。ただし、レビュー機能がサードパーティのウィジェットの中に完全に閉じている場合は、後付けで実装するのが難しいこともあります。

• 星評価のコンテナにmin-heightまたはaspect-ratioでCSSの高さを事前確保します。
• 星評価内に遅れて読み込まれるフォントや画像があるとリサイズが起きるため注意が必要です。
• 可能であればサーバーレンダリングを優先し、スクリプトによる挿入をなくします。
• CLSはデバイスやネットワークによって変動するため、ラボ計測だけでなくフィールドデータで測定します。

iframeウィジェットはCLSに対して有利か

iframeは親要素の段階でサイズが固定されることが多いため、コンテンツが届いても外側のボックスは拡張せず、レイアウトシフトを封じ込める効果があります。しかし同じ固定されたボックスは、クローラーやAI回答エンジンから見ると不透明です。iframe内のレビューテキストはページのコンテンツとして読まれにくい傾向があります。

つまり、明確なトレードオフがあります。iframeはレイアウトを守りますが、コンテンツを検索やAIに読まれにくくします。サーバーレンダリングはレイアウトを守り、テキストも読まれやすい状態を維持します。選択できるならサーバーレンダリングが両方の点で優れていますが、環境に応じた準備が必要です。

CLSを改善するとレビューが検索で見つかりやすくなるか

間接的に、ある程度まで。スペースを事前確保すればシフトはなくなり、ページ体験と検索順位への小さな改善が得られます。しかしその空のボックスは、スクリプトで後から埋められている限り、レビューのテキストをクローラーやAI回答エンジンに読ませることはできません。事前確保したスロットに後からスクリプトで注入される構造では、そのスクリプトを実行しないシステムにレビューのテキストは届きません。

全ての面で有効な対策は、星評価とレビューをサーバーのHTMLに含めて返す方法です。シフトがなくなるうえに、テキストが検索エンジンとAIに読める状態になります。多くのレビューアプリはページ上の買い物客向けに作られており、ウィジェットで完結しています。これがBeyondReviewsが解決しようとしているギャップです。すでにあるレビューをサーバーレンダリングで、読める状態で、引用できる形で提供し、CLSのコストを生みながらクローラーに何も伝えないボックスから脱却することを目指しています。

まとめ

後から挿入される星評価は、小さな見た目の問題ですが影響は大きいです。ページの最もコストが高い場所でレイアウトをずらし、Core Web Vitalsのスコアを悪化させ、購入の瞬間に信頼を損ないます。スペースを事前確保すればシフトをなくすことができます。サーバーレンダリングはより根本的な解決策であり、同時にレビューテキストを読める状態に保ちます。可能であれば後者を選び、難しい場合は前者を選んでください。