「オシャレウォーカー」トップページの表示速度ボトルネック研究

「ありそうでなかった、ここにしかない商品」を掲げる、レディースファッションの公式通販サイトです。幅広いテイストとサイズ感の洋服を扱い、トップページには日付ごとの新着・再入荷アイテム、カテゴリ別のランキング、特集やキャンペーンのバナーが並んでいます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。計測は Lighthouse のモバイル条件で行っています。

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

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は8.4秒から0.2秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は18.9秒から0.2秒へと変化するシミュレーション結果が得られました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も2.0秒から0.1秒へ変化しています。TBT（Total Blocking Time = メインスレッドのブロック時間）は、サードパーティタグを154リソース積んだ観測時点から一貫して0msでした。

CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は観測時点と解消シミュレーション後のどちらも0.000ですが、観測時点の0.000は「ずれていない」状態ではありませんでした。サードパーティタグがページ全体を一時的に隠していたため、実際に起きていたずれが計測に表れていなかったのです。この点は、サードパーティータグの節とボトルネック1で扱います。

ページの構成も大きく変わりました。画像の変換・縮小・遅延読み込みを含む解消シミュレーションを重ねた結果、総転送量は17.9MB（サードパーティタグ除去と CLS・FCP・LCP の解消シミュレーションを終えた時点）から約0.9MBへ、リクエスト数は333件から79〜92件へと減っています。

なお、解消シミュレーション後の値には、HTMLのサーバー応答時間の短縮、外部APIの結果のサーバー側キャッシュ、配信帯域を100Mbps相当に揃えるという、サイトのコードの変更だけでは実現できない3件のシミュレーションが含まれています。これらを含まない、サイト側のコードの変更だけの時点でも 総合スコア は100、LCP は0.4秒、SI は1.9秒に達していました。

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

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

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

詳細レポート

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

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

観測時点のページの全558リソースのうち、サードパーティタグ由来のリソースは154件（約3割）を占めていました。タグマネージャーのコンテナが2つ同時に動いており、さらにDMPのタグが3つ目のコンテナを読み込んでいました。コンテナのJavaScriptだけで合計1.2MBを超えています。

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

Google Tag Manager（GTM-PPTJRWT）経由で読み込まれているタグ ​

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

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

最も大きく動いたのは、広告・計測タグ10種類をまとめて除去した段階で、総合スコア は65から89へ、LCP は7.9秒から2.5秒へ変化しました。</head> の直前にあるタグ枠の中で、Google Optimizeのスクリプトが async なしで実行され、HTMLの解析を止めていたことが観測されています。

一方、GTM-TZZT9Q79を除去した段階では 総合スコア が92から63へ下がり、CLS が0.000から0.927へ跳ね上がりました。このタグはA/Bテストのちらつきを防ぐ処理として、<html> を最大2秒間 visibility: hidden にしていました。CLS は見えている状態で起きたずれだけを数えるため、隠されている間のずれは計上されていなかったのです。タグの除去で新たなずれが生じたのではなく、もともと存在していたずれが計測値として現れたと読み取れます。

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

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

ボトルネック1: メインスライダーの高さが確保されていない ​

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

観察された状況 ​

このページは、HTMLでは空の入れ物だけを出力し、JavaScriptがデータファイルを取得してから中身を挿入する構成を多用しています。更新頻度の高いコンテンツを扱ううえで自然な作りですが、挿入前の入れ物は高さを持たないため、中身が入った瞬間、下にあるコンテンツが押し下げられます。

ファーストビューの最上部にあるメインスライダーもこの構成で、スライドが挿入されるまでページネーション分の27pxしか高さがありませんでした。スライドが入ると約205px伸び、検索欄・お知らせ・閲覧履歴の枠など、ファーストビュー全体が下にずれていました。サードパーティータグの除去で計測に表れた CLS 0.927のうち、最も大きな部分を占めていたのがこのずれです。

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

スライダーの設定（画面に2枚表示・間隔3px・正方形）から挿入後の高さを計算し、スライダーの入れ物が空のときだけ、その高さをCSSで確保しました。中身が挿入された後は指定が効かなくなるため、最終的なレイアウトは変わりません。

シミュレーション結果 ​

CSSの数行で CLS は0.927から0.315へ、総合スコア は67から80へと変化するシミュレーション結果が得られました。1件で CLS の約3分の2が解消しており、ファーストビューで最も大きな領域の高さが、レイアウトのずれのボトルネックであったことが読み取れます。

同じ構成の検索キーワード一覧とお知らせ一覧、空のまま余白を占めていた送料無料の告知枠、後から幅が決まる固定ヘッダーにも関連するずれがあり、これらを含めた一連の解消シミュレーションで CLS は0.931から0.000へ、総合スコア は74から96へと変化しています。

ボトルネック2: 別ドメインから配信される描画ブロックCSS ​

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

観察された状況 ​

ブラウザが最初の描画を行うには、HTMLと描画をブロックするすべてのCSSが揃っている必要があります。このページでは、描画ブロックCSS 8本をHTMLとは別のドメイン（osharewalker.itembox.cloud）から読み込み、そのうち1本の中の @import がもう1本を直列に読み込んでいました。jQueryも公開CDN（ajax.googleapis.com）から同期的に読み込まれていました。

CSS 8本はファイルサイズが443Bから37.6KBまでばらばらであるにもかかわらず、すべてほぼ同じ時刻（1.27〜1.29秒）に到着していました。待ち時間の大半が転送ではなく、別ドメインへの接続確立に費やされていたことを示しています。

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

描画ブロックCSS 9本すべてを、HTMLと同じドメインから配信するように変更しました。CSSの中の url() はCSS自身のURLを基準に解決されるため、相対パスで書かれたフォント・画像などの参照26箇所は、元のドメインの絶対URLに書き換えています。あわせて、同じドメインの接続を使い回せる前提で、CSSの応答待ちを同じサーバーの静的ファイル相当（42ms）に揃えています。

シミュレーション結果 ​

CSSの配信元を変えただけで、FCP は1.3秒から0.8秒へ、LCP は2.3秒から1.0秒へと変化し、総合スコア は100に達しました。CSS 9本は0.39〜0.44秒に揃って到着するようになっています。この結果から、別ドメインへの接続確立の待ちが、そのまま描画開始の遅れになっていたと考えられます。

CSSの次に描画をブロックしていたjQueryを同じドメインから配信したシミュレーションでは、FCP が0.8秒から0.3秒へ変化しました。短縮幅の0.45秒は、Lighthouse が事前に推定していたjQueryの描画ブロック時間と一致しています。その後のCSSの結合・未使用ルールの削除・HTMLへの埋め込みまでを含めると、FCP は1.3秒から0.1秒へと変化しました。

ボトルネック3: 表示されない日付の商品画像の読み込み ​

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

観察された状況 ​

ここまでの解消シミュレーションを重ねた時点で、総合スコア はすでに100でした。それでもページの総転送量は12.8MBあり、そのうち最も大きな割合を占めていたのが、トップページ中ほどの新着・再入荷（NEW/RE-ARRIVAL）セクションです。

このセクションは9日分・216件の商品を生成し、日付ごとのスライドを同じ位置に重ねて、フェードで切り替えています。表示中でない日付のスライドはCSSで透明にして隠しているだけで、レイアウト上は存在していました。そのため中の画像はブラウザの遅延読み込みの対象から外れず、表示されない日付の画像までまとめて読み込まれていました。読み込まれていた115枚・6.68MBのうち、実際に表示されるのは22枚です。加えて、表示中の日付でもスクロールしないと見えない行の画像まで読み込まれていました。日付を切り替えたときにすぐ画像が出るという点では理にかなった作りですが、初回表示ではその分の通信がすべて発生していました。

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

表示中でない日付のスライドに content-visibility: hidden を指定し、描画そのものを省略するようにしました。CSS 1行の追加です。このシミュレーションは、日付を切り替えた直後にその日付の画像が読み込み中になることを前提に行いました（この計測環境では、切り替えから2.5秒後にはすべて表示されていました）。

シミュレーション結果 ​

総合スコア は100のまま変わりませんが、総転送量は12.84MBから3.08MBへと約76%減り、LCP は0.4秒から0.2秒へと変化しました。トレース上の実測 LCP は158msから150msとほぼ変わっておらず、この変化は、同時に始まる通信の数から LCP を見積もる Lighthouse の計算に、並行する画像のリクエストの大幅な減少が表れたものです。スコアには表れない場所で、表示されない画像の通信がページ全体を重くしていたことが、このシミュレーション結果から読み取れます。

この解消シミュレーションの1つ前には、スライダーのライブラリ（Swiper）が初期化時に全画像を先読みする設定により、ランキングやブランド欄で loading="lazy" が指定された画像54本・約3.3MBが読み込まれていたことも観測されています。

まとめ ​

オシャレウォーカーのトップページでは、観測時点の 総合スコア が64でした。LCP が8.4秒、SI が18.9秒と大きく、CLS の0.000はサードパーティタグによってずれが隠された状態の値でした。

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

• サードパーティータグ（154リソース）: 除去によって 総合スコア が64から74へ、LCP が8.4秒から2.1秒へ、SI が18.9秒から3.5秒へ変化しました。広告・計測タグ10種類の除去で最も大きな変化が観測され、A/Bテストのちらつきを防ぐ処理が CLS 0.927のずれを隠していたことも分かりました。
• メインスライダーの高さが確保されていない: 挿入後の高さをCSSで確保したシミュレーションでは、CLS が0.927から0.315へ、総合スコア が67から80へ変化しました。
• 別ドメインから配信される描画ブロックCSS: HTMLと同じドメインに配信元を移したシミュレーションで、FCP が1.3秒から0.8秒へ、LCP が2.3秒から1.0秒へ変化し、総合スコア が100に達しました。
• 表示されない日付の商品画像の読み込み: 描画を省略したシミュレーションで、総転送量が12.84MBから3.08MBへと約76%減り、LCP が0.4秒から0.2秒へ変化しました。

このほか、メインスライダーの画像がJPEGのまま表示サイズの約4倍で配信されていたことや、HTMLのサーバー応答時間（約0.32秒）が画像側の解消シミュレーション後の実測 LCP の7割以上を占めていたことも観測されています。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は64から100へと変化しました。最後の段階で残っていたのは、スコアに表れない転送量や描画の負荷であり、それらを含めて表示速度に影響する要因がページの各所に分散していたことが、この研究から読み取れます。