「ゲオオンラインストア」トップページの表示速度ボトルネック研究
jQueryなどを公開CDNから読み込む描画ブロックリソース、head内の同期スクリプト、商品カルーセルの一括初期化などのボトルネックが観測され、解消シミュレーションではLighthouseスコアが96から最大100まで変化する結果が得られました。Core Web Vitalsの若干の改善が期待できます。
詳細レポート 
ボトルネック一覧 
差分リポジトリ この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
株式会社ゲオストアが運営する、ゲオの公式通販サイトです。新品家電や中古スマートフォン・タブレット、中古ゲーム、中古パソコンなどを幅広く取り扱い、「赤ロム永久保証」や一定金額以上の購入での送料無料といったサービスを打ち出しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。
| 観測時点 | 解消シミュレーション後 |
|---|---|
 |  |
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 96 | 100 | +4 |
LCP | 1.7秒 | 0.1秒 | -1.6秒 |
FCP | 1.6秒 | 0.1秒 | -1.5秒 |
SI | 4.8秒 | 0.9秒 | -3.9秒 |
TBT | 24ms | 0ms | -24ms |
CLS | 0.001 | 0.000 | -0.001 |
観測時点の 総合スコア は96と、もともと良好な水準でした。それでも SI（Speed Index = ビューの視覚的な表示進捗の速さ）が4.8秒から0.9秒へ、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が1.7秒から0.1秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が1.6秒から0.1秒へと変化するシミュレーション結果が得られました。TBT（Total Blocking Time = メインスレッドのブロック時間）と CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は、観測時点ですでに小さな値でした。
なお、Lighthouse の LCP と FCP は、記録した読み込みをもとに算出したシミュレーション値です。読み込みの記録（トレース）上の実際の描画時刻は約1.96秒から約1.62秒への変化で、その大半を占めていたのはHTML自体のサーバー応答時間（TTFB、約1.55秒）でした。HTMLが届いてから描画されるまでの時間は約0.4秒から約0.07秒まで縮んでおり、フロントエンド側の要因はほぼ解消された状態で、残る時間のほとんどがサーバー側で占められていることが読み取れます。
読み込みプロセスの変化を動画で体験
観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも違いが見て取れます。CPUを4倍遅くし、回線速度を約10Mbpsに制限した条件で記録したこの動画では、読み込み完了（onload）までの時間が約11.5秒から約2.0秒に、転送量が約2.66MBから約0.64MBに変化しています。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。
オリジナルページの全402リソースのうち、サイト固有のリソースは143件（約4割）、サードパーティタグ由来のリソースは259件（約6割）を占めていました。HTMLに直接書かれていたタグは3つだけでしたが、Google Tag Manager の中から多数のタグが読み込まれ、さらにその一部が別のタグを連鎖的に読み込んでいました。
HTMLから直接読み込まれているタグ
| タグ名 | 種別 |
|---|---|
Google Tag Manager | タグマネージャー |
Akamai Bot Manager | ボット対策 |
ZETA RECOMMEND | レコメンド |
GTM経由で読み込まれているタグ
| タグ名 | 種別 |
|---|---|
GA4（3プロパティ） | アクセス解析 |
Google Ads（7アカウント） | 広告計測 |
CHEQ | 広告の不正クリック対策 |
Microsoft UET（CHEQ から連鎖） | 広告計測 |
Microsoft Clarity（Microsoft UET から連鎖） | ヒートマップ・行動解析 |
Meta Pixel | 広告計測 |
TikTok Pixel | 広告計測 |
Treasure Data | データ収集 |
X広告 | 広告計測 |
Yahoo!広告 | 広告計測 |
Mouseflow | ヒートマップ・行動解析 |
ミエルカヒートマップ | ヒートマップ |
除去シミュレーションの結果
| 段階 | 除去内容 | 総合スコア | LCP | FCP | SI | TBT |
|---|---|---|---|---|---|---|
| 観測時点 | - | 96 | 1.7秒 | 1.6秒 | 4.8秒 | 24ms |
| 第1段階 | CHEQ / Microsoft UET / Microsoft Clarity（16リソース） | 96 | 1.8秒 | 1.8秒 | 4.3秒 | 0ms |
| 第2段階 | Meta Pixel（17リソース） | 96 | 1.8秒 | 1.8秒 | 4.1秒 | 0ms |
| 第3段階 | TikTok Pixel（35リソース） | 96 | 1.8秒 | 1.8秒 | 4.3秒 | 0ms |
| 第4段階 | Google Tag Manager と配下のタグ一式（185リソース） | 100 | 1.2秒 | 1.1秒 | 1.8秒 | 0ms |
| 第5段階 | Akamai Bot Manager / ZETA RECOMMEND | 99 | 1.6秒 | 1.6秒 | 1.8秒 | 0ms |
サードパーティータグを全て除去した状態では、総合スコア は96から99へ、SI は4.8秒から1.8秒へ、TBT は24msから0msへと変化する結果が得られました。ページ内で唯一のロングタスク（98ms）は CHEQ のスクリプトによるもので、Google Tag Manager とその配下のタグだけでメインスレッド約300ms・転送量約1.2MBが消費されていました。この計測では LCP と FCP が同じ状態でも±0.4秒程度揺らいでおり、第4段階の値は特に良い回が出たものです。確実に読み取れるのは、「最初の描画」よりも「描画が完了するまでの過程」への影響、つまり SI の大幅な短縮です。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を排除したうえで、サイト固有のボトルネックを観察しました。本研究では全28件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
ボトルネック1: 公開CDNから配信される描画ブロックリソース
観察された状況
<head> 内で描画をブロックする jQuery 3.2.1、jQuery UI 1.13.2（JavaScriptとテーマCSS）が公開CDN（code.jquery.com）から、SwiperのCSSとJavaScriptが別の公開CDN（cdn.jsdelivr.net）から配信されていました。別ドメインのリソースは、DNSルックアップとTCP/TLS接続が追加で必要になります。トレースを見ると、自社ドメインのCSSとJavaScriptはHTML受信から約110ms後にはすべて届いていたにもかかわらず、HTMLパーサーは公開CDNからのjQueryの到着を待って約160ms停止していました。
解消シミュレーションの方法
公開CDNから読み込んでいた5つのリソースを、HTMLと同じ ec.geo-online.co.jp から配信する状態を作りました。jQuery・jQuery UIと、Swiperの2段階に分けて計測しています（Swiperの差分コミット）。
<!-- 観測時点 -->
<script src="https://code.jquery.com/jquery-3.2.1.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/swiper@12/swiper-bundle.min.js"></script>
<!-- シミュレーション -->
<script src="https://ec.geo-online.co.jp/cdn/code.jquery.com/jquery-3.2.1.min.js"></script>
<script src="https://ec.geo-online.co.jp/cdn/cdn.jsdelivr.net/npm/swiper@12/swiper-bundle.min.js"></script>シミュレーション結果
| 指標 | 解消前 | jQuery・jQuery UIの移管後 | Swiperの移管後 | 変化量 |
|---|---|---|---|---|
LCP | 1.4秒 | 0.3秒 | 0.1秒 | -1.3秒 |
FCP | 1.4秒 | 0.3秒 | 0.1秒 | -1.3秒 |
SI | 1.7秒 | 1.1秒 | 1.1秒 | -0.6秒 |
FCP が1.4秒から0.1秒へと、サイト固有のボトルネックの中で最も大きな変化が観測されました。Lighthouse のシミュレーションは描画前に必要な別ドメインへの接続を大きなコストとして見積もるため、その影響が強く表れています。トレース上の実際の描画時刻も、2つの公開CDNがともに同一ドメインになった時点で約1.92秒から約1.80秒へと約0.1秒早まりました。描画ブロックリソースが別ドメインにあることが、このページの最初の描画を待たせていたことが読み取れます。
ボトルネック2: head内の同期スクリプト
観察された状況
<head> 内と本文の途中に、jQuery（3.2.1と2.1.1）、jQuery UI、各種プラグイン、自社スクリプト、Swiperなどの同期スクリプトが並んでいました。HTMLパーサーは同期スクリプトに出会うと、そのダウンロードと実行が終わるまで後続のHTMLを解析しないため、本文の解析と最初の描画が後回しになっていました。
解消シミュレーションの方法
<script> 要素26個（外部16個・インライン10個）を、元の順序を保ったまま </body> の直前に移動した状態を作りました。スクリプト同士の実行順は変わりません。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
FCP | 0.09秒 | 0.07秒 | -0.02秒 |
SI | 1.1秒 | 1.0秒 | -0.1秒 |
| 実際の描画時刻（トレース） | 約1.80秒 | 約1.70秒 | 約-0.1秒 |
| HTML受信から描画まで（トレース） | 約0.25秒 | 約0.15秒 | 約-0.1秒 |
Lighthouse の FCP はすでに下限付近に達していたため、変化はわずかでした。一方、トレース上の実際の描画時刻は約0.1秒早まり、HTMLが届いてから描画されるまでの時間は約0.25秒から約0.15秒に縮みました。十数本の同期スクリプトの取得と実行を待つ時間が、実際の表示を遅らせていたことが読み取れます。
ボトルネック3: 商品カルーセル8個の一括初期化
観察された状況
jQueryの ready（DOMContentLoaded）には9ファイル・30個の処理が登録され、1つのタスクで連続して実行されていました。その中で重い処理の1つが、ページ内の8つの商品カルーセル（31スライド）をSwiperでまとめて初期化する initialSwiper() でした。Lighthouse の標準的な計測では TBT は0msでしたが、CPUを4倍遅くした条件では、この処理を含むタスクが50msを超えるロングタスクとして現れていました。
解消シミュレーションの方法
カルーセルの初期化を setTimeout で1つずつ別タスクに分けた状態を作りました（Swiperのオプションは変更なし）。直前に、メインスライダー（slick）の初期化も同じ方法で分離しています。このため、カルーセルの初期化はわずかに後ろへずれます。
シミュレーション結果
| 観測項目 | 解消前 | 解消後 |
|---|---|---|
DOMContentLoaded のタスク（トレース） | 14.0ms | 6.8ms |
CPU 4倍条件の DOMContentLoaded 付近のロングタスク（3回計測） | 56 / 89 / 90ms | なし / なし / なし |
CPU 4倍条件の TBT 概算（3回計測） | 6 / 39 / 40ms | 0 / 0 / 0ms |
DOMContentLoaded のタスクが半分以下になり、CPUを4倍遅くした条件で DOMContentLoaded 付近に発生していたロングタスクは3回とも観測されなくなりました。標準的な計測では表に出ないものの、処理能力の低い端末では、読み込み直後の一括初期化がメインスレッドをふさぐ要因になっていたことが、このシミュレーション結果から読み取れます。
まとめ
ゲオオンラインストアのトップページは、観測時点で 総合スコア 96という良好な値でした。そのうえで順に解消シミュレーションを行うと、スコアの陰に隠れていたボトルネックと、それぞれの影響の大きさが見えてきました。
- サードパーティータグ（259リソース）: 除去によって
SIが4.8秒から1.8秒へ短縮し、唯一のロングタスクも消えました。Google Tag Managerの配下には、HTMLを見ただけでは分からない数のタグが動いていました。 - 公開CDNから配信される描画ブロックリソース: 同一ドメインへの移管によって
FCPが1.4秒から0.1秒へ変化し、実際の描画時刻も約0.1秒早まりました。 - head内の同期スクリプト:
</body>直前への移動によって、HTML受信から描画までの時間が約0.25秒から約0.15秒に縮みました。 - 商品カルーセル8個の一括初期化: 初期化の分割によって、CPUを4倍遅くした条件での
DOMContentLoaded付近のロングタスクが観測されなくなりました。
全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は96から100へ、SI は4.8秒から0.9秒へと変化しました。一方で、実際の描画時刻の約96%はHTMLのサーバー応答時間（約1.55秒）が占めており、フロントエンドの変更では動かせないこの部分が、このページの表示速度に残る最大の要因であることも、この研究から確認できます。
この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
