こんにちは。LINEヤフーのディスプレイ広告（以下、ディスプレイ広告）の開発と兼務で、全社横断のWebパフォーマンス改善に取り組んでいるエンジニアの今宮です。
一般にWebページの表示速度はユーザー体験や事業KPIに影響するとされており、LINEヤフーでも全社横断でWebパフォーマンス改善に取り組んでいます。一方で広告については、「表示を速くすれば広告のKPIも改善するのか」は自明ではありません。本記事では、Speculation Rules APIによるページの事前レンダリング・広告の先読みの検証と、広告のみをPrefetchする検証を通して、広告の表示高速化がCTR（クリック率）とClick（クリック数）にどう影響するかを調査しました。
今回の検証では、広告のCTRとClickは絶対的な表示速度ではなく、ページとの相対速度に影響を受けることがわかりました。また、もともと表示が遅い広告を高速化するとCTRが有意に向上し、Clickも増加することが判明しました。
広告を掲載するサービス開発者の方はもちろん、ユーザーに訴求したいページ内コンポーネントを持つサービス開発者の方の一助になればと思います。
事前レンダリングによる表示高速化
事前レンダリングとは、ユーザーがページに遷移する前に、遷移先ページの読み込みとレンダリングを裏側で実施しておく技術です。遷移した時点で描画済みのページを表示できるため、ユーザーに速くコンテンツを届けることができます。今回は「Speculation Rules API」を利用して、この事前レンダリングを行いました。この仕組みについて、Yahoo!ニュースでの導入テスト結果を共有します。なお、本記事で紹介するテストは、すべてPC版のページを対象に実施しています。
Speculation Rules APIについて
「Speculation Rules API」は、Google Chrome等で利用可能なWeb APIです。このAPIは、あるページAから別のページBに遷移する前に、先読み（Prefetch）と事前レンダリング（Prerender）ができます。
PrefetchとPrerenderの違いとして、PrefetchはページBに遷移する前にリソースの取得を行うのに対して、Prerenderはレンダリングまで行います。
参考：Speculation Rules API - MDN
Prerender Hit Rateについて
Prerenderの導入で重要になる指標として、Prerender Hit Rateがあります。Prerender Hit Rateは、Prerenderしたページに実際にユーザーが遷移した割合です。Prerenderは遷移する前に事前レンダリングを行うため、ユーザーが遷移しなかったページへのリクエストとレンダリングは無駄になります。そのため、Hit Rateが低いと、遷移先のサーバーへの無駄なリクエストが増え、インフラコストが高まります。
事例1：Yahoo! JAPANトップページからYahoo!ニュースへのPrerenderのテスト
Yahoo! JAPANトップページからYahoo!ニュースへの遷移において、Prerenderを導入するA/Bテストを実施しました。今回のテストでは、Yahoo!ニュース トピックスの見出し（以下の画像の青色の箇所）をマウスホバーした際に、リンク先であるYahoo!ニュース トピックスの詳細ページを事前レンダリングするようにしました。また、広告に関しては、Prerender実施中にインプレッションが意図せず計測されることを避けるため、遷移後に広告リソースの取得と広告の表示を行うようにしました。
参考：LINEヤフーにおけるPrerender技術の導入とその効果
結果：ページは高速化したが広告KPIには寄与せず
このテストの結果については、ページ読み込み時間（performance.timing における loadEventEnd - navigationStart）は0.13秒（6.9％）ほど短縮されたものの、広告売上の増加やPV・ユーザー滞在時間の増加などには寄与しませんでした。また、広告のCTRとClickにも有意差はありませんでした。
またこのテストでは、青色のリンク要素をマウスホバーすると、Yahoo!ニュースのページにリクエストし、レンダリングするため通常よりもYahoo!ニュースへの負荷が高まりました。このテストのPrerender Hit Rateは約15％で、もしこの機能をそのまま本番導入すると、現在の約6倍のキャパシティが必要になることがわかりました。
事例2：Yahoo!ニュース トピックスの詳細ページからYahoo!ニュース記事詳細ページへのPrerenderと広告Prefetchのテスト
事例1の結果を踏まえ、今回のテストでは以下の改善策を講じました。
- Prerenderするリンク先は、特に遷移する可能性が高いものに絞る
- ページのPrerenderのみではなく、広告要素も事前に読み込み、表示を高速化する
リンク先を絞るため、Yahoo! JAPANトップページからの遷移ではなく、Yahoo!ニュース トピックスの詳細ページからYahoo!ニュースの記事詳細ページへの遷移に変更しました。
トピ ックスの詳細ページから記事ページへの遷移は、事例1のYahoo! JAPANトップページからYahoo!ニュースへの遷移よりも、Prerender候補の数が少なくなり、キャパシティに関する問題の軽減が期待できます。
また広告に関しては、種類に応じてPrerenderを行うものや、広告リクエストのうち事前に実行できる一部の通信をPrefetchするものなどを用意しました。
参考：Speculation Rules APIを用いたページ・広告表示の高速化によるメディア・広告KPIの改善への取り組み
広告フローと高速化のポイント
Yahoo!ニュースにおける通常の広告のフローは、以下のようになっています。
ユーザーがページAからページBへ遷移すると、ページの読み込み後に広告の読み込み処理が行われ、広告が表示されます。この時に大きなボトルネックになるのが、図の「広告リクエスト処理」、つまりネットワークの通信部分です。今回の高速化手法ではこの通信部分のボトルネック解消を図ります。
今回の高速化対象の広告
Yahoo!ニュース記事詳細ページのファーストビューに表示される右上の広告枠（aboveAD）とその下の広告枠（belowAD）について、今回は高速化を行いました。aboveADについては動画広告が配信され るかどうかで、（1）画像と（2）動画に分けています。
広告の概要は以下のとおりです。
| 広告枠 | 表示速度 | 配信される広告の種類 | 高速化手法 |
|---|---|---|---|
| aboveAD（1） | 普通 | 画像 | 一部通信Prefetch |
| aboveAD（2） | 比較的遅い | 動画 | 一部通信Prefetch |
| belowAD | 比較的速い | 画像 | Prerender |
aboveADとbelowADではそもそも配信される形式が異なり、belowADのほうが比較的高速に表示されます。また、広告にPrerenderを実装する場合、Prerender実施中にインプレッションが意図せず計測されないようコントロールする必要があります。belowADは自社（Yahoo!広告）でインプレッションの発火をコントロールできる一方、aboveADは他社（外部アドネットワーク）の広告が配信される可能性があり、自社ではコントロールしきれません。そのため、aboveADに対しては自社の通信部分のみを先読みする一部通信の高速化、belowADに関してはPrerenderの導入テストを行うようにしました。
結果：ページ配信側の必要キャパシティは半減し、aboveAD（2）のCTRが有意に向上
今回のテストでは、Prerender Hit Rateが事例1の約15％から約31％に向上しました。これにより、事例1で課題となっていたページ配信側の必要キャパシティは約6倍から約3倍に減少しました。また事例1と異なり、aboveAD（2）に関しては、CTRが有意に向上し、リフト値（未実施時に対する相対的な変化率）は2～3％ほどでした。またbelowADに関しては、有意差は出ていないものの、高速化するとCTRが低下する傾向が見られました。
広告のみ先読みすることによる広告表示高速化
今回の事前レンダリングによる表示高速化では、事例2で改善したものの、まだページ配信側に約3倍のキャパシティが必要になること、また、PrerenderできないaboveADに関してPrefetchで効果が出たことから、広告の表示速度が広告KPIに与える影響を切り分けるため、実験的に広告のみを先読みして効果を調査しました。
事例3：Yahoo!ニュース トピックスの詳細ページからYahoo!ニュース記事詳細ページへの広告Prefetchのテスト
事例2でPrerenderをテストしたYahoo!ニュースページに対して広告のみをPrefetchする実装を行いました。また、再検証も兼ねて「事例2：Yahoo!ニュース トピックスの詳細ページからYahoo!ニュース記事詳細ページへのPrerenderと広告Prefetchのテスト」も併せてテストしました。
以下の内容でテストを行いました。なお、テスト1で はページのPrerenderを行わないため、belowADはPrerenderの代わりにすべての通信をPrefetchするようにしています。
| テスト名 | ページ | aboveAD（1） | aboveAD（2） | belowAD |
|---|---|---|---|---|
| テスト1（Prefetchテスト） | 高速化なし | 一部通信Prefetch | 一部通信Prefetch | すべての通信Prefetch |
| テスト2（Prerenderテスト） | Prerender | 一部通信Prefetch | 一部通信Prefetch | Prerender |
結果：aboveAD（2）はPrefetchでもPrerenderと同程度に向上
結果としてはaboveAD（2）について、事例2と同様にCTRが有意に向上し、今回はClickも有意に増加することを観測しました。Clickのリフト値は、テスト1（Prefetchテスト）でもテスト2（Prerenderテスト）でも約1.4％でした。Prefetchテストに関しては、ページのPrerenderを行わないため、以前課題となっていたページ配信側のキャパシティ増加の問題は生じません。
結論
上記のテストを踏まえ、私たちは広告またはページの表示高速化が広告KPIにどのように寄与するのかを以下のように考えました。
広告KPIには絶対速度ではなくページとの相対速度が影響すると考えられる
通常、Yahoo!ニュースでは、ページが読み込まれた後に広告の読み込み処理が行われます。
ユーザーの視点では、ページ遷移の開始から広告を目にするまでの時間はPrerenderのほうが短いものの、テスト結果としては、Clickのリフト値はPrefetchでもPrerenderでも約1.4％でした。ここで、ページが表示されてから広告を目にするまでの時間（ページとの相対速度）で考えると、PrerenderとPrefetchでほぼ差がありません。
そのため、広告KPIには絶対速度ではなくページとの相対速度が影響すると考えています。
表示が遅い広告は高速化によってCTRが向上する可能性がある一方、すでに高速な広告では、さらなる高速化によってCTRが向上しない、あるいは低下する可能性がある
PrerenderやPrefetchのテストで、「aboveAD（2）」で有意にCTRが向上し、Clickが増加することを確認できました。aboveAD（2）は他の広告と比べて表示にもともと時間がかかる広告です。また、もともと遅くない「aboveAD（1）」や「belowAD」に関しては有意な向上は見られず、「belowAD」に関しては有意差はないものの、CTRが低 下する傾向が見られました。
補足：Yahoo!メールでの広告表示速度テスト
事前レンダリングや先読みの話とは少しずれますが、参考事例として、Yahoo!メールで実験的に行われた一部広告の表示速度テストを紹介します。そのテストでは、広告の表示が遅くなると、CTRが有意に向上することがわかりました。一方で、インプレッションは低下し、Clickや売上には有意差が出ませんでした。
これらの結果から、広告に限らず、ユーザーに訴求したいページ内コンポーネントについても、単純に速くすれば、もしくは遅くすればよいのではなく、クリックにつながりやすいスイートスポットのような表示タイミングがあるのではないかと考えています。
ただし、Yahoo!メールでの広告表示速度テストのとおり、インプレッションが低下すると、CTRは上昇してもClickが増加するとは限りません。以下のグラフの平坦な領域では、表示が遅れた場合のCTRの上昇がインプレッションの減少と相殺され、Clickはほとんど変わりません。一方、aboveAD（2）のように表示が遅い領域にある広告は、高速化することでClick自体が増加しました。
おわりに
今回、私たちはページと広告の表示高速化が広告KPIにどう影響するのかをテストし、絶対速度ではなくページとの相対速度が影響すること、広告にはクリックにつながりやすいスイートスポットがあるのではないか、という考えに至りました。Prerenderを導入するとUX (User Experience) 改善に役立つ一方で、サービス設計の段階でインフラコストを抑える仕組みを組み込まない限り、コストがかさみやすいのが実情です。この記事が、表示高速化の参考になれば幸いです。
