「All About」トップページの表示速度ボトルネック研究

生活総合情報サイトAll About（オールアバウト）は、各分野の専門家が日常生活に役立つノウハウや最新動向を発信するメディアサイトです。Next.jsで構築されたモダンなアーキテクチャを採用しており、モバイル環境での表示速度について、どのような要素がボトルネックとなっているかを研究しました。

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

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

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

総合スコア が74から100へと26ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が5.9秒から1.6秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が3.6秒から0.4秒へと大きな変化が観測されています。一方、TBT（Total Blocking Time）は観測時点ですでに0msであり、JavaScriptの実行ブロックに関してはボトルネックが見られませんでした。

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

本サイトでは、総合スコア や各指標の変化の大きさの割に、読み込みプロセス動画上での表示速度には大きな違いは見られませんでした。

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

詳細レポート

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

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

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

allabout.co.jp のトップページでは、以下のサードパーティータグが確認されました。

合計で約90リソースにのぼるサードパーティータグが検出されました。これらを段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、総合スコア は74から100へ変化し、LCP は5.9秒から1.8秒、転送サイズは5.30MBから2.51MBへと半減する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

なお、本サイトはNext.jsによるモダンなアーキテクチャが特徴的で、CSSのインライン化（Emotion）、全スクリプトへの defer 属性付与、コード分割など、FCP や TBT に関しては非常に優れた構成を持っていました。そのため、サイト固有のボトルネックは主に LCP に関連するものに集中しています。

ボトルネック: LCP画像のloading属性 ​

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

観察された状況 ​

ファーストビュー内に表示されるLCP対象画像（記事のサムネイル画像）に loading="lazy" が一律で設定されていました。FCP が0.1秒であるのに対し LCP が1.8秒であることから、FCP後の約1.7秒の大部分が画像の遅延読み込み待ちに費やされていると推測されます。loading="lazy" はブラウザの IntersectionObserver による可視性判定を経てから読み込みを開始するため、ファーストビュー内の画像であってもすぐにはフェッチが始まりません。

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

LCP対象画像の loading 属性を lazy から eager に変更し、fetchpriority="high" を追加しました。これによりHTMLパース時に即座に高優先度でフェッチが開始される状態をシミュレーションしています。

シミュレーション結果 ​

LCP の変化量としては0.2秒ですが、SI は0.8秒から0.4秒へとほぼ半減しており、ページ全体の視覚的な表示速度に対する影響は数値以上に大きいことが読み取れます。全画像に loading="lazy" を一律設定した場合に、ファーストビュー内画像の読み込みが遅延するという現象は多くのサイトで見られるパターンです。

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

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

観察された状況 ​

ページ内の画像36枚（JPEG 35枚 + PNG 1枚）が、WebPなどの次世代フォーマットに変換されずに配信されていました。画像の合計転送サイズは233KBでした。

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

全36画像をWebPフォーマットに変換しました。写真調のJPEGはWebP（lossy）、線画・文字のPNGはWebP（lossless）で変換しています。

シミュレーション結果 ​

LCP や SI の数値には直接的な変化が現れませんでしたが、画像転送サイズが52.8%削減されています。本サイトの画像はAkamai CDNから高速に配信されているため、デスクトップ環境では転送サイズの差がスコアに反映されにくい状況でした。モバイル回線など帯域が制限される環境では、この転送量削減が表示速度の安定性に寄与する可能性があります。

まとめ ​

All Aboutのトップページでは、サードパーティータグの影響が圧倒的に大きく、約90リソースのタグが 総合スコア を26ポイント、LCP を約4.2秒押し下げていたことがシミュレーション結果から読み取れました。特に Google Tag Manager / Analytics の除去だけで LCP が2.3秒短縮されるなど、タグマネージャーを起点としたスクリプト群の影響は突出していました。

サイト固有のボトルネックとしては、LCP画像への loading="lazy" の一律設定が SI をほぼ半減させる結果につながったほか、画像のWebP変換により転送サイズを半減させる余地が確認されました。

一方で、本サイトはNext.jsのモダンなアーキテクチャにより、FCP や TBT に関しては非常に優れた構成を持っていました。CSSのインライン化、全スクリプトの defer 指定、コード分割などが効いており、サイト自体の技術基盤がしっかりしていることもまた、この研究から読み取れる重要な事実です。