「サンプル百貨店」トップページの表示速度ボトルネック研究

株式会社オールアバウトライフマーケティングが運営する、話題の商品を税込・送料込でお試しできる日本最大級のお試しサービスです。食品、飲料、お菓子、日用品、化粧品、ファッション、雑貨などを幅広く取り扱い、累計利用者は420万人を超えています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

観測時点	全ボトルネック解消シミュレーション後

総合スコア が65から100へと35ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が14.8秒から0.3秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が11.1秒から0.8秒へと大きく変化しています。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も1.6秒から0.1秒へ短縮されました。

TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から11msと小さく、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）も0.000でした。ただし観測時点の CLS が0.000だったのは、A/Bテストタグがページ全体を最大2秒間 opacity: 0 で隠していたためです。不可視の要素のずれは CLS に計上されないため、タグを除去した時点で隠れていた0.098のずれが表面化しました。解消シミュレーション後の0.000は、このずれを解消したうえでの値です。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。ファーストビューの見た目は、前後でほぼ変わっていません。

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

詳細レポート

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

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

オリジナルページの全617リソースのうち、サイト固有のリソースは403件（約65%）、サードパーティタグ由来のリソースは214件（約35%）を占めていました。実際に読み込まれたリクエストで見ると、サードパーティタグは121リクエスト・約2.1MBの通信を発生させていました。

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

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

1つ目のタグマネージャー（GTM-MM2DCG）の配下には、上記を含む11系統のタグが含まれていました。広告タグ一式は入札処理を通じて60ドメインへの通信を発生させていました。また LINE Tag のサーバー応答には11.97秒かかっており、load イベントを14秒以上遅らせる要因になっていました。

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

CLS の増減は、タグが隠していたサイト側の動的コンテンツのずれが計測ごとに揺れているもので、タグ自体の影響ではありません。

サードパーティータグを全て除去した状態では、総合スコア は65から70へ、SI は11.1秒から4.4秒へ、TBT は11msから0msへ変化する結果が得られました。特に1つ目のタグマネージャー（GTM-MM2DCG）の除去だけで SI が8.5秒短縮しており、長時間応答するサードパーティー通信がページの視覚的な完成を大きく遅らせていたことが読み取れます。一方で LCP は12秒台のまま残っており、LCP の遅れの主因はサイト側にあることも同時に分かります。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: カルーセル画像の遅延読み込みが機能していない ​

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

観察された状況 ​

トップページのカルーセル3本には456枚のスライドがあり、すべての画像が <img class="swiper-lazy" src="..."> の形で記述されていました。JavaScript側ではスライダーライブラリの Swiper を遅延読み込み有効で初期化していますが、Swiper の遅延読み込みは data-src 属性を参照する仕様です。src 属性に実URLが書かれているため、JavaScriptが動き出す前にブラウザの先読み機能が456枚すべてを取得してしまい、遅延読み込みの設定が完全に空振りしている状態でした。

しかも、JavaScriptは日付を比較して期間外のスライドを削除するため、実際に表示されるのは456枚中24枚だけです。この時点の LCP の内訳を見ると、HTML受信から LCP 画像のリクエスト開始までの待ち時間（Load Delay）が6.1秒と全体の76%を占めていました。LCP 画像自体は133KBと特別に重いわけではなく、大量の画像が先に一斉ダウンロードされて帯域と接続を奪っていたことが遅れの原因でした。

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

454枚の画像の src / srcset 属性を data-src / data-srcset に書き換え、Swiper の遅延読み込みが本来の仕様どおりに機能する状態を作りました。LCP 対象の画像2要素のみ src のまま残しています。

シミュレーション結果 ​

本研究で最も大きな影響が観測されたボトルネックです。属性名を書き換えただけで LCP が8.1秒から1.1秒へ87%短縮し、総合スコア は100に到達する結果が得られました。ページ末尾までスクロールしたうえで全画像の状態を検査しても、読み込み失敗は0件でした。遅延読み込みを「設定しているのに効いていない」という実装の不整合が、LCP に対して極めて大きなボトルネックとなっていたことがこの結果から読み取れます。

ボトルネック2: CSSの別ドメイン配信 ​

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

観察された状況 ​

レンダリングブロックリソース（全ての読み込みが完了するまでページの描画が停止するリソース）である CSS のうち5本が、HTMLとは別のサブドメイン cdn.3ple.jp から配信されていました。同じ会社のドメインでも、ブラウザにとっては別オリジンであり、DNS 解決や TLS ハンドシェイクといった接続確立が別途必要になります。描画の開始が、この接続確立のコストを待つ構造になっていました。

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

5本の CSS の配信元を www.3ple.jp に変更し、HTMLと同一オリジンから配信する状態を作りました。背景画像の参照が壊れないよう、CSS 内の相対パス111件は絶対URLに変換しています。

シミュレーション結果 ​

FCP の変化は0.1秒にとどまった一方で、Lighthouse のシミュレーションでは LCP が3.9秒、SI が1.1秒短縮される結果が得られました。レンダリングブロックリソースの取得元が1オリジンに集約されたことで、その後に続く画像の取得開始も早まったと考えられます。静的ファイルをサブドメインに分ける構成は HTTP/1.1 時代の同時接続数制限への対策として広まったものですが、この構成では接続確立のコストが表示速度に無視できない影響を与えていたことがこの結果から読み取れます。

ボトルネック3: Google Fontsの多段読み込み ​

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

観察された状況 ​

Google Fontsから欧文フォントの Open Sans（ウェイト800）を読み込んでいましたが、このフォントが使われていたのは価格表示など3つの CSS ルールだけでした。それにもかかわらず、元の状態では親 CSS の中の @import から読み込まれ、「HTML → 親 CSS → Google Fontsの CSS → フォント本体」という4段の読み込みチェーンになっていました。加えて、fonts.googleapis.com と fonts.gstatic.com という2つの別オリジンへの接続確立も必要です。@import を <link> 要素に移して3段にした後も、Lighthouse はこのフォントの CSS をレンダリングブロックの最大要因（551ms。元の状態では536ms）として指摘しており、チェーン全体はページ内で最長のクリティカルチェーン（1,906ms）の起点になっていました。このシミュレーションはフォントの見た目が変わることを前提に行いました。

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

Google Fontsを読み込む <link> 要素を削除し、CSS の font-family 指定はそのまま残して、デバイスの sans-serif フォントにフォールバックさせた状態を計測しました。ファーストビューでの見た目の差分は0.66%で、価格の数字などの字形がわずかに変わる程度です。

シミュレーション結果 ​

総合スコア はすでに100に達していたため数値は動きませんが、FCP が0.6秒から0.1秒へ、LCP が0.9秒から0.3秒へと大きく短縮される結果が得られました。3つのルールでしか使われていない1種類の欧文フォントであっても、別オリジンをまたぐ多段の読み込みチェーンを作ることで、ページ全体の表示開始を律速していたことが読み取れます。価格表示のデザインとしてフォントを使いたい意図は理解できますが、その影響の大きさはこの数値に表れています。

まとめ ​

サンプル百貨店（3ple.jp）の表示速度を観測したところ、総合スコア 65、LCP 14.8秒、SI 11.1秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（121リクエスト・約2.1MB）: 除去によって SI が6.7秒短縮し、TBT が0msに。タグマネージャー1つの除去だけで SI が8.5秒短縮しました。A/Bテストタグがページを隠していたことで、CLS のずれが計上されていなかったことも分かりました。
• カルーセル画像の遅延読み込みの空振り（456枚中24枚のみ表示）: data-src 形式への書き換えで LCP が7.0秒短縮し、総合スコア が74から100へ。本研究で最大のボトルネックでした。
• CSSの別ドメイン配信（5本）: 同一オリジン化で LCP が3.9秒、SI が1.1秒短縮しました。
• Google Fontsの多段読み込み（3ルールのみで使用）: 除去によって FCP が0.5秒、LCP が0.6秒短縮しました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は65から100へ、LCP は14.8秒から0.3秒へと変化しました。特に遅延読み込みの設定が空振りしていたという、新しい仕組みの追加ではなく既存の仕組みの不整合が LCP の最大の要因だったことが、この一連のシミュレーションによって確認できた形です。