Web(以下、日経電子版)における広告掲示の技術について解説する。駆使して表示に関して適切なチューニングを行っており、日経電子版もほぼ同じ思想の元チューニングを行っているが、一点大きな違いを挙げるとするならば、広告表示の有無が挙げられる。その他にも様々なサイトトラッキングのサードパーティスクリプトを導入しているが、ご存知の通りこれらはメインとして打ち出したいコンテンツとはほぼ関連性はなく、パフォーマンス観点から見れば劣化させる要因でしかない。広告が無ければもっと速く表示できるのに...と思ったことはないだろうか。それは正しい感覚である。サイトを運営し、ビジネスを行っていく上で必要なものであることもまた正しい。「サイトが遅くなるから広告は入れません」という要望は通常通らないだろう。広告は遅いから仕方ない、と諦めないだからと言ってそのまま渡されたタグを設置して広告を表示する、と諦めないでほしい。広告は遅いのか、遅くする原因は何なのか、少しでも速く軽くするためにはどうすればよいかを計測し、検討する価値は十分にある。フロントエンドの高速化の為に行う施策に合わせて広告の表示手法を考える必要が出てくる。本章では実際に日経電子版での広告表示に関して計測したこと、そして検討・実施したことについて解説を行う。スクリプトを許可なく改変することで保証の対象外や著作権の違反になったりするケースもある。提供元と協議の上、問題がないことの許諾を得た上で実行してほしい。完全に隠蔽されてロジックを挟む余地のない手法で提供される広告も残念ながら存在する。経由で広告配信サーバと通信する手法であったため、導入側での対策を講じることが可能であった。広告の掲出に際して、具体的にパフォーマンスを劣化させる原因は何なのだろうか。先に結論を述べると、「広告表示に関わるリクエスト、スクリプティング、レンダリング全て」である。つのフェーズに分けてチューニングを行った。タグの埋め込みと、少しの実装コードで表示されるだろう。内部で追加のリクエストを発行している。指定された埋め込みタグ。以下必要に応じて追加されていくというロード形式がほとんどである。変更する必要がないため、これは正しい実装であると言える。リクエストがされることになる。スクリプティングも行われるため、その間のレンダリングはブロックされる。付けて遅延ロードすることが推奨される。このフローを最適化することで広告を掲出するまでの時間を改善する。いったものでスクリプトをバンドルして配信するのが今や一般的だろう。配信する手法を採用している。され、さらにキャッシュも十分に効く。側に改修があった場合も再ビルドすることで改修後のものを使用できるようにしている。するとエラーになるコードがあったため、結合時にパッチを当てて回避するなどの最適化も行っている。続いて広告の取得からスクリプティングまでの最適化だが、大抵の広告において、そのコードはメインスレッドを積極的に侵してくる。するサイトとは些か相性が悪いのが現状である。いったレガシーブラウザの時代から広告表示をさせるべく受け継がれてきた実装が原因だろう。重いスクリプトに依存しており、導入側の負担は増えるばかりである。必要の無いコンテンツは遅延ロードする仕組みだが、上記のような同期的なロジックと非常に相性が悪い。サーバーサイドで前処理を行うことも難しい。別スレッド化が思いつく。内で実行する案について検討した。改善が見られ、サブスレッドで初期化するほうが効率が良いという結果が得られた。初期化、サードパーティスクリプトの読み込みを行う方針にも適合した。配信することで影響を小さく抑えている。最後にレンダリングの制御について検討した。内で処理すべく前述の同期的な問題も同時に対応した。具体的には下記のような手法で解決している。このメソッドを一時的にオーバーライドすることでメソッドの挙動を上書きすることが可能である。その性質を利用し、擬似的にバッファリングを行う挙動に置き換えて対応した。実行後は元の挙動に戻してやる必要がある。書き出される予定のバッファがが得られるconsole.log(buffer);これにより任意のタイミングで広告表示が行える。差し替えの影響はゼロであった。内に移したことでメインスレッドを汚さなくなり、結果クリーンに保つことができた。アクセスについてもリフローは起きなかった。全ての追加ロードされるスクリプトを精査し、我々では対応できないもののみ仕方なくメインスレッドでの実行を許可することにした。これらの対策を施すことによって、メインスレッドと広告ロジックを分離させることに成功した。サイト上に実装した手法について解説する。表示するメリットは下記のとおりである:メインウインドウと同じレンダリングロジックが使えるスタイル・スクリプトはカプセル化されて外部に影響を与えない特に後者が大きく、コンテンツと広告の分離には適している。あれば広告のサイズによる高さ制御はメインウインドウのレンダリングロジックに従うため、その計算処理も省くことが可能である。リフローは同様に発生するがブラウザに任せるほうが良いだろう。内のカプセル化は不可能であった。表示を強制することで対策した。スタイルのカプセル化手法については後述する。呼ばれる掲出が一般的になりつつある。評価する必要があり、タイマースレッドの常駐はこれをレガシーブラウザで行うための実装だろう。ブラウザから使用できる。あるためにすでに利用できる段階であると言える。実際の導入においては仕様に記載されていない挙動の問題などもあったが、要素検出という点においては利用可能であると判断した。ツリーへの追加は検出できない。併用してこの問題を解決している。モダンなブラウザでは対応済みであるため、古いブラウザ対応がなければ利用可能だろう。true});Responsive広告はデスクトップターゲットとモバイルターゲットで掲出する広告を分ける必要性もある。ドキュメントに対して適切に広告を振り分けるために、ユーザーエージェントの判定はもちろん、レイアウト変更の検出で広告を動的にスイッチする機構も実装している。毎に広告をスイッチする。利用可能になり始めている。これらは組み込みであるため、自前で行うよりもパフォーマンスの向上が期待できるだろう。日経電子版でのアーキテクチャ最後に前述の最適化処理をまとめた日経電子版でのアーキテクチャについて述べる。呼んでいるアーキテクチャで広告の管理と表示を行っている。初期化と広告リクエスト、レイアウト変更の検知、同一広告の排他処理などビュー以外の処理全てを担当する。イベントインターフェースで通信し、必要な情報を受け取る。静的に解析し、コンテンツとスクリプトに分離した上でビューに渡すことで、ビューはコンテンツを先行してレンダリングし、追加で必要なスクリプトは別途遅延ロードさせる。ページ上に同一の広告を表示させないための排他処理も我々で実装し、表示に関する制御を可能な限りこちらでコントロールできるようにしている。よる検知後にインスタンス化され、コントローラへ接続通知をpostMessageで送信する。コントローラはこのメッセージを受信、広告を取得し、レンダリングに必要な情報のみをビューに戻すので、それを元にビューはレンダリングのみを行うだけでよく、メインスレッドでの余分なスクリプティングは最小限に抑えられる。フォールバックする設計のため、どの広告をどのように出すかは考えなくてよい。場合はそれ用に最適化した事前ビルドファイルをロードするのみである。どちらの場合も同じpostMessageのイベントインターフェースを実装しておくことで、コントローラ側での不要な分岐処理をしなくて良いようにしている。ページ上の広告表示フローは下図のようになる:通常通り表示する場合に比べてフローが複雑化しているのは否めないが、それを補う高速化の恩恵を得られ、かつ遅延ロードされる広告要素にも対応できた。レンダリング処理の最小化が概ね良好な結果を得る原因になったと評価している。別スレッド化くらいしか対策が打てないのが悔しい点である。コードがある限り現状は難しい。要素として扱えることが期待される。今回は導入側で出来る限りの最適化を行ったが、これらは広告を配信する側で対応できることがほとんどである。歴史的経緯と安定稼働が重要なのは承知の上ではある。フロントエンド技術はそろそろアップデートする時期に来ているのではないか。これらの対応が難しい現状では、フロントエンドの領域において広告はまだまだ最適化の余地があり、取り組む価値のあるものではないだろうか。本章では「広告の最適化」という、おおよそフロントエンドの技術領域について触れられることがないであろうテーマについて解説した。何か一つでも最適化するヒントになれば幸いである。permission.。