「fifth store」トップページの表示速度ボトルネック研究

「fifth store（フィフス ストア）」は、プチプラのトレンドファッションを扱うレディースファッション通販サイトです。カジュアルからフェミニンまでのスタイルを、季節のトレンドアイテムと定番商品の両面から手頃な価格で展開しています。スマートフォン向けのトップページには、画面の約6割を占めるメインビジュアルのカルーセル、カテゴリアイコン、新着商品（NEW ARRIVAL）のスライダーなどが並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は84でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）はともに2.6秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は11.2秒で、SI は「低速」の範囲に入っていました。TBT（Total Blocking Time = メインスレッドのブロック時間）は16ms、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.000です。解消シミュレーション後は 総合スコア が100に達し、LCP・FCP・SI はいずれも約0.5秒まで変化しました。

数値は、記録したページを同一条件で再生して計測したシミュレーションの値です。解消シミュレーション後に残る LCP 0.5秒のうち約89%（約0.43秒）は、HTMLのサーバー応答時間（TTFB）でした。

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

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

観測時点では画面が2秒以上白いままなのに対し、解消シミュレーション後は約0.5秒でメインビジュアルを含むファーストビューが表示されています。

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

詳細レポート

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

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

観測時点のページの全566リソースのうち、サードパーティータグ由来のリソースは388件（約7割）でした。なお、公開CDNから読み込まれていた jQuery と、Webフォント（Adobe Fonts・Google Fonts）は描画に直接関わる資源として除去の対象外とし、サイト固有のボトルネックとして扱いました。

Google Tag Managerを経由せずに設置されているタグ ​

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

visumo、Facebook Pixel、Yahoo!広告は、HTMLへの直書きと Google Tag Manager 経由の両方で同じスクリプトが読み込まれていました。

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

指標を大きく動かしたのは2つの段階でした。関連リソース125件・24MB超（主に動画）を読み込んでいた visumo の除去では、LCP・FCP が2.6秒から1.6秒へ、総合スコア が84から90へ変化しました。ただし観測時点の計測では、描画処理が終わってから画面への反映が約1秒遅れて記録される現象が毎回起きており、この1.0秒の全てが visumo 単独の影響とは言い切れません。もう1つは Google Tag Manager で、配下のタグ（関連リソース105件）がページの表示後も描画やスクリプト実行を続けていたことが要因と考えられ、除去によって SI は10.5秒から6.1秒へ変化しました。そのほかの16種は、単独では計測の揺らぎの範囲でした。

サードパーティータグを全て除去した状態では、総合スコア は84から94へ、LCP・FCP は2.6秒から1.5秒へ、SI は11.2秒から6.0秒へ変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルのあることが読み取れます。

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

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

ボトルネック1: Adobe FontsのCSSが最初の描画を止める ​

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

観察された状況 ​

サードパーティータグを除いた時点でも、HTML自体は約0.44秒で届いているのに、FCP は約1.5秒まで遅れていました。最初の描画に必要な CSS は3本ありました。自社の style.css に加え、英数字の見出しや価格に使われている欧文フォント futura-pt を配信する Adobe Fonts の CSS（use.typekit.net/ivc7faq.css）と、その中の @import で読み込まれる別の CSS（p.typekit.net/p.css）です。後の2本は別ドメインから配信され、しかも @import によって直列に読み込まれるため、3本が揃うのは約0.69秒でした。

本研究の計測環境では、描画に必要な CSS の揃う時刻が約0.5秒より前なら最初の描画は約0.5秒に、それより後なら約1.5秒まで持ち越される、という段階的な挙動が見られました。先に試した3つのシミュレーション（未圧縮だった p.css の GZIP 圧縮、Adobe Fontsの CSS の同一ドメイン配信、@import を link 要素に置き換えた並列化）では、CSS が揃う時刻は約0.69秒から約0.56秒へ早まったものの、この区切りを越えられず FCP は変わりませんでした。

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

同一ドメインに移した Adobe Fonts の CSS 2本の内容を、元の読み込み順のまま style.css の先頭に連結し、HTMLから2本の link 要素を削除しました。描画に必要な CSS は自社の1本だけになります。比較のため、Adobe Fonts の CSS を元の配信元のまま非同期で読み込むシミュレーションも行っています。

シミュレーション結果 ​

FCP は1.6秒から0.5秒へ変化しました。非同期で読み込んだ場合も FCP は0.5秒で、ほぼ同じ結果でした。

一方で、CLS は0.000から0.844へ、総合スコア は94から71へ下がっています。観測時点の CLS が0.000だったのは、レイアウトシフトが起きない作りだったからではなく、最初の描画が約1.5秒と遅く、それ以前に起きたレイアウトの変化が数えられていなかったためでした。描画が早まったことで、メインビジュアル画像の width・height 属性の欠落、JavaScript で後から挿入される高さ80pxのスマートバナー、JavaScript で挿入されるスライダーの基本レイアウト CSS という3つのレイアウトシフトの要因が表面化しました。これら3つを解消するシミュレーションを続けて行うと、CLS は0.000に戻り、総合スコア は95になりました。

欧文フォントの CSS は1本あたりの容量こそ小さいものの、別ドメインと @import の2段構えで描画の経路に入っていました。このシミュレーション結果から、Adobe Fonts の CSS が最初の描画を約1秒遅らせていたこと、そしてその遅さがレイアウトシフトを覆い隠していたことが読み取れます。

ボトルネック2: メインビジュアルが初期化まで透明 ​

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

観察された状況 ​

FCP に関するボトルネックを解消した時点で、FCP は0.47秒、LCP は0.72秒でした。LCP 要素は、メインビジュアルのカルーセルの1枚目の画像です。読み込みの経過を調べると、LCP画像はHTMLの到着直後に要求され、0.52秒には取得を終えていました。それにもかかわらず、描画されたのは0.72秒で、約0.19秒の描画待ちが生じていました。

原因は、サイトの CSS にある .swiper { opacity: 0; } というルールでした。カルーセルライブラリ Swiper の初期化が終わって .swiper-initialized が付くまで、カルーセル全体を透明にしておく指定です。初期化前のちらつきを防ぐためによく使われる書き方ですが、初期化はライブラリを含む JavaScript（約196KB）の到着と評価を待ってから行われるため、取得済みのLCP画像も、その間は画面に現れていませんでした。

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

メインビジュアルのカルーセルだけを初期化前から表示する CSS のルール（.main-visual.swiper { opacity: 1; }）を1行追加しました。先のボトルネック1で表面化したレイアウトシフトの解消として、スライダーの基本レイアウト CSS をサイトの CSS に先行して記述していたため、初期化前でも1枚目は初期化後と同じ位置と大きさで表示されます。

シミュレーション結果 ​

描画待ちは194msから34msへ縮まり、LCP は0.72秒から0.55秒へ変化しました（約23%の短縮）。CLS は0.000のままで、ファーストビューの見た目の差分も0%でした。

続いてメインビジュアル13枚を WebP に変換するシミュレーションも行い、LCP画像は約166KBから約27KBへ、LCP は0.49秒まで変化しています。画像の取得を速めるより先に、取得済みの画像を見せるまでの待ち時間が LCP を押し上げていたことになります。このシミュレーション結果から、初期化を待つ透明の指定が、LCP画像の表示を遅らせていたボトルネックであったことが読み取れます。

ボトルネック3: カルーセルの自動再生で表示が完成しない ​

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

観察された状況 ​

ボトルネック1と2を解消した時点で、LCP は0.49秒、FCP は0.48秒と十分に早くなっていましたが、SI だけが5.4秒のままで、総合スコア は96にとどまっていました。

SI は、計測の最後のフレームを「完成した画面」とみなし、そこへ近づく速さを評価します。このページでは、画面の約6割を占めるメインビジュアルのカルーセルが3秒ごとに切り替わり続けるため、計測の最後（約10.7秒）まで画面が最終状態と一致せず、読み込みが終わった後も表示が完成していないと評価されていました。自動再生を完全に止めた比較用のシミュレーションでは SI が0.5秒になり、SI の減点のほぼ全てが自動再生によるものだったことが確認できます。

ファーストビューで複数のキャンペーンを順に見せたいという意図は、ファッション通販のトップページとしてよく理解できます。

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

カルーセルの初期化直後に自動再生を止め、ユーザーの最初の操作（タッチ、スクロール、ホイール、キー入力）の後に自動再生を始めるように変更しました。切り替えの間隔（3秒）は変えていません。このシミュレーションは「何も操作しないうちはスライドが自動で切り替わらない」という挙動の変化を前提に行いました。

シミュレーション結果 ​

SI は5.4秒から0.5秒へ変化し、総合スコア は100に達しました。LCP・FCP は変わっていません。

この変化は読み込みそのものが速くなったことによるものではなく、SI が読み込み後の画面の変化を未完成と評価する性質によるものです。それでも、ユーザーが最初のコンテンツを目にする時刻とは関係なく、カルーセルの自動再生が SI を約10倍に押し上げていたことになります。このシミュレーション結果から、ファーストビューのカルーセルの自動再生が SI に与えていた影響の大きさが読み取れます。

まとめ ​

fifth store のトップページの表示速度を観測したところ、総合スコア 84、LCP・FCP 2.6秒、SI 11.2秒という値が計測されました。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（388リソース）: 全て除去した状態では 総合スコア が84から94へ、LCP・FCP が2.6秒から1.5秒へ、SI が11.2秒から6.0秒へ変化。UGC・動画ウィジェットの visumo と、配下に多数のタグを抱える Google Tag Manager が主な要因でした。
• Adobe FontsのCSSが最初の描画を止める: 描画に必要な CSS を自社の1本にまとめることで、FCP が1.6秒から0.5秒へ変化しました。同時に、描画の遅さに隠れていたレイアウトシフト（CLS 0.844）が表面化しました。
• メインビジュアルが初期化まで透明: 初期化前から表示することで、LCP が0.72秒から0.55秒へ変化しました。
• カルーセルの自動再生: 自動再生の開始を最初の操作の後にすることで、SI が5.4秒から0.5秒へ変化しました。

このほか、メインビジュアル以外の画像の WebP 変換、未圧縮のまま配信されていた SVG スプライト（418KB）の圧縮と未使用アイコンの削除、画面外の画像の遅延読み込みなどのシミュレーションも行いました。今回の計測環境では指標の変化は揺らぎの範囲でしたが、自動再生の変更以降のこれらのシミュレーションで、初期表示の総転送量は2.89MBから1.32MBへ減っています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は84から100へ、LCP は2.6秒から0.5秒へ、SI は11.2秒から0.5秒へと変化しました。とりわけ、容量の小さな欧文フォントの CSS が別ドメインと @import を経由して最初の描画を約1秒遅らせていたこと、そしてその遅さが CLS を0.000に見せていたことは、個々の指摘を1つずつ見るだけでは見えにくいボトルネックでした。最終状態に残る LCP の大半はHTMLのサーバー応答時間で、これらの要素がこのページの表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。