「しまむらパーク」トップページの表示速度ボトルネック研究

しまむらグループの公式オンラインストアです。しまむら・アベイル・バースデイ・シャンブル・ディバロの全ブランドの商品を扱い、オンラインストア限定商品のほか、近くのグループ店舗で受け取れば送料無料になるサービスも提供しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

本研究の Lighthouse 計測は、記録時の通信の速さを再現した条件で、CPUの速度制限はかけずに行っています。そのため FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は観測時点でも0.3秒と短く、TBT（Total Blocking Time = メインスレッドのブロック時間）も一貫して0msでした。それでも 総合スコア は51にとどまり、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は5.4秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は9.3秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.472と「悪い」判定の値を記録していました。

CPUの速度制限のない環境でもこれだけ遅いという事実は、このページの遅さの主な原因が回線やCPUの性能ではなく、描画の開始タイミングとレイアウトの組み立て方にあることを示しています。全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は100、LCP は0.1秒、CLS は0.000へと変化し、総転送量も49.88MBから4.26MBへ約9割減少しました。なお、解消シミュレーション後の LCP と FCP には、画像と CSS をHTMLと同じ接続で配信した場合を想定した理論値が含まれています。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画の撮影時、観測時点のページは90秒以内に読み込みが完了せず、メインビジュアルが表示されるまで大きな空白が続いたあと、表示と同時にレイアウトが大きくずれました。解消シミュレーション後は、読み込み完了までの時間が4.08秒、転送量は20.95MBから3.62MBへと変化しています。

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

詳細レポート

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

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

オリジナルページの全499リソースのうち、サードパーティタグ由来のリソースは245件（約5割）を占めていました。HTMLに直接記述されていたのは Google Tag Manager のスニペットだけで、Google Analytics 4・Google Ads と、残る11ベンダーのタグは全てそこから動的に読み込まれていました。さらに、同じスニペットがページ下部に埋め込まれた <iframe> 内のHTMLにも記述されており、1回の表示で2.06MBのコンテナを2回読み込む構成になっていました。

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

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

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

タグが多く載った状態では計測のばらつきが極めて大きく、同じページを繰り返し計測しても 総合スコア は45から78まで揺れていました。そのため途中段階のスコアの上下は誤差の範囲にあります。一方で、1つのスクリプトだけでメインスレッドを延べ5,060ms占有し、Web接客用の画像68件（28.56MB）を先読みしていた Repro の除去では、転送量が半分以下に減りました。

サードパーティタグを全て除去した状態では、転送量は49.88MBから18.00MBへ約64%減少し、SI は9.3秒から4.1秒へ短縮される結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティタグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

ただし、総合スコア は51から53へとほとんど動かず、CLS の0.472は245件のタグを全て除去しても変化しませんでした。LCP と CLS を悪化させていた原因が、サイト自身の実装側にあったことを示す結果です。

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

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

ボトルネック1: メインビジュアルがJavaScriptの初期化まで表示されない ​

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

観察された状況 ​

ファーストビューのメインビジュアル（jQuery プラグインの slick によるスライダー）には、CSS で opacity: 0 と visibility: hidden が指定されていました。表示に切り替わるのは、スライダーの初期化が完了したときに -loaded クラスが付与されてからです。

LCP 要素はこのメインビジュアルの画像です。つまり、画像そのものは早い段階で届いているのに、JavaScript の実行が完了するまで一切描画されない構造になっていました。JavaScript の実行タイミングに描画が左右されるため、サードパーティータグを除去した状態でも、LCP は計測のたびに9.1秒から13.5秒の幅で揺れていました。

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

メインビジュアルを初期状態から表示し、スライダーの初期化前（.slick-initialized クラスが付く前）に限って、初期化後と同じ横並びのレイアウトになる CSS を加えた状態を計測しました。初期化後は追加した指定が自動的に外れるため、最終的な見た目は変わりません。

シミュレーション結果 ​

LCP は10.1秒から1.0秒へ約9割短縮され、総合スコア は73から98へ変化する結果が得られました。計測のばらつきも、9.1〜13.5秒の幅から0.95〜1.07秒の幅へと収束しています。CSS の数行を変えただけのシミュレーションでこれだけの変化が生じたことから、スライダーの初期化を待つ表示の仕組みが、このページの LCP を決定づけるボトルネックであったことが読み取れます。

ボトルネック2: カルーセルの高さがJavaScript生成要素にしか指定されていない ​

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

観察された状況 ​

CLS の0.472は、ちょうど3回のレイアウトシフトの合計でした。そのうち97.9%は、メインビジュアル領域の高さが読み込み中に大きく変わる、1つの現象に由来していました。

メインビジュアルに並ぶ18枚の画像には width / height 属性がなく、領域の高さを決める CSS の指定も、slick が実行時に生成する .slick-slide 要素に対するものしかありませんでした。元のHTMLとCSSだけでは高さが決まらないため、領域の高さは次のように推移していました。

一度大きく膨らんで下のセクションを画面外へ押し出し、初期化とともに縮んで元の位置へ引き戻す、という2段階のずれが発生していました。

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

メインビジュアル領域の height: auto を、初期化後の実測値である height: 342px に置き換えた状態を計測しました。変更は CSS の1行だけです。この領域にはすでに overflow: hidden が指定されているため、初期化前に画像が縦に積み上がっても領域の内側に収まります。見た目の差分は0.0000%（ピクセル単位で完全一致）でした。

シミュレーション結果 ​

CLS は0.472から0.010へ、総合スコア は53から73へと変化する結果が得られました。CSS の1行で 総合スコア が20ポイント動いたことから、ライブラリが生成する要素にしかサイズの指定がないカルーセルの構造が、ページ全体のレイアウトのずれに直結していたことが読み取れます。

ボトルネック3: 埋め込みフレームが同じスクリプト12本を重複実行している ​

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

観察された状況 ​

ページ下部のレコメンド枠は、/toprecommend/ を読み込む <iframe> として埋め込まれていました。このフレーム内のHTMLは、ページ本体とまったく同じURLのスクリプト12本（jQuery、slick、Splide、1.49MBのベンダーバンドル apps.js、Bot対策スクリプトなど）を再び読み込み、再び実行していました。

計測トレースをフレーム別に集計すると、スクリプトの評価時間は本体が102.3ms、フレームが100.2msで、評価時間のちょうど半分が重複実行でした。フレームはページ最上部から約2,400px下にあり、初期表示には関わりません。

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

フレームの読み込みを、画面に近づいてから始めるように変えた状態を計測しました。なお、<iframe> に loading="lazy" を付けるだけでは、このフレームはブラウザが遅延読み込みを行う距離の内側にあったため、リクエスト数は変化しませんでした。そこで IntersectionObserver で画面との距離を監視し、近づいた時点で src を設定しています。このシミュレーションは、レコメンド枠の読み込みが後回しになることを前提として行いました。

シミュレーション結果 ​

SI は3.8秒から1.5秒へ約6割短縮され、総合スコア は100に到達する結果が得られました。改変が難しいBot対策スクリプトやベンダーバンドルも、重複実行がなくなったことで実行コストがほぼ半分になっています。画面の外にある1つの埋め込みフレームが、ページ全体の表示の進み方を大きく遅らせていたことが読み取れます。

まとめ ​

しまむらパークのトップページは、CPUの速度制限をかけない条件でも、観測時点で 総合スコア 51を記録していました。観察の結果、次のようなボトルネックが表示速度に影響していました。

• サードパーティータグ（245リソース）: 除去によって転送量が49.88MBから18.00MBへ、SI が9.3秒から4.1秒へ変化。一方で LCP と CLS はほとんど動かず、総合スコア は51から53にとどまりました。
• JavaScriptの初期化まで表示されないメインビジュアル: 初期状態から表示することで LCP が10.1秒から1.0秒へ変化。届いている画像が、スライダーの初期化を待って描画されずにいました。
• 高さが確保されていないカルーセル: CSS の1行で高さを確保することで CLS が0.472から0.010へ変化。ずれの97.9%は、ライブラリが生成する要素にしか高さを指定していない構造から生じていました。
• 埋め込みフレームでのスクリプトの重複実行: フレームの読み込みを後回しにすることで SI が3.8秒から1.5秒へ変化。スクリプトの評価時間の半分が、画面外のフレームでの重複実行でした。

この他にも、CSS と画像211件がHTMLとは別のサブドメイン（img.shop-shimamura.com）から配信されていることで接続の確立をやり直している構造が観察され、全画像を同一オリジンから配信したシミュレーションでは LCP が0.4秒から0.2秒へ短縮される結果が得られています。

一方で、fetchpriority="high" の付与、LCP 画像の preload、画面外画像への loading="lazy" といった定番とされる施策は、このページでは効果が見られないか、かえって悪化する結果になりました。このページの遅さは、描画を JavaScript に委ねた実装とサイズの決まらないレイアウトに集中しており、ボトルネックの所在はページごとに異なることが、この研究からも読み取れます。