「プレジデント・オンライン」トップページの表示速度ボトルネック研究

プレジデント・オンラインは、ビジネス誌「プレジデント」を発行するプレジデント社が運営する総合情報メディアです。経済・経営・働き方・ライフスタイルに関する記事を日々配信しており、国内有数のビジネス系ニュースサイトとして多数の読者を抱えています。本記事では、モバイル環境におけるトップページの表示速度に関するボトルネック研究の観測結果を記録します。

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

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

観測時点の 総合スコア は56、LCP（Largest Contentful Paint = 主要コンテンツが表示されるまでの時間）は15.9秒という数値が記録されました。一方で CLS（Cumulative Layout Shift = レイアウトのずれ）は0.000、TBT（Total Blocking Time = メインスレッドのブロック時間）は0msであり、レイアウトの安定性とメインスレッドの応答性については観測時点から良好な状態にあります。ボトルネックは主にネットワーク読み込み系（LCP / FCP / SI）に集中しているという構造が観測されました。

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

観測時点と解消シミュレーション後のページ読み込みを動画で比較できます。左が観測時点、右が解消シミュレーション後です。

※ このサイトでは画像の遅延読み込み制御の挙動により、動画による読み込みプロセスの再現がうまく表現できませんでした。実際の読み込み時間の変化は、前後のLighthouseスコアを参照してください。

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

詳細レポート

本研究ではまず、サードパーティータグ（広告・アクセス解析・トラッキングなど外部サービスのスクリプト）を除去したシミュレーションを行い、タグ全体が表示速度に与える最大改善ポテンシャルを観測します。同時に、以降のサイト本体のボトルネック観察におけるノイズ除去も兼ねています。なお、サイト運営上必要なタグも含まれるため、すべてを完全に除去することは現実的ではありません。

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

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

プレジデント・オンラインで確認されたサードパーティータグは 54種 に及び、観測時点では369リソース・合計10.79MBが読み込まれていました。これらを3つのグループに分けて段階的に除去した結果が以下の通りです。

3フェーズすべてを適用した結果、総合スコア は56から99へと+43ポイントの変化が観測され、LCP は15.9秒から1.8秒へと約14秒の短縮、リソース数は369から153へと216削減されました。サードパーティータグ全体の影響量として、これは極めて大きい数値です。

視覚的には、本サイトの広告枠はサーバーサイドで制御されているため、タグを除去しても見た目にはほぼ影響がないという結果が得られています（差分 0.11% 以下）。サードパーティータグがページスピードに与える影響の大きさを数値として記録に値するデータです。

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

サードパーティータグの影響を切り分けた上で、サイト本来の実装に起因するボトルネックを順次解消しながら観測を進めます。本研究では全11件の解消シミュレーションを実施しました。その中から、特に影響が大きかった3つのボトルネックを紹介します。

1. Google Fontsによる外部ドメインフォント読み込み — LCPが63.8%変化 ​

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

観察された状況 ​

サイトでは Google Fonts から欧文セリフ体フォント Libre Baskerville を読み込んでおり、fonts.googleapis.com からの CSS 定義ファイルと fonts.gstatic.com からの woff2 フォントファイルの2ドメインへのリクエストが発生していました。フォント自体は非同期読み込み（media="print" onload="this.media='all'"）に設定されていましたが、外部ドメインへの DNS ルックアップと TLS ハンドシェイクが2つ分発生していたという状況が観測されました。

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

Google Fonts 関連のタグ（preconnect / preload / stylesheet）をHTMLから削除し、CSS の font-family 指定をシステムフォント（OSに標準搭載された Georgia / Times New Roman）にフォールバックしました。

<!-- 削除 -->
<link rel="preconnect" href="//fonts.googleapis.com" crossorigin>
<link rel="preconnect" href="//fonts.gstatic.com" crossorigin>
<link rel="preload" as="style" href="https://fonts.googleapis.com/css2?family=Libre+Baskerville&display=swap">
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Libre+Baskerville&display=swap"
  media="print" onload="this.media='all'">

/* 変更前 */
font-family: Libre Baskerville, sans-serif;

/* 変更後 */
font-family: Georgia, "Times New Roman", serif;

シミュレーション結果 ​

Google Fonts 関連の2ドメインへのリクエストが完全に消えることで、LCP が0.9秒、FCP が1.0秒変化するという観測結果が得られました。本サイトのフォントは欧文セリフ体（約20KB）であり、日本語Webフォントと比べればデータ量自体は小さい規模です。それでも外部ドメインへの接続確立（DNS + TLS）が発生するだけで FCP に1秒近い影響が現れることが、この数値から読み取れます。

2. パブリックCDNリソースの外部ドメイン配信 — LCPが24.5%変化 ​

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

観察された状況 ​

ページでは jQuery / pwacompat / lazysizes という3つの汎用ライブラリが、それぞれ異なる外部 CDN（code.jquery.com / cdn.jsdelivr.net / cdnjs.cloudflare.com）から配信されていました。各ドメインごとに個別の DNS ルックアップと TLS ハンドシェイクが発生しており、これらはいずれもレンダリングに関わるスクリプトであるため、取得タイミングの遅延がページ表示速度に直接影響していたという状況が観測されました。

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

3つのライブラリをダウンロードして president.jp 自身の配信経路下に配置し、HTMLの <script> タグの src 属性を同一ドメインのパスに書き換えました。

<!-- 変更前 -->
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>

<!-- 変更後 -->
<script src="/cdn/code.jquery.com/jquery-3.7.1.min.js"></script>

対象となったリソースと元のドメインは以下の通りです。

シミュレーション結果 ​

外部 CDN へのアクセスが同一ドメイン配信に切り替わったことで LCP が0.4秒変化し、総合スコア が100に到達するという観測結果が得られました。パブリック CDN は「多数のサイトに共有されているため既にキャッシュされている可能性が高い」という想定で用いられてきた経緯がありますが、近年はブラウザのキャッシュ分離により外部 CDN のキャッシュ共有効果は失われています。その結果、外部ドメインへの接続確立コストのみが残る構造となっていることが、この数値から読み取れます。

3. 画像の未WebP化 — 画像総サイズが38.7%変化 ​

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

観察された状況 ​

ページで読み込まれる画像のうち、JPEG 形式6件と PNG 形式3件の計9枚がレガシーなフォーマットのまま配信されていました。これらの画像の総転送サイズは3.53MBであり、ネットワーク帯域の一定割合を占めていたという状況が観測されました。

LCP 画像自体は既に WebP で配信されていたものの、他の画像がネットワーク帯域を奪う形となっており、間接的に LCP 画像の取得タイミングにも影響していることが観察されました。

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

対象9画像を cwebp コマンドで WebP 形式に変換しました。

# JPEGをWebPに変換（品質80）
cwebp -q 80 input.jpg -o output.webp

# PNGをWebPに変換（ロスレス）
cwebp -lossless input.png -o output.webp

シミュレーション結果 ​

画像総サイズが38.7%変化し、ネットワーク帯域の圧迫が軽減されたことで、LCP 画像自体のフォーマットは変わらないにもかかわらず LCP が0.2秒変化するという観測結果が得られました。同一ページ内の画像同士が帯域を奪い合う構造が存在していたことが、この数値から立証されます。

まとめ ​

プレジデント・オンライン（president.jp）トップページの表示速度ボトルネックの実例研究では、観測時点の 総合スコア 56から解消シミュレーション後の100へ、LCP では15.9秒から0.4秒へという大きな変化が記録されました。

変化量の内訳としては、サードパーティータグ54種の除去による影響（総合スコア +43）が最も支配的であり、続いてサイト固有の実装では Google Fonts・パブリック CDN の外部配信・画像の未 WebP 化という3つのボトルネックが観測されました。特筆すべきは、CLS や TBT は観測時点から既に良好であり、ボトルネックがほぼ全面的にネットワーク読み込み系に集中していたという構造です。

本研究の目的はボトルネックの存在とその影響量を数値として可視化することにあり、観測された数値はサイトに実際どのような改変を行うべきかを示すものではありません。研究結果として残すデータが、Web表示速度におけるボトルネックの性質の理解の一助となれば幸いです。