「サマンサタバサ公式オンラインショップ」トップページの表示速度ボトルネック研究

株式会社サマンサタバサジャパンリミテッドが運営する、サマンサタバサ直営のファッション通販サイトです。Samantha Thavasa、SAMANTHAVEGA、Samantha Thavasa Petit Choice、Samantha Tiara、Samantha Thavasa GOLFなどのグループブランドのバッグ・財布・ジュエリー・アパレルを扱い、キャラクターとのコラボレーション商品も数多く展開しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア は56から100へ、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は4.9秒から0.1秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）と SI（Speed Index = ビューの視覚的な表示進捗の速さ）はいずれも3.6秒から0.1秒へと変化するシミュレーション結果が得られました。CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は、Googleの「良好」の基準である0.1を大きく超える0.385から0.000へと変化しています。TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点ですでに0msでした。

この研究では、記録した読み込みを回線の帯域制限やCPUの速度制限をかけずに再生して計測しています。Lighthouse の LCP FCP SI は記録をもとに算出した推定値で、リソースがすべて同一ドメインから低遅延で届く状態になると、HTMLの応答開始（0.1秒）より早い FCP を報告するほど楽観的な値になりました。そこで、ブラウザのトレースに記録された実際の描画時刻もあわせて示します。

実際の描画時刻でも約9割の短縮となりました。なお、帯域制限のないこの計測条件では、画像の軽量化のような「転送量を減らす」変化は時間として現れにくく、上の値には含まれていない変化もあります。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。この動画はモバイル回線相当の帯域制限をかけた条件で記録したもので、読み込み完了（onload）までの時間が約16.85秒から約0.56秒に、転送量が約3.96MBから約0.42MBに変化しています。

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

詳細レポート

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

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

オリジナルページの全333リソースのうち、サイト固有のリソースは143件（約4割）、サードパーティタグ由来のリソースは190件（約6割）を占めていました。Google Tag Manager のコンテナはトップページ本体と、非同期に読み込まれるHTML断片の2か所に別々のものが置かれていました。

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

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

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

サードパーティータグを全て除去した状態では、総合スコア は56から79へ、LCP は4.9秒から2.0秒へと変化する結果が得られました。この計測ではスコアが同じ状態でも±5ポイント程度揺らいでおり、第1〜第3段階と第5段階の変化はその範囲に収まっています。第6段階の+6も、追加計測では79 / 74 / 79と分布しており、すべてが除去の効果とは断定できません。

目を引くのは、変化のほとんどが第4段階の AccessTrade 1件に集中していた点です。Google Tag Manager 配下のタグ一式は解凍後のサイズで約18.65MBありましたが、すべて非同期で読み込まれていたため、除去してもスコアはほぼ動きませんでした。一方の AccessTrade は解凍後わずか5.0KBのスクリプトでしたが、async と defer のどちらも持たない同期スクリプトとして <head> 内に置かれ、応答開始まで約1.1秒を要していました。この1件の除去で FCP が3.7秒から2.5秒へ変化し、総合スコア が15ポイント上がっています。

<!-- head内に置かれていた同期スクリプト -->
<script src="https://h.accesstrade.net/js/nct/lp.min.js"></script>

タグの影響の大きさを決めていたのはファイルの量ではなく、HTMLのどこにどう書かれていたかでした。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

サードパーティータグの影響を排除したうえで、サイト固有のボトルネックを観察しました。本研究では全30件のボトルネック仮説を検証しました。その中から、この計測で効果が数値として確認できた3件を紹介します。

ボトルネック1: ファーストビュー画像の寸法未指定 ​

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

観察された状況 ​

トレースに記録されたレイアウトシフトはわずか2件で、その合計が CLS の0.385と完全に一致していました。2件とも原因と判定されたのは、ファーストビューに並ぶメインビジュアル画像（750×900）です。3点の <img> 要素には width と height の指定がなく、画像が届くまで高さ0のまま描画され、届いた時点で後続のブランド一覧などが一気に押し下げられていました。つまり CLS 0.385の100%が、この3点の寸法未指定に起因していたことになります。

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

メインビジュアル画像3点に、実寸の width="750" と height="900" を指定した状態を作りました。このサイトのCSSには img { max-width: 100%; } はあるものの height: auto がないため、属性だけでは画像が縦に引き伸ばされます。そのため style="width:100%;height:auto" もあわせて指定しています。

<!-- 観測時点 -->
<img src="/img/usr/top/visual/260831_top_visual_sv.jpg?260901v0" alt="...">

<!-- シミュレーション -->
<img src="/img/usr/top/visual/260831_top_visual_sv.jpg?260901v0" alt="..."
     width="750" height="900" style="width:100%;height:auto">

シミュレーション結果 ​

<img> 要素3つへの属性の追加だけで、CLS が0.385から0.000へと変化し、総合スコア が16ポイント上がる結果が得られました。サイト固有のボトルネックの中で、スコアを最も大きく動かしたのはこの寸法未指定です。なお、同じ計測で LCP と FCP は約0.4秒遅くなっていますが、この計測環境の揺らぎ（約±0.65秒）の範囲内でした。

ボトルネック2: 公開CDN3ドメインへの接続待ち ​

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

観察された状況 ​

このページは、jQuery UI、slick（カルーセル）、Font Awesome（アイコンフォント）を、3つの公開CDNから合計9件のリソースとして読み込んでいました。

これらのドメインへの最初のリクエストは応答開始まで0.57〜0.62秒かかっており、自社ドメインの静的ファイル（0.02〜0.05秒）の10倍以上でした。同じドメインへの2本目以降のリクエストが速いことから、その大半はDNSルックアップとTCP/TLS接続の確立にかかる時間と見られます。トレースを見ると、自社のリソースはすべて届いていたにもかかわらず、HTMLパーサーは公開CDNとの接続を待って約0.63秒、何もせずに止まっていました。

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

公開CDNから読み込んでいたCSS、JavaScript、フォントを、HTMLと同じ www.samantha.co.jp から配信する状態を作りました。CSSだけを移した段階（CSSの差分コミット）と、JavaScriptとフォントも移した段階の2段階で計測しています。

シミュレーション結果 ​

CSSだけを移した段階では、最初の描画は約0.01秒しか変わりませんでした。ajax.googleapis.com と cdnjs.cloudflare.com はCSSとJavaScriptの両方を配信していたため、CSSを移してもJavaScriptの取得で同じ接続待ちが発生していたためです。JavaScriptとフォントも移した段階で、トレース上の最初の描画と主要コンテンツの描画がそろって約0.6秒早まりました。この短縮幅は、事前に見積もった接続確立の時間とほぼ一致しています。2段階を通じて、Lighthouse の 総合スコア は98から100へ変化しました。別ドメインとの接続確立が、このページの最初の描画を待たせていたことが読み取れます。

ボトルネック3: 約1秒かかるHTMLのサーバー応答 ​

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

観察された状況 ​

HTML本体の応答開始（TTFB）までに約0.99秒かかっていました。自社の静的ファイルの応答開始が0.02〜0.05秒であることと比べると、この時間はネットワークの遅延ではなく、サーバー側でページを生成する処理の時間と考えられます。.aspx という拡張子から、リクエストのたびにHTMLを動的に生成しているページです。フロントエンド側のボトルネックを順に解消していった後も、最初の描画までの時間の大半を、このHTMLの応答待ちが占めていました。

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

HTML本体の応答開始を、一般的な目標値である0.1秒に短縮した状態を作りました。フロントエンドの変更だけでは実現できない、サーバー側の応答が速くなった場合を想定したシミュレーションです。

シミュレーション結果 ​

この時点の Lighthouse の 総合スコア はすでに100となり、推定値も実態を反映しなくなっていたため、トレース上の実測値で比較しています。TTFB の短縮幅とほぼ同じだけ、最初の描画、主要コンテンツの描画、表示の進み具合がそろって早まりました。フロントエンド側のボトルネックをすべて解消した状態でも、このHTMLの応答待ちが残る限り、最初の描画は1秒を切れなかったことになります。サイト固有のボトルネックの中では、このサーバー応答による変化が最大であったと読み取れます。

まとめ ​

サマンサタバサ公式オンラインショップのトップページでは、観測時点の 総合スコア が56でした。順に解消シミュレーションを行うと、性質の異なるボトルネックが重なっていたことが見えてきました。

• サードパーティータグ（190リソース）: 除去によって 総合スコア が56から79へ変化しました。その大半は、<head> 内に同期スクリプトとして置かれた5.0KBの AccessTrade 1件によるもので、18.65MBあった Google Tag Manager 配下のタグ一式はスコアをほとんど動かしませんでした。
• ファーストビュー画像の寸法未指定: 3点の <img> 要素への寸法の指定で、CLS が0.385から0.000へ、総合スコア が79から95へ変化しました。
• 公開CDN3ドメインへの接続待ち: 同一ドメインからの配信によって、トレース上の最初の描画が約0.6秒早まりました。
• 約1秒かかるHTMLのサーバー応答: 応答開始を0.1秒にしたシミュレーションで、最初の描画と主要コンテンツの描画がそれぞれ約0.9秒早まりました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は56から100へ、トレース上の主要コンテンツの描画は2.3秒から0.2秒へと変化しました。このページでは、ファイルの大きさよりも、描画を止める同期スクリプト、別ドメインとの接続確立、サーバーの応答といった「待ち時間」が表示速度を左右していたことが、この研究から確認できます。