「ねとらぼ」トップページの表示速度ボトルネック研究

ITmediaが運営するネットニュースサイトで、エンタメ・トレンド・生活情報など幅広いジャンルの話題を取り上げています。Astroフレームワークによる軽量なフロントエンド構成が特徴ですが、大量のサードパーティータグが表示速度にどのような影響を与えているかを観察するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が78から100へと22ポイント変化するシミュレーション結果が得られました。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が5.8秒から1.6秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が1.8秒から0.1秒へと大きな変化が観測されています。一方、TBT（Total Blocking Time）と CLS（Cumulative Layout Shift）は観測時点で既に良好な値であり、変化は見られませんでした。

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

本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。

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

詳細レポート

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

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

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

観測時点では、60以上のドメインから166件のサードパーティーリソース（2.92MB） が読み込まれていました。

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

GTM経由で読み込まれているタグ ​

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

サードパーティータグを全て除去した状態では、総合スコア は78から100へ、LCP は5.8秒から1.6秒へ、FCP は1.8秒から0.1秒へと変化する結果が得られました。特に注目すべきは、サイト自体の TBT は観測時点で既に0msであり、メインスレッドのブロッキングはすべてサードパーティータグに起因していたという点です。これはあくまで上限値ですが、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

サードパーティータグの影響を排除したうえで、サイト固有のボトルネックを観察しました。全10件のボトルネック仮説を検証し、その中から特に注目すべき3件を紹介します。

なお、サードパーティータグ除去後のサイト自体は非常に効率的な構成でした。Astroフレームワークによる軽量なHTML/JS構成により、総合スコア は既に100を達成しており、サイト固有のボトルネックによる指標変化は限定的でした。

ボトルネック: 未圧縮テキストリソース ​

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

観察された状況 ​

AstroフレームワークのJavaScriptファイル4件（jsx-runtime.chL-vPbI.js、index.BfF3ghPG.js、use-window-event.D5xCONbn.js、sw.js）が GZIP 圧縮されていない状態で配信されていました。HTMLやCSSは既に圧縮済みでしたが、これらのJSファイルは圧縮設定の対象から漏れていたと考えられます。

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

4件のJSファイルに GZIP 圧縮を適用し、転送サイズを削減した状態でシミュレーションを実施しました。

シミュレーション結果 ​

指標の変化幅は計測誤差の範囲でしたが、これはFCPクリティカルパス上のリソース（HTML・CSS）が既に圧縮済みだったためです。GZIP 圧縮はWebサーバーの設定だけで適用できるため、サイトの見た目や機能に影響を与えることなく、リソース配信の効率化に寄与する要素です。

ボトルネック: PC専用画像がモバイルでもダウンロードされる ​

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

観察された状況 ​

CSSの hidden md:block（モバイルでは非表示）が設定されたPC専用コンテナ内に4件の画像が含まれていました。CSSで非表示にしているだけのため、モバイル端末でも画像のダウンロードが発生しており、合計約36KBの帯域がLCP画像のダウンロードと競合していました。

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

PC専用コンテナ内の画像の src 属性を透明GIFのdata URIに置換し、モバイル環境でのダウンロードを防止する変更を加えました。

シミュレーション結果 ​

LCP の変化は35ms（1,627ms→1,592ms）と小さいものでしたが、不要な画像ダウンロードの排除によってLCP画像への帯域配分が改善されたことがこの結果から読み取れます。モバイルユーザーのデータ通信量削減にも寄与する要素です。

ボトルネック: LCP画像に loading="lazy" が設定されている ​

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

観察された状況 ​

LCP 対象のhero画像（puma-1024x768.jpeg）に loading="lazy" が付与されていました。loading="lazy" はビューポート外の画像の読み込みを遅延させるための属性ですが、LCP画像（ビューポート内の最も大きな画像）に適用すると、画像の読み込み開始が遅延してしまいます。

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

hero画像の属性を loading="eager" と fetchpriority="high" に変更し、ブラウザに最優先での読み込みを指示する状態でシミュレーションを実施しました。

シミュレーション結果 ​

シミュレーション環境では LCP の変化は計測誤差の範囲でした。ただし、loading="lazy" がLCP画像に設定されている状態は Lighthouse が明示的に警告するパターンであり、実環境、特にネットワーク帯域が制限されるモバイル環境ではブラウザの優先度スケジューリングが効果的に機能するため、シミュレーション以上の影響が考えられます。

まとめ ​

ねとらぼのトップページにおける表示速度のボトルネックは、その大部分がサードパーティータグに起因していました。60以上のドメインから166件・2.92MBにおよぶサードパーティーリソースが読み込まれており、これらを除去するシミュレーションでは LCP が5.8秒から1.6秒へ、FCP が1.8秒から0.1秒へと変化する結果が得られました。

特に、html-load.com や Cxense のような同期読み込みのスクリプトが FCP と LCP に大きな影響を与えていたことが、段階的な除去シミュレーションから読み取れます。

一方、サードパーティータグを除いたサイト自体の構成は非常に効率的でした。Astroフレームワークによる軽量なフロントエンド構成により、サイト固有のボトルネックによる指標変化は限定的であり、TBT は観測時点で0ms、CLS も0.000という結果が示すとおり、フロントエンドの基盤品質は高い水準にあります。