「ゲオオンラインストア」トップページの表示速度ボトルネック研究

株式会社ゲオストアが運営する、ゲオの公式通販サイトです。新品家電や中古スマートフォン・タブレット、中古ゲーム、中古パソコンなどを幅広く取り扱い、「赤ロム永久保証」や一定金額以上の購入での送料無料といったサービスを打ち出しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は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から直接読み込まれているタグ ​

GTM経由で読み込まれているタグ ​

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

サードパーティータグを全て除去した状態では、総合スコア は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>

シミュレーション結果 ​

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> の直前に移動した状態を作りました。スクリプト同士の実行順は変わりません。

シミュレーション結果 ​

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 のタスクが半分以下になり、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秒）が占めており、フロントエンドの変更では動かせないこの部分が、このページの表示速度に残る最大の要因であることも、この研究から確認できます。