「毎日新聞」トップページの表示速度ボトルネック研究
CSSが別ドメインから配信されている、JPEG/PNG画像がWebP未変換、Google Fontsがレンダリングをブロックしているなどのボトルネックが観測され、これらを解消するシミュレーションではLighthouseスコアが65から最大100まで変化する結果が得られました。Core Web Vitalsの大幅な改善が期待できます。
毎日新聞デジタルは、毎日新聞社が運営するニュースサイトです。政治、経済、国際、事件、話題、スポーツなど幅広い分野の速報や解説記事を配信しており、日本を代表するメディアサイトのひとつです。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 解消シミュレーション後 |
|---|---|
![]() | ![]() |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 65 | 100 | +35 |
LCP | 13.6秒 | 0.9秒 | -12.7秒 |
FCP | 3.1秒 | 0.8秒 | -2.3秒 |
SI | 5.7秒 | 1.3秒 | -4.4秒 |
TBT | 32ms | 0ms | -32ms |
CLS | 0.000 | 0.000 | 変化なし |
総合スコア が65から100へと35ポイント変化するというシミュレーション結果が得られました。特に LCP(Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間)が13.6秒から0.9秒へと大きく変化しており、複数のボトルネックが重なって表示速度に影響を与えていたことが読み取れます。
読み込みプロセスの変化を動画で体験
本サイトでは、観測時点では全体像が表示されるまでにかなりのタイムラグが見られますが、解消シミュレーション後はかなり早いタイミングで全体像まで一気に表示される様子が見て取れます。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全320リソースのうち、サイト固有のリソースは120件(約4割)、サードパーティタグ由来のリソースは200件(約6割)を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの6割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。
mainichi.jpではHTMLから直接読み込まれるサードパーティースクリプトが10種類確認され、さらに広告関連の子リソースが約40種類以上存在していました。総リソース数320のうち、約200件がサードパーティー関連です。
HTMLから直接読み込まれるタグ
| タグ名 | 種別 |
|---|---|
Google Tag Manager | タグマネージャー |
Google Publisher Tag | 広告 |
Google FundingChoices | 同意管理 |
Cxense | アクセス解析/DMP |
AnyMind360/FourM | 広告 |
LiveRamp ATS Wrapper | ID管理 |
1plusX/opecloud | DMP |
Firework | 動画ウィジェット |
SiGNITY Push通知 | プッシュ通知 |
dataLayer | アクセス解析補助 |
広告関連の子リソース(主なドメイン)
| ドメイン | 件数 | 種別 |
|---|---|---|
y.one.impact-ad.jp | 21 | 広告SSP |
d.socdm.com | 12 | 広告SSP |
hb.adingo.jp | 12 | 広告SSP |
gum.criteo.com 他 | 14 | 広告DSP |
presage.io | 8 | 広告SSP |
openx.net | 5 | 広告SSP |
smartadserver.com | 4 | 広告SSP |
除去シミュレーション結果
| 段階 | 除去内容 | 総合スコア | LCP | FCP |
|---|---|---|---|---|
| 観測時点 | - | 65 | 13.6秒 | 3.1秒 |
| 第1段階 | 広告関連タグ一括除去 | 83 | 3.9秒 | 2.3秒 |
| 第2段階 | GTM・DMP・動画ウィジェット等の残りすべて除去 | 98 | 2.0秒 | 1.8秒 |
サードパーティータグを全て除去した状態では、総合スコア は65から98へ変化し、LCP は13.6秒から2.0秒へ、SI は5.7秒から1.9秒へと短縮される結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。
サイト固有のボトルネック
サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全12件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
ボトルネック1: CSSが別ドメインから配信されている
観察された状況
4つの CSS ファイル(common_sp.min.css、module_top_sp.min.css、index_sp.min.css、swiper.min.css)がHTMLとは別のドメイン cdn.mainichi.jp から配信されていました。CSS はレンダリングブロックリソースであり、読み込みが完了するまでページの描画が停止します。HTMLのドメイン mainichi.jp とは別のドメインから取得するため、DNS解決と TLS ハンドシェイクの追加遅延が発生しており、FCP(First Contentful Paint = 最初のコンテンツが表示されるまでの時間)に直接影響していました。
解消シミュレーションの方法
CSS ファイルの配信元を cdn.mainichi.jp から mainichi.jp(HTMLと同一ドメイン)に変更し、HTML取得時に確立済みのHTTP/2接続をそのまま再利用できるようにしました。
<!-- 変更前 -->
<link rel="stylesheet" href="https://cdn.mainichi.jp/css/common_sp.min.css">
<!-- 変更後 -->
<link rel="stylesheet" href="https://mainichi.jp/css/common_sp.min.css">シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
FCP | 1.9秒 | 0.8秒 | -1.1秒(55%短縮) |
LCP | 2.0秒 | 1.0秒 | -1.0秒 |
SI | 1.9秒 | 1.4秒 | -0.5秒 |
CSS の配信ドメインを変更するだけで FCP が1.1秒短縮されるという結果が得られました。レンダリングブロックリソースである CSS が別ドメインから配信されていたことが、描画開始の遅れに対して大きな影響を与えていたことが読み取れます。
ボトルネック2: JPEG/PNG画像がWebP未変換
観察された状況
ページ内の26個の画像が JPEG/PNG 形式のまま配信されていました。元サイズ合計259.4KBに対し、より効率的な WebP 形式に変換すると145.7KB(43.8%削減)まで圧縮可能であることが確認されました。
解消シミュレーションの方法
26個の JPEG/PNG 画像を WebP 形式に変換し、画質を維持したままファイルサイズを削減した状態で計測を行いました。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
LCP | 1.5秒 | 1.4秒 | -0.1秒 |
個々の画像サイズが元々比較的小さいため、LCP への影響は0.1秒にとどまりました。ただし、画像総量としては113.7KBの転送量削減が得られており、ネットワーク帯域が限られるモバイル環境では体感的な差が生じ得る規模です。
ボトルネック3: Google Fontsがレンダリングをブロックしている
観察された状況
Google Fonts(Roboto wght@400;700)の CSS が fonts.googleapis.com から読み込まれ、続いてフォントファイルが fonts.gstatic.com から取得されるという2段階の連鎖が発生していました。この間、レンダリングがブロックされ続けます。Lighthouse は345msの節約可能と報告していました。
このシミュレーションは、使用フォントがシステムフォントに切り替わることを前提として行いました。Robotoは欧文フォントであり、日本語テキストが主体のmainichi.jpではフォントの見た目への影響は限定的です。
解消シミュレーションの方法
Google Fonts の CSS 読み込みと preconnect を削除し、フォントをシステムフォントにフォールバックさせた状態で計測を行いました。
<!-- 削除した行 -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap"
rel="stylesheet">シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
FCP | 1.2秒 | 0.8秒 | -0.4秒 |
LCP | 1.4秒 | 0.9秒 | -0.6秒 |
SI | 1.6秒 | 1.3秒 | -0.3秒 |
Google Fonts の読み込みを取り除くと、LCP が0.6秒、FCP が0.4秒変化するという結果が得られました。外部ドメインへの接続とフォントファイルの取得が2段階のチェーンを形成し、その間レンダリングがブロックされていたことが、この数値に表れています。
まとめ
毎日新聞(mainichi.jp)のトップページを観測したところ、総合スコア 65、LCP 13.6秒、FCP 3.1秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。
観測されたボトルネックとその影響は次のように整理できます。
- サードパーティータグ(約200件): 除去シミュレーションにより
総合スコアが +33、LCPが 11.6秒短縮。総リソース数320のうち約200件がサードパーティー関連であり、表示速度への影響が極めて大きいことが観測されました。 - CSSの別ドメイン配信: 同一ドメインへの移管シミュレーションで
FCPが55%短縮、LCPが1.0秒短縮。レンダリングブロックリソースの配信元が表示速度に与える影響の大きさが確認されました。 - JPEG/PNG画像の未変換:
WebP変換により画像総量が43.8%削減。LCPへの直接的な影響は限定的でしたが、転送量の面では無視できない規模でした。 - Google Fontsのレンダリングブロック: 除去シミュレーションで
FCPが0.4秒、LCPが0.6秒短縮。外部ドメインへの2段階チェーンがレンダリングを遅延させていたことが読み取れます。
全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は65から100へ、LCP は13.6秒から0.9秒へと変化しました。観測された各要素がそれぞれ独立して指標に与えていた影響の大きさが、この一連のシミュレーションによって確認できた形です。

