「アットコスメショッピング」トップページの表示速度ボトルネック研究

コスメ・美容の総合サイト @cosme（アットコスメ）の公式通販サイトです。多数のブランドの化粧品を扱い、口コミやランキングを参照しながら商品を購入できます。トップページには、キャンペーンバナーやランキング、新作・レコメンドのカルーセルが縦に長く並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点では、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が3.4秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が12.8秒と、画面の完成までに長い時間がかかっていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）、TBT（Total Blocking Time = メインスレッドのブロック時間）、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は観測時点から良好な値でした。表の数値は複数回の計測の中央値で、スクリーンショットは単回の実行のため、表示がわずかに異なります。

ただし、本研究の計測環境では、Lighthouse のシミュレーション値にネットワークの遅延が反映されず、HTMLのサーバー応答時間（約1.27秒）も含まれません。サードパーティータグの除去の途中から FCP・LCP は0.1秒前後の値になっており、総合スコア の100もシミュレーション上の値です。そこで本研究では、計測中にブラウザが実際に描画した時刻（以下、実測値）もあわせて観測しました。

実測の LCP は2.5秒から0.3秒へ、読み込み完了は28.6秒から0.3秒へと変化する結果が得られました。なお、この解消シミュレーション後の値には、HTMLと決済用iframeのサーバー応答をそれぞれ0.2秒に短縮した場合のシミュレーションが含まれます。サーバー側の変更を含めない時点では、実測の FCP は1.3秒でした。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。通信速度10.5Mbps、CPU 4倍の速度低下という条件で撮影した動画です。

観測時点では最初の描画までに時間がかかり、描画後もレコメンドの商品欄が長い間空のまま残ります。30秒経っても読み込みは完了しませんでした。解消シミュレーション後は読み込み開始の直後にファーストビューが表示されます。

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

詳細レポート

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

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

観測時点のページの全476リソースのうち、サードパーティータグ由来のリソースは299件（約6割）を占めていました。14種類のタグを1つずつ除去し、その影響を観測しました。

HTMLに直接記述されていたタグは次のとおりです。

タグマネージャーを経由して読み込まれていたタグは次のとおりです。

GTMのコンテナが3つ入れ子になった構造でした。段階的に除去した際の指標変化は次のとおりです。

（実測値の「-」はその段階で記録していない項目です）

大きな変化が観測されたのは、描画を止める同期読み込みのタグでした。検索窓の直後で読み込まれる NaviPlus サジェストは、その後ろにある LCP 画像（ファーストビューのキャンペーンバナー）の発見を遅らせており、除去によって 総合スコア が81から91へ変化しました。head内の iax.js と sna.js は並列に読み込まれていたため、両方を除去した段階で初めて実測の LCP が1.9秒から1.4秒へ変化しています。SI が大きく下がったのは、描画後も大量の処理と通信を続けていたGTMゾーン配下のタグと、展開後で約2.4MBの定義を持つGTMコンテナ本体を除去した段階でした。

サードパーティータグを全て除去した状態では、総合スコア は82から100へ、SI は12.8秒から0.7秒へ、実測の LCP は2.5秒から1.4秒へと変化し、転送量は10.63MBから4.03MBへと6割以上減る結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

前述のとおり、サードパーティータグの除去後は Lighthouse のシミュレーション値がほぼ一定（総合スコア 100）になりました。そのため以下では、実測値や、Lighthouse のモバイル設定と同じCPU 4倍の速度低下をかけたブラウザでの計測値（以下、CPU 4倍の計測）をあわせて示します。

ボトルネック1: HTMLのサーバー応答が遅い（TTFB 1.27秒） ​

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

観察された状況 ​

HTMLの TTFB（Time To First Byte = サーバーが応答を返し始めるまでの時間）が約1.27秒かかっていました。サードパーティータグを除去した後の実測 FCP は約1.4秒で、その92%をこのサーバー応答が占めていたことになります。

HTMLはCDN（CloudFront）のキャッシュを通らない動的なページとして配信されていました。同じCDNから配信される静的ファイルの TTFB は中央値38msだったことから、約1.2秒はほぼオリジンサーバーでのページ生成の時間と考えられます。

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

HTMLのサーバー応答時間を1,266msから200msに短縮した状態を作りました。フロントエンドの変更だけでは実現できず、サーバー側の改修を前提としたシミュレーションです。

シミュレーション結果 ​

サーバー応答の短縮量がほぼそのまま FCP・LCP の短縮になる結果が得られました。比較のため、この前段で行ったフロントエンド側の解消シミュレーション5件（head内のスクリプト15個の移動、CSS 3本のインライン化など）では、CPU 4倍の計測での FCP の変化は合計で約0.06秒にとどまっていました。サードパーティータグを除いた後の最初の描画を決めていたのは、ほぼサーバー応答の時間だったことが、このシミュレーション結果から読み取れます。本研究で最も大きな影響が観測されたサイト固有のボトルネックです。

ボトルネック2: 決済用iframeが読み込み完了を約26秒遅らせる ​

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

観察された状況 ​

決済トークンを取得するための非表示のiframe（display: none）が、DOMContentLoaded の時点で作られていました。このiframeのサーバー応答（payment.cosme.net）には約25.5秒かかっており、ブラウザはiframeの読み込みが終わるまで load イベントを発生させないため、ページの読み込み完了が約26秒遅れていました。

load を待って初期化されるレコメンドのカルーセルも、この間は操作できない状態でした。画面には表示されない要素が、ページ全体の読み込み完了を左右していたことになります。

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

iframeを作成する処理の呼び出しを、load イベントの後に移しました。iframeの作成、トークンの受信、Cookieの保存という処理の内容そのものは変えていません。

シミュレーション結果 ​

呼び出しのタイミングを1か所変えただけで、読み込み完了が約26秒から約0.3秒へと変化する結果が得られました。レコメンドのカルーセルの初期化も、約26秒後から0.5秒以内に早まっています。

総合スコア にはまったく表れない一方で、ページの読み込み完了とそれに依存する処理のすべてが、1つの非表示のiframeの応答に引きずられていたことが読み取れます。なお、決済用iframeのサーバー応答自体を0.2秒に短縮した場合のシミュレーションでは、決済トークンが揃うまでの時間も約26秒から約0.7秒へと変化しました。

ボトルネック3: レコメンドカルーセルが読み込み完了（約27秒後）まで非表示 ​

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

観察された状況 ​

サードパーティータグ除去後の Lighthouse の CLS は0.005と小さな値でした。しかし、Lighthouse が観測するのはページ先頭の表示範囲だけです。読み込み中にページをスクロールした状態で観測すると、初期画面の外で最大0.583のレイアウトのずれが起きていました。

このページのカルーセルは、CSSで初期状態を display: none にしておき、JavaScriptによる初期化の時点で表示する作りでした。なかでも「いま売れている商品」「メーカー新発売アイテムPICK UP」のレコメンドカルーセルは load イベントで初期化されるため、前述の決済用iframeの影響で（HTMLのサーバー応答を短縮する前の時点で）約27秒間は商品が1つも見えず、27秒後に突然出現して下のコンテンツを押し下げていました。

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

初期化の前から、初期化後と同じ先頭3件の商品を表示するCSSに変更しました。4件目以降だけを初期化まで非表示にしています。

シミュレーション結果 ​

読み込み中に指定の位置までスクロールして観測した CLS の最大値です（画面サイズは Lighthouse と同じ412×823、CPU 4倍の計測）。

Lighthouse の値には一切表れないずれが、スクロールしたユーザーの画面では0.1（Core Web Vitals の良好の基準）を大きく超えていたことが分かります。同じ構造を持つPICK UPブランドのカルーセル（スクロール位置1,500px）でも、初期化前から1枚目を表示するシミュレーションで CLS が0.139から0.000へ変化しました。CLS に関する5件の解消シミュレーションを重ねると、4つの観測位置すべてで CLS は0になっています。

このずれは、読み込み完了が約27秒遅れていたことで、ページを開いてから数十秒後という想定しにくいタイミングで起きていました。ボトルネック2と組み合わさることで影響が増幅されていた点が、このサイトに特徴的な構造です。

まとめ ​

アットコスメショッピングのトップページを観測したところ、総合スコア は82、SI は12.8秒で、画面の完成までに長い時間がかかっていました。観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（14種類・299リソース）: 全て除去した状態で 総合スコア が82から100へ、SI が12.8秒から0.7秒へ変化。特に同期読み込みの検索サジェストの除去だけで 総合スコア が10ポイント変化しました。GTMのコンテナは3つ入れ子になっていました。
• HTMLのサーバー応答（約1.27秒）: 0.2秒に短縮するシミュレーションで、実測の FCP・LCP が約1.0秒短縮。サードパーティータグを除いた後の最初の描画の9割以上を占めていました。
• 決済用iframeの応答待ち: iframeの作成を load の後に移すだけで、読み込み完了が約26秒から約0.3秒へ変化しました。
• 読み込み完了まで非表示のカルーセル: 初期画面の外で最大0.583のレイアウトのずれを生んでいました。カルーセルの初期化前の表示をCSSで確保するなど、3件の対処を重ねたシミュレーションでは、このずれが0になりました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は82から100へ、実測の LCP は2.5秒から0.3秒へ、読み込み完了は28.6秒から0.3秒へと変化しました。

このサイトの研究で特徴的だったのは、影響の大きかったボトルネックの多くが Lighthouse のスコアには表れにくいものだったことです。サーバー応答の時間はこの計測環境のシミュレーション値に反映されず、決済用iframeによる読み込み完了の遅れやスクロール後のレイアウトのずれも、総合スコア の上では変化がありませんでした。スコアの外側で表示速度を左右していた要因の大きさが、実測値と追加の計測によって確認できた形です。