></script> ↓ 以下必要に応じて追加されていく

というロード形式がほとんどである。不変なエンドポイントから内部のバージョンファイルをロードすることで、SDK の改修に対してもユーザーは読み込む URL を変更する必要がないため、これは正しい実装であると言える。

しかしながら、SDK の初期化だけで最低+2 回の HTTP リクエストがされることになる。さらにスクリプティングも行われるため、その間のレンダリングはブロックされる。

まず、一番最初の <script> タグを <head> でロードするのはそれだけで悪手であり、 async を付けて遅延ロードすることが推奨される。

最終的には、順序通りに 3 番目のスクリプトまでロードされてようやく広告 SDK の初期化が完了となる。このフローを最適化することで広告を掲出するまでの時間を改善する。

対策

昨今のフロントエンドは「ビルドシステム」を持ち、 rollup や webpack といったものでスクリプトをバンドルして配信するのが今や一般的だろう。そこで、日経電子版ではこれらの追加ロードされる SDK を事前に解決し、バンドルした上で CDN から配信する手法を採用している。

具体的には、1 番目のスクリプトを取得し、追加ロードされる箇所を特定し、そこに書かれている URL をさらに fetch、またそのレスポンスからさらなる追加ロードを検出、fetch…を繰り返し、最後にそれらを結合、minify して CDN から配信する。

これにより SDK 本体は 1 本の HTTP リクエストで完了し、確実に minify され、さらにキャッシュも十分に効く。またビルドハッシュを付与することで、SDK 側に改修があった場合も再ビルドすることで改修後のものを使用できるようにしている。また、配信されるコードは一部 minify するとエラーになるコードがあったため、結合時にパッチを当てて回避するなどの最適化も行っている。これにより SDK の初期化までの実行コストは O(N)から O(1)に改善し、実測値で初期化まで 100ms 程改善、スクリプトのバンドルサイズも 30%程度改善した。

スクリプティングと同期的メインスレッド至上主義

続いて広告の取得からスクリプティングまでの最適化だが、大抵の広告において、そのコードはメインスレッドを積極的に侵してくる。もちろん広告は「確実に表示される」ことが至上命題であるが、メインスレッドで動作することが前提として書かれたスクリプトがあまりに多く、昨今の高速化を KPI とするサイトとは些か相性が悪いのが現状である。実際に遭遇した実装として代表的なものを下記に挙げる：

document.write() で同期的に <script> タグを書き出す
Viewable 判定の為にリフローを起こし得るプロパティに頻繁にアクセスする
内部で setInterval() を実行し、タイマーがメインスレッドに常駐する
動画広告など、大量の追加ライブラリの読み込みを強制する

これらは IE6 といったレガシーブラウザの時代から広告表示をさせるべく受け継がれてきた実装が原因だろう。動画広告に至っては video.js などの重いスクリプトに依存しており、導入側の負担は増えるばかりである。日経電子版では First View に必要の無いコンテンツは遅延ロードする仕組みだが、上記のような同期的なロジックと非常に相性が悪い。

さらに、常に DOM アクセスを要求するためクライアントサイドのどこかで処理する必要があり、Worker やサーバーサイドで前処理を行うことも難しい。

対策

DOM があり、かつ別スレッドで動作可能という条件であれば、iframe での別スレッド化が思いつく。そこで SDK から広告データ取得と解析までを別の iframe 内で実行する案について検討した。

SDK とサードパーティスクリプトの読み込み

メインスレッドで遅延ロード vs iframe 内でのロードのベンチマークを取った結果、若干の揺れはあったものの iframe 内でロードを行う方が Start Render Time,及び Visually Complete Time の改善が見られ、サブスレッドで初期化するほうが効率が良いという結果が得られた。