「週刊文春 電子版」トップページの表示速度ボトルネック研究

「週刊文春」の最新スクープが雑誌発売前に読めるサブスクリプション型のニュースメディアです。電子版オリジナル記事や解説番組など、「週刊文春電子版」限定のコンテンツも配信されています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

観測時点	全ボトルネック解消シミュレーション後

総合スコア が71から100へと29ポイント変化するシミュレーション結果を得ました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が13.8秒から0.2秒へと大幅に変化しており、表示速度に強く影響するボトルネックが複数存在していたことが読み取れます。なお TBT（Total Blocking Time）は観測時点で既に0msであり、サイト自体のJavaScriptは軽量であることが確認されました。

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

本サイトでは、総合スコア や各指標には大きな変化が観測されましたが、読み込みプロセス動画上では観測時点と解消シミュレーション後で大きな違いを確認することはできませんでした。

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

詳細レポート

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

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

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

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

Google Tag Manager経由で読み込まれているタグ ​

Google Tag Manager 経由だけで93リソースが読み込まれており、Cookie Syncだけで20以上のドメインとの通信が発生していました。

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

サードパーティータグを全て除去した状態では、総合スコア は71から99へ、LCP は13.8秒から2.1秒へ変化する結果が得られました。特に Google Tag Manager 経由の93リソースの影響が顕著で、その除去だけで LCP が5.8秒から0.9秒へ、総合スコア が78から100へと大きく変化しています。実際にはこの全てを除去するのが現実的でないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルの存在が読み取れます。

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

サードパーティータグの影響を排除した上で、サイト固有のボトルネックを観察しました。全12件のボトルネック仮説を検証し、その中から特に影響の大きかった2件を紹介します。

ボトルネック: 画像フォーマット（JPEG/PNG） ​

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

観察された状況 ​

ページ内の176枚の画像がJPEGまたはPNG形式で配信されており、画像トラフィックの合計は12.01MBに達していました。WebPなどの次世代フォーマットは使用されていませんでした。

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

176枚の画像をWebP形式（品質パラメータ80）に変換し、ファイルサイズが小さくなったもののみを採用しました。

シミュレーション結果 ​

このシミュレーション時点ではサードパーティータグ除去後のスコアが既に100であったため、Lighthouse のスコア上の変化は観測されませんでした。しかし画像トラフィックが12.01MBから5.96MBへと半減しており、特にモバイル環境や低速ネットワークにおいて表示速度への影響が大きくなるボトルネックです。画像フォーマットの選択が転送量に与えるインパクトの大きさが読み取れます。

ボトルネック: Google Fonts（Roboto）のレンダーブロック ​

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

観察された状況 ​

HTMLの <head> 内で Google Fonts（Roboto）の外部CSSが読み込まれており、Lighthouse では472msの wasted time がレンダーブロッキングリソースとして報告されていました。fonts.googleapis.com への接続とCSSの取得が、ページの初期描画を遅延させている構造が観察されました。

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

Google Fonts（Roboto）の preconnect と外部CSSリンクをHTMLから除去しました。このシミュレーションは、フォントの見た目が変わることを前提として行いました。ただし、日本語サイトにおけるRobotoの使用範囲は英数字部分に限られることが多く、視覚的な変化は限定的です。

シミュレーション結果 ​

Google Fonts の外部CSSというたった1つのリソースの除去で、LCP が0.7秒から0.2秒へ、FCP が0.7秒から0.2秒へと、いずれも約0.5秒短縮される結果が得られました。総合スコア は変わらず100でしたが、LCP と FCP の絶対値が大きく変化しており、外部フォントCSSのレンダーブロックが初期描画に与えていた影響の大きさが明確に読み取れます。

まとめ ​

「週刊文春 電子版」トップページでは、LCP 13.8秒という観測値の大部分がサードパーティータグに起因していました。Google Tag Manager 経由の93リソースを含む多数のタグが表示速度に強い影響を与えており、タグ除去だけで 総合スコア は71から99へ変化する結果が得られました。

サイト固有のボトルネックとしては、Google Fonts（Roboto）の外部CSSによるレンダーブロックが顕著で、この1つのリソースだけで LCP ・ FCP がそれぞれ約0.5秒遅延していたことがシミュレーションで確認されました。また、176枚の画像がJPEG/PNG形式のまま配信されており、WebP変換によって画像トラフィックを50%削減できることも観察されました。

これらの結果から、サードパーティータグの最適化と、レンダーブロッキングリソースの見直しが、このサイトの表示速度に対して特に大きな影響を持つ要因であったことを確認できます。