「ベルメゾンネット」トップページの表示速度ボトルネック研究

株式会社千趣会が運営する通販サイトです。ファッションやインテリア、子供服、ディズニーグッズ、コスメまで、季節の暮らしにまつわるアイテムを幅広く取り扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は3.4秒から0.2秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は17.9秒から0.2秒へと大きく変化しました。CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）も0.805から0.000になっています。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）と TBT（Total Blocking Time = メインスレッドのブロック時間）は、観測時点ですでに小さな値でした。

なお、本研究は回線速度とCPU性能の制限（スロットリング）をかけない条件で計測しています。PageSpeed Insights の標準的なモバイル設定とは条件が異なるため、上の値はそのまま PageSpeed Insights の値になるものではありません。全段階を同じ条件で計測しているので、段階ごとの変化の比較には意味があります。

また、総合スコア は研究の途中で100に達したため、それ以降のボトルネックは、ブラウザで実際に計測した表示時間（以下、実測値）の変化で評価しています。後述するとおり、このページではスコアの算出値と実測値の間に大きな開きがありました。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。

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

詳細レポート

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

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

トップページを1回開くと350件のリクエストが発生し、そのうちサードパーティタグ由来のリクエストが198件（約6割）を占めていました。通信先のホストは、サードパーティ由来だけで123ホストにのぼります。

このページでは、タグマネージャーとBot検知の製品が自社ドメインのパス（/gtmgtg/、/akam/ など）から配信されていました。Lighthouse の third-party-summary 監査はこれらを第一者のリソースとして扱い、タグマネージャーの転送量を0.4KBとしか表示していません。実際には /gtmgtg/ と /sgtm/ の配下だけで6.61MBが配信されていました。

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

Google Tag Manager を除去するまでは計測が極めて不安定で、同じ状態を繰り返し計測しても 総合スコア が43〜71の間でばらついていました。途中の段階でスコアや LCP が上下しているのはこのばらつきによるもので、SI と FCP だけが一貫して短縮しています。Google Tag Manager の除去後はばらつきの幅が28点から4点に縮まっており、タグマネージャー経由で非同期に読み込まれる多数のタグが、実行のたびに違う順序で競合していたことがうかがえます。

サードパーティータグを全て除去した状態では、総合スコア は58から76へ、SI は17.9秒から1.0秒へ（約94%短縮）、LCP は3.4秒から1.1秒へ変化する結果が得られました。6種類のタグのいずれを除去しても、ファーストビューの見た目には1ピクセルの差も生じていません。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: カルーセルが初期化前に高さを持たない ​

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

観察された状況 ​

サードパーティータグを除去した時点で、このページの CLS は0.960でした。「良好」とされる0.1の約10倍にあたり、総合スコア を76で頭打ちにしていた要因です。

トレースのスクリーンショットを追うと、読み込み開始から約1.45秒の時点ではカルーセルの領域の高さがほぼ0で、約1.51秒の時点で本来の高さに広がり、下のコンテンツを一気に押し下げていました。このページのメインビジュアルとランキング商品のカルーセルは、jQuery プラグインの slick で作られています。slick は JavaScript による初期化が終わるまで要素に高さを与えないため、初期化の瞬間に領域が確定していました。ランキング商品のカルーセルでは、初期化後の高さは591pxです。

なお、メインビジュアルでは <picture> の <source> 要素に width / height がなく、モバイル向けに配信される縦長の画像（700×875）ではなく <img> 側の横長の比率（910×380）で領域が予約されていました。こちらを実寸に合わせたシミュレーションで CLS は0.952から0.777へ変化しており、残った0.777のほぼ全てがランキング商品のカルーセルに由来していました。

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

ブラウザでカルーセルの初期化前と初期化後の要素の位置と大きさを実測し、初期化後と同じ領域を初期化前から確保する CSS を追加した状態を計測しました。1枚目のスライドだけを表示し、ページ送りのドット行の高さもあらかじめ確保しています。指定はいずれもモバイル幅に限定しており、ファーストビューの見た目の差分は0%でした。

シミュレーション結果 ​

CLS は0.777から0.011へ、総合スコア は76から100へと変化しました。CSS の追加だけのシミュレーションで、本研究の中でも最も大きなスコアの変化が得られています。JavaScript で初期化するUIの、初期化を待つ間のレイアウトがページ全体のずれに直結していたことが読み取れます。

ボトルネック2: HTMLが返ってくるまで1秒以上かかる ​

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

観察された状況 ​

Lighthouse の算出上、FCP は0.1秒前後で満点でした。ところが、サードパーティータグを除去した時点の、ブラウザで実際に計測した FCP は約1.25秒で、その86.5%にあたる約1.08秒が、サーバーからHTMLが返ってくるまでの待ち時間（TTFB）でした。HTMLが届くまでブラウザは何もできないため、CSS や JavaScript をどれだけ整えても、その効果はこの待ち時間の後ろでしか現れません。

レスポンスヘッダーを見ると、server-timing にはCDNとオリジンの処理時間として合計65msしか記録されていません。一方で、CDNのキャッシュはミス（cdn-cache: desc=MISS）となっており、cache-control: no-store が指定され、Bot検知用とセッション用を合わせて17本の set-cookie が返されていました。

Lighthouse は、ページ全体で観測された最も短いサーバー応答時間をオリジンの代表値として扱います。このページではHTMLの約1.08秒が外れ値として扱われ、FCP のスコアには反映されていませんでした。同じレポートの server-response-time 監査は0点（「Root document took 1,070 ms」）であり、スコアと監査の結果が食い違っていました。

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

記録したHTMLの応答時間を1,070msから100msに書き換えて計測しました。100msは、ヘッダーから読み取れたCDNとオリジンの処理時間（65ms）にネットワークの往復を加えた値です。これは記録したレスポンスの応答時間を書き換えたシミュレーションであり、実際のサーバーには手を加えていません。

シミュレーション結果 ​

スコアの算出上はほとんど動かなかった FCP が、実測値では1.2秒から0.2秒へと短縮する結果が得られました。server-response-time 監査も0点から満点に変化しています。スコアが満点であっても、ユーザーが白い画面を見ていた時間の大半がHTMLの応答待ちであったことが、この結果から読み取れます。

ボトルネック3: ファーストビューの画像がCDNにキャッシュされていない ​

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

観察された状況 ​

画像配信ドメインの応答時間を集計すると、はっきりと2つの山に分かれていました。

ファーストビューで使う画像だけが、同じドメインの中央値（34ms）の20倍以上の時間を要していました。画像265件のうち193件は cache-control: private の指定で、CDNでキャッシュされずオリジンまで取りに行く状態だったと考えられます。HTML配信ドメイン（www.bellemaison.jp）のレスポンスは server-timing: cdn-cache; desc=HIT を含む一方、画像配信ドメイン（pic2.bellemaison.jp）のレスポンスはこのヘッダーを一切含んでいませんでした。

サーバー応答時間のシミュレーションを行う前（サードパーティータグ除去直後、実測 LCP 約2.0秒）の内訳を分解すると、LCP 画像のサーバー応答待ちが約0.79秒（40.1%）を占めており、画像のデータを転送する時間は約0.03秒（1.3%）にすぎませんでした。HTMLの応答待ち（54.7%）と合わせると、LCP の94.8%がサーバーの応答待ちでした。

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

画像配信ドメインの185件のうち、応答時間が中央値の34msを超えていた80件を34msに書き換えて計測しました。34msは、同じドメインで実際に観測されている中央値です。ボトルネック2と同じく、記録したレスポンスの応答時間を書き換えたシミュレーションです。

シミュレーション結果 ​

スコアの算出上の LCP はまったく動きませんでしたが、実測値の LCP は0.9秒から0.3秒へと約65%短縮する結果が得られました。LCP 画像の取得にかかる時間は、計測の粒度以下まで縮んでいます。2回目以降の訪問では速く返る画像が、初回に訪れたユーザーには800〜900msの待ち時間になっていたことが、この結果から読み取れます。

ボトルネック2とあわせた2つのサーバー応答時間のシミュレーションと、その間に行った画像の最適化により、実測値の LCP は2.0秒から0.3秒へ変化しました。

まとめ ​

ベルメゾンネットのトップページは、観測時点で 総合スコア 58でした。研究の結果、次のようなボトルネックが表示速度に影響していたことが分かりました。

• サードパーティータグ（198リクエスト）: 除去によって SI が17.9秒から1.0秒へ変化。自社ドメインから配信されるタグマネージャーとBot検知が含まれ、Lighthouse の監査ではその大きさが見えにくい状態でした。
• 初期化前に高さを持たないカルーセル: 初期化後と同じ領域を CSS で確保することで、CLS が0.777から0.011へ、総合スコア が76から100へ変化しました。
• 1秒を超えるHTMLの応答待ち: 応答時間を100msにすることで、実測値の FCP が1.2秒から0.2秒へ変化。スコア上の FCP が満点のまま見過ごされていたボトルネックでした。
• CDNにキャッシュされないファーストビューの画像: 応答時間を同じドメインの中央値にそろえることで、実測値の LCP が0.9秒から0.3秒へ変化しました。

この他にも、jQuery 経由の同期 XHR が3段連鎖してスクリプトを読み込む構造や、同期で読み込まれる19本の外部スクリプトなどが観察されています。ただし、CSS・JavaScript・画像といったフロントエンドのボトルネックを解消し尽くした後も、残った待ち時間の大半はサーバーの応答待ちでした。このページの表示速度の上限はサーバーの応答時間で決まっており、しかもその影響は Lighthouse のスコアにはほとんど現れていなかったことが観測されました。