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

株式会社セブン・ネットショッピングが運営する、本・雑誌・コミック・CD・DVDなどのエンタメ商品を中心とした通販サイトです。セブン‐イレブン店舗での受け取りなら送料無料で、nanacoポイントが貯まるほか、アーティストグッズなどの限定商品も扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

このサイトは、観測時点で 総合スコア が既に100に達していました。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と SI（Speed Index = ビューの視覚的な表示進捗の速さ）にはシミュレーション上の変化が見られるものの、スコアの上では差が表れません。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は観測時点から0.1秒でした。

本研究の Lighthouse は、回線の往復遅延を0、帯域を無制限とみなし、CPUの速度低下も行わない条件で計測しています。そのため TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から0msでした。またこの条件では、HTMLのサーバー応答時間（約0.23秒）がシミュレーション値にほとんど反映されず、FCP 0.1秒はその応答時間すら下回る値になっています。そこで本研究では、計測中にブラウザが実際に描画した時刻（以下、実測値）や、転送量などの物理量もあわせて観測しました。実測値は1秒未満の差が中心になるため、小数点第2位まで記載します。

実測の SI は3.07秒から0.33秒へ、読み込み完了は1.47秒から0.35秒へ、総転送量は5.04MBから477KBへと変化する結果が得られました。CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）も、観測時点の0.018から0へ変化しています。スコアが100であっても、表示の完了までの時間と転送量にはボトルネックが潜んでいたことを、このサイトの研究結果は示しています。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。解消シミュレーション後は日本語Webフォントを読み込まない状態のため、文字の書体が端末標準のゴシック体に変わっています。

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

詳細レポート

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

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

オリジナルページの全200リソースのうち、サイト固有のリソースは101件（約5割）、サードパーティタグ由来のリソースは99件（約5割）でした。

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

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

このページでは、1つ目のコンテナが注入した AudienceSearch が、さらに2つ目のGTMコンテナを読み込む入れ子の構造になっていました。2つ目のコンテナとその配下のスクリプトは、約511KBに上ります。

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

段階的に除去した際の指標変化は次のとおりです。FCP は全段階で0.1秒でした。

SI が1.8秒から0.4秒へ大きく変化し、CLS が0になったのは b→dash の除去の段階です。b→dash のWeb接客用スクリプトは、読み込み後にスタイルやアニメーションの定義を動的に挿入し、約0.9〜1.2秒後まで処理を続けていました。この遅い時点での描画の変化が SI を押し上げていたと考えられます。また、b→dash の同期スクリプトの読み込みが止まったことで後続のタグの注入も止まったとみられ、同じトリガーで後に続く AudienceSearch と2つ目のGTMコンテナも発火しなくなりました。この段階の変化は、b→dash 単独ではなく、それに連なるタグ群全体の影響として観測されたものです。LCP のシミュレーション値は段階ごとに上下しており、タグの影響よりも計測の揺らぎが表れていました。

サードパーティータグを全て除去した後の実測値と物理量を観測時点と比べると、シミュレーション値がほぼ動かなかった一方で、はっきりした変化が表れています。

サードパーティータグを全て除去した状態では、総合スコア は100のまま、SI は1.8秒から0.3秒へ、読み込み完了は1.47秒から0.45秒へ、メインスレッドの処理時間は1,208msから180msへと変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。観測時点では3.49MBあったスクリプトの転送量の大半がタグ由来で、除去後に残ったスクリプトはサイト自身の4本だけでした。

一方、実測の FCP・LCP はタグの除去前後でほとんど変わっていません。最初の描画とメインビジュアルの表示を決めていたのはタグではなくサイト自身の構成であり、タグを除去したことでその構造が観察しやすくなりました。

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

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

総合スコア は全工程で100のままだったため、各ボトルネックの影響は、5回計測の中央値と実測値、転送量などの物理量の変化で観測しています。

ボトルネック1: 高品質のJPEGのまま配信される画像 ​

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

観察された状況 ​

LCP 要素はトップのスライダーの1枚目の画像で、品質94のJPEG（約237KB）でした。スライダーは8枚あり、2枚目以降の画像（それぞれ200〜400KB）も LCP 画像と同時に読み込まれていました。この時点では、LCP より前に35件・約2.7MBの画像が読み込みを終えていました。

このサイトはCDNにCloudflareを使っており、応答ヘッダーには画像最適化機能の判定として cf-polished: webp_bigger が記録されていました。「WebPにすると容量が大きくなる」と判定され、JPEGのまま配信されていたことになります。この判定の背景には、元の画像の品質の高さがあると考えられます。

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

LCP 画像を含むページ内のJPEG画像31件を、WebP（品質75）に変換した状態を作りました。画像のURLとHTMLは変えていません。再生環境では各リソースの転送時間が録画時の値のまま再現されるため、変換後の画像は、録画時の回線速度を保ったまま新しい容量から転送時間を計算し直しています。スクリーンショットの比較では、見た目の差分は検出されませんでした。

シミュレーション結果 ​

LCP のシミュレーション値は0.40秒から0.12秒へと約7割短縮する結果が得られました。Lighthouse の推定モデルは、LCP より前に読み込みを終えた画像の数と容量に強く影響されるため、スライダーの2枚目以降を含めた画像全体の軽量化が大きく表れています。実測の LCP の変化は0.03秒と小さいものの、5回の計測値の範囲は解消前後で重なっていません。この計測環境は回線の帯域を奪い合わない条件のため、画像の容量の差が表れにくい構造です。帯域を分け合う実際のモバイル回線では、合計で約2.4MBの差がより大きく表れると考えられます。

このシミュレーション結果から、高品質のJPEGのまま配信される画像が、サイト固有のボトルネックの中でも特に大きな影響を持っていたことが読み取れます。

ボトルネック2: CSSの到着を待つ最初の描画 ​

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

観察された状況 ​

最初の描画は、レンダリングをブロックするCSS（読み込みが完了するまでページの描画が停止するリソース）2本、main.css と homePage.css の到着を待っていました。さらに、<head> 内でCSSより後に置かれたインラインスクリプトがCSSの読み込みを待ってHTMLの解析を止めており、CSSが届くまで <body> の解析も始まっていませんでした。

サードパーティータグの除去などを終えた、このボトルネックの調査開始時点で、実測の FCP までの内訳は次のとおりでした。

また、main.css はサイト全ページ共通のスタイルシート（約214KB）で、商品詳細・カート・マイページなどの規則も含んでおり、Lighthouse はこのページで約81%が未使用と判定していました。

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

次の4段階を順に重ねました。

1. ページ内の <script> 13個のうち、最初の描画前に必要な2個を除く11個を、出現順を保ったまま </body> の直前へ移動（<head> 内からは6個。defer・async などの属性は変えていない）
2. トップページ専用の homePage.css を main.css の末尾に結合して1本に
3. HTMLと各スクリプトに出現しないセレクタを削除（約214KBから約87KB）
4. 軽量化したCSSを、<link> から <style> に置き換えてHTMLに埋め込み

1〜3の段階では、実測の FCP はいずれも0.31秒前後のままでした。以下は4の段階の前後の値です。

シミュレーション結果 ​

CSSをHTMLに埋め込んだ段階で、実測の FCP は0.31秒から0.27秒へ約11%短縮する結果が得られました。HTMLの転送量は約10KB増えたものの、CSSを取得する往復がなくなり、HTMLの受信からレイアウトの開始までが約0.02秒になっています。スクリプトの移動・CSSの結合・未使用CSSの削除は、単独では FCP に変化が表れず、埋め込みが加わって初めて効果が観測されました。描画の経路上に複数の待ちが重なっていた構造が、このシミュレーション結果から読み取れます。

なお、1のスクリプトの移動では、実測の LCP も0.41秒から0.37秒へ変化していました。移動前は解析途中の不完全なページでレイアウトが走り、画面外にある loading="lazy" の画像3件が初期の読み込み範囲と判定されていたためです。

一連のシミュレーションの後も、実測の FCP 0.27秒の約84%は、HTMLのサーバー応答時間が占めていました。

ボトルネック3: 日本語Webフォントの読み込み ​

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

観察された状況 ​

ページ全体の文字に、Google Fontsの日本語Webフォント「Noto Sans JP」（500・700の2ウェイト）が使われていました。サイトの見た目を端末によらずそろえたいという意図は、十分に理解できるものです。一方、日本語のフォントは文字数が多いため、Google Fontsは文字の範囲ごとに分割したファイル（このページでは23ファイル）で配信しています。初期表示ではそのうち12ファイル（約278KB）が読み込まれ、フォントのCSS（約62KB）と合わせて約340KBの転送になっていました。

さらに、このフォントのCSSは media="print" で読み込まれ、onload で media を切り替える方式でした。切り替えの時点でページ全体のスタイル再計算が発生し、その後も分割されたフォントのファイルが1つ届くたびに、ページ全体の再レイアウトが起きていました。

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

HTMLからフォントのCSSの読み込みと、fonts.gstatic.com への preconnect を削除しました。CSSの font-family は変えていないため、文字は端末標準のゴシック体で表示されます。このシミュレーションは、文字の書体が変わることを前提に行いました。スクリーンショットの比較での差分は3.8%で、文字の字形と字幅の変化のみでした。

シミュレーション結果 ​

総転送量が約27%減り、スタイル計算・レイアウトの時間は約4割短縮する結果が得られました。いずれも5回の計測値の範囲は解消前後で重なっていません。CPUを4倍に減速した補助計測でも、スタイル計算・レイアウトの時間は322〜336msから241〜252msへ変化しています。

この計測環境では実測の FCP・LCP に変化は見られなかったものの、日本語Webフォントがページの転送量とメインスレッドの処理に与えていた影響の大きさが、このシミュレーション結果から読み取れます。

まとめ ​

セブンネットショッピングのトップページを観測したところ、総合スコア は100、TBT は0msと、Lighthouse の上では既に良好な値が計測されていました。一方、実測の SI は3.07秒、読み込み完了は1.47秒、総転送量は5.04MBで、スコアに表れないボトルネックが残っていました。

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

• サードパーティータグ（99リソース）: 除去によって SI が1.8秒から0.3秒へ、読み込み完了が1.47秒から0.45秒へ、メインスレッドの処理時間が1,208msから180msへ変化しました。b→dash に連なるタグ群は、CLS 0.018の発生源でもありました。最初の描画には影響していませんでした。
• 高品質のJPEGのまま配信される画像: WebPへの変換で画像31件の容量が3.41MBから1.03MBへ減り、LCP のシミュレーション値が0.40秒から0.12秒へ短縮しました。サイト固有のボトルネックの中で最も大きな影響が観測されました。
• CSSの到着を待つ最初の描画: スクリプトの移動とCSSの軽量化を経て、CSSをHTMLに埋め込んだ段階で、実測の FCP が0.31秒から0.27秒へ変化しました。
• 日本語Webフォントの読み込み: 約340KBのフォントの読み込みをなくすと、総転送量が27%減り、スタイル計算・レイアウトの時間が約4割短縮しました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は100のまま、実測の SI は3.07秒から0.33秒へ、総転送量は5.04MBから477KBへと変化しています。

全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間（約0.23秒）が実測 FCP の約84%、実測 LCP の約7割を占めていました。同じCDNから返る静的ファイルの応答は中央値約0.03秒である一方、HTMLはCDNでキャッシュされず（cf-cache-status: DYNAMIC）、毎回オリジンサーバーで生成されています。これはサーバー側の処理であり本研究のシミュレーションの範囲外ですが、このサイトに残る最大のボトルネックとして観測されています。