「シネマトゥデイ」トップページの表示速度ボトルネック研究

最新映画ニュース、作品情報、予告編動画、インタビュー、興行成績ランキングなど、映画に関する情報を網羅的に提供する総合映画メディアサイトです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が95から100へ変化するシミュレーション結果が得られました。観測時点で既にスコア95と高水準にあるサイトですが、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が5.8秒と突出して大きな値を示しており、主にサードパーティータグに起因するボトルネックが集中していたことが読み取れます。

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

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

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

詳細レポート

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

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

オリジナルページの全253リソースのうち、サイト固有のリソースは73件（28.9%）、サードパーティタグ由来のリソースは180件（71.1%）を占めています。リソース総数の7割以上がサードパーティタグによるものであり、パフォーマンスへの影響の大きさを端的に示しています。

www.cinematoday.jp で確認されたサードパーティータグは次のとおりです。

特に AnyMind360 のPrebidヘッダービディングは同期スクリプトとしてHTMLに読み込まれており、そこから連鎖的に126件ものDSP/SSPリソースが生成されていました。

以下は、サードパーティータグを段階的に除去した際の指標変化です。

サードパーティータグを全て除去した状態では、総合スコア が95から100、SI が5.8秒から0.8秒へ変化する結果が得られました。180件超のサードパーティーリソースが削減されており、特に SI の大幅な変化から、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック: CDNリソースの外部ドメイン配信 ​

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

観察された状況 ​

jQuery 2.2.0が ajax.googleapis.com から、Font Awesome 4.1.0のCSSが netdna.bootstrapcdn.com から、メインCSSが img.cinematoday.jp からそれぞれ配信されていました。HTMLドメイン（www.cinematoday.jp）とは異なるドメインへのアクセスが発生するため、ドメインごとにDNSルックアップとTLSハンドシェイクが追加で必要となり、リソースの取得開始が遅延していました。Font Awesome CSSのTTFBは508msに達しており、レンダリングブロックリソースとして FCP に直接影響していました。

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

jQuery、Font Awesome CSS、メインCSSの配信元をすべて www.cinematoday.jp に変更し、HTML取得時に確立済みのコネクションを再利用できるようにしました。

シミュレーション結果 ​

このシミュレーション結果から、外部CDNへの接続コストが LCP や FCP に与えていた影響の大きさが読み取れます。HTMLドメインと同一のドメインからリソースを配信することで、ドメインごとのDNS解決やTLSハンドシェイクを省略でき、リソース取得の開始が早まった形です。

ボトルネック: JPEG/PNG画像のWebP未変換 ​

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

観察された状況 ​

ページ上の44枚のJPEG/PNG画像が旧来のフォーマットのまま配信されており、合計で約1.22MBのデータ量となっていました。LCP 対象のヒーロー画像（ピックアップ記事のメイン画像）は35.0KBのJPEG形式でした。

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

44枚の画像をすべてWebP形式に変換しました。変換後の合計サイズは584.2KBとなり、53.2%の削減が得られました。LCP 対象画像は35.0KBから18.5KBに縮小されています。

シミュレーション結果 ​

WebP変換による影響は LCP に集中して現れました。ヒーロー画像のダウンロード時間が短縮されたことにより、ページの主要コンテンツが描画されるタイミングが約0.3秒早まった形です。画像フォーマットの違いだけでこれだけの差が生じるという点で、画像配信がページ速度に与える影響の大きさが読み取れます。

ボトルネック: CSSファイルの分散 ​

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

観察された状況 ​

メインCSS（mobile2.min.css）と Font Awesome CSS（font-awesome.min.css）が別々のファイルとして配信されていました。CSSはレンダリングブロックリソースであるため、すべてのCSSファイルのダウンロードが完了するまでページの描画が開始されません。2つのCSSファイルのダウンロードが並列に行われる場合でも、HTTPリクエストのオーバーヘッドが余分に発生していました。

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

Font Awesome CSSの内容を mobile2.min.css に統合し、CSSのHTTPリクエストを1件削減しました。

シミュレーション結果 ​

CSSファイルを1件削減しただけで、LCP が0.5秒、FCP が0.2秒変化するというシミュレーション結果が得られました。LCP の変化幅が大きいのは、CSSリクエスト削減により全体のリソース読み込みシーケンスが効率化されたためと考えられます。レンダリングブロックリソースの数がページ描画タイミングに直結するという事実が、このシミュレーション結果から明確に読み取れます。

なお、CSSの統合・1ファイル化は、現在では HTTP/2 の普及などにより必ずしも有効なプラクティスとは限りません。今回のシミュレーションのように良好な結果が観測されることもありますが、参考程度にとどめてください。

まとめ ​

シネマトゥデイのトップページは、観測時点で 総合スコア 95と高水準にありましたが、SI が5.8秒と突出しており、サードパーティータグの影響が大きいことが読み取れました。特に AnyMind360 のPrebidヘッダービディングは同期スクリプトとして126件のリソースを連鎖的に生成しており、SI を大きく押し上げていた主要因でした。

サイト固有のボトルネックとしては、外部CDNからのリソース配信による接続コスト、JPEG/PNG画像のWebP未変換、CSSファイルの分散が観測されました。これらを解消するシミュレーションでは、LCP が1.3秒から0.3秒、FCP が0.6秒から0.3秒まで段階的に変化する結果が得られています。いずれもサイトの機能や見た目に影響を与えない技術的な要因であり、表示速度に対する影響の大きさが明確に立証されました。