「ニューズウィーク日本版」トップページの表示速度ボトルネック研究
head内の同期スクリプト、LCP画像の遅延読み込み設定、複数CSSファイルの分散などのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが62から最大100まで変化する結果が得られました。Core Web Vitalsの大幅な改善が期待できます。
ニューズウィーク日本版
詳細レポート 
ボトルネック一覧 
差分リポジトリ この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
ニューズウィーク日本版は、米国Newsweekの日本語版として国際ニュースや政治・ビジネス・テクノロジーなど幅広いトピックを扱うニュースメディアサイトです。モバイル環境でのトップページ表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 全ボトルネック解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 62 | 100 | +38 |
LCP | 14.1秒 | 0.1秒 | -14.0秒 |
FCP | 3.8秒 | 0.1秒 | -3.7秒 |
SI | 5.8秒 | 0.5秒 | -5.3秒 |
TBT | 33ms | 0ms | -33ms |
CLS | 0.069 | 0.000 | -0.069 |
総合スコア が62から100へと38ポイント変化するというシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が14.1秒から0.1秒へと約14秒の短縮が観測されており、表示速度に大きく影響するボトルネックが存在していたことが読み取れます。
読み込みプロセスの変化を動画で体験
観測時点とボトルネック解消シミュレーション後のページ読み込みを比較すると、ワンテンポ早く全体像が見えていることが確認されました。
なお、この動画は少し上下にずれています。これは動画撮影のアルゴリズムの都合で上下方向にずれてレンダリングされているもので、実際のページ表示とは異なります。ご了承ください。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルページの全373リソースのうち、サイト固有のリソースは85件（約2割）、サードパーティタグ由来のリソースは288件（約8割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの8割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。
newsweekjapan.jpのHTMLから直接読み込まれていたサードパーティータグは以下の13件です。
| タグ名 | 種別 |
|---|---|
AnyManager Recover | アドブロック検知・リカバリ |
AnyMind ATS | Header Bidding |
Google Publisher Tag (GPT/DFP) | 広告配信 |
Taboola | レコメンドウィジェット |
PrimeAd | 広告 |
Datasign CMP (webtru) | 同意管理 |
Cxense (Piano) | DMP/パーソナライズ |
Impact-ad (Unitag) | トラッキング |
CCC Media House ID | 会員認証 |
Google CSE brand | 検索ウィジェット |
Chartbeat | アクセス解析 |
Google Tag Manager | タグマネージャ |
Google Analytics (レガシー ga.js) | アクセス解析 |
これらのタグがエントリポイントとなり、Criteo、Amazon Ads、AppNexus、Index Exchange、OpenX、PubMatic、Rubicon、Yahoo広告など数十ドメインのリソースが連鎖的に読み込まれていました。観測時点のリソース数は373件、総転送サイズは7.48MBにのぼります。
段階的除去シミュレーションの結果
| 段階 | 除去対象 | 総合スコア | LCP | FCP | SI |
|---|---|---|---|---|---|
| 観測時点 | - | 62 | 14.1秒 | 3.8秒 | 5.8秒 |
| 第1段階 | 広告関連5件（GPT、Taboola、AnyMind ATS、AnyManager、PrimeAd） | 79 | 4.2秒 | 3.4秒 | 3.5秒 |
| 第2段階 | トラッキング・解析6件（Datasign CMP、Cxense、Impact-ad、CCC、Google CSE、Chartbeat） | 100 | 0.2秒 | 0.1秒 | 0.7秒 |
| 第3段階 | GTM + GA（レガシー） | 100 | 0.3秒 | 0.2秒 | 0.6秒 |
サードパーティータグを全て除去した状態では、総合スコア は62から100へ変化し、LCP は14.1秒から0.3秒、FCP は3.8秒から0.2秒まで短縮される結果が得られました。特に広告関連タグの除去だけで LCP が約10秒短縮されており、広告配信処理の影響の大きさが際立っています。また、広告タグの動的挿入によって生じていた CLS も0.069から0.000に解消されました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を除去した状態で、全8件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
ボトルネック: head内の同期スクリプト
観察された状況
<head> 内に7つの外部スクリプトが async / defer 属性なしで配置されていました。jQuery、Slick、Swiperなどのライブラリが同期的に読み込まれており、これらのスクリプトのダウンロードと実行が完了するまでHTMLパーサーが停止し、最初の描画が遅延する状態にありました。
解消シミュレーションの方法
7つの同期スクリプトを <head> から <body> 末尾に移動し、HTMLパースとCSS適用がスクリプトの読み込みを待たずに先行できるようにしました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 0.2秒 | 0.2秒 | -0.1秒 |
FCP | 0.1秒 | 0.1秒 | -0.04秒 |
SI | 0.5秒 | 0.5秒 | -0.03秒 |
このシミュレーション結果から、同期スクリプトによるレンダリングブロックが FCP と LCP の両方に影響を与えていたことが読み取れます。サードパーティータグ除去後の時点ですでにスコアは100に達していたため数値の変化幅は小さく見えますが、ミリ秒単位での短縮（FCP -37ms、LCP -52ms）が観測されました。
ボトルネック: LCP画像の遅延読み込み設定
観察された状況
トップページのヒーロー画像（#pickUpImg 内の <img> 要素）がLCP要素として特定されましたが、この画像に loading="lazy" が設定されていました。loading="lazy" はビューポート外の画像に対する遅延読み込みを意図した属性ですが、LCP対象のファーストビュー画像に設定されていると、IntersectionObserverによる判定を経てからリクエストが発行されるため、読み込み開始が遅れます。
解消シミュレーションの方法
LCP画像の loading="lazy" を loading="eager" に変更し、あわせて fetchpriority="high" を追加することで、ブラウザが即座に最優先でこの画像を取得するようにしました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 0.2秒 | 0.1秒 | -0.1秒 |
FCP | 0.1秒 | 0.1秒 | -0.04秒 |
SI | 0.5秒 | 0.5秒 | -0.02秒 |
LCP が179msから117msへ62ms短縮される結果が得られました。LCP画像自体はFastly Image Optimizerによって既にAVIF形式（10,728 bytes）に最適化されていたため、画像サイズの問題ではなく、読み込み優先度の設定がボトルネックとなっていたことが分かります。
ボトルネック: 複数CSSファイルの分散
観察された状況
<head> 内に10個のCSSファイルが個別の <link> 要素として配置されていました。CSSはレンダリングブロックリソースであり、全てのCSSファイルの読み込みが完了するまで最初の描画が発生しません。10個の個別リクエストはHTTP/2で並列化されますが、リクエストごとのオーバーヘッドが積み重なっていました。
解消シミュレーションの方法
10個のCSSファイルを1つのファイルに結合し、CSSリクエスト数を削減しました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 0.3秒 | 0.2秒 | -0.03秒 |
FCP | 0.2秒 | 0.1秒 | -0.02秒 |
SI | 0.6秒 | 0.5秒 | -0.02秒 |
FCP が159msから144msへ15ms短縮される結果が得られました。個々の変化量は小さいものの、CSSファイルの分散がレンダリング開始を遅らせる要因の一つであったことが確認されました。
なお、CSSの統合・1ファイル化は、現在では HTTP/2 の普及などにより必ずしも有効なプラクティスとは限りません。今回のシミュレーションのように良好な結果が観測されることもありますが、参考程度にとどめてください。
まとめ
ニューズウィーク日本版のトップページでは、13件のサードパーティータグ（広告・トラッキング・解析）がページスピードに与える影響が極めて大きく、これらの除去シミュレーションだけで 総合スコア が62から100に、LCP が14.1秒から0.3秒にまで変化する結果が得られました。リソース数373件・総転送サイズ7.48MBという観測値は、広告配信に伴う連鎖的なリソース読み込みの規模を物語っています。
サイト固有のボトルネックとしては、<head> 内の同期スクリプト7件によるレンダリングブロック、LCP画像への loading="lazy" 設定、10個のCSSファイルの分散が観測されました。これらはいずれもサイトの機能や見た目に影響を与えずに解消できる技術的な要因であり、シミュレーションではそれぞれミリ秒単位での短縮が確認されました。
本サイトの特徴として、ファーストパーティのJavaScriptは非常に軽量で TBT は観測時点でも33msと良好でした。また、LCP画像はFastly Image Optimizerにより自動的にAVIF形式に変換・配信されており、画像サイズの面では十分に最適化されていました。表示速度のボトルネックは主にサードパーティータグの量と、HTMLの構成面（スクリプト配置・CSS分散・画像属性）に集中していたことが、今回の研究を通じて明らかになりました。
ニューズウィーク日本版
この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
