「ABC-MARTオンラインストア」トップページの表示速度ボトルネック研究
JPEG/PNGのままの画像150件、アイコン数個のために描画を止めるアイコンフォントのCSS、head内の同期スクリプトなどのボトルネックが観測されました。Lighthouseスコアは99から100への変化でしたが、SIは3.3秒から0.2秒へ短縮し、Core Web Vitalsの改善余地が読み取れます。
この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。
株式会社エービーシー・マートが運営する、靴の公式通販サイトです。ABCマート限定販売のスニーカーや人気ブランドのシューズをはじめ、ブーツ・サンダル・ビジネスシューズ・パンプス・キッズシューズまで幅広く扱い、ABC-MART GRAND STAGEなどの業態の特集も掲載しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。
Core Web Vitalsにつながる指標の改善ポテンシャル
観測されたボトルネックを仮に解消した場合、Lighthouse の指標は以下のような変化を示しました。
| 指標 | 観測時点 | 解消シミュレーション後 | 変化量 |
|---|---|---|---|
総合スコア | 99 | 100 | +1 |
LCP | 0.4秒 | 0.1秒 | -0.3秒 |
FCP | 0.4秒 | 0.1秒 | -0.3秒 |
SI | 3.3秒 | 0.2秒 | -3.1秒 |
TBT | 0ms | 0ms | 変化なし |
CLS | 0.014 | 0.000 | -0.014 |
| 観測時点 | 解消シミュレーション後 |
|---|---|
![]() | ![]() |
このサイトは、観測時点で 総合スコア が既に99に達していました。SI(Speed Index = ビューの視覚的な表示進捗の速さ)は3.3秒から0.2秒へ大きく変化したものの、LCP(Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間)と FCP(First Contentful Paint = 最初のコンテンツが表示されるまでの時間)は観測時点から0.4秒と短く、スコアの上では差がほとんど表れません。
本研究の Lighthouse は、記録した通信を再生する環境で、CPUの速度低下を行わない条件で計測しています。実際のモバイル回線よりも通信条件が良いため、TBT(Total Blocking Time = メインスレッドのブロック時間)は全工程を通じて0msでした。また、解消シミュレーション後の LCP・FCP の0.1秒は、HTMLのサーバー応答時間(約0.26秒)すら下回る推定値です。そこで本研究では、計測中にブラウザが実際に描画した時刻(以下、実測値)や転送量もあわせて観測しました。実測値は1秒未満の差が中心になるため、小数点第2位まで記載します。
観測時点の LCP 0.4秒にも注意が必要です。この時点で LCP と判定されていたのはヘッダーのバナーのテキストで、メインビジュアルのカルーセル画像は LCP の候補として記録されていませんでした。サードパーティータグを除去した段階で判定の対象がカルーセル画像に変わったため、実測の FCP・LCP は、タグを除去した時点を起点として比較します。
| 指標(実測値・物理量) | 観測時点 | タグ除去後(起点) | 解消シミュレーション後 |
|---|---|---|---|
実測 FCP | - | 0.49秒 | 0.34秒 |
実測 LCP | 0.49秒(ヘッダーのテキスト) | 0.76秒 | 0.35秒 |
| 総転送量 | 18.81MB | 13.24MB | 0.93MB |
カルーセル画像の実測 LCP は、タグ除去後の0.76秒から0.35秒へ短縮し、総転送量は観測時点の18.81MBから0.93MBへと約95%減る結果が得られました。CLS(Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ)も0.014から0へ変化しています。スコアが99であっても、表示の完了までの時間と転送量にはボトルネックが潜んでいたことを、このサイトの研究結果は示しています。
読み込みプロセスの変化を動画で体験
観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。この動画は Lighthouse の計測とは異なり、回線速度を約10Mbps、CPUを4倍遅くした条件で撮影しています。カルーセルは自動で切り替わるため、左右で表示中の画像は異なる場面があります。
| 動画の計測条件での値 | 観測時点 | 解消シミュレーション後 |
|---|---|---|
| 転送量 | 13.70MB | 1.03MB |
DOMContentLoaded | 1.64秒 | 0.72秒 |
読み込み完了(load イベント) | 11.58秒 | 1.14秒 |
観測時点ではカルーセル画像が表示されるまで白い領域が残り、ページ下部の画像も遅れて表示されます。解消シミュレーション後はファーストビューがほぼ一度に描画され、約1.1秒で読み込みが完了しました。
サードパーティータグの影響
本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的でないものの、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。
本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全538リソースのうち、サイト固有のリソースは236件(約4割)、サードパーティタグ由来のリソースは302件(約6割)でした。
HTMLから直接読み込まれているタグ
| タグ名 | 種別 |
|---|---|
visumo | スタッフコーディネート(UGC)ウィジェット |
ReviCo | レビュー用タグマネージャー(独自のjQueryを追加読み込み) |
NaviPlus | レコメンド・検索サジェスト(同期スクリプト) |
MessagingService | メッセージ配信(同期スクリプト) |
Yahoo!タグマネージャー | タグマネージャー(記録時の応答本文は0バイト) |
Dynalyst | リターゲティング広告(設定のスニペットのみ) |
Google Tag Manager(GTM-TJVGXZW) | タグマネージャー |
Google Tag Manager(GTM-KV38N7) | タグマネージャー(2つ目のコンテナ) |
Google Tag Manager経由で読み込まれているタグ
| タグ名 | 種別 | 経由したコンテナ |
|---|---|---|
Google Analytics 4 | アクセス解析 | GTM-TJVGXZW・GTM-KV38N7 |
Logicad | 広告 | GTM-TJVGXZW |
Universal Analytics | アクセス解析 | GTM-KV38N7 |
Google Ads | 広告 | GTM-KV38N7 |
Facebook Pixel | 広告計測 | GTM-KV38N7 |
TikTok | 広告計測 | GTM-KV38N7 |
X広告 | 広告計測 | GTM-KV38N7 |
Microsoft広告・Microsoft Clarity | 広告・アクセス解析 | GTM-KV38N7 |
ミエルカ | アクセス解析 | GTM-KV38N7 |
Criteo | 広告(多数の広告SSPとの同期を含む) | GTM-KV38N7 |
LINE Tag | 広告計測 | GTM-KV38N7 |
Yahoo!広告 | 広告 | GTM-KV38N7 |
SmartNews | 広告 | GTM-KV38N7 |
メルカリ広告 | 広告 | GTM-KV38N7 |
RTB House ほか | 広告 | GTM-KV38N7 |
GTM-KV38N7の配下だけで、83ホスト・223件のリクエストが発生していました。
除去シミュレーションの結果
段階的に除去した際の指標変化は次のとおりです。FCP は全段階で0.4秒でした。
| 除去段階 | 総合スコア | LCP | SI | CLS |
|---|---|---|---|---|
| 観測時点(タグあり) | 99 | 0.4秒 | 3.3秒 | 0.014 |
visumo 除去 | 94 | 3.0秒 | 2.9秒 | 0.014 |
ReviCo 除去 | 86 | 4.2秒 | 2.0秒 | 0.014 |
NaviPlus 除去 | 83 | 4.6秒 | 2.0秒 | 0.014 |
MessagingService 除去 | 97 | 2.6秒 | 1.7秒 | 0.006 |
Yahoo!タグマネージャー 除去 | 99 | 2.2秒 | 1.7秒 | 0.006 |
Dynalyst 除去 | 98 | 2.4秒 | 1.7秒 | 0.006 |
| GTM-TJVGXZW 除去 | 96 | 2.7秒 | 1.7秒 | 0.006 |
| GTM-KV38N7 除去 | 95 | 3.0秒 | 0.8秒 | 0.006 |
最初の visumo の除去で LCP が0.4秒から3.0秒へ、総合スコア が99から94へ変化しているのは、表示が遅くなったためではありません。観測時点では、visumo の非同期スクリプトが DOMContentLoaded を遅らせていたため、カルーセルの初期化より先に画像の読み込みが終わり、画像が LCP の候補として記録されていませんでした。visumo を除去すると初期化が先に行われ、本来の LCP 要素であるカルーセル画像が正しく判定されました。見た目は除去の前後で同一(スクリーンショットの差分0%)です。この段階以降、LCP のシミュレーション値は同じ状態でも約2.2〜5.9秒の範囲で揺らいでおり、スコアの上下はタグの影響よりも計測の揺らぎを表しています。
一方、SI は段階を追って下がりました。ReviCo の除去では2.9秒から2.0秒へ、MessagingService の除去では、<body> 末尾にあった別ドメインの同期スクリプトがなくなり、実測の DOMContentLoaded が約0.18秒早まりました。最後のGTM-KV38N7の除去では、SI が1.7秒から0.8秒へ、読み込み完了(load イベント)が3.94秒から0.84秒へ変化しています。
サードパーティータグを全て除去した状態では、SI は3.3秒から0.8秒へ、リクエスト数は536件から236件へ、総転送量は18.81MBから13.24MB(約-5.6MB)へと変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。
サイト固有のボトルネック
サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究ではサードパーティータグを含む全47件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。
工程の後半では 総合スコア が100のまま動かなかったため、各ボトルネックの影響は、前後を3回以上計測した中央値の実測値と、転送量などの物理量の変化で観測しています。
ボトルネック1: JPEG/PNGのまま配信される画像
観察された状況
ページの画像150件はすべてJPEGかPNGで配信されており、WebPやAVIFは1件もありませんでした。合計は約10.8MBで、Lighthouse の「次世代フォーマットでの画像の配信」の削減見込みは4,828KiBに上っていました。LCP 要素であるカルーセル先頭の画像も、750×1060pxのJPEG(約222KB)です。
画像の中身を調べると、拡張子は .jpg なのに Content-Type: image/png で配信され、中身はJPEGという画像が73件ありました。拡張子やContent-Typeだけでは、画像の実態がつかめない状態になっていました。
解消シミュレーションの方法
ファイル先頭のバイト列から画像の実際の形式を判定したうえで、150件をWebPに変換した状態を作りました。写真は非可逆(品質75)、透過を含む写真調のPNGは非可逆にアルファを可逆で組み合わせ、アイコン・ロゴ・文字のPNGは可逆で変換しています。画像のURLとHTMLは変えていません。見た目の差は検出されませんでした。
シミュレーション結果
| 指標 | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
| 画像150件の合計容量 | 10.82MB | 4.23MB | -61% |
LCP 画像の容量 | 約222KB | 約26KB | -88% |
LCP 画像の受信にかかった時間 | 約52ms | 約5ms | -47ms |
Lighthouse の総転送量 | 11,178KiB | 5,689KiB | -49% |
LCP(シミュレーション値・中央値) | 0.5秒 | 0.3秒 | -0.2秒 |
実測 LCP(中央値) | 0.57秒 | 0.53秒 | -0.04秒 |
LCP のシミュレーション値は0.5秒から0.3秒へ短縮し、ページの総転送量はほぼ半分になる結果が得られました。実測の LCP の変化は0.04秒にとどまったものの、この計測環境は実際のモバイル回線より通信条件が良く、画像の容量の差が表れにくい構造です。帯域の限られた回線では、約6.6MBの差がより大きく表れると考えられます。
このシミュレーション結果から、JPEG/PNGのまま配信される画像が、サイト固有のボトルネックの中でも特に大きな影響を持っていたことが読み取れます。
ボトルネック2: アイコン数個のために描画を止めるアイコンフォントのCSS
観察された状況
<head> では、アイコンフォント FontAwesome のCSSがレンダリングをブロックするリソース(読み込みが完了するまでページの描画が停止するリソース)として読み込まれていました。このCSSは公開CDN(maxcdn.bootstrapcdn.com)から配信されており、本研究ではその前の工程で同一ドメインからの配信に置き換えています。それでも、画像に関するボトルネックの解消シミュレーションに加え、画像CDN(img.abc-mart.net)のキャッシュヒットをサーバー側の設定として想定したシミュレーション(実測 LCP 約-0.05秒)も行った時点で、実測 LCP 0.47秒の内訳は次のようになっていました。
| 区間 | 時間 | 割合 |
|---|---|---|
| HTMLのサーバー応答待ち | 約0.26秒 | 56% |
HTMLの受信と FontAwesome のCSSの到着待ち | 約0.13秒 | 28% |
| 同期スクリプトの実行、HTMLの解析とレイアウト | 約0.03秒 | 6% |
| カルーセルの初期化、画像のデコードと描画 | 約0.05秒 | 10% |
実測 LCP | 0.47秒 | - |
この時点で LCP 画像自体は最初の描画より前に届いており、最初の描画の時刻を決めていたのは、約0.39秒の時点で届く FontAwesome のCSSでした。一方、ページの中で使われていたアイコンは、フッターのSNSアイコン3つと「›」形の矢印だけでした。
解消シミュレーションの方法
FontAwesome の <link> を削除し、SNSアイコンは同じ形のパスを使ったインラインSVGに、矢印はCSSマスクに置き換えました。大きさと色は従来どおり親要素の font-size・color を引き継いでおり、スクリーンショットの比較での差分は0.04%未満でした。
シミュレーション結果
| 指標(中央値) | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
実測 FCP | 0.42秒 | 0.37秒 | -0.05秒 |
実測 LCP | 0.47秒 | 0.42秒 | -0.05秒 |
実測 SI | 0.46秒 | 0.41秒 | -0.05秒 |
実測の FCP・LCP・SI がそろって約0.05秒短縮する結果が得られました。3回の計測すべてで、解消前より小さい値でした。Lighthouse の LCP・FCP のシミュレーション値は解消前から0.1秒前後で、この変化はほとんど表れていません。
アイコン数個の表示のために読み込まれていたCSSが、ページ全体の最初の描画を待たせていたことが、このシミュレーション結果から読み取れます。
ボトルネック3: head内の同期スクリプト
観察された状況
<head> では、jQuery、jQuery Migrate、slick、Swiper、tile、common、smartpn、user_spの8本のスクリプトが同期的に読み込まれ、HTMLの解析と最初の描画を止めていました。
本研究では、このボトルネックの解消シミュレーションを FCP と LCP の調査の段階でも行っていましたが、いずれも実測値に変化が表れず、採用を見送っていました。当時は FontAwesome のCSSの到着が最初の描画の時刻を決めており、スクリプトの待ちはその陰に隠れていたためです。
解消シミュレーションの方法
ボトルネック2の解消シミュレーションを終えた状態で、すべての <script> 要素(外部ファイル11本とインラインスクリプトを合わせて19要素)を、出現順を保ったまま </body> の直前へ移動しました。外部スクリプト11本はすべてjQuery本体か、jQueryや他のスクリプトから使われるライブラリだったため、async 属性の付与は行っていません。このシミュレーションは、スクリプトの実行タイミングが変わることを前提に行いました。
シミュレーション結果
| 指標(中央値) | 解消前 | 解消後 | 変化量 |
|---|---|---|---|
実測 FCP | 0.37秒 | 0.35秒 | -0.02秒 |
実測 LCP | 0.42秒 | 0.35秒 | -0.07秒 |
実測 SI | 0.41秒 | 0.36秒 | -0.05秒 |
実測の LCP は0.42秒から0.35秒へ短縮し、3回中2回の計測で、カルーセル画像が最初の描画と同時に表示される結果が得られました。Lighthouse の LCP のシミュレーション値はかえって93msから121msへ増えましたが、これは Lighthouse の推定で、LCP 画像の読み込みが末尾へ移したスクリプトの後に回されるためで、実測値と 総合スコア は悪化していません。
最初の描画の前に複数の待ちが重なっており、手前の待ちを取り除いて初めて次の待ちの影響が観測される構造を、このシミュレーション結果は示しています。
まとめ
ABC-MARTオンラインストアのトップページを観測したところ、総合スコア は99、TBT は0msと、Lighthouse の上では既に良好な値が計測されていました。一方、観測時点の LCP はヘッダーのテキストを対象に判定されており、本来の LCP 要素であるカルーセル画像の表示や、SI 3.3秒、総転送量18.81MBには、スコアに表れないボトルネックが残っていました。
観測されたボトルネックとその影響は次のように整理できます。
- サードパーティータグ(302リソース): 除去によって
SIが3.3秒から0.8秒へ、リクエスト数が536件から236件へ、総転送量が約5.6MB減少しました。最後に残ったGTMコンテナの除去だけで、読み込み完了が3.94秒から0.84秒へ変化しています。 - JPEG/PNGのまま配信される画像: 150件のWebPへの変換で画像の合計容量が10.82MBから4.23MBへ減り、
LCPのシミュレーション値が0.5秒から0.3秒へ短縮しました。サイト固有のボトルネックの中で最も大きな影響が観測されました。 - アイコン数個のために描画を止めるアイコンフォントのCSS: CSSをなくすと、実測の
FCP・LCP・SIがそろって約0.05秒短縮しました。 - head内の同期スクリプト: アイコンフォントのCSSをなくした後で初めて影響が表れ、実測の
LCPが0.42秒から0.35秒へ変化しました。
全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は99から100へ、SI は3.3秒から0.2秒へ、カルーセル画像の実測 LCP はタグ除去後の0.76秒から0.35秒へ、総転送量は18.81MBから0.93MBへと変化しています。なお、この最終値には、サーバー側の設定を想定したシミュレーション2件(画像CDNのキャッシュヒット、RSSフィードの件数削減)の効果も含まれています。
全ての解消シミュレーションを終えた後も、HTMLのサーバー応答時間(約0.26秒)が実測 FCP 0.34秒の約4分の3を占めていました。HTMLの応答時間の短縮にはサーバー側の改修が必要で、本研究ではシミュレーションしていませんが、このサイトに残る最大のボトルネックとして観測されています。
この研究は自主的に実施したものであり、サイト関係者からの依頼によるものではありません。掲載の取り下げを希望される場合はお問い合わせください。

