「日経電子版」トップページの表示速度ボトルネック研究

日本経済新聞社が運営する経済・ビジネス総合メディアです。経済、金融、政治から国際情勢まで幅広いニュースを配信しており、国内最大級の経済メディアとして知られています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

Core Web Vitalsにつながる指標の改善ポテンシャル ​

観測されたボトルネックを仮に解消した場合、Lighthouseスコアは以下のような変化を示しました。

観測時点	解消シミュレーション後

総合スコア が77から100へと23ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が6.7秒から1.0秒へと大きな変化が観測されています。一方、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は観測時点で0.2秒と非常に高速であり、TBT（Total Blocking Time = メインスレッドのブロック時間）と CLS（Cumulative Layout Shift = レイアウトシフト量）はともに0で、フロントエンド設計の基盤が極めて優れていることが読み取れます。

読み込みプロセスの変化を動画で体験 ​

本サイトでは、ごく短い時間だけ観測時点のほうが先にレンダリングが進む瞬間が見て取れます。ただし、LCP を含むページ全体のレンダリング完了までで見ると、解消シミュレーション後のほうが早く到達しています。とはいえ、総合スコア の変化量と比べると、読み込みプロセス動画上での見た目の差は非常に小さなものに留まっています。

サードパーティータグの影響 ​

詳細レポート

本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。

本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全193リソースのうち、サイト固有のリソースは162件（約8割）、サードパーティタグ由来のリソースは31件（約2割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの2割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。

nikkei.comで確認されたサードパーティータグは次のとおりです。

HTMLから直接読み込まれているタグ ​

ブラウザ/OS内部通信 ​

合計29リソースが除去対象として確認されました。

除去シミュレーションの結果 ​

サードパーティータグを全て除去した状態では、総合スコア が77から99へ変化し、LCP は6.7秒から2.1秒へと4.6秒短縮される結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。特に LCP への影響が顕著であり、サードパーティータグの大部分が LCP のタイミングに集中して影響を与えていたことが分かります。

なお、除去後の視覚的レグレッションテストではDiff Percent 0.0000%であり、ページの見た目に変化はありませんでした。今回のサイトでは、サードパーティータグがチャットウィジェットや広告枠などのUI要素を直接描画していなかったためです。

以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。

サイト固有のボトルネック ​

サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全4件のボトルネック仮説を検証しました。その中から、特に影響が大きかった2件を紹介します。

なお、nikkei.comのフロントエンド構成は多くの点で優れており、CSS が1ファイル・小サイズ・同一ドメイン配信、JavaScriptが type="module" でレンダリング非ブロック、全リソースがBrotli/gzip圧縮済み、Webフォント不使用、CLS と TBT がともにゼロという状態でした。サイト固有のボトルネックは少なく、残された課題は主にインフラ配置と画像フォーマットに集中していました。

ボトルネック1: 画像CDNのオリジンがシカゴに配置されている ​

詳細レポート 差分コミット

観察された状況 ​

画像CDN（article-image-ix.nikkei.com、imgixで運用）から配信される画像のTTFB（Time To First Byte）が930〜986msと非常に遅い値でした。レスポンスヘッダの分析から、imgixのオリジンサーバーがシカゴ（cache-chi-klot8100179-CHI）に設置されていることが判明しました。日本のユーザーがシカゴのサーバーにアクセスする場合、太平洋横断の往復遅延だけで約200〜300msが必要であり、さらにSSL/TLSハンドシェイクやサーバー処理時間が加わって約930msのTTFBとなっていました。LCP の対象となるメイン画像もこのCDNから配信されているため、画像CDNのTTFBが LCP の主要なボトルネックでした。

解消シミュレーションの方法 ​

article-image-ix.nikkei.com ドメインの全画像（69リソース）のTTFBを930〜986msから30msに短縮するシミュレーションを実施しました。これは、imgixのオリジンサーバーを日本リージョンに配置した場合に相当する変更です。

シミュレーション結果 ​

このシミュレーション結果から、画像CDNの地理的配置が LCP に与えていた影響の大きさが読み取れます。TTFBが約930msということは、画像のダウンロードが始まる前に約1秒のオーバーヘッドが発生しており、その遅延が LCP にほぼそのまま反映されていたことになります。

ボトルネック2: 不要な画像preloadが帯域を圧迫している ​

詳細レポート 差分コミット

観察された状況 ​

HTML head内に19個の <link rel="preload" as="image"> タグが記述されており、CSS の <link rel="stylesheet"> タグより前に配置されていました。preload対象は小さなSVGアイコンやロゴ画像であり、FCP や LCP の時点で必須のコンテンツではありませんでした。HTMLパース開始直後に19個の画像preloadリクエストが発行され、クリティカルリソースとの帯域競合が発生していることが観測されました。

解消シミュレーションの方法 ​

HTML head内の19個の画像preloadタグを削除するシミュレーションを実施しました。

<!-- 削除した19個のpreloadタグ（一部抜粋） -->
<link rel="preload" as="image" href="https://www.nikkei.com/api/svg/v1/k-search.rev-adf84c.svg?fill=%23333">
<link rel="preload" as="image" href="/.resources/k-components/logo/masthead.rev-b8cf30e.png">
<link rel="preload" as="image" href="/.resources/k-components/icon/prime-digital-governance.rev-0b4eacf.svg">
<!-- ... 他16個のSVGアイコン・ロゴ画像 ... -->

シミュレーション結果 ​

FCP への直接的な変化は限定的でしたが（計測の揺らぎ範囲内）、LCP が0.4秒短縮される結果が得られました。不要な画像preloadを削除することで画像CDNからの画像取得と CSS / JavaScriptの読み込みの帯域競合が解消され、LCP 対象画像の表示が早まったものと考えられます。preloadは本来クリティカルリソースの読み込みを前倒しするための仕組みですが、対象が不適切な場合にはむしろ逆効果となることが、このシミュレーション結果から読み取れます。

まとめ ​

日経電子版（nikkei.com）の表示速度を観測したところ、総合スコア 77、LCP 6.7秒という値が計測されました。一方で FCP 0.2秒、TBT 0ms、CLS 0.000という数値から、フロントエンド設計の基盤が非常に優れていることも同時に確認されました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグの集合体: 29リソースの除去によって 総合スコア が+22ポイント、LCP が4.6秒短縮。ボトルネック全体の中で最も大きな影響が観測されました。
• 画像CDNの地理的配置: imgixのオリジンサーバーがシカゴにあることでTTFBが約930msとなっており、日本リージョンへの配置変更シミュレーションで LCP が0.6秒短縮。
• 不要な画像preloadによる帯域圧迫: 19個のアイコン・ロゴ画像のpreload削除で LCP が0.4秒短縮。
• JPEG/PNG画像のWebP未変換: 39枚の画像をWebP変換することで LCP が0.1秒短縮、転送サイズは59.6%削減。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は77から100へ、LCP は6.7秒から1.0秒へと変化しました。このサイトの場合、フロントエンドの設計品質が高いために、ボトルネックはサードパーティータグとインフラ配置という「サイトの外側」に集中していたことが、一連のシミュレーション結果から読み取れます。