「ロッピング」トップページの表示速度ボトルネック研究

テレビ朝日グループの株式会社ロッピングライフが運営する、テレビショッピングの通販サイトです。「じゅん散歩 ものコンシェルジュ」「ニッポンめしあがれ」などテレビ朝日の番組で紹介された商品を扱い、トップページには番組ごとの最新の放送商品、売れ筋ランキング、キャンペーン、商品カテゴリ、特集などが縦に長く並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は94と高い水準でしたが、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は5.6秒で、この指標だけが「改善が必要」の範囲に入っていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は1.5秒、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は1.8秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.049です。解消シミュレーション後は、SI が0.2秒、FCP と LCP がともに0.1秒まで変化しました。

なお、本研究の Lighthouse は、通信の遅延・帯域制限とCPUの速度制限をかけない条件で計測しています。TBT（Total Blocking Time = メインスレッドのブロック時間）が全期間で0msなのはこの条件によるものです。低速回線とCPUの減速を想定する PageSpeed Insights のモバイル計測では、同じページでも値はこれより大きくなります。そのため本記事では、指標の値そのものよりも、変化の比率と、各ボトルネックの影響の大きさの順序に注目しています。また、帯域制限がない条件では転送量の削減が時間に表れにくいため、転送量や要求数の変化もあわせて示します。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画は左が観測時点、右が解消シミュレーション後です。

動画は Lighthouse とは別の条件で記録しているため、表の値は先ほどの指標とは一致しません。観測時点では表示が始まるまでに時間がかかり、その後も長く読み込みが続くのに対し、解消シミュレーション後は1秒以内に読み込みが終わっています。

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

詳細レポート

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

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

観測時点のページの全629リソースのうち、サードパーティータグ由来のリソースは325件（約5割）を占めていました。Google Fontsは、サイト側で配信方法を変えられるため、サードパーティータグではなくサイト固有のリソースとして数えています。

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

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

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

サードパーティータグを全て除去した状態では、総合スコア は94から99へ、LCP は1.8秒から0.8秒へ、SI は5.6秒から0.8秒へ変化する結果が得られました。

変化が大きかったのは2つの段階です。1つは、head 内の同期スクリプトで画像の配信先を書き換えていたLandingHubで、除去によって LCP が1.2秒短縮しました。もう1つは、転送量約48KBと小さなタグだったAudienceSearchです。このタグは継続的な通信によってページが静止するまでの時間を約28.5秒まで引き延ばしており、その間、自動で回転するカルーセルの描画まで SI に加算されていました。除去後はページが約1.9秒で静止し、SI は3.0秒から0.8秒へ変化しています。

なお、Googleタグの段階ではスクリプトの転送量が約3.7MB減っています。広告タグの多くは単独の影響が計測の揺らぎ（±0.1秒程度）に埋もれる大きさで、表の LCP や FCP が段階ごとに上下しているのもこの揺らぎによるものです。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

サードパーティータグを除去した後の FCP や LCP は1秒未満の値になるため、以下の表では小数点第2位まで示しています。また、このページの値は1回ごとに揺らぐため、本文では3回計測の中央値もあわせて扱います。

ボトルネック1: Google FontsのCSSが別ドメインから描画を止める ​

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

観察された状況 ​

ページの head には、読み込みが完了するまで描画が始まらないレンダリングブロックの CSS が6本ありました。このうち、Google Fontsの CSS（357KB、@font-face が399件）だけが別ドメインの fonts.googleapis.com から読み込まれていました。別ドメインのため新しい接続（DNS・TCP・TLS）が必要で、自社ドメインの CSS が約0.24秒で揃っていたのに対し、この CSS は約0.33秒に届き、最初の描画の時刻を決めていました。Lighthouse の「レンダリングを妨げるリソース」の指摘もこの CSS だけでした。

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

同じ内容の CSS をサイトのドメインから配信する状態を作り、<link> の参照先を差し替えました。CSS の内容は変えておらず、フォントの見た目は変わりません。

シミュレーション結果 ​

3回計測の中央値でも、FCP は0.46秒から0.19秒へと約6割短縮し、3回の値の範囲は重なりませんでした。<link> の参照先を同一ドメインに変えただけで、最初の描画の経路から別ドメインへの接続が消えたことになります。直前のシミュレーションで head 内の同期スクリプト（tom-select.complete.min.js）を body 末尾へ移して defer を付け、HTMLの解析が早く終わるようになっていたことも、CSS 待ちの短縮がそのまま FCP に表れた理由です。

この後、ページで使われない @font-face を削除した場合は FCP が0.14秒へ、30個に分かれて fonts.gstatic.com から届いていた日本語フォントを1ファイルにまとめ、欧文フォントとともにサイトのドメインから配信した場合は0.12秒へと、さらに短縮する結果も得られています。Google Fontsまわりの一連のシミュレーションを合わせると、FCP は0.46秒から0.12秒へ変化しました。このシミュレーション結果から、別ドメインから読み込まれるGoogle Fontsの CSS が、サードパーティータグを除いた状態で最も大きく表示の立ち上がりを遅らせていたことが読み取れます。

ボトルネック2: 画面外の画像まで一斉に取得している ​

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

観察された状況 ​

このページの LCP 要素は、メインビジュアルのスライダー1枚目の画像です。ところがページ内の <img> 262件には loading="lazy" が1件もなく、スマートフォンのファーストビューに見える画像は9件だけなのに、初期読み込みで198件・12.2MBの画像を取得していました。番組ごとの放送商品を並べたトップページは縦に長く、スマートフォンでは折りたたまれて見えない商品カードの画像まで含まれています。FCP より前に119件の画像の取得が始まり、LCP 画像と同時に走っていました。

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

<main> 以降の画像251件に loading="lazy" を付けました。LCP 画像と、スマートフォンまたはPCでファーストビューに入る画像は対象から外しています。JavaScript で後から生成するランキングの商品画像にも同じ属性を付けました。

シミュレーション結果 ​

初期読み込みの画像は198件から26件へ、画像の転送量は12.2MBから1.67MBへと、それぞれ約87%と約86%減る結果が得られました。LCP は0.12秒から0.10秒への短縮ですが、3回の計測値の範囲は重なっておらず、要求の減少が Lighthouse の推定にも表れています。10MBを超える転送の削減も、帯域制限のない今回の条件では時間に表れにくくなっています。実際のモバイル回線では、LCP 画像と同時に走っていた170件超・10MB超の取得がなくなることの影響は、より大きくなると考えられます。

続けて画像をWebP形式に変換したシミュレーションでは、初期読み込みの画像転送量がさらに0.47MBまで減りました。このシミュレーション結果から、画面外の画像の一斉取得が、このページで最も大きな転送量を生んでいたボトルネックであったことが読み取れます。

ボトルネック3: 日本語Webフォントが総転送量の大半を占める ​

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

観察された状況 ​

画像のボトルネックを解消した段階で、ページの総転送量は1.73MBまで減っていました。その56%を占めていたのがWebフォントで、中でも日本語フォントのNoto Sans JPは1ファイルで930KBありました。日本語フォントは文字数が多いため、欧文フォントと比べてデータ量が桁違いに大きくなります。なお、本研究ではレイアウトのずれを観察する段階で font-display を swap から optional に変更しており、この時点では初回訪問の多くの場面でフォントの到着を待たずに端末の標準フォントで表示されていました。見出しや価格を揃った書体で見せたいというデザイン上の意図は理解できます。

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

2段階で観察しました。まず、トップページで使われている1,761文字だけにフォントを絞り込み（サブセット化）、見た目を保ったまま転送量がどう変わるかを計測しました。続けて日本語フォントの読み込みそのものを除外し、端末の標準ゴシック体で表示する状態を作りました。後者のシミュレーションは、フォントの見た目が変わることを前提として行っています。

シミュレーション結果 ​

日本語フォントを1,761文字に絞り込んだ段階で総転送量は29%減り、日本語フォントを読み込まない状態ではさらに36%減って、総転送量は1.73MBから0.79MBへと半分以下になりました。フォント到着後のスタイル再計算やレイアウトのやり直しもなくなっています。

LCP が変わらないのは、帯域制限のない今回の計測条件ではフォントの転送時間が表れにくいためです。仮に1.6Mbpsの回線であれば、標準フォントへの切り替えで減った約435KBは約2.2秒分の転送に相当します。このシミュレーション結果から、日本語Webフォントが、このページの転送量のうちサイト側で最も大きな割合を占めていたことが読み取れます。

まとめ ​

ロッピングのトップページの表示速度を観測したところ、総合スコア 94、FCP 1.5秒、LCP 1.8秒、SI 5.6秒という値が計測されました。総合スコア は高い一方で、SI が大きく、表示が落ち着くまでに時間がかかる状態でした。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（325リソース）: 全て除去した状態では SI が5.6秒から0.8秒へ、LCP が1.8秒から0.8秒へ短縮。特に、画像の配信先を書き換えるLandingHubが LCP に、通信を続けてページの静止を遅らせていたAudienceSearchが SI に大きく影響していました。
• 別ドメインから描画を止めるGoogle FontsのCSS: 同一ドメインからの配信によって FCP が0.46秒から0.19秒へ短縮。日本語フォントファイルの配信元の変更などと合わせると0.12秒まで変化しました。
• 画面外の画像の一斉取得: 遅延読み込みによって初期読み込みの画像が198件・12.2MBから26件・1.67MBへ減少。
• 日本語Webフォント: サブセット化と標準フォントへの切り替えによって、総転送量が1.73MBから0.79MBへ減少。

このほか、画像の width / height 属性の不足によるレイアウトのずれ、無圧縮で配信されていた約836KBのHTML、8,859要素に及ぶ大きなDOMなども観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は94から100へ、SI は5.6秒から0.2秒へ、LCP は1.8秒から0.1秒へと変化しました。サードパーティータグによる読み込みの長期化に加え、別ドメインのフォント CSS、大量の画像、日本語Webフォントといった要素が、このページの表示速度と転送量に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。