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

BuzzFeed Japanは、エンターテインメント、ニュース、ライフスタイルなど幅広いカテゴリのコンテンツを配信するデジタルメディアサイトです。観測時点で 総合スコア 98と既に高水準ですが、SI（Speed Index）が3.1秒とやや遅く、表示体感速度にどのようなボトルネックが影響しているかを研究しました。

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

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

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

総合スコア が98から100へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が3.1秒から1.1秒へと約2秒短縮されるシミュレーション結果が得られました。TBT と CLS は観測時点で既に最良値であり、本サイトのJavaScript実行効率やレイアウト安定性は非常に優れていることが読み取れます。一方で SI に集中的にボトルネックが存在していたことが、今回の研究で明らかになりました。

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

本サイトでは、指標や 総合スコア の上では大きな変化は見られませんが、解消シミュレーション後は LCP に該当する画像を含め、画像の表示がワンテンポ早くなった様子が見て取れます。

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

詳細レポート

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

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

サードパーティタグの大半（285件/56%）は広告配信システムが占めています。広告配信システムは転送サイズ・メインスレッド時間ともに最も大きく、パフォーマンスへの影響も最大です。データプラットフォーム（18件/4%）はリソース数は少ないものの、Permutiveのメインスレッド時間（149.7ms）が大きく、LCPに影響していました。

本サイトのHTMLおよび Google Tag Manager 経由で読み込まれていたサードパーティータグは次のとおりです。

505リソース中285件がサードパーティーリソースであり、段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、SI が3.1秒から1.2秒へ約2秒短縮される結果が得られました。特に広告配信システムの除去だけで SI が約2秒短縮されており、広告タグが表示体感速度に与えていた影響の大きさが読み取れます。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが分かります。

以降のセクションでは、サードパーティータグを除去した状態を起点として、サイト固有のボトルネックを観察していきます。

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

サードパーティータグの影響を切り離した状態で、サイト固有のボトルネックを調査しました。全8件のボトルネック仮説を検証し、その中から特に影響の大きかった2件を紹介します。

ボトルネック1: CDN JavaScriptの外部ドメイン配信 ​

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

観察された状況 ​

cdn.jsdelivr.net から配信されていた pubcid.min.js が、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）のクリティカルパス上にありました。外部ドメインからの読み込みでは、DNS解決とTLSハンドシェイクという追加の接続コストが発生し、メインコンテンツの描画開始を遅延させている状況が観測されました。

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

cdn.jsdelivr.net から読み込んでいたJavaScriptファイルを、サイトと同一ドメイン（www.buzzfeed.com）から配信する状態に変更しました。これにより、HTMLの取得時に確立済みの接続を再利用できるようになります。

シミュレーション結果 ​

FCP が37.8%短縮されるという結果が得られました。JavaScriptファイル1つの配信ドメインの違いだけで、これだけの差が生じていたことが分かります。このシミュレーション結果から、クリティカルパス上のリソースを外部ドメインから読み込むことの影響の大きさが読み取れます。

ボトルネック2: 未使用CSSの残存 ​

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

観察された状況 ​

Lighthouse の unused-css-rules 監査で、メインのスタイルシート feeds.css の97.2%が未使用であると報告されていました。CSSはレンダリングブロックリソースであるため、ファイルサイズが大きいほどパースに時間がかかり、描画開始が遅れる要因になります。feeds.css は271KBあり、そのほとんどがトップページでは使用されていない状態でした。

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

PurgeCSSを使用して、HTMLで実際に参照されているCSSセレクタのみを残す処理を行いました。その結果、feeds.css は271KBから59KB（78%削減）にまで縮小されました。

シミュレーション結果 ​

CSSの転送サイズが212KB削減されたことで、CSSのダウンロードとパースが高速化し、FCP と LCP の両方に変化が観測されました。97%が未使用という状況は、サイト全体で共通のCSSファイルを配信している構成によるものと考えられますが、トップページの表示速度にとっては無視できないボトルネックであったことが、このシミュレーション結果から読み取れます。

まとめ ​

BuzzFeed Japanのトップページは、観測時点で 総合スコア 98・TBT 0ms・CLS 0.000と、すでに非常に高い水準にあるサイトでした。SI が3.1秒とやや遅い点がボトルネックとして存在しており、その主な要因はサードパーティータグ（特に広告配信システム）にあることが、除去シミュレーションで明らかになりました。

サイト固有のボトルネックとしては、外部CDNからのJavaScript配信が FCP に約38%の影響を与えていたこと、未使用CSSの残存が FCP と LCP の両方に影響していたことが観測されました。いずれも 総合スコア 自体への影響は小さいものの、実測値ベースでは無視できない差として表れていた点が、今回の研究で得られた知見です。