テスト環境ということもあり、ブレ幅が大きいものの、広告タグを実装することでスコアが大幅に減少することは間違いなさそうです。ただしコアウェブバイタルのスコアを上げるために、広告収益を下げてしまっては本末転倒。今後は広告収益面を考慮したSEO対策、コアウェブバイタルへの対応が重要になってくると考えられます。

コアウェブバイタル向上のための実施施策

次に、コアウェブバイタルのスコア向上のために弊社で実施した3つの施策をご紹介できればと思います。ユーザーエクスペリエンス自体を上げるための施策は山ほどありますが、本記事では広告収益面を考慮したうえで実施した施策をご紹介できれば幸いです。

①広告領域の確保

CLSスコアであるページの安定性を高めるために広告領域の確保を実施しました。
レイアウトシフトが発生する要因は、画像や広告サイズが指定されていないことが挙げられています。
運用型広告を実施する場合、

• 複数の広告サイズを受け入れることでより単価の良い広告を入札する
• 高単価な入札があった場合のみ表示させる（ない場合は閉じる）

といった運用をするケースが多く、ページのガタつきに直結していました。　
運用型広告を実装したままCLSスコアを上げるためには、サイズ不定な要素を無くし、レイアウトのズレを解消する必要があります。

・広告サイズを固定し、表示領域を確保する

広告は固定サイズで導入が推奨されていますが、動的要素を入れないといけない場合やサイズ固定ができない場合はプレイスメントの最小の高さで確保しておくと、シフトが最小限に抑えられます。最小の高さは過去の配信レポートからレンダリングされたサイズを確認いただくことをおすすめします。

・呼び出し広告サイズに2/3の高さの設定と自社広告の入稿

広告が呼び出されなかった場合、空白が発生する可能性があります。その場合の対策として、第二の呼び出しサイズに2/3の高さの広告を設定する、自社広告を入れておくなどである程度解消されると考えられます。また、ATFでレイアウトシフトが発生するとスコアへ影響が大きいと考えられるため、優先枠を絞って段階的に対応を進めても良いと思います。

②『preload』の実装

次に推奨する方法は、リソースを事前に読み込ませるために『preload (プリロード) 』を実装し、表示速度を高める方法です。
preloadとは先行読み込みをブラウザに指示する機能でヘッダー部分に記述して利用します。preloadを活用し優先的にScriptなどの要素を呼びだすことができます。
運用型広告を実装する場合、広告を表示するまでに各SSPなど外部にリクエストを飛ばし入札事業社と単価をきめ、広告を戻すという複雑な処理が必要となり、必然的に表示が遅くなってしまいます。またHeaderBiddingにしてもウォーターフォールにしても接続先が増えるほど表示速度は低下します。
広告表示速度を上げるためには、リクエストをいかに速く送るのかがポイントとなります。そこで効果的な方法がpreloadです。
preloadを活用し、広告表示に関係するGoogleのタグコードである『gpt.js』やHeaderBiddingのコードの『prebid.js』などを先に読み込ませることにより、ほかのコンテンツを表示させている間に、広告表示の準備ができるようになります。また、「gpt.js」や「prebid.js」自体は、他のJavaScriptの読み込みを妨げないので、できるだけ先頭近くに設置するだけでも効果があります。

③JavaScriptやCSSの軽量化

最後に使っていないファイルの削除や記述の軽量化をおすすめします。この方法も比較的、少ない工数で実施できる対策と考えられます。
LCPスコアを低下させる原因にレンダリングブロック、FIDスコアの低下の主な原因は大量のJavaScript実行による遅延です。
レンダリングブロックとは、Webページを読み込んで画面に描画することを待たせてしまう要因のことで、そのような外部ファイル等をレンダリングブロックリソースと呼びます。一般的なレンダリングブロックリソースはヘッダー部分のjsやCSSファイルであることが多く、そうした遅延の要因を減らす施策が重要となっています。レンダリングブロックの解除や軽量化には、以下のような施策が有効と考えられます。

・minify化（コードの中の不要なコメント、改行、空白の削除）や、使用していないファイルの削除

PageSpeed Insightsで「改善できる項目」を見ていただくとより具体的に表示速度に影響している Script やリソースがわかります。