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

ダイヤモンド・オンラインは、ダイヤモンド社が運営するビジネスパーソン向け情報メディアです。業界を深掘りした独自特集や、経営・経済・マネー情報、スキルアップ記事を日々発信し、ビジネスリーダーの意思決定を支えています。本記事では、モバイル環境におけるトップページの表示速度ボトルネックの実例研究の観測結果を記録します。

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

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

本サイトは観測時点で 総合スコア 93と比較的高い水準にあり、CLS（Cumulative Layout Shift = レイアウトのずれ）は0.000、TBT（Total Blocking Time = メインスレッドのブロック時間）は0msと、インタラクティブ系の指標は既にクリアされていました。一方で LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は3.1秒、FCP（First Contentful Paint = 最初のコンテンツ描画までの時間）は1.8秒という観測値が記録されており、描画系指標にボトルネックが存在していることが読み取れます。解消シミュレーションの結果、LCP が0.1秒、FCP が0.1秒まで変化し、総合スコア も100に到達しました。

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

観測時点と解消シミュレーション後のページ読み込みを動画で比較できます。左が観測時点、右が解消シミュレーション後です。Lighthouseの指標の変化ほど、体感的な速度の変化は見られませんでした。

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

詳細レポート

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

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

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

ダイヤモンド・オンラインで確認されたサードパーティータグは以下の通りです。Google Tag Manager 経由で GA4、Facebook Pixel、Bing UET、Google Ads Conversion、Google reCAPTCHA などが読み込まれていました。

すべてのサードパーティータグを除去した場合の変化は以下の通りです。リソース数は199から95へと約半減しました。

特に GPT広告 関連の9ドメイン51リソースが影響量の大半を占めており、連鎖的なサブリソース読み込みが LCP を押し上げていたことが観測されました。

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

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

1. CSSの別ドメイン配信 — FCPが92%、LCPが94%の変化 ​

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

観察された状況 ​

トップページのレンダリングに必要な swiper-bundle.min.css が、HTMLと異なるドメイン dol.ismcdn.jp（自社CDN）から配信されていました。HTMLは diamond.jp から配信されているため、ブラウザは dol.ismcdn.jp に対して新たにDNS解決・TLSハンドシェイクを行う必要があり、その初回接続だけで939msのTTFB（Time To First Byte）が観測されています。CSS はレンダリングブロックリソース（読み込みが完了するまで描画が開始されないリソース）であるため、この939msがそのまま FCP の遅延として積み上がっていました。

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

swiper-bundle.min.css の配信元を dol.ismcdn.jp から diamond.jp（HTMLと同一ドメイン）に変更しました。HTML側の link タグの href を書き換えるのみの変更です。

<!-- 変更前 -->
<link rel="stylesheet"
  href="https://dol.ismcdn.jp/common/dol/js/lib/swiper-11.1.3/swiper-bundle.min.css">

<!-- 変更後 -->
<link rel="stylesheet"
  href="https://diamond.jp/common/dol/js/lib/swiper-11.1.3/swiper-bundle.min.css">

シミュレーション結果 ​

1つのボトルネックの解消だけで 総合スコア が97から100に到達するという、本研究で最大の影響量が観測されました。別ドメインからの CSS 配信による初回接続オーバーヘッドが、観測時点における FCP・LCP の最大のボトルネックとして機能していたことが、この数値から立証されます。

2. Webフォントの読み込み — 転送サイズ175KBの削減 ​

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

観察された状況 ​

サイトでは欧文Webフォント Oswald-Regular.ttf（87KB）と Roboto-Regular.ttf（168KB）の2種類・3つの @font-face 宣言が dol.ismcdn.jp から読み込まれていました。合計255KB（gzip後約129KB）のフォントファイルがページ描画の前後でネットワーク経由で取得されており、ページ全体の転送サイズを押し上げる要因となっていました。

CSS の font-family 指定には Hiragino Sans、sans-serif などシステムフォントのフォールバックが既に記述されていたため、Webフォントを廃止しても表示崩れが発生しない構造になっていました。

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

3つの @font-face 宣言と対応する woff/ttf ファイル参照を削除しました。font-family 宣言側は既存のフォールバック指定がそのまま適用されるため、変更不要です。

/* 削除 */
@font-face {
  font-family: 'roboto';
  src: url('https://dol.ismcdn.jp/.../Roboto-Regular.ttf') format('truetype');
  font-weight: normal;
}
@font-face {
  font-family: 'oswald';
  src: url('https://dol.ismcdn.jp/.../Oswald-Regular.ttf') format('truetype');
}

シミュレーション結果 ​

視覚回帰テストの Diff Percent は0.2119%と、ほぼ変化なしの水準でした。Lighthouse スコアはCSS同一ドメイン化の時点で既に100に到達していたため数値上の変化は小さいものの、ページ全体の転送サイズが175KB削減されるという観測結果が得られました。日本語サイトにおける欧文Webフォントの使用が、見た目のインパクトと転送サイズのトレードオフの対象となり得ることを示すデータとして記録されます。

3. JPEG/PNG画像のフォーマット — 転送サイズ500KBの削減 ​

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

観察された状況 ​

トップページには記事サムネイルを中心に、合計85枚のJPEG/PNG画像が配置されていました。いずれも WebP（Googleが開発した高圧縮画像フォーマット）への変換が行われておらず、従来フォーマットでの配信となっていました。Lighthouse の監査でも画像最適化の指摘が残っており、ページ全体の転送サイズに対するボトルネックとなっていることが観測されました。

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

トップページで読み込まれている85枚のJPEG/PNG画像をすべて WebP 形式に変換しました。

変換画像数: 85枚
変換前サイズ: 1.22MB
変換後サイズ: 744KB
削減率: 40.2%
削減量: 約500KB

シミュレーション結果 ​

Lighthouse スコアは既に100に達していたため指標上の変化は観測されませんでしたが、画像の転送サイズが500KB削減されるという結果が記録されました。モバイルや帯域の狭いネットワーク環境、あるいは記事ページを連続で閲覧する際のトータルのデータ転送量に対して、確実に影響を与えるスケールの削減量です。観測時点のトップページに積もっていた画像フォーマットのボトルネックの大きさを示すデータとして残します。

まとめ ​

ダイヤモンド・オンライン（diamond.jp）の表示速度ボトルネックの実例研究では、Lighthouse スコアで93から100、LCP で3.1秒から0.1秒という変化が観測されました。

観測時点で 総合スコア 93という比較的良好な状態にあったサイトにおいても、CSS の別ドメイン配信、欧文Webフォントの読み込み、画像フォーマットという3種類のボトルネックが存在していたことが、解消シミュレーションの数値として立証されました。中でも CSS の別ドメイン配信の影響量が突出しており、別ドメインへの初回接続で発生する939msの TTFB が、FCP と LCP の双方を押し上げる支配的要因になっていたことが読み取れます。Webフォントと画像フォーマットについては指標上の変化は限定的だったものの、ページ転送サイズが合計で約675KB削減されるという物理的な観測結果が記録されました。

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