「ア ハッピー マリリン」トップページの表示速度ボトルネック研究

ぽっちゃり体型の女性に向けた、大きいサイズのレディース服の通販サイトです。Mサイズから10Lサイズまでのサイズ展開で、トップスやワンピース、ボトムス、アウターから下着・フォーマルまでを取り扱っています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア は67から100へ、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は10.3秒から1.5秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は8.5秒から1.6秒へと変化するシミュレーション結果が得られました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も1.0秒から0.5秒へ短縮されています。TBT（Total Blocking Time = メインスレッドのブロック時間）と CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は、観測時点からほぼ0でした。

ページが読み込むリソースの量も大きく変化しています。

本研究の計測は、ページを再生する環境の回線に帯域制限をかけずに実施しました。そのため、転送量の削減は Lighthouse の指標にはほとんど表れていません。また、Lighthouse の指標は実際の描画時刻ではなく、ネットワークの依存関係から再計算したシミュレーション値です。このページでは、HTML文書の受信完了（約0.49秒）より前の時刻を FCP として記録する場面もありました。サードパーティータグを除去した後の FCP の解消シミュレーションの過程では、実際の描画時刻に近い値（observed値）の FCP は約2.6秒から約1.6秒へ変化しています。

後述するとおり、総合スコア はサードパーティータグを除去した時点で100に達しています。そのため、サイト固有のボトルネックについては、スコアではなく指標の中央値やレイアウトシフトの発生率の変化で影響を示します。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画の計測では、転送量は7.81MBから1.27MBへ、読み込み完了までの時間は18.51秒から2.14秒へと変化しました。観測時点では、解消シミュレーション後に比べて描画の始まりが遅く、読み込み完了まで長く通信が続きます。

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

詳細レポート

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

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

オリジナルページの全362リソースのうち、サイト固有のリソースは124件（約3割）、サードパーティータグ由来のリソースは238件（約7割）を占めていました。タグの多くはHTMLに <script> として直接書かれておらず、ECプラットフォームがURLエンコードしたHTML文字列を実行時に注入する方式で設置されていました。3つのタグマネージャーのうち1つだけでも、広告・DMP・SNS計測・Cookie同期が連鎖し、143リクエスト・67ホストに達しています。

タグマネージャー・計測・接客系のタグ ​

広告・DMP系のタグ ​

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

タグを1つ除去するたびに LCP が素直に短くなるわけではありませんでした。重いタグが消えて帯域が空くと、残ったタグ群のリクエストが前倒しで始まり、ページ本来のコンテンツがかえって後回しになるためです。最後のタグを除去した段階で、LCP は8.0秒から1.4秒へ一気に収束しました。個々のタグの重さよりも、サードパーティーの JavaScript による飽和状態そのものがボトルネックになっていたことが読み取れます。

アンチフリッカーのタグを除去した段階で CLS が0.815に跳ね上がったのは、新たなずれが生じたためではありません。このタグは最大2秒間ページ全体を visibility: hidden にしており、見えない間のレイアウトシフトは CLS に計上されません。元から存在したずれが、除去によって表に出てきたことになります。

サードパーティータグを全て除去した状態では、総合スコア は67から100へ変化し、LCP は10.3秒から1.4秒へ、SI は8.5秒から2.0秒へ、転送量は11.10MBから4.92MBへと変化する結果が得られました。どの段階でもファーストビューの見た目の差分は0%でした。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

この時点で 総合スコア はすでに100に達しており、LCP やレイアウトシフトの値は計測のたびにばらつきます。そのため、以下のシミュレーション結果の多くは、20回計測の中央値や、大きなずれが発生した回の割合で示しています。

ボトルネック1: CSSが8枚に分割して配信されている ​

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

観察された状況 ​

このページは、描画をブロックする CSS を8枚に分けて、HTMLとは別のドメインから配信していました。HTML文書の受信は約0.49秒で完了しますが、その直後に3枚の CSS とレコメンド用の JavaScript がほぼ同時に要求され、3枚の CSS は完了まで約0.94秒かかっていました。1本ずつが遅いのではなく、同時に要求された4本が帯域を奪い合っている状態です。CSS の転送量59.7KBのうち87%は、このページで使われていないルールでした。

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

未使用ルールの削除とHTMLと同じドメインからの配信を行ったうえで、8枚の CSS を読み込み順を保ったまま1枚に結合した状態を計測しました。ファーストビューの見た目の差分は0%でした。

シミュレーション結果 ​

FCP の中央値は約半分になりました。解消後の0.2秒はHTML文書の受信完了より前の値で、前述のシミュレーション値の特性が表れた数字です。未使用ルールの削除と同一ドメイン化を含む FCP まわりのシミュレーション全体では、observed値の FCP は約2.6秒から約1.6秒へと、およそ4割短縮されています。

注目したいのは、それまで計測の1〜2割で発生していた CLS 0.4前後の大きなずれが、結合後は20回中0回になったことです。CSS を8枚に分けていた間は、初回描画のタイミングが CSS の届き方に左右され、回ごとにぶれていました。そのため、描画とカルーセルの初期化の順序も時々入れ替わっていました。1枚にまとめたことで到着のタイミングが揃い、この競合が起きなくなったと考えられます。分割された CSS が、描画の遅れと表示の不安定さの両方に影響していたことが読み取れます。

ボトルネック2: カルーセルの高さがJavaScriptの初期化まで定まらない ​

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

観察された状況 ​

サードパーティータグを除去した時点で、公式の計測値の CLS は0.000でした。ただし前述のとおり、アンチフリッカーを外した段階では0.815が記録されており、通信のタイミングをずらすストレス計測では最大1.107のずれが再現されていました。

原因は、ページ最上部にある2つのカルーセル（7枚と9枚）でした。カルーセルの CSS には高さや overflow の指定がなく、スライダーライブラリが JavaScript で初期化するまで、スライドは縦一列に積み上がります。初期化されると1枚分の高さに縮むため、その下のコンテンツ全体が約1,640px跳ね上がっていました。

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

初期化前の状態にだけ効く CSS（.slick-initialized クラスが付く前のトラックを横並びにし、画像に aspect-ratio を与える）を <head> に追加した状態を計測しました。初期化後の見た目は変わらず、ファーストビューの差分は0%でした。効果を確かめるため、通常の計測に加えて、スライダーを初期化する JavaScript の到着を3秒遅らせてずれを再現する「ストレス計測」も行っています。

シミュレーション結果 ​

公式の計測値は解消前から0.000のため変化していませんが、ストレス計測では最大1.107のずれが0.006まで小さくなりました。観測時点の CLS が0だったのは、アンチフリッカーによる隠蔽と、JavaScript の到着タイミングの偶然によるものです。ストレス計測で再現される大きなずれの原因は、初期化前のカルーセルのレイアウトを定めていない構造にあったと読み取れます。

ボトルネック3: スライダーがHTMLのパース中に同期で初期化される ​

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

観察された状況 ​

ページ中ほどのスライダーを初期化するスクリプトが、$(function(){}) などで読み込み完了を待たず、HTMLのパース中に直接 .slick() を呼んでいました。初期化の際に強制同期レイアウトが発生し、メインスレッドを占有して最初の描画の機会を後ろへ押しやっていました。

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

初期化の処理を setTimeout(..., 0) で包み、次のタスクに切り出した状態を計測しました。スライダーの動き出しがわずかに後ろへずれることを前提としたシミュレーションです。

この変更は、メインスレッドの最長タスクを見ていた段階では、最長タスクが50msを超える回が増えたため一度見送っています。その後、別のカルーセルの連続初期化を分割して最長タスクが約25msまで短くなったことで状況が変わり、あらためて計測しました。

シミュレーション結果 ​

FCP の中央値は約半分になり、単一のシミュレーションとしては最大級の変化でした。この時点では大きなレイアウトシフトの発生率が10%から20%になりましたが、統計的に意味のある差ではなく、その後のボトルネック1の解消で0%になっています。スライダー1つの初期化のタイミングが、最初の描画を大きく遅らせていたことが読み取れます。

まとめ ​

ア ハッピー マリリンのトップページでは、次のようなボトルネックが表示速度に影響していました。

• サードパーティータグ（238リソース）: 除去によって 総合スコア が67から100へ、LCP が10.3秒から1.4秒へ変化。タグ単体の重さよりも、多数のタグによる飽和状態がページ本体の読み込みを押し出していました。アンチフリッカーは CLS 0.815のずれを隠していました。
• 8枚に分割されたCSS: 1枚への結合によって FCP の中央値が約半分に。計測の1〜2割で起きていた大きなレイアウトシフトも0%になりました。
• 初期化前に高さが定まらないカルーセル: CSS で初期化前のレイアウトを固定することで、ストレス計測の CLS が1.107から0.006へ変化しました。
• HTMLのパース中に同期で初期化されるスライダー: 初期化を次のタスクに切り出すことで、FCP の中央値が0.9秒から0.4秒へ変化しました。

この他にも、LCP 画像に優先度の指定がないことで画像のリクエストが約0.77秒待たされていたこと、観測時点の画像の転送量が5.83MB（タグ由来の画像を含む）に達しており、WebP変換・適正サイズ化・遅延読み込み・重複の解消によってシミュレーションでは1.35MBへ変化したことなどが観測されています。後者は帯域制限のない今回の計測では指標にほとんど表れませんが、実際のモバイル回線では読み込み時間に直結する量です。

一方で、HTML本体のサーバー応答時間（約0.49秒）や、非圧縮1.68MBの単一の JavaScript バンドル、カルーセルの初期化に依存する LCP 要素の描画待ち（約0.8秒）は、既存のリソースの変更ではシミュレーションできず、今回の結果には含めていません。解消シミュレーション後も、実際のユーザーの体感速度を左右する要因として残っていることが観測されました。